Sales sees an available item while the warehouse has already reserved the last unit for another order. At the same time, there is an order in purchasing whose delivery date is only documented in the email history. Such situations show that inventory management encompasses more than an item list: it connects decisions about inventory, procurement and customer promises.

Individual merchandise management can make these connections visible. However, their benefit does not come from as many key figures as possible on a home page, but rather from a reliable model of operational processes. Anyone planning such a system should therefore start with movements, responsibilities and exceptions. The following example describes possible requirements; it does not represent a customer project that has actually been carried out.

Master data is the common language

Item numbers, units and variants must be unique. If a product is purchased as a box and sold as a single item, a comprehensible conversion is required. Supplier item numbers, packaging units and internal designations should also be saved separately. An additional column of text only resolves such relationships temporarily.

Before migration, duplicates, unused fields and inconsistent spellings must be examined. Otherwise, a company can start a technically modern application with the contradictions of the previous lists. For important master data, it should be clear who is allowed to create and change it. Changes to units or variants can affect open orders and may require special checks.

Inventory is more than a number

Physically present, reserved, blocked and expected receipt of goods are different states. A meaningful inventory display differentiates them. Available quantities cannot be represented reliably if reservations are only listed as comments on the order. Likewise, goods that are damaged or have not yet been checked should not automatically be considered deliverable.

A robust model documents inventory movements with reference to the triggering process. Goods receipt, withdrawal, stock transfer, inventory correction and cancellation have different meanings. This means you can later understand how an inventory was created. Simply overwriting a current number, on the other hand, obscures the cause of a deviation and makes troubleshooting and coordination between departments more difficult.

Consider simultaneous bookings

If two people access the same inventory, the application must not allow a reservation based only on a previously loaded screen value. Checking and booking must match at the database level. Transactions can treat related changes as a unit. The PostgreSQL documentation explains this principle using several steps that are intended to succeed together or be rejected together. The specific blocking and conflict procedure depends on the system chosen.

From need to order

A low inventory is an indication, but not a final purchasing decision. Replenishment time, minimum order quantity, open deliveries and demand also play a role. The application should therefore show the basis on which an order proposal is created. Automatically generated suggestions remain verifiable if their origins and assumptions are visible.

A fictitious wholesaler could initially collect orders and only send them to the supplier after approval. Partial deliveries must then be assigned to the original order. If a remainder remains open, it is explicitly visible. Price deviations and changed dates belong in a defined processing path instead of disappearing into separate email inboxes.

Order entry and customer information

When entering an order, commercial and logistical requirements come together. Contact person, delivery address, price agreement and desired date must match. A distinction must also be made between which information is taken over from the master data record and which deliberately applies to this order. A later change of address must not unintentionally rewrite processes that have already been completed.

Clear status values with understandable transitions are helpful. An order can be entered, checked, released, partially delivered or completed. Each status should have a technical meaning. Anyone who is allowed to change an order does not necessarily have the right to release it. The inventory effect must remain traceable, especially in the case of cancellations and changes in quantities.

Use interfaces specifically

Shops, shipping services, accounting and supplier portals can provide or require relevant data. However, an interface should not automatically transfer all existing fields. First, it must be clarified which system is the leading source for an item, an address or a payment status. Only then are data flow, updates and error handling determined.

An import needs checks for mandatory fields, data types and unique keys. Reading in the same delivery again must not create duplicate inventory movements without being noticed. Incorrect data sets should be able to be put back with an understandable reason. A technical protocol alone is not enough if employees then have to correct the process technically. The article about APIs and interfaces deepens these transitions.

Automation with controllable limits

Recurring processes are particularly suitable for automation when their rules are clear. Examples include reporting low inventory levels, preparing recurring orders, or generating a shipping list upon approval. Automation should not hide a missing decision at the same time. Incomplete delivery addresses or conflicting prices require a recognizable exception process.

Automated tasks require assignees, recurrence rules, and termination conditions. If a background process is interrupted, it must then be possible to continue it safely. Employees should also see whether a task was planned, completed successfully or failed. Invisible automation creates new uncertainty as soon as its result does not match expectations.

Define evaluations in an understandable way

Sales, order intake, inventory value and delivery ability answer different questions. A dashboard should not mix these sizes. When it comes to the inventory value, for example, it is relevant which valuation method is used and whether blocked stocks are included. A graphical representation without definition can lead different departments to conflicting conclusions.

The source, calculation, period and update status should be documented for each key figure. Those responsible must be able to check comparative values. When it comes to tax or commercial law requirements, the appropriate specialist systems and tests must be included. An individual merchandise management system is not just legally compliant accounting or audit-proof archiving because of its functional designation.

Plan web-based operation correctly

A web application can make central data accessible via browser and simplify the distribution of program versions. However, this is only helpful in the warehouse if devices, scanners, network coverage and working environment are taken into account. Small buttons on an office screen are not a suitable benchmark for a mobile warehouse interface.

A pilot should cover a complete but limited process: for example, goods receipt, storage and withdrawal of a group of items. At the same time, authorizations, backups and restores are checked. A coordinated replacement procedure is required in the event of disruptions. If you consider these points early on, you can avoid the actual introduction failing due to everyday operating conditions.

Do not add inventory and corrections later

The inventory is a good test of the data model. A counted inventory and the previously calculated inventory may differ from each other. The application should handle both information in a comprehensible manner and record a confirmed correction as a separate process. If only the current number is replaced, the cause, test method and responsibility disappear from the technical context.

The same applies to returns. Returned goods are not automatically resalable. It may first need to be checked, blocked or assigned to a special storage area. Which conditions are required depends on products and operational requirements. Even a small pilot should therefore contain at least one return and one corrected booking.

For the introduction, a manageable group of items with different properties can be selected: a single item, a product with a packaging unit and a variant with blocked stock. These examples can be used to check whether units of measure, reservations and returns fit together. The selection should show typical complexity without changing the entire operation at the same time.

Finally, every inventory correction needs appropriate authorization. Anyone who records goods is not necessarily allowed to release every difference themselves. A clear separation of recording and confirmation can support technical controls. Which evidence needs to be retained is agreed with the responsible commercial and, if necessary, legal specialists.

From a list to reliable processes

The core of good merchandise management is a comprehensible connection between data and processes. A common interface can support this connection if technical rules, data quality and technical security are developed together. The more clearly exceptional cases are described, the more reliably the initial scope of development can be limited.

Ours ERP application example shows a possible interface with explicitly fictional data. For a specific application, GRITTMANN would first record movements, responsibilities and existing systems. This is followed by a concept whose benefits and limitations can be verified based on actual work processes.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 06.03.2026.