When one customer order goes to several suppliers, staff can end up typing the same information into multiple requests. A changed address or partial arrival then raises a difficult question: which document needs updating? The archived requirements establish direct supplier-to-site delivery and several suppliers working on one site. I therefore read the design around order lines, allocated quantities and fulfillment events, rather than a fixed pairing between one customer and one supplier.
Site, order, line and allocation are different records
A site supplies the business context. Customer orders belong within that context and contain product lines with requested quantities. Some or all of a line can be allocated to a supplier. In a synthetic example, ten units split into six and four create two allocations, while the customer order remains ten units. Keeping those relationships explicit prevents additional supplier documents from inflating the customer quantity.
An allocation can carry buying price, requested delivery date and destination as well as supplier and quantity. The customer selling price remains a separate value. Sharing a product identifier is not a reason to share the price. The design must also define which price appears on which outward document. Preventing internal costs from appearing on a customer statement begins with the data relationship, rather than relying on a visual layout to conceal an ambiguous value.
Group documents according to the request being made
The same supplier does not necessarily mean the same request. A different site, issuing business or delivery condition can require a separate document. Preserved working notes describe grouping within the same business context by supplier and requested delivery date. The useful unit is what can actually be requested together, not the number of tabs that happens to look tidy in an interface.
Saving a customer document again should not generate another supplier draft every time. Nor should editing the customer document silently overwrite a supplier request already confirmed and sent. The system needs conditions for updating an existing draft and conditions that stop automatic replacement once downstream history exists. Repeating an action also deserves an explicit check: two clicks should not become two business requests merely because the interface briefly stopped responding.
Dispatch and receipt describe different events
Copying ordered quantity directly into delivered quantity would make partial delivery impossible to explain. A supplier's dispatch report and a site's receipt confirmation are different evidence too. Attaching dispatch, receipt and return events to allocations makes fulfillment measurable. Present requested quantities and the relevant stage totals alongside each other instead of adding several descriptions of the same goods into one misleading total.
There are also several meanings of remaining. A quantity not yet allocated needs a purchasing decision. An allocated quantity not yet dispatched needs supplier follow-up. A dispatched quantity without confirmed receipt needs a delivery check. A single remaining badge hides those distinctions. Show which stage lacks evidence and provide a route to the relevant record, so the overview can lead to an actual next action.
More links are useful only when they are justified
Matching partner names, product names and nearby dates in older data does not prove a site relationship. Just as suppliers should not be fixed to customers without evidence, historical links should not be fixed through convenient guesses. An unresolved link can remain unassigned. Reusing information is valuable within relationships already established; otherwise automation can distribute one incorrect assumption across several documents faster than a person can notice it.
Review the structure with synthetic cases involving several suppliers, a split line, partial receipt, returns and changes after sending. Check that customer quantity does not grow and that previously sent versions remain available. This article compares dated design notes, selected code and inspection records; it does not establish the present delivery state of an operating site. The reason to put the site at the center is not simply to collect screens in one place. It is to make different documents and events refer to the same underlying piece of work.