Kontakt

Ansicht
Dokumentation

SD_SHIPMENT_DELIV_ITEM_FILTER - NOTRANSL: Filtern von Lieferungsdaten aus Transporten

SD_SHIPMENT_DELIV_ITEM_FILTER - NOTRANSL: Filtern von Lieferungsdaten aus Transporten

RFUMSV00 - Advance Return for Tax on Sales/Purchases   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.
SAP E-Book

Functionality

1. Description

In the processing of shipments/freight costs, information from the deliveries and their items is needed. Depending on usage, however, different parts (delivery items) are relevant. The central function module SD_SHIPMENT_DELIV_ITEM_FILTER (function group V56T) for the filtering of delivery data in the creation of shipments and further processing of shipments is designed to replace existing (individually distributed) routines for filtering the delivery data that is read.

The following are currently defined as different applications of the filter (domain flttyp with fixed values):

  • Shipment processing
  • IDOC processing
  • Transportation planning
  • Shipment cost (freight) calculation
  • CO transfer (freight)

Additionally:

  • No processing
  • Checking for transportation relevance (tprel).

The following are currently defined as 'item types':

  • Product selection (psl)
  • Bills of materials or empties (returnable packaging) (bom)
  • Batch split (bat)
  • Text item (txt)
  • Packaging item (pac)
  • Standard items (stn)
  • Discounts in kind (rbk)

(The 'item types' defined here are used only within the function module and should not be confused with the item types for grouping item categories)

A filter profile that allows the individual processing of the item types is defined for each usage (see below).

Because certain item types are liable to occur in nested ( e.g. product selection with batch split material as subitems) or multilevel form (e.g. BOMs as subitems of BOMs), the filter module works recursively. An endless recursive invocation is prevented by an internal counter.

The definition of the filter profiles is effected in the Include RV56FILT via a macro. The filter profile used in each case is generated at runtime. The filter routines themselves are defined in Include LV56TF0F and are invoked dynamically. For the creation of new filter profiles or new filter routines, the two Includes are provided with comments. Additional filter routines must also be defined in Include LV56TF0F. With regard to naming, note the naming convention described in Include RV56FILT. Within the filter routine, the parameter e_filter_not_found must be set to false (0) because this is set to true (1) by the invoking routine before the dynamic perform instruction and is checked after the return.

If a new item type is to be included, in addition to the extension of the filter profiles, above all the routines for the analysis and separation of the items must be modified. In the case of a modification, note that the delivery items i_vtrlp_all within the module must not be changed.

Within the function module, a customer function that offers a postprocessing option after the normal processing of the data is additionally defined. For this purpose, in addition to the filtered data e_vtrlp_filter, the original data i_vtrlp_all and the delivery headers i_vtrlk are also available.

The invocation of the filter module necessitates the following parameters:

  • i_filter_type,,:,,Filter type
  • i_vtrlp_all ,,:,,Delivery items (are not changed within the module)
  • e_vtrlp_filter,,:,,Delivery headers (optional if necessary within the customer function)

Overview of filter profiles used:


  • Product selection
  • Shipment processing: ,,Substitute only

  • IDOC processing:,,,,Substitute only

  • Transportation planning:,,,,Original only

  • Freight cost processing:,,Substitute only

  • CO transfer:,,,,Substitute only

  • Bill of materials:
  • Shipment processing,,,,tvlp-tprel (Customizing)

  • IDOC processing:,,,,tvlp-tprel (Customizing)

  • Transportation planning:,,,,bwart <>0 (Movement type)

  • Freight cost processing:,,tvlp-tprel (Customizing)

  • CO transfer:,,,,tvlp-tprel (Customizing)

  • Batch split
  • Shipment processing:,,,,Main item only (with quantitites)

  • IDOC processing:,,,,Main and subitems

  • Transportation planning: Main item only (with quantitites)

  • Freight cost processing:,,Main and subitems

  • CO transfer:,,,,Main and subitems

  • Packaging item
  • Transportation planning:,,,,Not relevant

  • IDOC processing:,,,,Not relevant

  • Transportation planning:,,,,Not relevant

  • Freight cost processing:,,Not relevant

  • CO transfer:,,,,Not relevant

  • Text item
  • Shipment processing:,,,,tvlp-tprel (Customizing)

  • IDOC processing:,,,,tvlp-tprel (Customizing)

  • Transportation planning:,,,,tvlp-tprel (Customizing)

  • Freight cost processing:,,Not relevant

  • CO transfer:,,,,Not relevant

  • Standard item
  • Shipment processing:,,,,Relevant

  • IDOC processing:,,,,Relevant

  • Transportation planning:,,,,Relevant

  • Freight cost processing:,,Relevant

  • CO transfer:,,,,Relevant

  • Discount in kind
  • Shipment processing:,,,,Relevant

  • IDOC processing:,,,,Relevant

  • Transportation planning:,,,,Relevant

  • Freight cost processing:,,Relevant

  • CO transfer:,,,,Relevant

