Microsoft CRM 2015.. a great little customer management system, but why did do they leave suppliers out?
Anyway how do I create and manage suppliers using Dynamics CRM?
or do you need different software for that?
Cheers,
In previous versions I have created custom entities for Vendor and Supplier. Here are some of the setup I did, of course always depends on business needs.
1:N Supplier to Product relationship
Added fields for supplier details
1:N Contact to Supplier for POC at organization
1:N User to Supplier for POC within our organization
If you are not using the out of the box quote to order to contract process then you will need to accommodate for Product inventory and qty on hand limits.
Used Goals and Rollups to set minimum inventory levels and restock alerts
Make sure finance is involved in the design of this process as they may be particular about how reordering is handled. While users may want it automated there might be internal requirements, specifics on contracts with suppliers that require some additional review.
Created relationships for Contract and opportunity records
This was needed to improve reporting since you cannot report out on second tier relationships. For example - how many opportunities are coming related to this particular supplier who is delayed delivering. If the supplier relationship is not on the Opportunity record itself you cannot get to it.
These were the key items I thought mattered. There is always more, but you should not need to purchase an alternative supplier tracking software.
Related
I'm designing database for an mobile-based ecom platform.
Currently, the system have one and only one shop. The design for the database of the system has the tables below:
User
Product
Category
Review
Order
Now, I want to scale up the system so that it can support multiple shops. User can sign-up as a seller and create their own shop, manage their own products and orders.
How can I design such a database from the original database which was designed only for one shop?
I have two options in mind but I have no idea whether they will works or not:
For each record in the table, I add a field shopId that ref to the id of the shop it belongs to. Then I will index this field to increase query's performance.
For each shop, I create a new collection/table to store the data that belongs to it. For example: shop1_product, shop1_order,... are the tables i will create for the shop1.
Are the approach above valid? Is there any other better approach.
P/s: I'm using MongoDB, and the system doesn't require operations across many shops.
Thank you guys!
I am self-hosting Odoo 12 Community Edition (Configuring before uploading my Subscription Key). I am attempting to configure Point of Sales for two different companies, I noticed I can set the starting POS category for each company but what I'm trying to accomplish is to seperate the categories and products to only be available in their respective Points of Sale. I'm new to Odoo so I am not sure if this would have unintended consequences due to table relationships.
Any help would be much appreciated! Thank you
I need to implement a granular, hierarchical security to my dimensions and cubes (facts).
The requirement is that when the user connects to SSAS I want them to see the subset of data data which belongs to that particular tenant only.
On top of that, I need to be able to allow the user to interact with dimensions and facts she/he has the rights to. For example, if Manager A manages Person B and Manager C, who manages Person D, then when Manager A look at sales he/she needs to be able to see everybody down the hierarchy, including Manager C and Person D sales. But if that OLAP client is Manager C, then he/she only sees Person D's sales. This has to work recursively as any hierarchy (child-parent relationship) does.
My basic data set is comprised by:
Tenant
Customer
Employee (self referencing entity for sales reps, managers, supervisors, etc)
Supervisor (a many to many relationship entity that specifies additional managers to a particular employee), i.e., the Manager ID on the Employee table refers to the primary manager. If that person is managed by somebody else in addition, then this table gets populated.
Role (employee's role including their seniority level)
Sales
Promotion
as for the relationships, each Tenant has multiple Customers, Employees Roles, Promotions and Sales. My transactional database is normalized to the 3rd normal form and all tenants share the same database.
I tried to denormalize the structure to the best of my knowledge when creating the dimensions and facts. For example, I have the Tenant surrogate key in the Sales fact and about any other dimension. By the way, is that something you guys would recommend?
I have researched the web and I see different approaches of implementing this design, being:
Security Wise
factless fact table between Fact and Dimensions and user context set via USERNAME(). In my case I would have to map all Dimensions to Employees (with a primary key/foreign key approach) and add new measure groups, etc.
use the Default member and Allowed set with STRMEMBER on each Tenant attribute, setting Visual Totals to true.
Management Hierarchy
mostly add new dimension over a factless for each many-to-many I want to map
It looks like there is some overlap between the approaches but I am not sure how well this would perform, nor do I know if there are any other ways to implement this.
Note: our system is a product sold on the web, therefore I can't simply have one role for each Tenant, otherwise this would have been easier to solve.
Can somebody recommend an approach?
Cheers,
Robson
I'm trying to create a proper database layout for a project I'm working on, however I can't seem to work out which is best.
Basically the "app" is something where a User can be assigned to many Products, and a Product can be have many Customers.
From here, each Customer has a Service, which is specific to that Customer and Product.
A Service can have many Incidents, but an Incident can only be assigned to one Service.
A User can also have Incidents, but an Incident can only have one User.
Here is the two designs I have made for this:
http://i.imgur.com/ZcCFcdg.png
As you can see, the left design has a table specific tables for the Many-Many relationships, where as the right one has a overall pivot table for them all.
I see both of these methods working (in my head) - however since I'm not the best with this, are there any downsides to either of these methods? And do you see any problems I'll run into, in the future?
Also, is the right one even a proper way of doing it?
I'm also going to be using the Eloquent ORM.
Look up 'Third Normal Form'. This gives rules on how to design tables. You could take one or other of your current designs and apply the three rules to see where you get to.
I would say the one on the right is wrong: too much duplicate information, and unclear relationships. The one on the left is OK, but the two Many-Many tables are redundant. You know a Product and Customer are linked because it's in the Service table. You know a User and Product are linked because its in the Incident + Service tables.
Cheers -
After clarification, a User belongs to a Customer. In that case, add CustomerID to the User table - this is important data about the user and should be included. It will allow you to stop the User raising Incidents on Products not associated with the Customer.
This also will enable you to list the Products associated with the User via the Customer the User is associated with.
Further, the Customer should have it's ID on Product, and Service should have the ProductId, not the CustomerID, as the Service is associated with a Product and only with a Customer via the Product it is associated with.
I am building a POS system that support multi branches.
The system is going to support these features.
Each store should have a local database for it's own inventory list and invoice. (Local database to avoid internet failure).
There is a reporting DB that contains information of all shop (inventory, invoice, etc), the reporting DB can be async to shopDB.
Each shop contains a unique shop code to indentify the record ownership, also a part of key (to avoid issue with primary key).
Shop system can query Reporting DB for inventory list on other shop (customer can place an order, shop may query for full inventory list and get other branches ship them the inventory).
Currently I am building the system with Java, PostgreSQL and Cayenne, but I am open to change the DB or ORM tool in case there is any technology limitation.
I tried to read a lot with Replication and Clustering, but it doesn't appears to suit my need.
Any clues on what I should look for ? Or should I build the replication on app layer instead of DB layer ?
The thing that strikes me here is what happens when shop A sells inventory for shop B while shop B sells the same inventory?
why cant the application access other shops dbs?
have you read about federated databases - http://dev.mysql.com/doc/refman/5.1/en/federated-description.html
http://en.wikipedia.org/wiki/Federated_database_system