Changelog

Generating carton labels for a fulfillment downloaded the PDF to the browser and nowhere else, so the compliance artifact lived on whichever laptop the packer used rather than on the order.

The generated PDF is now filed in the order’s Documents section alongside the rest of the order’s files. The file name comes from the fulfillment number, so regenerating labels replaces the existing document instead of stacking copies. Filing happens in the background, so the confirmation says the labels downloaded and the document is on its way — give it a moment before looking for it under Documents.

Correcting a shipment that shouldn’t have been reported meant asking support to walk the state back. Fulfilled fulfillments couldn’t be cancelled, and shipments couldn’t be undone once they existed. The path forward for a mis-shipped order was manual.

Every active fulfillment shipment card now has a Cancel Shipment action. Cancelling it returns the fulfillment to In Progress so the shipped work can be walked back or fulfilled again, and the shipment stays in fulfillment history rather than disappearing. A confirmation dialog explains the outcome before the cancellation runs.

Cancelled shipments drop out of current coverage, shipment costs, exports, and shipped metrics, so an accidental report doesn’t skew the numbers. Cancel Fulfillment on the fulfillment itself stays hidden once a fulfillment has shipped; the shipment is the entry point for reversing shipped work. Shipments reported through an integration follow the same rules: an integration-reported cancellation now records a cancelled shipment rather than removing it.

A product’s External Identifiers card shows a Not Linked badge when an identifier has no integration behind it. That badge is a button now: click it, pick the integration, and the identifier is linked — without leaving the product to find the action on the integration’s detail page.

Linking is catalog-wide. A partner name maps to one integration for the whole catalog, so linking from one product links every unlinked identifier under that partner name. The dialog says so before you confirm, and the row flips to Linked once the job finishes.

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.

Sales receipts and invoices put freight on QuickBooks’ own shipping field rather than on a line item, so document totals separate merchandise from shipping the way QuickBooks expects. A setting on the integration controls whether Endless uses that field, and saving it checks what your QuickBooks account reports — turning it on for an account that has the field off is refused at save time rather than failing on the next push. Item descriptions are no longer sent on receipts and invoices; the product name is what appears on the document.

Two new settings set defaults for what Endless sends: default payment terms on invoices, and a default deposit account on sales receipts. Leave either empty and QuickBooks applies the customer’s default or Undeposited Funds. Both can be overridden per document from the accounting card on an order, and a document that inherits shows the default by name — “Net 30 (default)”. Pushed documents carry line descriptions from the accounting item’s sales description, falling back to the SKU. The Send button is now Push To QuickBooks, the Sent To QuickBooks badge opens the document directly in QuickBooks, and an Items Linked badge in the card header, with Linked and Unlinked badges per line, says whether every line resolves to an accounting item.

Importing matches better in two places. A product whose first mapping field is ambiguous is resolved by a later mapped field when the two agree; a genuine conflict stays unlinked and is written to the integration log rather than silently skipped. Customers and vendors match on display name, which is what QuickBooks uses to keep records unique, so a record sharing an email address with another one imports instead of being dropped. Run Import Terms once per QuickBooks integration after this deploys to fill in terms imported earlier.

The embedded tariffs tool is up to HTS 2026 Revision 17, so classifications and duty rates match the latest release the ITC published. Three August news items missed on the primary Federal Register and USTR sweep are added to the tool’s Updates feed after being verified against official sources.

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.

Decomposition — whether a bundle ships pre-made, decomposes into its components, or refuses to decompose at all — used to be a single setting on the fulfillment plan. That forced every bundle on a plan to behave the same way, so a traditional kit and a virtual bundle could not sit on the same order without a plan swap.

Every composable product now carries its own decomposition setting on the Relationships tab, next to its component list. Four options:

• Use fulfillment plan default — the current behavior. Defer to whatever the plan says.
• Never decompose (require pre-built inventory) — a finished unit or nothing.
• Use pre-made if available, otherwise decompose into components — pre-made stock first, then decompose when short.
• Use pre-made if available, and only decompose if components are in stock — pre-made stock first, then decompose only when components can cover the shortfall.

A product’s setting always wins over the plan, including an explicit Never against a plan asking to decompose. The plan is only consulted when the product is silent.

The two inventory numbers the decision actually turns on sit right beside it — the unallocated stock “use pre-made” draws from, and the available-to-make that “decompose into components” draws from. Component rows now show available-to-allocate per SKU, so an operator can see the stock behind each branch of the rule.

The setting is on every composable product type, aliases included. Manufactured products default to Never rather than inheriting a decomposing plan, so a base item with a released bill of materials no longer ships its raw components in place of the finished good. Existing products with no setting keep their previous behavior exactly — the plan default still applies.

The products export and CSV importer round-trip the setting losslessly. A blank cell leaves the value alone; Use fulfillment plan default is the only way to clear a product back to the plan from a spreadsheet.

Documents attached to a record used to be a list of filenames — usually whatever the supplier’s system produced — so a Bill sat next to a Packing List with no way to tell them apart at a glance and no way to narrow the list.

Every attachment now takes an optional short tag. Set it once from the row’s edit icon and pick from the tags already used on that record type across the company: the fourth PO you open offers Invoice, Packing List, BOL, and Specs on its first upload. Type to search, hit Create when nothing matches, or clear the tag with Remove. Every click saves and closes.

A filter above the list scopes the visible documents to one tag, with Untagged shown when the record has both tagged and untagged files. The tag itself renders as a badge next to the filename so the list reads as a set of categories rather than a stack of file names.

Tags are per-record, plain text, and capped at 50 characters. Orders, products, purchase orders, supply shipments, and suppliers all get it in the same shape. A read-only record — an archived PO, a non-editable product — shows the badge without the edit control.