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
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!
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.
My client has a company with the following structure:
The HO (HO)
The Manufacturing Plant (MF)
Other warehouses (OW)
Each of these branches has its own local warehouse as described, respectively.
The warehouse access rights should be distributed over these warehouses, as each stock keeper should only deal with his warehouse.
In Odoo Sales, each sales team member can be restricted to see only his leads.
However, in Odoo Warehouse, I cannot see such access rights.
Please help with your experience.
Add following record rule to warehouse
['|',('company_id','=',False),('company_id','child_of',[user.company_id.id])]
I hope this helps.
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