2. Invocation of filter module (modifications in other program parts)

Deliveries are accessed in the program (via several function modules arranged hierarchically) for the generation of shipments or in the processing of existing shipments of different items:

  • (1) RV_SHIPMENT_PRINT_VIEW
  • (2) RV_SHIPMENT_VIEW
  • (3) RV_SHIPMENT_READ
  • (4) SD_SHIPMENT_DELIVERY_VIEW

From the superordinate function module in each case, the subordinate module below it is accessed. To keep the number of invocations down, the filter module is built into SD_SHIPMENT_DELIVERY_VIEW. The filter type is passed on from (1) to (4). The interfaces of the function modules are extended.

In order not to change the functionality towards the outside (particularly in the case of customer solutions), the filter type is an optional parameter in all cases. It currently contains the mandatory pre-set value 'check for transportation relevance' in all cases. Accordingly, the previous standard filter in the form routine delivery_read (LV56TF0D) (check for transportation relevance) was removed from the function module RV_SHIPMENT_READ. In all invocations of the function modules requiring a special filtering of the data, the filter type must be passed on accordingly.

Within the function module SD_SHIPMENT_DELIVERY_VIEW, the data is read from database from the table lips. Optionally, a reduced data record is read in here in the form routine minimized_lips_select (LV56LF02). This data record was enhanced for the filter module because additional fields are necessary to differentiate between the item types/for certain filter routines. If or when new filter routines or new item types are added, this data record may have to be enhanced further.

Important:,,

The indicators for the different item types (e.g. xchar, uepos, uepvw, posar , etc.) are not changed during filtering. This means that (e.g.) if the main item of a product selection is removed, the subitems remain identified as such and consequently the data is incomplete. For this reason, as a rule multiple filtering of the data is not possible.

Example

Notes

Further information

Functionality

1. Description

In the processing of shipments/freight costs, information from the deliveries and their items is needed. Depending on use, however, different parts (delivery items) are relevant. The central function module SD_SHIPMENT_DELIV_ITEM_FILTER (function group V56T) for filtering the delivery data in the creation or further processing of shipments is designed to replace the existing (individually distributed) routines for filtering the delivery data read.

The following are currently defined as different applications of the filter (domain flttyp with fixed values):

  • Shipment processing
  • IDOC processing
  • Transportation planning
  • Shipment cost (freight) calculation
  • CO transfer (freight)

Additionally:

  • No processing
  • Check for transportation relevance (tprel).

The following are currently defined as 'item types':

  • Product selection (psl)
  • Bills of materials or empties (returnable packaging) (bom)
  • Batch split (batch split) (bat)
  • Text item (txt)
  • Packaging item (pac)
  • Standard items (stn)
  • Discount in kind (rbk)

(The 'item types' defined here are used only within the function module and should not be confused with the item types for grouping item categories)

A filter profile that allows the individual processing of the item types is defined for each usage (see below). The determination of the relevant item type is effected via certain fields (listed in attachment A).

Because certain item types are liable to occur in nested ( e.g. product selection with batch split material as subitems) or multilevel form (e.g. BOMs as subitems of BOMs), the filter module works recursively. An endless recursive invocation is prevented by an internal counter.

The definition of the filter profiles is effected in the Include RV56FILT via a macro. The filter profile used in each case is generated at runtime. The filter routines themselves are defined in Include LV56TF0F and are invoked dynamically. For the creation of new filter profiles or new filter routines, the two Includes are provided with comments. Additional filter routines must also be defined in Include LV56TF0F. With regard to naming, note the naming convention described in Include RV56FILT. Within the filter routine, the parameter e_filter_not_found must be set to false (0) because this is set to true (1) by the invoking routine before the dynamic perform instruction and is checked after the return.

If a new item type is to be included, in addition to the extension of the filter profiles, above all the routines for the analysis and separation of the items must be modified. In the case of a modification, note that the delivery items i_vtrlp_all within the module must not be changed.

Within the function module, a customer function that offers a postprocessing option after the normal processing of the data is additionally defined. For this purpose, in addition to the filtered data e_vtrlp_filter, the original data i_vtrlp_all and the delivery headers i_vtrlk are also available.

