Delivery order message EWS - LXIR Suborder LXIRSuborder result

The flow describes the arrangement of new purchase order and return order, as well as change and cancellation.

Return orders are handled as a customer order type in LXIR and as a purchase order type in the EWS. Everything that is called the purchase order or row below also applies to return orders.

Purchase orders are called Call-off orders in LXIR.

Addition of new purchase order line / return order line cannot be done.

Change of purchase order / return order can be made. This occurs when changing the delivery date and or number. Cancellation can be made by full purchase order / return order but not line. However, cancellation of the purchase order line / return order line takes place during partial storage as the old line is replaced with a new one and this in order to reduce the risk of mis-storage. If DELVRY arrives at the ready-marked line, it must be rejected and alerted.

No feedback is made from the EWS in addition to the submission of registration.

A PURORD does not have to mean that there will be a DELVRY in response to all purchase order lines / return order lines, but the answer to these can come in several separate DELVRY messages. This happens when certain lines in a PURORD are answered but not all simultaneously. There should be no more answers with reference to the same POR and associated sequence number in different messages. If this happens, the answer must be rejected and an alarm added to the error log. On the other hand, there may be several answers to the same purchase order line / return order line and sequence number in the same message.

LXIR EWS only works with balances, not the term "be".

NEW PURCHASE ORDER

CHANGE PURCHASE ORDER

Purchase Order

All triggerings are created by events in LXIR.

• New : Call-off orders against EWS-controlled warehouses are created. Call-off orders are sent immediately to LWS / EWS.
• Change : When changing the above call order (the entire order or single line) in the ArrivalDate and OrderQuantity fields, a modified purchase order is immediately sent to the EWS.
• Cancellation : Upon cancellation of the above call-off order, a cancellation is sent to the EWS immediately. Only entire user interface purchase orders can be canceled.

All triggerings are created by events in LXIR.

• New : Return order against EWS controlled stock is created. Return orders are sent immediately to the EWS.
• Change : When changing the above order (the entire order or single line) in the ArrivalDate and OrderQuantity fields, a changed return order is sent to the EWS immediately.
• Cancellation : Upon cancellation of the above return order, a cancellation is sent to the EWS immediately. Only whole return order from user interface can be canceled.

• Purchase orders and return orders always start from LXIR.
• The article must be posted
• The supplier must be registered
• The client must be registered as a supplier (for return orders)
• Upon return order, client is sent as supplier number (SupplierId)

XML structure

 LXIRSubOrder (1)

 Envelope (1) LXIRSubOrder

LXIRSubOrder Header (1-999)

HeaderInfo (1) LXIRSubOrder

Header SubOrderHeader (1)

LXIRSubOrder Header SubOrderHeader SubOrderHeaderInfo (1)

HeaderAds (1) LXIRSubOrder

LXIRSubOrder Header SubOrderHeader SubOrderRow (1-99999)

SubOrderRowInfo (1) LXIRSubOrder

SubOrderRowAdditions (1) LXIRSubOrder

LXIRSubOrder Header SubOrderHeader SubOrderRowPreAdvice(0-99999)

SubOrderRowPreAdviceInfo(1-99999) LXIRSubOrder

Here, "IN" is always sent if it is a call-off and "RV" or "KR" if it is a return order. (RV refers to Return order Claim, KR refers to Return Order Known and Return order unknown)

The following OperationCode combinations on head and row level are allowed for purchase orders / return orders

When changing lines / rows, only these rows are sent down.

When a PURORD can be counted as completed, the response has arrived on all lines as expected, a cleaning message should immediately be sent to the EWS. This message should be viewed as a cancellation of the entire purchase order / return order. This is done by sending a PURORD with only the following information at the main level

OperationCode: 3

OrderNumber: Current

What can happen when checking DELVER is that only a part of the expected number on the line came up. Partial storage and then the following should happen if there is no information that it is OK with a certain percentage deviation.

The same order head must be sent but with:

OperationCode: 0 (Nolla).

The line delineated is now to be canceled immediately and this is done on POR by sending the following:

SubOrderHeader SubOrderRow SubOrderRowAdditions OperationCode: 3

OrderPosition: Current row

OrderSubPosition: Current subpos

Then it's time to put up a new POR as the original but now with

SubOrderHeader SubOrderRow SubOrderRowAdditions OperationCode: 1

OrderPosition: Current row

OrderSubPosition: Increase by 1

OrderQuantity: The number that did not arrive.

Delivery date is available on both main level and row level. For new layouts, these have the same dates, but this can be changed in two ways:

1. All lines change dates and head dates. (Change delivery date for the entire purchase order / return order)
2. Single line changes date.

XML structure

LXIRSubOrderResult (1)

Envelope (1) LXIRSubOrderResult

Header (1)

HeaderInfo (1)

LXIRSubOrderResult \ t

SubOrderHeaderInfo (1) LXIRSubOrderResult

SubOrderRow (1-99999) LXIRSubOrderResult

SubOrderRowInfo (1) LXIRSubOrderResult SubOrderRowInfo

DeliveryBlocked (0-1) LXIRSubOrderResult

The element is optional. This can be seen as an ITECHG being sent with blocking of balance directly upon delivery.

To check the response to a purchase order / return order, reference is made to the line with OrderNumber + OrderPosition + OrderSubPosition.

The answer to a line can come "split". That is, a row that is sent down with expected delivery of eg 300pcs can then come back with three rows of 100pcs on each. However, the answer to a line will always be collected within one and the same message. In this case of split, all rows have the same OrderPosition + OrderSubPosition, ie these do not count in the answer.

Over-delivery is not allowed, parent system must be updated and changed line sent before placing in storage.