How Weave works
One Business Central company, one Ongoing goods owner, both directions. What moves, and how it stays correct.
To the warehouse
When a document is released in Business Central.
Released, then sent
Weave's extension in Business Central queues every released document that touches the warehouse. Weave sends the queue every five minutes and marks each row in Business Central with the result, so the person who released it sees it where they work.
Items
New items are created in the warehouse and item card changes reach it, every hour. A new order's items are created in Ongoing before the order that needs them.
Purchase orders
With the supplier, order date, line texts and prices. Released again after a change, the order is restated in the warehouse.
One inbound order per delivery
When the warehouse closes a purchase order that is still partly outstanding, Weave can advise the remainder as a follow-on order, PO-104233-R2 after PO-104233, so a second delivery never means reopening a closed order. Off until you switch it on, agreed with the warehouse first.
Sales orders, transfers and purchase returns
Sales orders when released, including orders paid at the checkout that Business Central holds at Pending Prepayment. Transfers in and out, and purchase returns for the buyer to finish in the warehouse.
Back to Business Central
What the warehouse did, posted per event.
Purchase receipts
One receipt per delivery (order and date), received and never invoiced. An over-delivery above your tolerance stops for a buyer to answer instead of being posted.
Sales shipments
Shipped and invoiced: one shipment and one invoice per order and departure day, for exactly what left.
Customer returns
Returns received on a return order, and returns booked back onto the original sales order. Each is credited at the return order's own price, with the return fee from your table by reason and currency. The reason decides sellable stock or the claims location, and a reason nobody has mapped raises an exception rather than defaulting to sellable.
Transfers, adjustments and claims
Transfer receipts and shipments. Stock counts and corrections from the warehouse. Once a week, one transfer order out of the claims location for what both systems agree is on the claims bin, created and never posted.
Built to be correct
Checked against the code, in the words a Business Central consultant would use.
A cursor per feed, advanced last
Weave reads Ongoing's inbound transaction feed, where every event has its own id, with a cursor stored on Weave's side. Each page is stored first and the cursor moved after. An interruption in between costs a re-read of one page, and the re-read inserts nothing.
Lot ids and an inclusive fromId
Ongoing's OriginalArticleItemId is a lot id, not a transaction id: several rows share one, and some are byte-identical. Its fromId is inclusive. So a row is matched against the stored rows of its lot by content, and a new row takes the next ordinal. A first read, a full replay and a lot that grew since all come out right.
Date windows where there is no id
Shipments and movements have no id to follow, so they are read as a window with an overlap and deduplicated on a natural key. A shipment that changes is kept as a new version, never overwritten.
Per event, never cumulative
No quantity sent to Business Central is a running total. Each event carries its own quantity, and the Ongoing event id is stamped on the posted receipt line.
Retries that cannot double
Posting the same event again returns the original document instead of receiving it twice. A request whose answer never arrived is settled by asking Business Central what it holds, never by sending it again blind. Five attempts, then one exception for a person.
The invoice is the event
Business Central defaults Qty. to Invoice to everything shipped and not yet invoiced on the whole order. Weave sets it on every line, as the last write before posting, to what this posting moves. Receipts and purchase returns are never invoiced.
Read-only by construction
The clients that read Ongoing can only read. Every write goes through one file of named operations with its own credential, and no caller can pass it a verb or a path. Weave never writes Ongoing's reported-quantity field, so it cannot disturb another integration on the same goods owner.
Its own pages in Business Central
Business Central's standard v2.0 API pages leave out location, variant and return reason, and its own receive action invoices. Weave's extension publishes API pages and posting runners with exactly what Weave needs, and Weave signs in as its own Entra application, so postings name Weave, never a person.
Watching both systems
So you hear about a problem before a customer does.
Order check
Reopening or deleting a sales order or a transfer out in Business Central asks the warehouse first, live. Once picking has started, a reopen asks for confirmation and a delete is refused with the reason. An order the warehouse has not started can be cancelled there when a person deletes it, if you switch that on. Nothing else is ever cancelled.
Stock comparison
Every night, per SKU, Business Central's stock at the warehouse locations against Ongoing's. Picked goods count as still in the warehouse until they ship, and the claims location is compared on its own.
Oversold and backlog
Released sales order lines against what the warehouse can actually pick. Late sales orders, purchase orders gone quiet after a partial receipt, and transfers stuck in transit, by age.
Exceptions, raised once
A condition raises when it is new or comes back after being fixed, and closes itself when a later run fixes it. Mark fixed, or Expected, ignore.
Go live per flow
Each flow has its own switch and start time, so you can turn on receipts before shipments, and the first documents can be posted by hand and checked before the schedule takes over.