The invocation of the filter module necessitates the following parameters:

  • i_filter_type,,:,,Filter type
  • i_vtrlp_all ,,:,,Delivery items (Not changed within the module)
  • e_vtrlp_filter,,:,,Delivery headers (optional if necessary within the customer function)

Overview of filter profiles used (names of individual filter routines, see points 3 and 4):


  • Product selection
  • Shipment processing:,,Substitute only

  • IDOC processing:,,,,Substitute only

  • Transportation planning:,,,,Original only

  • Freight cost processing:,,Substitute only

  • CO transfer:,,,,Substitute only

  • Bill of materials
  • Shipment processing:,,,,tvlp-tprel (Customizing)

  • IDOC processing:,,,,tvlp-tprel (Customizing)

  • Transportation planning:,,,,bwart <>0 (Movement type)

  • Freight cost processing:,,tvlp-tprel (Customizing)

  • CO transfer:,,,,tvlp-tprel (Customizing)

  • Batch split
  • Shipment processing:,,,,Main item only (with quantities)

  • IDOC processing:,,,,Main and subitems

  • Transportation planning:,,,,Main item only (with quantities)

  • Freight cost processing:,,Main and subitems

  • CO transfer:,,,,Main and subitems

  • Packaging item
  • Shipment processing:,,,,Not relevant

  • IDOC processing:,,,,Not relevant

  • Transportation planning:,,,,Not relevant

  • Freight cost processing:,,Not relevant

  • CO transfer:,,,,Not relevant

  • Text item
  • Shipment processing:,,,,tvlp-tprel (Customizing)

  • IDOC processing:,,,,tvlp-tprel (Customizing)

  • Transportation planning:,,,,tvlp-tprel (Customizing)

  • Freight cost processing:,,Not relevant

  • CO transfer:,,,,Not relevant

  • Standard item
  • Shipment processing:,,,,Relevant

  • IDOC processing:,,,,Relevant

  • Transportation planning:,,,,Relevant

  • Freight cost processing:,,Relevant

  • CO transfer:,,,,Relevant

  • Discount in kind
  • Shipment processing:,,,,Relevant

  • IDOC processing:,,,,Relevant

  • Transportation planning:,,,,Relevant

  • Freight cost processing:,,Relevant

  • CO transfer:,,,,Relevant

2. Invocation of filter module (modifications in other program parts)

Deliveries are accessed in the program (via several function modules arranged hierarchically) for the generation of shipments or in the processing of existing shipments for different items:

  • (1) RV_SHIPMENT_PRINT_VIEW
  • (2) RV_SHIPMENT_VIEW
  • (3) RV_SHIPMENT_READ
  • (4) SD_SHIPMENT_DELIVERY_VIEW

From the superordinate function module in each case, the subordinate module below it is accessed. To keep the number of invocations down, the filter module is built into SD_SHIPMENT_DELIVERY_VIEW. The filter type is passed on from (1) to (4). The interfaces of the function modules are extended.

In order not to change the functionality towards the outside (particularly in the case of customer solutions), the filter type is an optional parameter in all cases. It currently contains the mandatory pre-set value 'check for transportation relevance' in all cases. Accordingly, the previous standard filter in the form routine delivery_read (LV56TF0D) (check for transportation relevance) was removed from the function module RV_SHIPMENT_READ. In all invocations of the function modules requiring a special filtering of the data, the filter type must be passed on accordingly.

Within the function module SD_SHIPMENT_DELIVERY_VIEW, the data is read from database from the table lips. Optionally, a reduced data record is read in here in the form routine minimized_lips_select (LV56LF02). This data record was enhanced for the filter module because additional fields are necessary to differentiate between the item types/for certain filter routines. If or when new filter routines or new item types are added, this data record may have to be enhanced further.

Important:,,

The indicators for the different item types (e.g. xchar, uepos, uepvw, posar , etc.) are not changed during filtering. This means that (e.g.) if the main item of a product selection is removed, the subitems remain identified as such and consequently the data is incomplete. For this reason, as a rule multiple filtering of the data is not possible.

Example

For an example, see function module SD_SHIPMENT_DELIVERY_VIEW

Notes

Further information





Parameters

E_VTRLP_FILTER
I_FILTER_TYPE
I_VTRLK
I_VTRLP_ALL

Exceptions

FILTERROUTINE_INCORRECT
FILTERROUTINE_NOT_FOUND
FILTERTYPE_NOT_FOUND
ITEM_PROCESSING_ERROR

Function Group

V56T

CL_GUI_FRONTEND_SERVICES - Frontend Services   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.

Length: 21554 Date: 20240523 Time: 081259     sap01-206 ( 278 ms )