Ongoing WMS and Business Central: seven things the integration has to get right
Moving orders one way and receipts the other is the easy half. These are the places where the two systems disagree about what happened, and what Weave does in each.
1. A partial delivery is a delivery
A purchase order line in Ongoing's REST API carries running totals: advised, received and reported. An integration that posts from those posts the difference between two totals, and a total cannot say that three more units arrived just now. The workaround is to close the order so the delivery shows, and reopen it for the next one.
Ongoing's SOAP API has what the REST API lacks, a per-event inbound transaction feed where every event has its own id. Weave reads that feed, posts each event once, groups a day's events on one order into one receipt, and stamps the Ongoing event id on the posted receipt line, so asking which event produced a receipt is a lookup.
2. Invoicing on a partial shipment
Business Central defaults Qty. to Invoice to everything shipped and not yet invoiced on the whole order. On a partially shipped order, a posting that ships and invoices bills an earlier shipment's goods under this one. Weave sets Qty. to Invoice on every line to what the posting moves, as the last write before it posts.
Receipts are the other way round. They should be received and not invoiced, because the supplier's invoice is somebody else's to post, and Business Central's standard receive action invoices and then fails on the missing Vendor Invoice No. That is one reason Weave posts through a runner in its own extension.
3. An article is an item and a variant
Ongoing holds one article number per size and colour. Business Central stores the item and the variant separately, and its standard v2.0 API pages leave out the location, the variant and the return reason. Posting needs the split, reconciliation needs the join, so Weave's extension publishes its own pages with exactly those fields.
4. Returns arrive two ways
Some returns come in on a return order. Others are booked back onto the original sales order, and a feed of inbound orders never sees them: at one retailer that was 81 orders in 60 days. Weave reads both, credits at the return order's own price and charges the return fee your table sets for the reason and currency.
The reason also decides where the goods belong, sellable stock or the claims location. A reason nobody has mapped raises an exception, because defaulting it into sellable stock would sell damaged goods as new.
5. Orders change after release
Customer service reopens an order to take a line off it, or deletes it. Both are safe only while the warehouse has not started. With Weave, Business Central asks the warehouse live before either: once picking has started, a reopen asks the person to confirm and a delete is refused with the reason.
6. Stock drifts unless someone looks every night
Weave compares Business Central's stock at the warehouse locations with Ongoing's, per SKU, every night. Picked goods count as still in the warehouse until they ship, because Ongoing drops a picked unit before Business Central books the shipment, and the claims location is compared on its own, so a unit on the wrong shelf shows even where the totals agree.
7. An alert nobody reads is not an alert
An alert per failed document soon becomes a list nobody opens. In Weave a condition raises once, when it is new or comes back after being fixed, and closes itself when a later run fixes it. Only work that has used up its attempts asks a person.
Questions
Does Weave need an extension in Business Central?
Yes, one. It queues released documents, publishes the API pages Weave reads and writes through, and holds the posting runners that receive, ship and credit per event. Weave signs in to it as its own Microsoft Entra application.
What permissions does Weave's user need in Business Central?
The WEAVE permission set its extension ships, Microsoft's D365 BASIC for the licence entitlement, and posting rights for the documents it posts, such as D365 PURCH DOC, POST. Other extensions that react to a posting can need their own grant.
How does Weave keep its place in Ongoing's feeds?
With its own cursor per feed, stored on Weave's side and advanced only after the events are stored. It never uses Ongoing's reported-quantity field, so it does not disturb another integration reading the same goods owner.
Which direction does what?
Business Central to Ongoing: items, purchase orders, transfers, sales orders and purchase returns. Ongoing to Business Central: purchase receipts, sales shipments, customer returns, transfers, stock adjustments and claims transfer orders.
Does Weave post supplier invoices?
No. Purchase receipts are received and never invoiced. Sales shipments are invoiced and customer returns are credited, each for exactly what that posting moves.