Changelog

Send purchase orders and inbound shipments to Business Central from Endless. Map the supplier to a Business Central vendor, then use Send on the purchase order. You can link an existing document instead of creating a duplicate.

Links on purchase orders, sales orders, and products make it easier to move between the two systems.

The second fulfillment-number format — order number with fulfillment index — now uses the distribution center number when the fulfillment order has one. An order routed to distribution center 842 numbers its fulfillment SO12345-DC-0842 rather than SO12345-FO1. A fulfillment order without a distribution center still uses the index, so a company that does not ship to distribution centers is unaffected.

When two fulfillment orders on one order share a distribution center — for example, when a strategy sources one distribution center across two buildings — the second appends its index (SO12345-DC-0842-2). This applies only to fulfillment orders created from now on, as the setting already states.

When a B2B order split into fulfillments going to different destinations, warehouse integrations and EDI documents read the retailer’s PO, vendor, department, distribution center, ship window, and routing straight off the order, so every split fulfillment shipped against the order’s original destination. Each fulfillment now carries its own effective data — its override where one is set, the order’s where it is not — and every warehouse payload and every EDI 856 and 810 scoped to a single fulfillment reads that. A fulfillment with no override produces the same payload as before. Third-party billing carrier can be overridden per fulfillment as well; special instructions stays on the order.

The EDI tab on any order carrying a store distribution has a Store Packout Plan section showing the plan the retailer sent. Items are rows and stores are columns, with the item pinned left and its total pinned right, across three views: As Ordered from the purchase order, As Packed rolled up from every fulfillment’s containers, and Variance between them. Filter by distribution center and store, search by SKU, name, UPC, or purchase-order identifier, and download exactly the view you are looking at.

When the order splits, the plan groups by fulfillment order. Each becomes its own collapsible section headed by its number, distribution center, and store and unit counts, holding only the stores it ships — a purchase order across six distribution centers reads as six sections rather than one 87-column table, and two fulfillments shipping the same store stay apart instead of merging their units. A Fulfillment Order filter appears when the order is split, the CSV carries a Fulfillment Order column, and an unsplit order renders as it did. Two things to know about the numbers: store distribution lines match order lines on the purchase-order line identifier both sides already carry, so any identifier scheme resolves, though orders imported before this change keep the previous matching path; and a quantity that could not be restated in eaches is treated as unknown rather than zero, so it stays out of every total and Variance does not read as a full overage.

Supply shipments could only be created one at a time. Import Shipments and Export Shipments are now in the table actions menu on the shipments list, mirroring the flow on purchase orders, and the first-run empty state offers Import Shipments so a company with no shipments can reach the importer before there is any data.

The export is import-ready: run it, edit the file in a spreadsheet, and re-import it. Item rows link to a purchase order line by PO Number plus Item SKU, and unit cost, HTS code, and carton data are filled from that line. Container Size, Incoterms, and Cost Allocation are list columns rather than free text, so a raw value cannot leave the shipment unreadable. Shipment status is export-only, because it moves through a validated transition graph and stays a UI action.

A purchase order used to carry one set of dates for the whole order, which forced buyers to keep partial-ship schedules in a spreadsheet on the side. Each PO line now has its own Expected Ship Date, and the PO Details tab is reworked around expected and actual milestones. Header and line dates are independent — setting the header does not push down to the lines.

Fill the lines three ways: type a date directly, copy the header date onto the selection, or calculate each line’s date from its lead time added to a base you pick at run time — issue date, confirmed date, or one you supply. Lines without a lead time come back in a Skipped list rather than failing the action, and every strategy resolves to a concrete date before it is saved, so a later rebuild does not recalculate to a date the buyer never agreed to. The header ship window is derived from the line dates, so an order with mixed dates reads as a range. PO dates now honor clear, set, and omit correctly for every date including Payment Due, and both the CSV export and import carry the Expected Ship Date columns.

Bulk-editing a purchase order’s dates or status meant opening the orders one at a time, because the importer covered about half the fields on a PO. Every operator-writable field is importable now, and the default export lines up with the import, so a file can be exported, edited in a spreadsheet, and re-imported without remapping.

