Changelog

Push to Accounting can now update a linked item in QuickBooks Online. Before, an update could be issued and Endless would report it as pushed, but nothing in QuickBooks changed. Update requests now include the fields QuickBooks requires, preserve the fields Endless does not map, and retry once against the current version if QuickBooks has changed the item since the last import. An item without a sales or a purchase side is refused up front instead of failing on the way out. A refusal that QuickBooks itself blocks — clearing the income account on some existing items — now reaches the operator as a failure instead of a green result.

When ShipStation refuses a new order, the timeline entry for the failure now carries the full response from ShipStation under the More details row, alongside the short error message. The visible line stays concise, and the underlying reason — which used to be discarded, leaving customers with only “no orderId returned” — is there when you need to see it.

Extensiv fulfillments used to be marked as fully shipped the moment Extensiv returned a tracking number, so a partially shipped order looked complete in Endless and was reported complete to any downstream sales channel. Endless now records what each Extensiv package actually contained as a shipment on the fulfillment, and the fulfillment stays in progress until every item has shipped. Inventory is committed once every item has shipped rather than on the first tracking number, packages without a tracking number are recorded rather than dropped, and re-polling a fulfillment without changes leaves it alone, so the 15-minute Extensiv poll no longer duplicates shipment activity over its 24-hour visibility window. Miscounted orders can be repaired one fulfillment at a time; orders already reported complete to Shopify cannot be corrected there, since Shopify does not accept shrinking an existing fulfillment.

Extensiv sometimes leaves the SKU off a package content and names the line through its own order item id instead. Endless resolved contents by SKU alone, so those contents matched nothing and no shipment was recorded — the fulfillment stayed in progress after the order shipped, with nothing on the log to say so. A package content now falls back to the Extensiv order item id to find the matching line, where the SKU is reliably present. A content that still cannot be resolved is reported on the fulfillment’s log with its Extensiv line rather than dropped, so a mismatch shows up on the order. A background sweep re-ingests already-stuck fulfillments once the fix is deployed. It checks each candidate against Extensiv’s API, only touches orders that report shipped quantities, paces its calls against Extensiv’s rate limit, and reports throttled orders so the next run picks them up.

Generate Labels on a fulfillment’s Containers tab now produces real scannable GS1-128 carton labels for retailers with a GS1 label mapping. What the button rendered before looked like a carton label and carried no barcode symbology, so a carton sent against it was refused at the retailer’s dock. Labels are requested once per non-archived container on the fulfillment, ordered so the carton number on the label matches the “Container N” shown in the packer’s tab. Fulfillments with no retailer label mapping keep the local label they always used, so nothing changes for anything outside EDI.

Before a batch is sent, cartons without a valid GS1 SSCC are refused and the missing codes become the primary action, so an operator gets a fix rather than a disabled button. When a retailer expects GS1 labels but the account is not set up to generate them, the action blocks and explains rather than substituting a local label the retailer would reject. Once labels exist the menu item reads Regenerate Labels.

The Claim Authority and Reset Order controls are gone from imported orders. You can edit sales-order details, add and change fulfillments, and cancel the order without first taking authority away from its source integration. Fields the source integration manages carry a caution and a save-time confirmation on the fields that use them, so an edit that the source may later overwrite goes through with a warning rather than as if nothing had changed. The fulfillment plan follows the source until a fulfillment change is made in Endless or work begins on it; from that point Endless drives the plan and the activity timeline records the handoff. Canceling an in-progress order cancels every unfulfilled fulfillment order under it, preserves shipments that already went out, and stops the source from restoring the plan on its next pass.

Sales and fulfillment order details are reshaped around the new default. Internal notes live on their own Notes tab with a count badge, and the tab you had open stays selected as you move next or previous through the orders list. The two separate banners at the top of an imported order — one for source-managed ownership, one for fulfillment sync — collapse into a single sync card that names the source, whether it is still sending updates, and whether the fulfillment orders match what the source said. Fulfillment cards default to expanded on active fulfillments and collapse to their items list once fulfilled or cancelled. Advanced view splits an active fulfillment across tabs for Items, Details, Metadata, Timeline, Shipment, and Containers; simple view shows items only. Blockers on a fulfillment list every unmet condition rather than only the next one, with a per-condition Resolve button next to each. The sync card no longer overloads the word “blocked”, and the copy on bulk Reload from source, refresh toasts, and the timeline explains changes in terms of fulfillment orders rather than an internal fulfillment plan.

