MAJCDEALL: Additional updates for the order header file SORDER

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.

Context and operating mode

Transaction

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.

Log file

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.

Open tables

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
 

NO_REAJUST: Re-adjustment of the STK quantity to the complete sales unit

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).

Context and operating mode

Transaction

There is no transaction in progress.

Log file

There is no open log file.

Call context

It is called in all the processes for sales order allocations.

It is located in the REAJUSTE_QTY label of the TRTVENALL processing.

Available variables and masks

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

AFTGENALLORD: After allocation of an order line

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.

Context and operating method

Transaction

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.

Log file

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.

Call context

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:

  • From the order management, when using the Create, Save, Delete, Allocation and Close buttons.
  • From the delivery request management, when using the Create, Save, Delete buttons.
  • In the automatic allocation function
  • In the allocation by product function
  • In the de-allocation function
Available variables and masks
  • the allocation has been processed.
  • the order detail or delivery request line is on line, but it is not yet updated with the new quantities allocated. The [F:SOQ] buffer is therefore loaded.  
  • The screen for allocation parameters is on line and loaded.

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.

Open tables

In the table below, the significant content flag indicates that the content matches the context (the current customer is loaded...).

Open tables

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