Batch Error

Rauf

Rauf

VIP Member
I have voided two payment batches and while posting I'm receiving the attached errors, which do not give a specific error, it says "record invalid"

No F0911 records exist in this Batch.
Error: Batch 528481 M In Error.
Error: Payment 00242325 16966 18112103 In Error.
Error: Record Invalid
One or more batches had errors.
 

Attachments

  • Batch Error.jpg
    Batch Error.jpg
    14.3 KB · Views: 27
  • Batch Error WC.jpg
    Batch Error WC.jpg
    26.3 KB · Views: 26
Rauf,

Was there a R09801E produced? Was there anything in the work centre?
 
Hi Peter,

R09801E is generated with a blank page.
I have attached the work center message too, but there is also no clue. It just says "Record Invalid"

I thought it was due to security. But I tried with SYSADMIN and still getting the same issue.
 
Hi Peter,

Some technical information,

In an initial debugging, I have found the error is set by F0911 Write Cash Account business function.
I'm continuing to find out more.
 
Hi Peter,

The Oracle document have some clue too. But we don't have access to support right now.

E1: 04: Payment Batch Error: No F0911
Records Exist in This Batch (Doc ID
2250475.1)
Last updated on MARCH 31, 2017
APPLIES TO:
JD Edwards EnterpriseOne Accounts Payable - Version
9.1 and later
Information in this document applies to any platform.
SYMPTOMS
A payment batch may fail due to an AP PrePayment
BSFN function (B000062) comparing the corresponding
paid voucher (F0411) table data and payment voucher
(F0414) table data by the follow fields: DOC, DCT, KCO,
SFX and SFXE. If there is a failure to match any one of
the fields the following error (error number 0002) will
occur on the R09801E error report: 'No F0911 Records
exist in this Batch'. In addition, the work center
message displays a message 'Payment 0 0 in Error'
*
Change the error messaging to provide a better error
description to help the user to determine and quickly
correct the matching process so that the payment batch
can post.
 
Hi Peter,

I also compared the F0411 and F0414 and I could get two records, so it is matching with all the 5 fields.

Code:
select * from proddta.f0411
join proddta.f0414 
on RPDOC = RNDOC
and RPDCT = RNDCT
and RPKCO = RNKCO
and RPSFX = RNSFX
and RPSFXE = RNSFXE
where RPDOC = 187
 
Rauf,

I have just returned from the end-of-year break.

Did the void create all the appropriate lines? When the payments were voided, were the vouchers voided too?
 
Hi Peter.

Welcome back.

We were also in year-end hassle, that is why we caught this batch in our analysis. The void created proper entries in the payment module, and also the voucher were voided.

As we had no time to spend on this during year-end process, we just replicated the payment entry and void operation in the test environment. Then removed all entries of the said batch from production. Copied the test environment entries to production and posted. It worked very well. We also re-posted the affected accounts to ensure the balance is correct.
 
Hi Peter,

The issue is recurring now.
And it happens from the same user and for same supplier.

I'm trying to find the root cause. It's very hard to replicate all the batches in test.
I guess it is something related with security. But your valuable suggestions are welcomed.
 
No.

It's standalone vouchers.
I guess, users did some thing wrong in wrong places.

Is there any way to roll back all related vouchers (or safely delete) and enter again ?
 
Rauf,

Sorry for the delay in reply. I've had a very hectic few days.

Provided there aren't any values in the Purchase Order columns in F0411 you should be able to void the vouchers and re-enter them.

If there are values in the Purchase Order columns in F0411 (the values do not have to relate to JDE Purchasing), then voiding the voucher will not work. If the values relate to JDE purchasing (and my memory is accurate), the purchase orders will need to be cancelled. If the values don't relate to JDE purchasing, they may need to be removed manually in the database.

Please check all the processing in your test environment first, before attempting a fix in production.
 
Back
Top