Ansicht
Dokumentation

SD_DELIVERY_FOR_TRANSPORT - NOTRANSL: Lieferungen selektieren für Transport

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Functionality

This functional module serves in the selection of deliveries for the shipment.

If desired (OPTION_SELECTION_SCREEN = 'X'), a selection screen is displayed on which the user can enter the selection criteria according to which he/she wishes to select deliveries. One must observe the Functional method of delivery selection.

This selection screen belongs to report RV56LFSL. This is called up via SUBMIT, whereby assignments are given to it (e.g., whether it is called up for goods receipt or for goods issue ---> Parameter SHIPMENT_PROCESSING_TYPE).

Communication with this report runs via memory (EXPORT/ IMPORT): After pressing the 'Execute' button (F8), input is exported into memory (SELECT_OPTIONS_EXPORT(RV56LFSL)) and imported again by the functional module (SELECT_OPTIONS_IMPORT(SAPLV56L)).

Thereafter, a is checked as to whether the data entered fits the actual shipment completion type (SHIPMENT_PROCESSING_TYPE). It can happen that the user used a variant for incoming shipments even though he/she wants to create outgoing shipments. This would cause difficulties.

The selection screen can be prepared by assigning the name of a selec- tion variant for report RV56LFSL to this functional module (SELECTION_SET) or by predetermining data in table SELECT_OPTIONS.

OPTION_DIALOG can control whether this functional module is to bring I-Messages or not.

OPTION_SEARCH_STRATEGY assigns how deliveries are to be searched for. The default is 'I' for the search via the Index table VTRDI. 'L' is a direct input of delivery numbers. It serves only test purposes, however.

The actual selection takes place in this functional module.

This has the following consequences:

• First, assignments to the heading 'Reference to' are processed. In this way it is determined, for example, in the specification of ship- ment numbers, which deliveries are in these shipments. The result could be, necessarily, a quantity of delivery numbers inasmuch as 'Reference to' specifications were made). See, for example, BEZUG_FUER_LIEFERUNGEN(SAPLV56L).

• A SELECT is made on the index table VTRDI with the delivery numbers (so far as they are available) and with the specified selection criteria (INDEX_SELEKTIEREN(SAPLV56L)). The result is now a table with concrete delivery numbers corresponding to the selection criteria.

• The deliveries are read via the functional module SD_SHIPMENT_DELIVERY_VIEW.

• Checks are executed as to whether the deliveries are really valid:

• Does the company code of the plant of the deliveries match the company code of the shipment planning point (Parameter TRANS_PLANNING_POINT)?

• Is the delivery not blocked?

• There are still selection criteria not checked up till now, since they are not in the index table VTRDI (e.g., postal code). These are now checked.

• The result now is deliveries which fulfill all criteria. The delivery header data is in table DELIVERY_HEADER and the item data is in DELIVERY_ITEM. The export parameter NUMBER_OF_DELIVERIES specifies how many deliveries were successfully selected. ERROR_OCCURED displays whether errors occurred.

If desired (NO_DISPOSITION = SPACE), the deliveries are immediately allocated to the shipment withe number SHIPMENT_NUMBER. The table SHIPMENT_ITEM is changed and also the shipment header SHIPMENT_HEADER. This may only happen, however, if the shipment is not yet completed (parameter SHIPMENT_COMPLETION).

In the framework of shipment processing, not all data of the delivery is needed. If OPT_MINIMIZED_DELIVERY_DATA = 'X', only that data from the database really necessary is read (a lot of item data is omitted). This parameter is then passed onto the functional module SD_SHIPMENT_DELIVERY_VIEW.

Blocking the delivery is normally carried out with the scope parameter '2'. I.e., the block is transferred to the update task during the asynchronous update. With ENQUEUE_SCOPE_PARAMETER another scope para- meter can be assigned for the block. For example, in collective pro- cessing for shipment creation (transaction VT04), the block is not to be passed along but rather to be retained by the current program. The reason for this is that deliveries in collective processing can be thoroughly and repeatedly processed (e.g., initial, main and subsequent shipments of a shipment chain). Between these parts, updates occur but the blocks are not to disappear).

This functional module creates a log of the selection. This log can be displayed with SD_DELIVERY_FOR_TRANSPORT_LOG.

Example

Notes

Further information

Parameters

DELIVERY_HEADER
DELIVERY_ITEM
ENQUEUE_SCOPE_PARAMETER
ERROR_OCCURED
E_DISPO
LEG_INDICATOR
NO_DISPOSITION
NUMBER_OF_DELIVERIES
OPTION_DIALOG
OPTION_SEARCH_STRATEGY
OPTION_SELECTION_SCREEN
OPT_MINIMIZED_DELIVERY_DATA
RUN_WITH_SELECT_OPTIONS
SELECTION_SET
SELECT_OPTIONS
SHIPMENT_COMPLETION
SHIPMENT_HEADER
SHIPMENT_ITEM
SHIPMENT_NUMBER
SHIPMENT_PROCESSING_TYPE
STANDARD_SEL_SET
TRANS_PLANNING_POINT

Exceptions

EMPTY_SHIPMENT
WRONG_CALL

Function Group

V56L

BAL Application Log Documentation   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.

Length: 6813 Date: 20240523 Time: 051054     sap01-206 ( 115 ms )