SAP ABAP Data Element CIFUPCSSAG (Cross-System Update Logic for Sales Scheduling Agreements)
Hierarchy
☛ SAP_APPL (Software Component) Logistics and Accounting
   ⤷ SCM-BAS (Application Component) SCM Basis
     ⤷ CIF (Package) Core Interface
Basic Data
Data Element CIFUPCSSAG
Short Description Cross-System Update Logic for Sales Scheduling Agreements  
Data Type
Category of Dictionary Type D   Domain
Type of Object Referenced     No Information
Domain / Name of Reference Type CIFUPDUSE    
Data Type CHAR   Character String 
Length 1    
Decimal Places 0    
Output Length 1    
Value Table      
Further Characteristics
Search Help: Name    
Search Help: Parameters    
Parameter ID   
Default Component name    
Change document    
No Input History    
Basic direction is set to LTR    
No BIDI Filtering    
Field Label
  Length  Field Label  
Short 10 Upd. Logic 
Medium 15 Update Logic 
Long 40 Update Logic for Sales Scheduling Agmnts 
Heading 55 Update Logic for Sales Scheduling Agreements 
Documentation

Use

If changes to the same sales scheduling agreement are saved in SAP APO and in the ERP system at the same time and transferred to the respective target systems, this can lead to inconsistencies.

You can avoid or rectify such inconsistencies by using cross-system update logic.

If you do not use cross-system update logic, these inconsistencies are not recognized. You can analyze the inconsistencies using the CIF comparison/reconciliation of transaction data and correct them.

Example

The planner changes, deletes, or creates a confirmation for a scheduling agreement in SAP APO. At the same time, a delivery is created and saved in the ERP system that triggers delivery allocation with the confirmation in SAP APO. The delivery allocation redetermines the open quantities of the sales scheduling agreement item.

  • Case 1 - The change by the planner overwrites the change from delivery allocation.

    If the change by the planner is saved in SAP APO once delivery allocation has taken place, this change by the planner overwrites the change from delivery allocation in SAP APO.

    In SAP APO, an open quantity for the confirmation is not correct because the quantity of the delivery was not taken into account. The open quantity is too high (or too low if the delivery was cancelled).

    In the ERP system, the open quantity in the delivery due list was reduced by the quantity that has been delivered in the meantime.

  • Case 2 - The delivery allocation overwrites the change by the planner.

    If the delivery allocation is saved after the planner has already changed and saved the confirmation, the result of delivery allocation in SAP APO overwrites the change by the planner.

    In the result, the open quantities and the original quantities in SAP APO are too low compared to the ERP system (if the planner increased the quantity) or too high (if the planner reduced the quantity).

If you use cross-system update logic, these inconsistencies are recognized at different points in time.

  • Case 1 - The change by the planner overwrites the result of delivery allocation.

    This case is recognized in SAP APO when the change by the planner is saved. Since the delivery in the ERP system has increased the update counter, the system recognizes that the scheduling agreement still has a lower update counter when the change by the planner is saved in SAP APO. For this reason, the save and the transfer of the order to the ERP system are prevented.

  • Case 2 - Delivery allocation overwrites the change by the planner.

    This case is only recognized after the change by the planner has been transferred to the ERP system. This change is always accepted in the ERP system.

    This means that the data is correct in the ERP system because the change by the planner is adopted. In SAP APO, the result of the change by the planner is missing in liveCache.

    You can use the retransfer to control whether the result of the change by the planner is recreated in liveCache from the confirmation history or not in SAP APO:

    • Update logic with automatic retransfer
      • In SAP APO, the system creates the liveCache order from the quantities and dates of the last confirmation saved to the database and executes delivery allocation. This means that the orders in SAP APO and in the ERP system will then agree.
    • Update logic without automatic retransfer
      • The different orders in SAP APO and in the ERP system are initially retained. You can analyze the inconsistencies using the CIF comparison/reconciliation of transaction data in SAP APO and rectify them by executing a retransfer to the ERP system.
      Note that for a retransfer, the "faulty" data is retransferred from SAP APO. The planned changes made in SAP APO are also lost in the ERP system. This means that you have "faulty" data in both systems.

History
Last changed by/on SAP  20030602 
SAP Release Created in