consolut - /SAPAPO/FOT_CALCULATE_MERGE - Function module with Split algorithm

/SAPAPO/FOT_CALCULATE_MERGE - Function module with Split algorithm

Fill RESBD Structure from EBP Component Structure General Data in Customer Master
This documentation is copyright by SAP AG.

Functionality

Merge several orders into one order:

There are three ways to Merge an order. These are distinguished from the field LS_FOTMOD-WIPMOVE in the subroutine: MERGE_SOFT_MAPPING.

HARD Merge:,,No WIP allowed at a RP that does not have a mapping.
Soft UP :,,WIP from non-mapped RPs is added to the earlier mapped RP: The mapping for non-mapped RPs is added to accomplish this task.
Soft DOWN:,,WIP from non-mapped RPs is added to the succeeding mapped RP: The mapping for non-mapped RPs is added to accomplish this task.

DIFFERENT UNITS OF MEASURE HANDLING:

This function module takes care of the unit of measure changes between the orders, as well as the reporting point quantities in the order in the following manner:

The Surviving order header quantity is used as the base unit of measure (BASEUNIT) in the order.

All the quantities in the order are converted to the base unit before calculations. The unit ofmeasure conversion must be defined in the original order's material master or in the configuration.If configuration also has the conversion factor defined for the two units in question, then the material master conversion factor will be over-written by the one defined in the configuration.

As the final product of the merging order has to be same as the surviving order's product, the header unit of measures of the merging and surviving orders remain same.

If there are different units of measure used in the order reporting point structures, their conversion factor to the order header unit must be defined either in the material master, or the configuration.

All the quantities are calculated after converting the quantities in baseunit, and then the calculated quantities are converted back to their respective units of measures.

The information of the Original (surviving + merging ) orders and Resulting (surviving) order are sent in the table CT_ORDERS.

CT_ORDERS has nested RP (reporting point) structure CT_ORDERS-RP_TAB

RP_TAB has nested:

GM (Goods Movement) for a particular RP

ACT (Activity / resource utilization) for a particular RP

CT_ORDERS-MAIN_ORDER = 'X' identifies the Surviving order (Main Original / Resulting)

CT_ORDERS-MAIN_ORDER = ' ' identifies the Merging orders (Original)

CT_ORDERS-ORD_STATUS = Determines the level of the transaction

Example

Scenario example:

Merging order1	Merging Order2	Surviving Order
ORDER_B		ORDER_C		ORDER_A
RP	WIP	RP	WIP	RP	WIP
B1	3	C1	5	A1	15
B2	7	C2	0	A2	17
B3	5	C3	15	A3	15
	C4	5	A4	35
	C5	5
	C6	15
Mapping Table		New Surviving Order
A1--B1		A1	30 (=15+3+7+5)
A1--B2		A2	42 (=17+15+5+5)
A4--B3		A3	15
A1--C1		A4	55 (=35+5+15)
A2--C3
A2--C4
A2--C5
A4--C6

Note:

The Components and Resources attached to particular reporting points will also be transferred to thenew surviving order based on the mapping table information. For those reporting points in the mergingorder,that do not have a mapped surviving order reporting point, the GM / ACT data will be transferred to the next mapped reporting point.