Ansicht
Dokumentation
SD_SHIPMENT_SPLIT_CRITERIA - NOTRANSL: VT04: Lieferungen aufgrund bestimmter Kriterien zu Transporten z
rdisp/max_wprun_time - Maximum work process run time BAL_S_LOG - Application Log: Log header dataThis documentation is copyright by SAP AG.
Functional module SD_SHIPMENT_SPLIT_CRITERIA
Interface
In this functional module, split criteria are processed which are spe- cified in the complex data category I_SPLIT_CRITERIA.
I_SPLIT_CRITERIA is a table with field names ( = split criterion, field from VTRLK), for which more information is avaialble (e.g., ignore upper/lower case, etc.). Additionally, groupings can be made for each field. A group is presented via a RANGE table. Hence, groupings are a table with tables. The split criteria, as a whole, are a table with tables with tables (see TYPE-POOL VT04).
Delivery data is given via I_VTRLK and I_VTRLP. The result of the (preliminary) collection returns in C_VTTP.
Principle
The approach is clarified in the following example:
Assume we have 3 split criteria:
- Route
- Shipping point
- Goods recipient
Two deliveries may go into one shipment only if route, shipping point and goods recipient are the same. How can one generate this collection in a high-performing manner ?
One possibility is to generate an internal table with delivery number and the three split criteria. One sorts these according to the split criteria and then goes over this table. Then, always when split cri- terial change, a new shipment must be created.
This procedure has the disadvantage that the internal table must be assigned in a fixed way (i.e., route, shipping point and goods reci- pient). What's to be done if other fields are selected from the field catalogue (load point, carrier, postal code of the goods recipient, etc.)? In principle, all fields of the field catalogue had to be available. Only those chosen as split criteria are filled, however.
This has the disadvantage that practically the entire data volume of deliveries would be doubled. Since, just then, very many deliveries are processed in collective processing, this is not recommended.
Hence, the following solution:
One split criterion after the other is handled. A small table is
laid out for each containing the delivery number and an unformatted data field (CHAR45) in which the
split criterion is copied (in our case, e.g., for delivery 0080000414, route 000001; for delivery 0080000415, route 000003, etc.).
This table can be sorted and sequence numbers can now be assigned (this is increased each time when the route changes). Instead of with the route itself, work is only done with the sequence number (regarding the split criterion 'route').
Now, one can buile an additinal table in which the sequence number for deliveries and for each criterion is stored. This is a 'table with tables', whereby the 'main table' contains so many entries as there are deliveries, while each 'subtable' is very small (type INTEGER) and has only as many entries as there are split criteria.
The disk space requirement is minimized in this way. Additionally, one can now also process groupings because these ultimately influence only the sequence number.
The main table can now be sorted (according to the field 'subtable'). Thereafter, one goes through the main table and then, when the subtable changes (when the split criteria change), a new shipment must be created.
Processing in the functional module
An internal table is formed (L_SORT_TAB) which contains as an entry among other things, a table of sequence numbers (i.e., a table with tables). These numbers are the sequence numbers with regard to the first, second, third, ... split criterion.
In Form init_sort_tab a table is first laid out which contains for each delivery a table with N sequence numbers (N = number of split cri- teria). With 200 deliveries and 4 split criteria, L_SORT_TAB contains 200 entries and each entry has a small internal table with 4 INTEGER numbers (the sequence number). These sequence numbers are not defined and L_SORT_TAB was laid out only for storage management reasons (if the tables in the internal table are successively enlarged, this uses up more time).
Processing proceeds split criterion by split criterion and the following happens:
- In Form create_help_tab, an auxiliary table is laid out for each split criterion (L_HELP_TAB), which, for each delivery, contains the entry which is the split criterion (e.g., route). If groupings are assigned, the grouping number is determined and placed as the sequence number into L_HELP_TAB.
- L_HELP_TAB is now sorted in Form create_sequence_numbers according to the criterion (e.g., according to route), and the sequence numbers are assigned (so long as they were not already preassigned by the grouping). In grouping formation, one can specify whether the deliveries not falling into the groups
- are to be ignored
- all fall into one group
- eacj value forms its own group
This is taken into account here as well.
- On the basis of this transaction, each delivery now has a sequence number with reference to the current split criterion. This is placed into table L_SORT_TAB in move_enumeration_to_sorttab.
In form create_shipment_assignment, L_SORT_TAB is finally sorted accor- ding to the 'Subtable'. Then, when this changes, a new shipment is formed. The result is placed into C_VTTP.
Further information
Parameters
C_VTTPI_SPLIT_CRITERIA
I_VTRLK
I_VTRLP
Exceptions
Function Group
V56MSUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up Fill RESBD Structure from EBP Component Structure
This documentation is copyright by SAP AG.
Length: 6088 Date: 20240523 Time: 070630 sap01-206 ( 125 ms )
