ERP & messages

The ERP maintains articles, customers, suppliers, sales orders, and purchase orders. It sends the WMS the operational article and order data needed for Warehouse work. The WMS manages locations, pallets, reservations, tasks, packaging, and handover.

The Shop uses the ERP catalogue and available-to-sell quantities. Checkout creates an ERP customer record for the signed-in user when needed and records the delivery address. A cart is checked again at checkout, so an article that sold out while you were browsing can prevent the order.

Orders placed Monday to Friday before 14:00 Berlin time are planned for delivery on the next weekday. From 14:00 and at weekends, shipment is planned for the next weekday and delivery for the weekday after that. Friday afternoon and weekend orders are therefore planned for Tuesday. This calendar skips weekends. Prices and VAT are recorded with the order lines. Shipping currently costs €4.95 per order below €50 gross goods value, and is free from €50.

The ERP sends the order to the WMS and records whether it was accepted. Before release, an administrator can change or cancel the ERP order. Release hands it to the Warehouse and locks it. Subsequent shortages, shipment, and delivery updates come back through the integration.

Customer emails include order confirmation and subsequent updates such as cancellation, shortages, and shipment. Demo customer emails are recorded in the ERP email history without being sent. Orders placed through a real Shop account queue actual emails to the account address; the history records a copy, not proof of delivery.

The purchasing run estimates daily demand from customer quantities ordered over the last 28 days. It compares available stock plus outstanding purchase quantities with demand during the supplier’s lead time plus three safety days.

When that position is too low, the ERP tops up toward ten days of demand, rounded to full pallets. It groups purchases by supplier and sets the due date using the supplier’s lead time. An active article with no recent demand gets one pallet when nothing remains, provided it has a supplier.

The supplier simulation creates a despatch advice and the ERP forwards it to the WMS. Receiving reports the actual arrival back to the ERP; expected purchase quantities should not be mistaken for physical stock.

Inbound messages record what the WMS received, including message type, payload, processing status, and errors. Outbound messages record reports from the WMS to its partners. Open the message details to distinguish a transport problem from data rejected by the receiver.

Start with the business record and its send status, then inspect the corresponding message. An ERP order saved locally is not proof that the WMS accepted it. Administrators can resend supported ERP records and outbound WMS messages after resolving the underlying issue.

A failed outbound report does not undo the WMS booking. Retry the report after correcting the cause; do not receive, correct, or ship the goods a second time just to make the systems agree.

For stock differences, compare the same article and the last stock update, then check receipts, corrections, and shipment reports. Picks and internal pallet moves do not send the same stock-change reports as receipt and shipment.

Fictional demo customers are visible to everyone. For orders linked to a real Shop account, only that customer and administrators see the personal details. Other viewers see Shop customer with the order and customer numbers, while addresses and contact details are hidden. The same protection applies to handheld views, message payloads, tracking, and shipping labels; another customer’s emails are hidden.

Real people working on the handheld appear to other viewers as Warehouse helper. You see your own name, and administrators can see worker names. The virtual crew and the public manager keep their names. A masked name is deliberate, not a missing master-data record.