SPM (Service Parts Management) InterCompany STO CRM Billing issue

Lately I met an issue in the inter-company STO scenario in the SPM solution (Service Parts Management) with one of our customers.

The scenario starts from Purchase Order(Stock Transfer Order) in ERP and based on that an Replenishment (outbound) delivery order is created and the delivery order will be replicated to EWM system for picking and goods issue, after that however, the billing due list will be generated in CRM system and therefore billing document will be created via integration with CRM Billing. This article will focus on the detailed issue only but not the SPM solution. For more information about SPM, you can check details here.

The issue is that pricing information on the purchase order, is not actually copied into the final billing document in CRM system. 

Pricing info in Purchase Order (ERP)

Pricing info in Billing document (CRM)

This scenario looks complicated because it involves several different systems and from business point of view we also see topics like inter-company purchasing and CRM billing.

My very first understanding is that the pricing of purchase order will be copied to delivery document and then copied to CRM billing document through CRM Middleware. Therefore if there is inconsistency, there should be something wrong in between and the very first idea is to check the pricing information of the delivery document.

Roughly looking into this condition data, I thought it was wrongly copied from the PO/STO. However, after reconsidering the business process, I realized there should be something more than just copying the condition data.

In inter-company STO, there would be two plants involved. One is issuing the product while the other is receiving. The purchase order is initialized by the Receiving Plant but the Replenishment Delivery Order is initialized by the Issuing Plant and also the Billing document should be initialized by the Issuing Plant. Therefore I double checked the STO and ODO, if you look at the two screenshots above, you will also find that condition types inside the two orders are actually different.

Checking Pricing for Purchasing (it is called “Calculation Schema” in MM instead of “Pricing Procedure” in SD)

Path: SPRO –> Mat. Mgt –> Purchasing –> Conditions –> Def. Pricing Deter. Process –> Def. Calc. Schema

Checking Pricing for SD

Path: SPRO –> Sales & Distr. –> Basic Functions –> Pricing –> Pricing Control –> Def. & Assign Pricing Procedure. (or you can use t-code v/08)

I am not familiar with the SPM configuration but obviously I see that the Purchase Order’s condition data is coming from Pricing Procedure in MM while the delivery document’s condition data is coming from Pricing Procedure in SD. And eventually the information passing didn’t work between these two different conditions.

Until now I still don’t understand why the customer is configuring the pricing both in SD and MM in such a way (and I would like to know if anybody want to share it). However, after discussion with one of our SPM developers, I got some more information.

“Actually during delivery posting, the STO pricing conditions are read from the STO and transferred directly to CRM without copying them into the delivery. This is what is called the ‘delivery interface’ in SPM. The logic for Inter company STO billing functionality in SPM has been implemented in FM /SPE/STO_CONDITIONS_ADD. “ He said.

The logic for condition data transferring in the FM /SPE/STO_CONDITIONS_ADD.

 1   LOOP AT it_lips INTO ls_lips.
 2 
 3 * Process only replenishment deliveries
 4 * Does the item refer to a purchase order?
 5     CHECK ls_lips-vgtyp = vbtyp_bestell.
 6 * Is the Delivery Relevant for Billing?
 7     CHECK ls_lips-fkrel = 'V'.
 8 
 9     IF ls_likp-vbeln <> ls_lips-vbeln.
10       READ TABLE it_likp INTO ls_likp
11                          WITH KEY vbeln = ls_lips-vbeln.
12       CHECK sy-subrc = 0.
13     ENDIF.
14 * Is the document an outbound delivery and not a return delivery ?
15     CHECK ls_likp-vbtyp = vbtyp_lino AND ls_likp-werks IS NOT INITIAL.
16 
17 * Is there a number for conditions in the delivery?
18     CHECK ls_likp-knumv IS NOT INITIAL.
19 
20 * Read condition from the purchase order item
21     PERFORM konv_read USING    ls_lips-vgbel
22                                ls_lips-vgpos
23                                ls_likp-knumv
24                                ls_lips-posnr
25                       CHANGING lt_konv.
26 
27 
28 * Add conditions from the PO item to the conditions of delivery item
29     LOOP AT lt_konv INTO ls_konv.
30 
31 * Condition record of type 0VPR might be added by middleware
32       CHECK ls_konv-kschl <> lc_kschl_0vpr.
33 
34 * Do not add conditions, which are already defined in delivery
35       READ TABLE it_konv WITH KEY knumv = ls_likp-knump
36                                   kposn = ls_lips-posnr
37                                   kschl = ls_konv-kschl
38                          TRANSPORTING NO FIELDS.
39       CHECK sy-subrc <> 0.
40 
41       APPEND ls_konv TO et_konv.
42 
43     ENDLOOP.
44 
45   ENDLOOP.

After this, further check was done in CRM’s configuration for billing document.

Checking pricing strategy for CRM Billing (in CRM).

Path: SPRO –> CRM –> Billing –> Def. Billing Item Categories / Def. Billing Types.

Configure the corresponding billing document type and the billing document item category.

  

Debugging finally confirm that the Pricing Type is the root cause. When it is set as “Copy Manual Pricing Elements and Redetermine the Others”, the pricing info somehow is not flowed in. As it is a integration scenario, I am not quite sure how the pricing info is updated. (should be some BAPI or FM in CRM to receive the updates). After change the pricing type to “Copy Pricing Element no change and Redetermine the Others”, the issue was resolved.

(The end)