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