Technical Articles
Credit Exposure Update Process at FSCM by Web Methods
In actual life, every purchase transaction with a credit card will trigger a credit limit check at the credit system. It checks if the total credit exposure has already used up or exceeded the credit limit, meanwhile it will offset those credit exposures immediately with every payment. The same thing at SAP FSCM, open orders contribute to the credit exposure of a business partner in SAP Credit management.
In this blog, I’ll try to show the process of how credit exposure been updated by web methods for one specific invoice. Our approach is Non-PI Synchronous FSCM Integration via WSRM. (You can check SAP help or this article for the Non-PI approach.)
Credit exposure overview at front-end
Customer with business partner number 4062280 purchases one product service and the SAP system has one open invoice which is a debit memo with number 5400219845 against the service order.
This is the Billing document 5400219845:
Let’s check its accounting document which has 4710.00 GBP for account 4062280.
Now check the credit exposure detail for BP 4062280 at credit segment GB01 at BP. And we can find the total credit exposure at the overview screen. (The total exposure is 4710.00 GBP as well, cause here I use this simple scenario which has only one open invoice till now.)
After clicking the button ‘Display liabilities’ on the right side we can get the credit exposure details. It will list all total exposure by different categories.
Double click the item line with type ‘200’ which against open invoices, then there’re exists our open invoice 5400219845 (been used as Partner message ID as well). It has one field called key: SG2254002198452020001 which will be used at web methods as one linkage.
Those credit exposure items have been stored at the table UKM_ITEM.
Web service messages overview at front-end
If we check nearest web methods related to this update at web service utilities: Message monitor (SRT_TOOLs), there’re exists one pair of messages:
- One is sender (Interface name: CreditCommitmentNotification_Out);
- Another one is receiver (Interface name: CreditCommitmentNotification_In)
Obversiouly, the first sender been triggered to send out the message. Double click the first sender message, we can see all those details include BP number, credit segment, credit exposure category, invoice number, and its amount and key against UKM_ITEMS I mentioned above.
So the question is how this credit exposure been updated by those web messages?
A brief introduction to Web methods
The two messages are exchanged using the Web Services Reliable Messaging (WS-RM) log that ensures both the transfer of messages and that they are received in the correct order. It sounds like bgRFC (background RFC) concept and here it works like IDOC but transfers data inside one SAP system between FSCM and other modules instead of between different systems. (Please check this PDF file for more details about SAP Credit Management Configuration Guide.)
Transaction SRT_TOOLS->WS Configuration->SOA Manager:
Then goto Service Administration->Web Service Configuration:
Using the filter object type is “consumer Proxy” and the object name contains pattern ‘*UKM*’, we can find credit management related web services listed. Our sender message mentioned interface: CreditCommitmentNotification_Out is on the list.
The details configuration per web service configuration is out of the ABAP territory : p
Service Consumer Interfaces overview
Let’s check the sender’s message listed sender interface namespace ‘http://sap.com/xi/PI/FIN/Operational/Global’ and its sender interface named as ‘CreditCommitmentNotification_Out’ by call TCODE: SPROXY.
The proxy name ‘CO_UKMR3_COMMITMENT_NOTIFICTN’ maintained here actually is a Class here contains one method called: ‘EXECUTE_ASYNCHRONOUS’ which is the key method for message transfer and will be triggered at next section mentioned BADI.
Btw, these proxy settings and its related interface class/method are totally SAP standard for me.
The last key chain- BADI: BADI_SD_CM
Implement BADI BADI_SD_CM for the following methods which will be triggered at various places to perform a credit check and update order, delivery, invoices, etc. plus credit exposure as well.
|
Method |
Description |
|---|---|
|
FSCM_GET_MASTER_DATA |
Determine master data of partner before credit check, in particular the risk category |
|
FSCM_CREDIT_CHECK_ORDER |
Call credit check from order |
|
FSCM_CREDIT_CHECK_DELVRY |
Call credit check from delivery |
|
FSCM_COMMITMENT_UPDATE_ORDER |
Update new or changed order values |
|
FSCM_COMMITMENT_UPDATE_DELVRY |
Update new or changed delivery values |
|
FSCM_COMMITMENT_UPDATE_INVOICE |
Reduce order values during billing and create open billing values if no immediate transfer to FI |
|
FSCM_DISPLAY_CREDIT_MESSAGES |
Control output of messages for a credit check-in dialog |
|
FSCM_CREDIT_CHECK_SM_ORDER |
Call credit check from service order |
For sample code, see the implementation UKM_SD_FSCM_INTEGR1 that is also available with SAP Note 1130061.
Take our case as an example which will be using the method “FSCM_COMMITMENT_UPDATE_INVOICE”. Inside the code of this implementation, the key is cl_ukm_xi_facade_r3_50=>if_ukm_commitment_push_r3~push_commitment which will generate the message using the Service Interfaces ‘CO_UKMR3_COMMITMENT_NOTIFICTN’ mentioned above.
Here object lo_send TYPE REF TO co_ukmr3_commitment_notifictn, and call method ‘execute_asynchronous’ to send credit exposure details out. Now the whole map is clear and the same thing for the receiver message and its interface.
And you can find the message type ‘CreditCommitmentNotification’ used by those web methods at Namespace http://sap.com/xi/FSCM/Global.
Here the proxy name ‘UKM_COMMITMENT_NOTIFICATION’ is the structure of Credit Exposure Information for web message contents.
Monitor of credit exposure
Compare credit exposure between sending systems (FI-AR and SD) and receiving systems (SAP credit management) we can using TCODE: UKM_MASS_RECON. Please check standard SAP help for more details.
Conclusion
Thanks for reading so far without sleepy. Finally, reach to the last section:
- After order been created/updated, related BADI implementation will be triggered accordingly to update various tables and statuses. Credit exposure update process for invoice has been triggered at the implementation FSCM_COMMITMENT_UPDATE_INVOICE of BADI: BADI_SD_CM.
- Method of sender interface CO_UKMR3_COMMITMENT_NOTIFICTN will be used to generate a message type of CreditCommitmentNotification_Out. Then the method of receiver interface II_UKM_COMMITMENT_NOTIFICATION will be used to receive the message in XML format and update tables like UKM_ITEMS which been reflected at exposure details at business partner credit master data.
- Those generated methods can be monitored by web method message monitor (SRT_TOOLS) even re-execute if encounter some error. There’re so many web methods been generated daily and web method message has an expired date, please note that it’ll disappear one day.
- We can filter them by change date&time range for related orders. And UKM_LOGS_DISPLAY provides credit exposure update search checkbox as well. The timestamp filter is mandatory otherwise it’ll time out for sure. (Hope HANA will fix this)
This is my view from a developer’s view. If anything incorrect, please kindly let me know. Thanks.
Hi Jigang Zhang
many thanks for this detailed description and explanation. appreciate that!
Just some remarks from my experience : in S/4 Hana the webservices are only used for multiple system scenario. In one system environment they are not used anymore.
kind regards and looking forward for other nice blogs
Rolf
@ Rolf Hübner Thanks for the infor 🙂