oldest open item in FSCM is not being updated

[Former Member]

Hi Gurus,

I've activated the UKM_FILL BADI and all the Payment Behaviour Key Figures are being updated except the oldest open item. Can you give a hand here? did I miss another BADI?

My active BADIS are:

UKM_R3_ACTIVATE

UKM_SD_FSCM_INTEGR1

UKM_FILL

and still the field is not being update, did I miss some other BADI?

thank you a prompt reply is really appreciated.

[Former Member · Accepted solution]

I found out that the UKM_TRANSFER_VECTOR finds the oldest open item but has an X on the"Data Invalid" Column, has any one had this problem before? How can I correct this issue and turn it into valid data?

Thank you

[Former Member · Accepted solution]

hi Nicolas

Sorry I don't have an answer, but I have a question if I may?

With the following 2 transactions, do they still need to be run if you are using WS-RM? If so, do you set up as regular background jobs?

UKM_TRANSFER_VECTOR

UKM_TRANSFER_ITEMS

Also, does UKM_TRANSFER_VECTOR update the table UKMBP_VECTOR_IT?

Thanks

Trevor

[Former Member · Accepted solution]

Hi Trevor,

The two transactions you mention are meant to be used only in initial loads of customer master data and/or financial data. In other words, FSCM will automatically update all records from the moment you activate it onward. If you require it to include previous records that were part of an initial load you use:

UKM_TRANSFER_VECTOR  -> to update all your customer payment behaviour summaries.

UKM_TRANSFER_ITEMS -> to update all the credit commitment related to liability category 200.

To update the remaining credit commitment liability categories (100, 300 and 400) use the program UKM_RVKRED07 via the SE38 transaction.

These transactions are also used when there are some errors in your commitments and/or payment behavior summary.

SAP's best practice suggests that you first erase all commitments or payment behaviour using transactions UKM_COMMITMENTS and UKM_VECTORS respectively, and then rebuild it using both transactions you mentioned and the program I added.

If you want to periodically create a job it would be useful to erase all records first ( this could be done once a year, just to maintain the data's consistency, but I do not suggest a daily job to do this since FSCM already does this from its activation onward).

I hope this sheds some light on the transaction use and regular background job configuration,

Regards

[Former Member · Accepted solution]

thanks Nicolas ... that really assists.

I can see Payment History data in tables like UKM_TRANSFER_ARV but I can't see the data on the Business Partner. Do we need to activate UKM_FILL Badi for this to populate?

Thanks again

Trevor

[Former Member · Accepted solution]

Hi Trevor,

I noticed I didn't answer part of your question, I apologize. The table UKM_TRANSFER_ARV is the AR Payment Behaviour Summay (Vector) information that will be sent to the UKMBP_VECTOR_IT, through the the method FILL_VECTOR of the UKM_FILL BAdI. Thus, both tables will only populate when you have connected FSCM to ECC via XI or WS-RM which is your case and the BAdI has been active. Again FSCM will do this automatically from the moment you activate it onward, but if there is somw information that the system is not taking into account or you see any errors on the info shown, run UKM_VECTORS transaction to erase the payment behaviour summary info and then run the UKM_TRANSFER_VECTOR transaction to reconstruct the data.

hope this helps,

Nicolas

[Former Member · Accepted solution]

hi Nicolas

when we run UKM_TRANSFER_VECTOR we get Invalid Data on each of the proposed entries to UKM_TRANSFER_ARV (and therefore UKMBP_VECTOR_IT) - no entries appear in these tables.

What is wrong here ... is it the Badi's? We have activated UKM_FILL

Thanks for your assistance

Regards

Trevor

[Former Member · Accepted solution]

hi Nicolas - i think you had the same problem with Invalid Data - how did you solve?

Thanks again

[Former Member · Accepted solution]

Hi Trevor,

In my case we found out that the reason why the Oldest Open Items never was always labelled as invalid data was that in our implementation of the BAdI  UKM_FILL implementation  in the FILL_VECTOR method, the data for the Oldest Open Item was not filled into the XI message (there was no code whatsoever related to the oldest open item).

We found the missing coding in CL_UKM_XI_FACADE_R3_50~IF_UKM_VECTOR_PUSH_R3~

CONVERT_OUTBOUND:

...

IF g_badi_active = 'X'. <<< true in our system CALL METHOD o_badi_fill->fill_vector <<<  BAdi is called

IMPORTING

et_xi_msg = lt_data

CHANGING

is_notification = it_vector_raw.

ELSE. <<< not executed

... <<< here comes the code after the call of the BAdI implementation. Our

implementation looks like we copied this coding, omitting the part for

the OOI.

[Former Member · Accepted solution]

Thanks Nicolas ...we will check our settings/config

Regards

Trevor

[Former Member · Accepted solution]

Trevor,

After struggling with the last solution we have come across a final solution. Please insert the following code, in your UKM_FILL BAdI in the FILL_VECTOR method:

***START - OOI - 05/12/2012

*   OVERDUE ITEM

    MOVE: ls_in-ovdue_logsys    TO ls_data-oldest_open_item-accounting_document_id-scheme_agency_id,
          ls_in-ovdue_objtype   TO ls_data-oldest_open_item-accounting_document_id-scheme_id,
          ls_in-ovdue_objkey    TO ls_data-oldest_open_item-accounting_document_id-value.
*     ls_in-X_OVDUE_REVOKED
    MOVE: ls_in-ovdue_net_date  TO ls_data-oldest_open_item-overdue_net_date.
    IF NOT ls_in-ovdue_curr  IS INITIAL.
      CALL METHOD cl_gdt_conversion=>amount_outbound
        EXPORTING
          im_value         = ls_in-ovdue_amount
          im_currency_code = ls_in-ovdue_curr
        IMPORTING
          ex_value         = ls_data-oldest_open_item-amount-value
          ex_currency_code = ls_data-oldest_open_item-amount-currency_code.
    ENDIF.

***END - OOI - 05/12/2012

we have tested this code and works perfectly, it wil still show the invalid data on your UKM_TRANFER_VECTOR Log but the info will be populated in the UKMBP_VECTOR_IT accordingly.

Please consider this the final solution.

Hope this helps.

Cheers,

[Former Member · Accepted solution]

thanks Nicolas ... I will pass on to our programmer:

Are you able to send the entire coding for the UKM_FILL BAdI in the FILL_VECTOR method ??

Your assistance is greatly appreciated.

Thanks

Trevor

[Former Member]

How did you define ls_data?

I tried to define it like

DATA: ls_data TYPE ukmr3_credit_commitment.

But is showing errors during activation saying ls_data doesn't have a component with that name.

[Former Member]

Hi Sameer,

This quite an old thread, however I will try to answer your question the best I can with what I can remember.

The definition is in the standard's method code as shown below:

We copied and pasted it to a new Z implementation and added the code shown above to the Overdue Ítem section, which used to be blank . I am looking at the standard code in a SAP 6.0 ECC ehp 7.0 and the code has been added where it used to be blank:

It may be the case that by just copying (and activating) the standard's BAdI coding you won't need to add the code I mentioned above since the the thread was written back in 2012 with an ehp 4.0 ERP which is a bit outdated right now.

Hope this helps,

Nicolas