Use this entry point to take over after the allocation of an order line or a delivery request line.
For the order lines, it is used to perform additional updates for the corresponding order header or updates for other tables
For the delivery request lines, since the corresponding order header is not updated, it is used to perform updates for other tables.
It is called in such functions as automatic allocations, allocations by product, de-allocations and at the level of the manual allocation button.
There is a transaction in progress (allocation update transaction, with update of the order line, of the corresponding WIP and of the order header) (for orders only).
The GOK variable is used and tested. It is equal to 1. It can be set to 0 if the transaction should be abandoned.
There is an open log file.
It gives for each order line processed, the allocated/de-allocated quantity and/or the shortage quantity, and for each non processed line, the reason why the allocation could not be carried out.
Different call cases - Available variables and masks
This entry point is called:
in the automatic allocation function,
in the allocation by product function,
in the de-allocation function,
at the level of the manual allocation button.
It is called during the allocation update transaction for an order line or for a delivery request:
the allocation has been processed.
the order detail line or delivery request line has been updated. The [F:SOQ] buffer is therefore loaded. The WIP level has been updated.
For the orders, the order header has been read with lock, the fields are updated, and you are right before the rewrite order. The [F:SOH] buffer is loaded.
For delivery requests, the order header is loaded (buffer [F :SOH]) but it has been read without lock.
At the level of automatic processing, the allocation processing is carried out from the order lines according to a specific sort order. The order number is not the first sort criterion. As a consequence, the order header update is not carried out once but for each line that is processed. This entry point is thus called for each processed line.
In the table below, the significant content flag indicates that the content matches the context (the current customer is loaded…).
Table | Significant content | Table Title |
SORDER | Yes | Order headers |
SORDERQ | Yes | Order line quantities |
SORDERP | Yes | Order line prices |
SORDERC | Yes | Product / customer orders (contract orders) |
ITMMASTER | Yes | Products |
ITMMVT | No | Product - Movements |
ITMFACILIT | Yes | Products - Sites |
STOALL | No | Allocation |
STOCK | No | Stock |
STOLOT | No | Lot numbers |
Use this entry point in the processing for sales order allocations.
After determination of the quantity to be allocated in STK, this quantity is re-adjusted so that it corresponds to a whole number of sales units. This entry point is used to avoid carrying out this re-adjustment (sales unit does not correspond to a packing unit in STK for example).
There is no transaction in progress.
There is no open log file.
It is called in all the processes for sales order allocations.
It is located in the REAJUSTE_QTY label of the TRTVENALL processing.
In order to avoid performing the re-adjustment of the quantity in whole sales unit, the GOK global variable needs to be set to 0.
For example:
GOK = 0
Use this entry point to take over after the allocation of an order line or a delivery request line.
It is used after the creation/modification/reduction/deletion of an allocation in order in know the allocated quantity and shortage determined by the allocation engine.
The entry point is called in the GENALLORD subprogram.
It is called upon allocation/deallocation of an order line or delivery request line.
It is called in the order and delivery request management, and in the functions for automatic allocations, allocation by product and deallocation.
There is one transaction in progress: Update transaction for an order or a delivery request when the GENALLORD subprogram is called from the order or delivery request management. Update transaction for an allocation when the GENALLORD subprogram is called from the allocation functions.
There is no open log file when the GENALLORD subprogram is called from the order or delivery request management. There is an open log file when the GENALLORD subprogram is called from the allocation functions.
The entry point is called from the GENALLORD subprogram of TRTVENALL. This subprogram is called upon allocation/deallocation of an order line or delivery request line.
It is called for each line concerned by an allocation:
The following variables are the variables passed as parameters in the GENALLORD subprogram:
On receipt:
· LSOQ: SOQ screen class ([F:SOQ] by default)
· LSOP: SOP screen class ([F:SOQ] by default)
· LTRTLIG: Processing type
"C"=Creation, "M"=Modification, "D"=Reduction, "A"=Cancellation
· LIMPCLI: Posting of the customer allocations (1=No, 2=Yes)
· LGENSHT: Generation of the shortages (1=No, 2=Yes)
· LALLPAR: Partial allocations (1=No, 2=Yes)
On issue:
· LALLSTU: Actual allocated quantity
· LSHTSTU: Shortage quantity
· LRET: Return code
The WALLSTU work variable contains the actual allocated quantity.
The WSHTSTU work variable contains the shortage quantity.
The EP is called right before the LALLSTU and LSHTSTU variables are populated with the WALLSTU and WSHTSTU variables. It is used to block WALLSTU and WSHTSTU, and it does not provide the possibility to change them.
In the table below, the significant content flag indicates that the content matches the context (the current customer is loaded...).
In the table below, the significant content flag indicates that the content matches the context (the current customer is loaded...).
Table | Significant content | Table title |
SORDERQ | Yes | Quantity line orders |
ITMMASTER | Yes | Products |