The purchase side

Everything on the sales side has a mirror here. The documents are the same; what changes is which of you posts and which of you reads.

Most companies start with the sales side, because that is where the customer is asking for it. The purchase side is where the saving usually is, because that is where people are typing.

The documents, the other way round

DocumentDirectionWhat happens
OrderOut to the supplierPosting a confirmation request on the purchase order sends it
Order changeOut to the supplierA later send of an order the supplier already has, naming only the lines that differ
Order cancellationOut to the supplierCancelling the purchase order tells the supplier
Order confirmationIn from the supplierTheir answer lands on the purchase order
Despatch adviceIn from the supplierWhat is on its way, before it arrives
InvoiceIn from the supplierMatched against the order and what was received

Sending an order

Posting a confirmation request on the purchase order sends it, where an outbound agreement for the order inquiry exists for that supplier. The button is Confirmation request, not Confirm. Confirming the order writes a confirmation journal and sends nothing.

The supplier gets the order in their system without anyone rekeying it, which removes the most common source of a wrong delivery: a line typed twice.

Changing an order the supplier already has

A second send of the same purchase order is a change, not a new order. On EDIFACT it travels as an ORDCHG, which names the lines that differ and the action on each: added, deleted, changed or unchanged.

Whether a supplier gets one is set on their agreement. Left off, a second send goes out as the order document again, which is what a supplier who never asked for ORDCHG has always received. Switched on, a change with no ORDCHG agreement behind it is refused and names the order, rather than leaving as a replacement the supplier would book as a second order.

Suppliers differ on whether a buyer may add a line to an order they are already working. The agreement says which of the two this one is, and where the answer is no, the change is refused here with the reason rather than sent and quietly ignored at the other end.

Cancelling an order

Cancelling a purchase order tells the supplier, where you sent them the order in the first place. There is no separate cancellation document. The cancellation travels as the same order document carrying a cancel message function, and it repeats the order as the supplier knows it rather than a copy with every quantity zeroed, which most partners’ validation refuses.

Supports cancellation on the outbound agreement is what turns this on, because whether a format and a partner can express a cancellation is an agreement between two parties and not something we decide for them. With it off the cancel goes through in Dynamics and the supplier is not told.

Taking a confirmation

An incoming confirmation says what the supplier will actually deliver. It is staged and compared first, the same as any inbound document, and the comparison is against the purchase order you sent: the prices you agreed, the quantities you asked for, the dates you wanted.

A confirmation that agrees on everything can update the purchase order by itself. One that changes a price or a date waits, because that is a decision rather than an update. That is exactly the case you want a person to see, and the one that is currently invisible when confirmations arrive as PDFs.

Receiving against a despatch advice

An incoming despatch advice tells you what is coming and, where the supplier packs to licence plates, exactly how it is stacked.

Two routes exist, and you do not pick between them. The module decides per order line. A line whose item and warehouse are both warehouse enabled becomes an advance shipping notice on a licence plate, so the goods can be scanned in. Every other line becomes a line on an item arrival journal. One despatch advice can use both routes, because an order can hold lines on both kinds of warehouse.

Neither route posts a receipt

A despatch advice announces goods that have not arrived yet, so the arrival journal is left for your people to post when the lorry is at the door. Posting it on arrival of the document would assert a physical receipt nobody has made.

Matching supplier invoices

An incoming supplier invoice is staged and compared against the purchase order and what was received against it. That is the three way match. Where the three agree, the invoice is saved into Pending vendor invoices carrying the supplier’s own invoice number, and the people who already approve invoices finish it in the screen they know.

EDI posts nothing to the ledger. Where the three do not agree, the difference is shown: a price that moved, a quantity that does not match what was received, a line that was never ordered. A credit note is never posted this way. It is held for a decision, naming the invoice it corrects, because crediting a supplier is not something a document should do on its own.

This is where the payback usually is

Companies tend to measure EDI by the sales side because that is what a customer asked for. The purchase side is where the hours are: every supplier invoice that reaches Pending vendor invoices by itself, already matched against the order and the receipt, is a person not reading a PDF, not typing a line, and not chasing a difference three weeks later when the payment is queried.

Allowances and charges

Freight, packaging, a discount off the total: what a received document states as an allowance or a charge becomes a charge on the record the module builds, not a note somebody reads and types in again. A confirmation’s charges land on the purchase order, an invoice’s on the pending vendor invoice.

Where the charge sits on the document decides where it lands. A charge the document puts on the header goes on the header, a charge it puts on a line goes on that line. The comparison reads them too, so a charge that was not agreed shows up as a difference rather than as a surprise on the total.

One document, several orders

A supplier may put the order number on the line rather than in the header, and one despatch advice or invoice may cover several of your orders. The module reads it either way: an order number in the header settles it for the whole document, and without one each line is resolved from its own reference.

A line that names a different order from the header is the one case that goes red, because the two cannot both be right. A despatch advice may span several orders on one vendor account; an invoice or credit note may span several under one invoice account, in one currency.

Acknowledgements, both ways

The receipts work the same in both directions. You answer your suppliers’ documents if you have agreed to, and you expect answers to yours. A supplier who never acknowledges your orders is a supplier whose orders you cannot prove arrived, and acknowledgements covers what to do about it.

Where to start

With one supplier, and with the invoice. It is the flow with the clearest saving and the one where a mistake is caught by the matching rather than by a customer. Add the order and the confirmation once the invoices are reaching Pending vendor invoices cleanly.

The purchase side · LunoLake docs