An ERP designed for many businesses can make it difficult to find the path one company actually uses. The purpose of this project was not to reproduce every existing menu. It was to remove unnecessary functions, add necessary connections and organize the system around the company's real work. Staff needed an understandable way to complete tasks, while the owner needed an understandable way to see the situation. I wanted the program to explain the workflow rather than requiring the business to adapt to a copied menu structure.
Direct delivery without warehouse stock is one concrete example of that choice. Removing a stock-balance function went together with adding site-based orders, supplier requests and receipt records. The following account uses that example to explain the starting point for a system customized to a company's work.
Staff and owners ask different questions of the same records
Staff need to know what to do next: which supplier should receive a request, whether a document was sent and which items still need receipt confirmation. The owner may first need unresolved work, amounts, site progress and differences requiring attention. Rather than entering the same facts twice, I approached the design as different views of the same records, organized around the reader's role and question.
A large total is not enough to make an owner overview useful. Sales and actual receipts, supplier requests and actual purchases, dispatch and site receipt have different meanings. Unknown amounts should remain visible, with a route to the records that require review. An intuitive system does not simply show less information. It gives the right person a clear sequence and enough meaning to make the next decision. This describes the design intention, rather than a claim that every possible user has completed usability testing.
No warehouse changes what a quantity means
The archived requests explicitly say that stock balances are not managed. Later requests explain that suppliers deliver directly to project sites and that several suppliers can serve one site. Modeling a receipt into the company's warehouse followed by a shipment out would therefore describe events that had not happened. An apparently familiar stock screen could create extra work: staff would have to maintain fictional movements to satisfy the software.
Removing warehouse stock does not remove quantities. Ordered, allocated, dispatched and received quantities still answer different business questions. My design distinction was between the meanings of those quantities. The business needed to know which part of a customer order had not arrived, without pretending that the goods had passed through a warehouse. That distinction is useful when evaluating a proposed system: ask what real event makes each number change, and who can provide evidence for that event.
Put the site above individual supplier relationships
A fixed customer-to-supplier pairing makes the first example easy. It stops being sufficient when another item at the same site comes from another supplier. The conversation introduced precisely that condition. The design therefore places orders under a site and allocates quantities of individual order lines to suppliers. Dispatch and receipt records attach to those allocations. A supplier is a participant in fulfilling the order, rather than the owner of the entire customer relationship.
Consider a synthetic order for ten units, split into six units from one supplier and four from another. Preparing two supplier requests must not turn the customer order into twenty units. The customer document can preserve selling prices while supplier documents preserve buying prices and delivery instructions. Several documents can describe one piece of work. Their existence is not a reason to add their quantities or amounts together without checking their roles.
A smaller scope still needs explicit exceptions
Leaving out stock management is more than a shortcut to an earlier release. The system still needs a position on partial delivery, returns, cancelled requests and supplier changes. I find it useful to write down events before naming features. A request has been prepared; someone has actually sent it; dispatch has been reported; a person at the site has confirmed receipt. Those statements require different evidence and should not be collapsed into a single completed badge.
If the business later starts using a warehouse, these fulfillment quantities should not simply be renamed stock. Locations, ownership, movement timing and physical counting would need their own rules. An extensible system does not need every future function on its first day. It does need records whose current meaning is clear enough that a later function can attach without rewriting what earlier events meant. That is the practical value of a narrow but carefully defined starting point.
Questions to answer before commissioning the software
I would start with a working day: what arrives, who checks it and what must be prepared for somebody else? Mark the values staff type repeatedly, the points requiring a decision and the facts that are not yet known. Then identify the things the software must not invent, such as a warehouse movement, a missing price or an unconfirmed delivery. A small menu can support substantial work when those boundaries are understood.
This account comes from comparing selected requests, design notes, preserved implementation and dated inspection records. I did not reopen the operating ledger or replay a real delivery while writing it. For another business, choose concrete cases where a supplier changes, one order splits or a cancellation follows a partial delivery. The proposed system should explain what happens to each existing record in those cases. That exercise usually reveals the necessary scope more reliably than a checklist of familiar ERP modules.