Scribd
Upload
45 views6 pages

Planned Order Duplication Issue

The document describes an issue where planned orders created in SAP APO are duplicated when transferred to the ECC system. This is caused by a failure to map the order IDs between the systems during transfer due to an enhancement in Cipla that prevents the ECC system from generating a planned order number. The solution is to collect the SUBRC from the enhanced code and pass it to SY-SUBRC to allow the order number generation and mapping to succeed.

Uploaded by

akshay Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
45 views6 pages

Planned Order Duplication Issue

The document describes an issue where planned orders created in SAP APO are duplicated when transferred to the ECC system. This is caused by a failure to map the order IDs between the systems during transfer due to an enhancement in Cipla that prevents the ECC system from generating a planned order number. The solution is to collect the SUBRC from the enhanced code and pass it to SY-SUBRC to allow the order number generation and mapping to succeed.

Uploaded by

akshay Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Contents

Issue Description ........................................................................................................................................... 2


Symptom ................................................................................................................................................... 2
Reproduction of the issue ......................................................................................................................... 2
Standard expected behavior: .................................................................................................................... 3
Reason and Root Cause Analysis .................................................................................................................. 4
What is causing the issue .......................................................................................................................... 4
Solution ......................................................................................................................................................... 6

Page 1 of 6
Issue Description
Symptom
Planned orders created from the APO PPDS are getting multiple when they are transferred to the SAP
ECC system.

Reproduction of the issue


Step 1: Open SAP APO development system and execute transaction /N/SAPAPO/RRP3. Choose the
planning version, material and plant as shown below.

Step 2: Create an order by providing a date (in future) and quantity. You can follow the dates and
quantities as shown below.

(a) Press Ctrl+F1 to switch to edit mode.


(b) Provide date, quantity and press Enter

(c) You will see a planned order number (which is internal to APO).

Page 2 of 6
Step 3: Save the planning result (Press Ctrl + S) and refresh (Shift+F9)

Now you see two planned orders (one with ECC number range and the original one with APO number
range)

Here 312957 is the ECC number range planned order and 10000029 is the APO PPDS number range
planned order.

The issue is manifold if someone uses transaction /N/SAPAPO/CCR in the APO PPDS system to do a
transactional data reconciliation. The system always assumes that the original order is not sent to the
SAP ECC system and every time the “corrective” action is taken – a fresh order is created.

Standard expected behavior:


In standard system with CIF integration, the planned order ID remains the same in both the system and
the APO order number is replaced by the ECC order number.

Page 3 of 6
Reason and Root Cause Analysis
The standard integration happens in the following way:

(1) Order is created in APO with two identification tags (order ID and order number from the APO
number range)
(2) The order is transferred to SAP ECC, the ECC system takes its number range and updates the
CIFORDMAP table with mapping of the ECC order number and the same order ID – thus making
order ID as the unique global identifier across both the systems
(3) The information from SAP ECC (about the new number range) is then retransferred to APO PPDS
with the same mapping as in step 2
(4) APO performs the necessary modification and the number change is reflected.

The reason for duplication of orders is – when the step 3 is happening, the SAP ECC system is unable to
send this mapping, because it has already failed to perform the mapping in CIFORDMAP table that was
supposed to happen in step 2. The order is retransferred from ECC without an order ID and APO treats it
as a new order.

What is causing the issue


While creating the planned order in the ECC system (step 2), system calls the following function module
in the SAP ECC system.

This planned order number (lv_plnum) is a precondition for successful mapping:

Page 4 of 6
In the current scenario is Cipla, the variable lv_plnum is initial.

Further analysis of the function module CIF_PLDORD_INBOUND is done. It calls the following internal
API which was supposed to give this number:

Further drill down is done on this function module MD_PLDORD_CREATE_W_COMP_BAPI. The code
section which is responsible for generating the number is highlighted below:

Standard integration will just create the order successfully and a return code zero is expected (SY-SUBRC
= 0).

However, here we are getting a SUBRC = 4 (generally happens when a select query fails).

The form PLANNED_ORDER_NO_DIALOG section contains form fcode_hzpl_plaf.

This has been enhanced in Cipla.

Page 5 of 6
If the select query of code line 207 fails – it will then result in SUBRC = 4 and the same will continue in
failing the SUBRC check in FM MD_PLDORD_CREATE_W_COMP_BAPI. The order number information is
thus lost and the mapping is not performed.

Solution
Collect the SUBRC information at the start of the enhancement in a local variable. Provide this SUBRC
value to SY-SUBRC at the end of the enhancement as necessary.

Page 6 of 6

You might also like