The orders list has separate ORDER STATUS and ERP STATUS columns. The two columns reflect how orders work: what the buyer committed to is tracked apart from how the order is carried out downstream and how it is settled financially. Order status describes the order's stage in DigiTrade; the ERP's response follows the handoff separately. Use Status and Erp status as separate diagnostic dimensions.

The orders list has a Status filter and an Erp status filter. The platform itself defines the order status values, so every shop sees the same set regardless of which ERP it uses. Keeping the filters separate preserves the distinction between commercial state and downstream execution. A single status cannot represent commercial commitment, downstream execution and financial settlement together.

If your shop holds orders for approval before they go to the ERP, each order stays with DigiTrade until a staff member approves it in the Admin Panel. An order that is waiting for approval has not been sent to the ERP, so it has no ERP answer to compare. The ERP's acceptance or rejection arrives later, after the order is handed off.

Publishing an order for downstream processing is not the same as accepting it, creating an ERP order, fulfilling it, or invoicing it. A link between the order and an ERP record is only a reference, and it does not show on its own that the ERP took the order or finished it. When an order has only been handed off, describe it to customers and colleagues as on its way to the ERP, not as confirmed. In a shop without an approval step, placing an order queues it for the ERP and sets its order status to Complete at once. At that stage the ERP has not replied, so a successful checkout tells you the order is lined up for the ERP, not that the ERP has agreed to it. For a shopper's storefront order without approval, the order-placed event occurs at submission, or at payment capture when paid by card. Approving an order or placing one as an agent does not raise that event. A notification depends on a switched-on automation that listens for the event and includes a message step. The ERP can still reject the order after the order-placed event. The connection's own signals, such as a successful send, a sync run or a delivery receipt, are not the same as the ERP agreeing to the order. An ERP document number is a scoped reference to the order in that ERP, and it never replaces the order's own identity in DigiTrade.

The orders list has an ERP DOCUMENT # column, and the order page has an Erp Document # field. The shopper's document list distinguishes the DigiTrade document number from the ERP document number. It displays the ERP document number when one exists and leaves that cell empty otherwise. When a customer quotes an order number, check whether it is the ERP document number or the platform's own number before you search the ERP.

If you can't tell whether the ERP received an order, reconcile the two systems before retrying. While you compare the two systems, work out which kind of problem you have: the order never arrived, its data was translated wrongly, it failed a check, the ERP refused it on business grounds, or the two systems simply disagree. An ERP rejection raises an event that a switched-on automation can use to send a notification.

The order page has an ERP request / response button. Open the ERP request viewer when you investigate a rejected order, because it is intended to display the request exactly as the ERP got it, which you can then check against the format your ERP expects.

Use the Admin Panel to follow and act on orders, but not as the final word on them, because it neither keeps the connected systems' own records nor does the processing work itself. What you can do there is limited to what your role allows, and it never lets you skip an approval your shop requires. For anything that happens after the sale, the ERP or the other system responsible for that fact has the final say. Changes through the Admin Panel must stay within the platform operations and authority available to your role.