Shopify keeps sending updates and shipments back after a local change. A Shopify order used to stop accepting webhook updates the moment an Endless user claimed it to route a fulfillment somewhere — cancellations, quantity changes, and other source-side edits were rejected without a trace on the order, and only surfaced later when the mismatch was investigated. Routing a fulfillment no longer takes ownership of the order itself. Shopify keeps sending order-level updates and Endless keeps applying them, while the routed WMS remains the one that reports the shipment. A refused webhook update now shows on the order timeline instead of disappearing, so a rejection is visible where the update would have landed. Canceling an order also refuses up front when one of its fulfillments cannot be modified by the person acting, rather than partially applying and leaving the order in a mixed state. Separately, a Shopify-owned order shipping from a building that had a Default WMS attached was failing to close through Shopify — the warehouse default was being treated as if the order had already been re-routed away from Shopify, and the ship confirmation was rejected on the way back in. Shopify now keeps the fulfillment until you re-route it explicitly or hand it off to a downstream system, so the close-and-ship flow completes even when the building has a Default WMS set; explicit re-routes still transfer control right away.

The inventory export setup copy on Rithum, Walmart, Shopify, Amazon FBM, Skubana, and Faire now names both switches that decide what gets sent: the integration-level permission that controls whether inventory exports at all, and the per-building inventory settings that control which building’s stock counts toward it. The previous copy only mentioned one, so a channel that looked configured to export could still send nothing because no building was included.

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.

QuickBooks Online has a new Import All action that pulls your chart of accounts, vendors, customers, items, and payment terms into Endless in one step, so setting up the integration no longer means running each import from a separate menu. Payment terms come in as part of the initial import and no longer appear as a standalone action afterwards. Sending invoices, sales receipts, or product data to QuickBooks before Import All has run returns a clear message that the integration has not been initialized, instead of sending records with missing references and leaving unmatched entries on the QuickBooks side.

Items match to your existing products through whichever product field your item defaults say each accounting field comes from. Tenants whose QuickBooks items are named from the product SKU and coded from the UPC — where the previous match compared against the SKU and then the name and could link almost nothing — now link on the actual mapping. The same rules run in both directions, so a product looked up from the item and an item looked up from the product resolve to the same pair. When two products carry the same mapped value the item is left unlinked rather than attributed to one of them at random. An unlinked product tries to match on demand the next time an operator asks for it, and mass import does the same on the integration-level mapping.

The QuickBooks Data Mapping tab has a Suppliers table. Each supplier gets a picker that searches your QuickBooks vendors as you type, and selections stage in the table so you can work through several and save them together. Pull vendors re-imports the list without leaving the tab, and a vendor already mapped to one supplier is unavailable in the others, so the same vendor cannot be used twice. If you connected QuickBooks before this, run Import Vendors once so vendors you have already synced appear in the picker.

Two changes on the product header. Push to Accounting asks for confirmation before it runs, rather than overwriting the QuickBooks record on the first click. The Synced to accounting badge is gone: it recorded that a push had happened, not that the two records still agreed, so a product that had drifted still read as up to date.

Sales enabled now defaults on when you apply defaults, matching QuickBooks’ requirement that inventory and service items carry an income account; records created with it off were refused. A company with more than one accounting integration connected can push to the one it names rather than whichever was found first.

The ShipStation ship-notify webhook was reading only the first page of a shipment batch, capping it at 100 shipments per call — anything past the hundredth was dropped with no error and no retry. The webhook now walks every page. Measured in production over the last thirty days, 89 batches exceeded that limit and at least 21,565 shipments never reached Endless. A nightly reconciliation job had been backfilling those shipments once a day, so the missing ones only became visible when that job stopped running. Two guards land alongside: a shipment already recorded with the same tracking number is skipped on repeat callbacks, and voided labels are excluded so a canceled label does not mark an order shipped. When ShipStation reports a shipment that Endless cannot apply to the order, the dispatch step now writes a timeline entry tagged as a ShipStation shipment failure, with the human-readable reason and the technical detail kept apart. Forty-one orders in production had been sitting with the fulfillment marked shipped and the order still in progress, with nothing on the timeline saying why; the run still continues over the remaining shipments and only the failing one leaves a trace.

The ShipStation nightly reconciliation writes a summary log on every run, including runs that find nothing to do, with counters for shipments fetched, orders touched, fulfillments matched, fulfillments reconciled, lookback window, and duration. Fetch failures are logged before they propagate — before, that path sat outside the error handler and left no trace — and each per-fulfillment failure records its own error message. Between 2026-07-25 and 2026-08-02 the job had stopped running and produced the same trace as a healthy no-op run; matched versus reconciled now separates those cases. This change makes the job observable; retry, backoff, and rate-limit handling are separate work.