Confirmed delivery date is optional on order responses
Confirmed Delivery Date Is Optional on Order Responses
POST /v2/transactions no longer rejects an order response of type CHANGE without a confirmedDeliveryDate. Before, a CHANGE response needed the date in the header or on every item. You can now send an order response with only a confirmedShipmentDate, or with no confirmed date at all.confirmedDeliveryDate is still prohibited on REJECT responses, and a supplied date must still be a valid date. Whether a confirmed delivery date is required depends on your trade partner.Item identifiers without a GS1 or BUYER domain
Item Identifiers Without a GS1 or BUYER Domain
POST /v2/transactions no longer rejects a line item, or a sales report location, because none of its identifiers has the domain GS1 or BUYER. An item identified only by a SUPPLIER identifier is now accepted on every document type. Which identifiers are required depends on your trade partner.On invoices, credit notes, shipping notices and sales reports, each item, and each sales report location, still needs at least one identifier. On orders, order responses, dispatch instructions, dispatch instruction responses and receival notices, identifiers may now be empty.Free quantity on order line items
Free Quantity on Order Line Items
New fieldfreeQuantity added to order line items (OrderItem), matching the field already available on invoice and credit note line items. It represents quantity provided free of charge in addition to (not part of) quantity — for example, a line with quantity 10 and freeQuantity 2 means 12 units are delivered in total, 2 of which are free of charge.Transport label on transport units
Transport Label (SSCC Labels)
New read-only fieldtransportLabel on transport units for Shipping Notice and Dispatch Instruction Response, returned by GET /v2/transactions. It contains zplUrl and pdfUrl — links to the generated SSCC transport label in ZPL and PDF format. The field is populated by Procuros and is not accepted on input.Automatic cleanup of outdated document versions
Automatic Cleanup of Outdated Document Versions
When a new version of a document is detected, any older version that is still waiting to be collected is now automatically removed from the pending queue. This meansGET /v2/transactions will only ever return the latest version of a document — you no longer need to check isLatestVersion when processing pending transactions, though it remains available for completeness.See Document Versioning for full details.Document versioning fields
Document Versioning
New fields onTransaction and ReceivedTransaction schemas: replacesProcurosTransactionId, replacedByProcurosTransactionId, and isLatestVersion — allowing you to detect superseded documents and trace version chains.New guide: Document Versioning — explains how Procuros links old and new versions of the same document. All receiving guides have been updated with versioning information.Order identifier on shipping notice line items
Order Identifier on Shipping Notice Line Items
New fieldorderIdentifier added to shipping notice line items, allowing you to trace each line back to its originating order.Technical sender party
Technical Sender Party
New partytechnicalSender added to all document types. This identifies the system or party that technically transmitted the document, which may differ from the commercial sender.Relaxed ship-to identifier requirements
Relaxed Ship-To Identifier Requirements
Identifier fields on theshipTo party are no longer required, giving more flexibility when the shipping destination does not carry a formal identifier.Receival notice
Receival Notice
Added receival notice documentation. See Sending Receival Notices.Pricing unit fields on orders
Pricing Unit Fields on Orders
New fieldspricingUnitQuantity and pricingUnitOfMeasure added to order line items, supporting scenarios where the pricing unit differs from the ordering unit.