The importer accepts all ten header dates, Short Description, and PO Status, under the labels the UI uses. PO Status offers every value the status control offers, and a status set through the import records the same history row, timeline event, and log entry as one set by hand. Suppliers resolve by handle rather than legal name — the supplier export and import both carry a Handle column and existing suppliers are filled with a slug from their name, so there is a short value to type instead of reproducing “Acme Widgets & Sons, Incorporated” exactly. A handle that resolves wins over a stale name, and one that does not resolve is a row-level error rather than a silent fall back to a different supplier. A blank cell leaves the stored value alone, and a renamed column errors and names its replacement.

Dates export month-first with a four-digit year, which is what survives a spreadsheet save. One behavior change reaches beyond the importer: a purchase order’s own payment terms and incoterms no longer inherit from the supplier’s defaults when the incoming value is blank, so an update or import that clears the field keeps it clear. A new PO still inherits, having nothing of its own to keep.

Veracore now handles the full supply-shipment loop. A shipment sent to a Veracore-backed warehouse posts as an expected-arrival record, and the key Veracore returns stays on the Endless shipment for reconciliation. Received quantities come back through Veracore’s Expected Arrivals report on the same daily schedule the other warehouse integrations use, and a shipment closes when every line is fully received. Veracore’s owner ID is derived from the System ID already on the integration, so there is nothing new to configure. A missing System ID or Expected Arrival Date is reported before the send is attempted rather than as a generic failure afterwards, and re-sending the same ASN is safe.

Veracore integrations also get a Lot Tracking toggle. With it on, each ASN line sends the shipment item’s lot number as the product version Veracore reads, so a receiving warehouse keeps the lot on record. Pull Inventory branches on the same flag: lot-tracked accounts submit the Product Detail with FIFO report and each SKU version is mirrored into its own warehouse location, with Default Available zeroed so a versioned SKU is not double counted. Non-lot-tracking accounts are unchanged, and a partially versioned account still reconciles — rows with a blank version fall back to a single total on Default Available.

Select products in the product list and choose Create Carton Labels from Bulk Actions, or use the same action on a product’s detail page, to generate master and inner carton labels as a PDF from each product’s packout data. Each file holds one carton type, in 6x4 landscape or 4x6 portrait. The GTIN prints as a real ITF-14 barcode at the size the GS1 spec requires, and the on-screen proof shows the label at print size, so what you approve is what prints. Products missing a unit count or GTIN are listed first and can be fixed in the same tray before you generate.

The creator opens as a dialog, so menus and selects on the page behind it stay usable while it is open, including fulfillment-rule menus. This is separate from the GS1-128 carton labels generated on an EDI fulfillment’s Containers tab; those still work the same way.

Royal Mail is now selectable as a carrier alongside the rest of the built-in carrier list. Pick it from the carrier picker anywhere a carrier is set.

A retail EDI purchase order that names a per-store breakdown now splits into fulfillments that carry that plan, and the containers tab knows how to pack against it. Auto-Pack gains a By store (retailer plan) strategy — one container per destination store, pre-filled to the retailer’s quantities, selected by default when the fulfillment carries a store distribution. Before anything is generated it lists shortfalls, identifiers it could not resolve, and units the retailer named no store for. Non-EDI orders and retailers that ship to one destination see no change — the strategy, warnings, validator option, and pick list export all depend on the distribution being present.

Every carton carries its mark-for store as a badge, and a Store column appears on the summary tab. Contents flagged against the retailer’s plan — “Store 0204 expects 25 units”, “Not on store 0201’s plan” — sit on the specific item row that caused them, and the checks aggregate across a store’s cartons so a surplus on one SKU does not offset a shortfall on another. The Validate Containers dialog gains a Pack for Store Quantity option that requires every store’s cartons to match the plan before Close Containers is allowed; the option turns itself off on fulfillments without a distribution and never persists true. Export Store Pick List (DC, Store, SKU, UPC, Product Name, Quantity) is offered whenever a fulfillment has containers, including on cartons an operator assigned stores to by hand.

Rollout note: takes effect per integration once the destination grouping is set on the routing strategy, store codes are added to the integration’s location code mapping, and the trading partner’s live template is updated to emit the store distribution.