EBS MT940, NTRF alone is the transaction type for Transfer, Charges, Intrest, Clearing etc.

[vishnurallabandi]

Dear Gurus,

I have come across a bank file in which only NTRF is the transaction type for all reason codes as an ex, BGI, CLR, MISC, TRF.

But for all of these reason codes bank is sending only NTRF as an external transaction type alone and no where in the file the seperation can be seen.

As an example below is the altered file in similar to the bank file for Misc, charges and intrest. How to crack it, request your early response and points will be rewarded.

MISC.

Charges and Intrest

Thanks.

Regards,

Vishnu Vardhan.R

[Bohdan · Accepted solution]

Hi vishnurallabandi,

Normally, MT940 standard implies that question mark "?" should be used as delimiter between the fields of the bank statement. See typical example below:

In your case, it looks as though the bank is using custom delimiter "/". Please try to maintain user parameter RFEKA400_DELIMITER in SU3. Set the value to "/" and try to upload bank statement either as structured MT940 bank statement. If the system will allow you to do that, you can try to maintain the first four characters from the line :86: e.g. ORDP, REMI, EREF as the BTC code for the mapping in OT83.

Notes:

- I'm not sure if the "/" is allowed as delimiter. This functionality was introduced in OSS 1085596 - RFEKA400: SWIFT MT940 enhancements and this special character is not specifically mentioned. But it is worth a try.

- further, there might be a problem that the line :86: is immediately followed by a delimiter "/". I'd expected something like this - :86:ORDP/NAV/REMI .... Extra delimiter before ORDP might cause issues. If that's the case, you can resort to the user exit EXIT_RFEKA400_001 to remove it during the upload. Before you do that, test the upload together with the ABAP developer and check if it causes any issues and if removal during pre-processing will help. My post might provide a helpful reference on this matter.

Regards,

Bohdan

[vishnurallabandi]

Hi Bohdan,

Thanks for your swift reply.

First part:

From the format perspective i have uploaded few sample files and system is accepting it as is'/'.

Second Part

As you suggested OT83 i see these characters(ORDP/REMI/EREF etc) were used in multiple places of the different files too for different line items, as an example below is the snippet created for our reference. Will it not create any problem if the same reason code comes in different files?

Below is for the other reason code BG:

For the same reason code in other file

Also will it be a good idea to approach the bank for the format specification and business transaction codes to locate the relevant BTC's?

Thanks.

Regards,

Vishnu Vardhan.R

[Bohdan]

Hi vishnurallabandi,

If you're able to load bank statement "/" as a delimiter without a SU3-parameter, that's really good. If these keys can be found multiple times across the note to payee, it should not be a problem. Normally, the interpretation mechanism should consider the first 3-4 characters from line :86: as a BTC-code.

And you're right: it is a good idea to get in touch with the bank and get the list of BTC-codes and their meaning. This will simplify your life considerably.

Regards,

Bohdan

[vishnurallabandi]

Dear Bohdan,

Yes it is working with '/' by default.

Thanks for the input on BTC Mechanism it enhances my understanding as I am more into Bank Statements now.

Rewarding points for your swift help.

Regards,

Vishnu Vardhan.R