Pixi API documentation

Unofficial · by koempf24.de

Postman collection
Direct-Fulfillment Write

pixiDFCreateInvoices

Creates direct fulfilment (DF) invoices for order lines that are ready, optionally restricted to and enriched with ship vendor and tracking data from XML.

The call creates invoices for direct fulfilment orders. The actual work is done by the internal procedure Pixi_CreateFulfillmentIncoices, which runs with CreateEmp = 'API'.

Steps

  1. An exclusive application lock pipiDFCreateInvoices is requested with a timeout of 5 seconds, so that parallel runs are serialised.

  2. If OrderlinesXML is given (an empty string counts as NULL), the elements /Orderlines/Orderline are read with the child elements OrderlineKey, ShipVendor, ShipmentTrackingId and ReturnTrackingId.

  3. If ShowDetailedMessages = 1, the input is validated first:

    • The XML must be present and contain at least one Orderline.
    • The ship vendor code (taken from the first line of each order) may be at most 3 characters long.
    • All shipment tracking IDs of an order, joined with ;, may be at most 512 characters long. The same limit applies to the return tracking IDs.
    • Every OrderlineKey must exist in Orderlines.

    If any check fails, all error rows are returned and no invoice is created.

  4. Invoices are created. The behaviour depends on the settings EnableFulfilmentTypeOne and EnableFulfilmentTypeTwo:

    • Type one: order lines from the XML that have status FUT are first set to FUS. Then one invoice is created per order that has FUS lines. With XML, only the listed lines are used; without XML, all FUS lines are used.
    • Type two: candidate orders are those whose lines are all FUS or in a final state, and that have at least one FUS line without an invoice. The XML does not restrict the candidate orders. It only restricts which FUS lines are added to the invoice. Lines with status MIN are always added.

  5. Each order is processed in its own transaction:

    • The invoice is created, flagged with Fulfillment = 1 and given its invoice positions.
    • The ship vendor from the XML overrides the ship vendor of the order.
    • Tracking IDs from the XML are stored on the invoice. Several IDs can be separated by ;, and each distinct ID becomes its own invoice package.
    • The order lines are set to AUS with InvRef and ShipDate.
    • An invoice number is assigned, an entry is posted to the customer account and the invoice is scanned out.
    • An InvoiceCreated event is published.

  6. If ShowDetailedMessages = 1, one status table is returned:

    • one OK row listing the invoice numbers linked to the given order lines;
    • an ERROR row listing orders whose given lines have no invoice position;
    • an ERROR row if neither of the two applies.

With ShowDetailedMessages = 0, no result set is returned.

Notes

  • Errors are swallowed. The whole body runs in TRY/CATCH. The CATCH block only releases the application lock, so SQL errors never reach the caller. With ShowDetailedMessages = 0 the caller gets no feedback at all.
  • Lock result is not checked. The return value of sp_getapplock is ignored. If the lock cannot be obtained within 5 seconds, processing continues anyway.
  • Lock not released on validation errors. On the early returns after a validation error the lock is not released explicitly. It stays with the session until the session ends.
  • Truncation risk. ErrorMessage is varchar(512) and the list of invoice numbers is held in a varchar(512) variable. Long lists of order numbers or invoice numbers can be truncated, or can raise a truncation error that is then silently caught.
  • Validation is optional. It only runs with ShowDetailedMessages = 1. Without it, the internal procedure reads ShipVendor as varchar(3) and the tracking IDs as varchar(512), so longer values may be cut.
  • Meaning of the OK row. It lists every invoice linked to the given order lines, which can include invoices created earlier. The code comment names a supplier without CanDoDirectFulfillment or a line status other than FUT as typical reasons for a missing invoice.
  • Settings.
    • If neither EnableFulfilmentTypeOne nor EnableFulfilmentTypeTwo is 1, no invoices are created.
    • With DoNotSendAUSmailOnFulfillment = 1/Y, the order lines are additionally marked CustomerEMailed = 'Y'.
  • Invoice numbers. An existing external invoice number on the order lines (InvoiceNrExternal) is used when the invoice is created. The internal procedure then calls Pixi_GetNextInvNr and writes its result to InvoiceNr. Whether that keeps the external number cannot be seen because that procedure is not attached.
  • Rollback per order. An invoice without positions is rolled back and deleted, as is an order that produced errors. Other orders are not affected.
  • Further side effects. Several nested procedures are not attached: GOS_Qi_InvoiceNOD, Pixi_CA_AddPixiInvoice, GOSScanOutInvoice, Pixi_PollCreateRecords, Pixi_MQ_EventPublish and Pixi_AddDataForSEPAExportToInvoice. Their side effects are not documented here.

Tables used

Orderlines · Write Invlines · Write Invoices · Write InvoicePackage · Write OrderHeader · Read Addresses · Read Customers · Read OrderStates · Read Currency · Read ShipVendor · Read
SQL object:
dbo.pipiDFCreateInvoices
Updated at 2026-10-30