Postman collection
Orderlines Write

pixiBreakOrderline

Splits (breaks) an order line into two lines by moving a given quantity into a new order line, optionally with a new status.

Breaks an existing order line, identified by OrderlineKey, into two order lines. The call is a thin wrapper around the internal procedure GOSBreakOrderline. All parameters are passed through unchanged.

Steps:

  1. GOSBreakOrderline is executed with OrderlineKey, NewQty, NewStatus, InvlineRef, UserName and BinRef. Its internal parameters TermID, LargeOrderToBreak and PLHKey keep their defaults.
  2. GOSBreakOrderline opens a transaction, or sets a savepoint if a transaction is already open. It takes an exclusive application lock named Orderline_<OrderlineKey> with a 5-second timeout, then calls GOSBreakOrderline_Base to do the actual split.
  3. The inner procedure returns a row with Success and NewOrderlineKey. The wrapper captures this row internally and does not pass it to the caller.
  4. If the captured Success value is not 1, the call raises an error with severity 11.

On success the call returns no result set. The key of the newly created order line is not returned. Callers must find it afterwards, for example by reading the order lines of the order again.

Notes

  • The split logic lives in GOSBreakOrderline_Base, which is not attached. The exact meaning of NewQty (quantity of the new line or of the remaining line), the valid values of NewStatus, the effect of InvlineRef and BinRef, and the tables changed cannot be derived from the available code.
  • GOSBreakOrderline uses an exclusive application lock per order line (sp_getapplock, 5-second timeout). Concurrent splits of the same line are serialized. If the lock cannot be obtained, the error Could not obtain the lock is raised internally.
  • Errors inside GOSBreakOrderline are caught. The transaction is rolled back and the error is logged via log.InsertError. Whether the original error then reaches the caller depends on log.InsertError, which is not attached.
  • The result of the inner procedure is captured with INSERT ... EXEC. A ROLLBACK inside an INSERT ... EXEC can itself cause a SQL Server error, so failures may surface with a different message than expected.
  • Pitfall: if the inner procedure returns no row, the check on Success evaluates to NULL. In that case no error is raised, even though nothing may have been split.
SQL object:
dbo.pipiBreakOrderline
Updated at 2026-10-30