Once you have completed the prerequisites described in previous section(Roadmap to transitioning from BDC on ME32K to using RFC for service outline agreements )and created a mapping program to map the input parameters of RFC : BBP_ES_OA_UPDATE you can proceed with following steps to update contract data in purchase order header (EKKO) and condition header (KONH) tables.
All the Three Updates listed below are one-time updates in a system. Once the update has been executed it will never have to be repeated again, the RFC will ensure the data is consistence going forward.
Updating EKKO.
One of the first checks that the RFC performs when it is invoked is to check if the status of outline agreement is set to M - Purchasing Document from E-Sourcing (ie. EKKO-STATU = 'M'), for Change/Update operation. If you have been using BDC to create/update outline agreement, this field is most likely blank as it is not visible on the ME31/32K screens.
The idea behind this check is to ensure that the RFC is not being used to update outline agreements which were not created by the RFC. I haven't been able to locate a OSS note which will set status of relevant outline agreement records to 'M', so I am updating this value using a direct table update.
NOTE: Again to reiterate, this is only needed if you want the existing outline agreements created via BDC to work with RFC, any outline agreements created from scratch using the RFC will not require this update.
Updating ESLL.
When creating a new OA through the RFC, ESLL-EXTERNALID is copied over to ESLL-EXTROW and they are always kept in sync. However if you have been relying on the BDC to update service outline agreement, the EXTERNALID field is most likely blank. To update Outline agreement using RFC ESLL-EXTERNALID should be equal to ESLL-EXTROW. If this condition fails the update will not work.
In my scenario I have created a utility to perform a one time direct table update which copies the ESLL-EXTROW to ESLL-EXTERNALID field to ensure they are always in sync. Also consider implementing sap note: 2222611: BAPI for service PO Entry sheet and contract :esll-extow - EHP 5
Updating KONH.
Unfortunately every time to you add a date rate to conditions for your services, the new condition created in created in the KONH table with the incorrect date validity period ( old record is not demarcated correctly ) as shown in the image below. I am not sure why this happens but according to my functional counter part this has been happening forever and since the validity period in ME32K is pulled from A081 table ( which has right from/to dates) it has never been a problem. I haven't explored this issue in detail , but OSS Note: 1970016 - BAPI_CONTRACT_CHANGE: Unexpected item condition record validity periods are created might be useful. Not sure if this is a bug or expected behavior, since a new contract created via this RFC created KONH records with proper validity period demarcation which match records in A081 table.
Anyhow, if the date range on KONH table are incorrect for service conditions of any outline agreement, update using RFC will not work for these objects. As with updating EKPO table, I went with direct table update of date range in KONH by copying the correct validity period from A081 table. Below screenshot shows the KONH entry after table update ( matches A081 from above image ).
The hierarchy diagram below should help you create a simple update program to correct the KONH validity period by updating them with period from A081 table.
- One the prerequisites from the previous blog are implemented and the existing contract records in the system are updated as explained above you should be ready to use RFC: BBP_ES_OA_UPDATE and replace the BDC.
- Please keep in mind a major limitation of using the RFC is that you need to pass all the data present in the outline agreement in case of change operation to the RFC. So take the following Outline agreement scenario.
EKPO
| LINE ITEM | |
|---|---|
| 0010 | LINE ITEM FOR PLANT 1 |
| 0020 | LINE ITEM FOR PLANT 1 |
ESLL
| LINE ITEM | SERVICE ITEM | DESCRIPTION |
|---|---|---|
| 0010 | 0010 | Service Item 10 for Plant1 |
| 0010 | 0020 | Service item 20f or Plant1 |
| 0020 | 0010 | Service item 10 for Plant2 |
KONH
| LINE ITEM | SERICE ITEM | VALID TO | VALID FROM | Condition |
|---|---|---|---|---|
| 0010 | 0010 | 12/31/9999 | 05/25/2016 | Condition 1 for Service item 10,line item 10 |
| 0010 | 0010 | 05/24/2016 | 01/01/2015 | Condition 1 for Service item 10,line item 10 |
| 0010 | 0020 | 12/31/9999 | 01/01/2015 | Condition 2 For Service item 20, line item 10 |
| 0020 | 0010 | 12/31/9999 | 05/25/2016 | Condition 1 for Service item 10, line item 20 |
| 0020 | 0010 | 05/24/2016 | 01/01/2015 | Condition 1 for Service item 10, line item 20 |
In the above scenario, if you requirement is to only add a new Validity period ( 05/25/2016 to 12/31/9999) highlighted condition above, you still need to pass all other conditions for all crafts for all line items event if they are not changed. Any record which is not passed to the RFC though the interface will be DELETED.
This is a major short coming of the RFC approach as compared to BDC, Following are the expected time line based on line items as per E-sourcing community blog ( SAP Sourcing) .
In our test system, we have noticed the update takes upto 28~ 30 minutes to update outline agreement with 12-14 plants, each with 20 services and 2 or 3 validity periods each with 26 conditions. This kind of performance is unacceptable in our scenario so we have customized the RFC: BBP_ES_OA_UPDATE further to pass only changed records. If you face the same performance bottleneck continue to the next part of this blog for further details.
- SAP Managed Tags:
2 Comments
