About Organization、Facility and ProductStore

Assuming a retailer with 100 physical stores, two online stores, and two distribution centers (a standard goods distribution center and a fresh food distribution center, respectively), the main business includes: online and offline retailing, centralized purchasing, physical stores ordering to distribution centers, distribution centers to physical stores allocation, inter-store transfers, and stocktaking.
How should we design the organizational structure for this client?
I think option one is:

  1. The distribution center is set as Organization, and the corresponding Facility is set according to the warehouse situation.
  2. The physical store and online store are set up as ProductStore, the physical store configures its own Facility, and the online store’s Facility should be the Facility associated with the distribution center

After designing the organizational structure in this way, online and offline retailing, centralized purchasing, and stocktaking can basically be supported, but how should the physical stores ordering to distribution centers, distribution centers to physical stores allocation , inter-store transfers be supported?
A. physical stores ordering to distribution centers: if use the current Order, how should I fill in the vendorPartyId and customerPartyId of the OrderPart?
B. Distribution center to store allocation: if you use the current Shipment, there are fromPartyId and toPartyId on that entity, while ProductStore does not have its own partyId
C. There is a similar problem with inter-store transfers: how to fill out the transfer order and transfer corresponding logistics documents

I wonder how people solve these kinds of problems?

1 Like

An organization is typically a company, department, or team in a company. What you describe with stores and distribution centers would be more of a facility than an organization.

I’m not sure why you would set a distribution center as an Organization. Is this for a vendor and customer party for orders?

This sounds more reasonable and thought out. Although it really depends on what your use case is, and what the assumptions the services make under the hood.

I believe that typically how this is handled is an internal ecommerce website that knows about the inventory of each facility, and allows selection of product with an amount, order creation, and shipping from one facility to another.

One potential for this is to have an hierarchical organization structure (separate from facilities) that each employee (and user account) is a part of. Each facility has an organization with the employees who’s parent facility is the overall business name. This assumes a 1-1 mapping of an employee to facility. Then when a user goes to the internal ecommerce website the facility is already known. An alternative is to have the employee select the facility, and the facility to ship move inventory to.

An important part of figuring out how to design software like this is to clearly define the roles and processes of the organization, and under what conditions does a given role need to perform this action. If you haven’t already, reading HEMP or these HEMP excerpts are a good starting point for solving these types of problems. If you’re interested, signing up for Coarchy could be exactly what you need to figure out a solution to this problem. It’s got a free trial for trying it out.

[Disclosure: I’m the primary owner of Coarchy.]

Thanks @michael very much!

Set distribution center as an Facility is no problem

I don’t know which Moqui Entity to support the order creation