on 09-23-2010 1:56 AM
We get the bank statements in BAI2 format. The statements are uploaded by a scheduled job every night. Because of transmission issue we did not receive files for 3 days . However, we received the files for subsequent days which were uploaded. Once we noticed this we requested the Bank for the files for the missing days and uploaded the first missing one. When we uploaded the second missing one we got the error FB771 - Statement already exists; entry ignored
The following is the sequence of events
Uploaded correctly upto 09/13.
Stmt 306 09/13
Nothing uploaded on 09/14 to 09/16, uploaded statement for 09/17 and 09/20
Stmt 307 09/17
Stmt 308 09/20
Then uploaded statement for 09/14
Stmt 309 09/14
Tried uploading statement for 09/15, but got the FB771 error.
After reading other posts, I understand that the system calculates the statement number by adding 1 to the last statement date (and not the last statement number). Thus in our case when we uploaded stmt for 09/14, system checked the last stmt date of 09/20, found statement number 308 and added 1 to it to assign statement number 309. And when uploading stmt for 09/15, it again saw the last stmt date of 09/20 and added 1 to 308 and found that the statement 309 already exists and thus the error.
How do I resolve this? I know there is program RFEBKA96, but that is not to be used in production environment. Is that the only option here?
Thanks for your help.
See my last post
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello
Request you to please check the FEBKO and FEBEP tables and see what all has been posted. Then take a decision whether you want to use the RF program.
Rgds
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, in future we will have to be extra cautious to prevent such issue. However, as of now I see the RF*96 deletion program as the only alternative.
If I take that route, I think I will have to delete the statements 307, 308 and 309 by following these steps:
1. For each statement note down the document numbers posted
2. Reverse the posted documents using FB08 or FBRA as applicable
3. Remove the check encashment date for each outgoing check that was cleared
4. Run RFEBKA96 program to delete the 3 statements
5. Reupload all the statements in the correct sequence.
Of course, I am averse to doing this exercise and would need suggestions for a workaround. Also, please comment if as a last resort I have to use RF*96 program is there anything I am missing in the above steps?
Thanks
We had a similar situation once. When I looked into it, the only options I found was to either not load the statements and post the transactions from the statements manually; or use the process you have outlined to reverse documents, reset clearings and delete the subsequently loaded statements.
Regards,
Shannon
Shannon - I read one of your other posts on this topic and that was also very helpful. Can you tell me what you mean by post the transactions manually? Do you mean FF67? But that entails new configuration. Also, do we come back to FF_5 after resolving the issue?
Which route did you take?
I am planning to replicate the issue in Test\QA environment today and delete the statements and reupload them.
Thanks,
Ash
By post manually, I mean just looking at the transactions in the statement - either via the BAI file or via the bank website - and making the needed postings via the online transactions - as if you weren't using bank statement functionality at all. So any checks would need to be manually updated with encashment dates and payment documents cleared via FB05/F-04. Any deposits would also need to be cleared via FB05/F-04. Any postings that don't involve clearings (i.e. fees) are posted via FB01/FB50, etc.
Thinking about it more, I think we've had similar situations more than once. In our case it was the bank "dropping" a bank account from the statement file for a few days. I think the first time we reversed/deleted and reloaded because there were only a couple of days' statements that had to be done for. However, I think another time, there were several days' statements loaded after the missed statements and we decided that the volume of transactions in the missed statement was low enough that we just posted manually. I seem to remember that the Accountants were less worried about the statements not being in the system because it was in the middle of the fiscal period - rather than right at the beginning or end.
Hope this helps.
Regards,
Shannon
Hello
I also had to use this RF program as a matter of fact and could not find any other way. But after that made it very clear so everyone who was involved in the process that this is not to be done again.
Still you can wait for some more suggestions and also raise an OSS to see if there is any other way out.
rgds
This issue is resolved. We followed the steps outlined earlier and it works. Please use transaction FCHG to remove the encashment date.
Also, test thoroughly in Test client before you do it in Prod. Once we were comfortable in Test client, the production run went pretty smooth.
Thanks and Regards
User | Count |
---|---|
101 | |
12 | |
11 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.