Bank Reconciliation - Incorrect Statement ID Sequencing causing Reconciliation Errors

[zainulabdin-2024]

Hi Experts,

We implemented EBS during the middle of the year and started to generate Statement ID (FEBKO- AZIDT) automatically. However, before implementing EBS, users were entering Statement IDs manually using the number ranges that were greater than the ones EBS was generating post-implementation.

After the year-end close, this glitch of last year now started to create issues because the bank statement ID 000001/2024 is picking the highest number of Statement IDs that were posted in 2023 to reconcile opening/closing balances.

I was wondering if there is any way to change the EBS Reconciliation logic of picking Statement ID sequencing or the sequence in itself without reversing the bank statements as the statements pertain to almost 10-month back periods.

Appreciate the guidance on this subject please. Thank you

[Bohdan]

Hi zainulabdin_2024,

That's an interesting scenario. I think that the numbering of the bank statements has at least three keys:
- FEBKO-AZNUM - this is normally external bank statement key (field :28: from bank statement in MT940-format).

- FEBKO-AZIDT - this is some concatenation of fiscal year + external statement - at least this is how it behaves in my system.

- FEBKO-KUKEY - internal bank statement key to store & link the statement line to the head of the statement and other associated tables.

I think what you can try to do is to adjust the number of the bank statement via BADI FIEB_CHANGE_BS_DATA (see the link here). But there might be a catch - if the validation that is causing your error happens before the BADI execution, it might not help. Anyway, I think it is worth a try. You can try to devise your own logic for AZIDT (e.g. try concatenation of 9024 + NNNNN, where NNNNN is sequential number provided by bank in AZNUM). Why 9024 ? Well in case if you'll not be able to reuse 9024 each year, you can start incrementing it each year by one. For example in 2025 you'll use 9025 and so on. But there is a chance that this interval is higher than the numbers entered manually by the users.

If this suggestion does not help, you can write a small utility program, that will adjust the values for AZDIT and possible for AZNUM for previous years i.e. manual statements.

Regards,

Bohdan