payment info displayed twice in payment medium (DMEE)

[Former Member]

Hi Experts,

I have an issue where for a particular comapny code XYZ there are two payment info created in payment medium for the same collection date, where as there should be one Payment info created.

For other company codes it is creating only one.

I have not made any changes in the DMEE tree structure.

Also, I have checked all the transactions OPBM1/OBPM2/OBPM4. FQP1/FQP3/FQP4...etc but I every thing is configured same for all the companycode.

I have also checked if there could be some ZFMs which could cause this discrepancy but there are none.

Has someone come across this kind of issue..Please let me know what could I possibly be missing?

Thanks.

[Former Member · Accepted solution]

Hi Priyanka,

the payment info block is no only created per request colection date, check on transaction DMEE the grouping for tree type PAYM and format tree SEPA_DD, for example, the following criteria are considered:

-Sequence type - First, recurrent, one shot

- Request collection date

-Scheme type - CORE, B2B

Can you check if one of these values is different in the two payment info?

Regards

Adriano.

[Former Member]

Hi Adriano,

Thanks for your response.

I did chek the same.  PFA, the attachment.

• The request collection date is same.
• The scheme type is CORE. Still the documents are send in different payment info <PMTINF>

This isnt helping.

[Former Member]

And what about the sequence type, are all the payment info RECU or FRST? Are you running the payment run using parallel processing? Can you share the full XML file?

Regards,

Adriano.

[Former Member]

Hi Adriano,

In the payment medium generated, the sequence type are a combination of RECU and FRST. I am running the payment run via FPY1. Sincere apologies, but due to confidential information in it I cannot share the full xml file.

Could there be something which I can check apart from what you have mentioned.

Thanks.

[Former Member]

The reason for the multiple payment info is the sequence type, a new payment info is created for each sequence type. If you don't use parallel processing in the payment run you can avoid this by implementing a grouping string in event 00 of the payment medium, transaction FQP3, payment medium SEPA_DD, function module FKK_PAYMEDIUM_EU_SEPA_DD_00 has no code, you need to fill the sequence type in field  E_SRTF1, for this you should check if the mandate that is used on the payment is a new one or an already used one. Something like:

CONSTANTS: lc_frst TYPE srtf1_pay VALUE 'FRST',
lc_rcur TYPE srtf1_pay VALUE 'RCUR',
lc_ooff TYPE srtf1_pay VALUE 'OOFF'.

DATA: l_mandate_info TYPE sepa_str_mandate_pain_dd.
DATA: l_current_mandate TYPE sepa_str_data_mandate_data.

IF i_payh-mguid <> space.
CALL FUNCTION 'SEPA_MANDATE_API_GET_FOR_DD'
EXPORTING
i_mguid           = i_payh-mguid
IMPORTING
e_mandate_pain_dd = l_mandate_info.

IF l_mandate_info-pay_type = '1'.

MOVE lc_ooff TO e_srtf1.

ELSE.

CALL FUNCTION 'DMEE_SEPA_MANDATE_GET'
EXPORTING
i_mguid        = i_payh-mguid
IMPORTING
e_mandate_data = l_current_mandate.

 
IF l_current_mandate-firstuse_docid EQ
l_current_mandate-lastuse_docid.
e_srtf1 = lc_frst.
ELSE.
e_srtf1 = lc_rcur.
ENDIF.
ENDIF.

The issue is that without sorting, each time the payment sequence changes from one payment to another, SAP created a new payment info.

If you use parallel processing, this can work but only on each parallel processing interval, if you really want one payment info for each sequence type, request collection date, then you need a more complex solution and I would require consultancy work to implement it.

Adriano.