Skip to Content

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.

          STATUS_M.jpg

          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.

     KONH_incorrect.jpg

     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 ).

     KONH_correct.jpg

   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.

          OA_repository_hierarchy.jpg

  • 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) .

RFC_expected_time.jpg



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.


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply