UKM_BP to FD32

[Former Member]

Hi all,

We want to keep using the old component of Credit Management (FI-AR-CR) for the checks in Sales and Distribution (SD) and Accounts Receivable Accounting (FI-AR) (that is why we won´t activate the BADI for FIN-FSCM-CR). The reason is that the checks are being processed outside SAP and there are many interfaces in place with the old check from FI-AR and SD (interfaces between SD, FI-AR and the legacy system that checks the credit limit against the exposure).

However, we believe there are functionalities that we DO want to use:

- UKM_BP (BP role UKM000):

- Score (based on external credit info, further info, creditworthiness data, etc)

- External Credit information

- automatic determination of risk class

- further information (negative, credit events, exceptions, insurances, etc)

- creditworthiness data

- Credit Segment Data: Credit Limit (also using SCASE transaction for credit limit request)

Based on the above, the idea is to transfer the data entered in UKM_BP to FD32 (credit limit, risk class, credit group, etc. -using some mapping roules-)

I have a couple of questions:

1- Is there and IDOC, BAPI, etc. to move the data from UKM_BP to FD32?

2- Does anyone see any disadvantage of using the above implementation strategy?

Many thanks and ideas and suggestions are more than welcome!

[Former Member · Accepted solution]

Please note in FSCM Credit Management you can perform credit checking for SD and FI documents.

I would strongly advise you not to even consider splitting the process up as you have stated as it will not work, be very time consuming and be very hard if not impossible to upgrade, apply support packs or enhancement packs.

My advice is simple - activate the new module and align your credit checking to how you had before via FD32

[former_member193516 · Accepted solution]

I suggest to go with above advice.

Due to our system landscape (n SD systems, 1 FSCM) and previous use of credit mgt in one SD system we had this requirement as well. We developed a program for transferring (only) credit limits into the FD32 / KNKA/ KNKK.

People in that system still went to FD33 to check the exposure values and limits.

However, the update in FD32 of exposure is in some cases different to the one in UKM_BP. We followed up a few cases and compared the values- mostly FSCM exposure was correct (very time consuming).

Now the people from the agreed to look into the central FSCM system for seeing the data.

Regards

Hein

[Former Member · Accepted solution]

Many thanks to both of you for the reply!

I might need to explain further: Currently there are many interfaces running between the credit check in FI-AR / SD (Exposure, Credit Limit, etc.) and an external system (legacy system called "Credit Control System" that also takes data from the P.O.S.).

If I implement FSCM Credit Management I will have to re-build those interfaces (there are aprox. 5 or 6) because the data will be in FSCM and not anymore in FI-AR / SD. On the other hand, the customer is satisfied with the credit control provided by SAP FI-AR / SD. The customer is requiring to add new functionalities regarding the process to establish the credit limit rate (score, external credit information, etc) and the authorization chain that can be covered with FSCM.

My analysis was to compare the cost of creating 1 interface (between FSCM UKM_BP and FD32) vs creating several interfaces (between FSCM and the legacy called "Credit Contro System") -of course it requires more effort to implement the interfaces between FSCM and the legacy- On the other hand, because of the customer needs, I don´t see any additional benefit of implement the full FSCM CR component (the piece required by the customer is covered as I mention above)

Do you guys agree with my analysis?

@ Hein, what bapi / idoc / exit did you use to transfer the data?

Many Thanks again!!!

[former_member193516 · Accepted solution]

Hi,

I am not a programmer. As far as I know there has been a custom function module created, which enables also creating base customer data for FD32 (tables KNKA, KNKK) because these are in our landscape not/ or not completely available.

Regards

Hein