Finance | Project Operations, Human Resources, ...

ER rreporting :Vendor Payment Journal Status Update from Bank Return Files (Duplicate ACK )

(4) Share

Report

Posted on by VM-08071421-0

166

Hi Everyone.

We’re integrating with a bank (let’s call it “ABC Bank”) in D365 Finance and Operations. When payment files are sent via ER from the Vendor Payment Journal using the "Generate Payments" button, the bank responds with two acknowledgment files – ACK1 and ACK2.

Here's the issue:

The bank uses the same status code (ACCP) in both ACK1 and ACK2, even though ACK2 can later contain a rejection (RJCT).
In our setup, we use the Return format status mapping table to map these bank codes to internal statuses.
When ACK1 arrives with ACCP, the system immediately updates the Vendor Payment Journal Line status to Approved.
Because the line is already marked as Approved, ACK2 (even if it has RJCT) doesn't change the status to Rejected, which leads to an incorrect status being displayed in the system.

What I’ve investigated:

The VendorPaymentJournalLineEntity and VendorPaymentJournalLinePaymentStatus entities are involved.
I traced the Return format status mapping, but couldn't find a direct reference or logic in the code where the status update actually happens or where it checks if an update should occur based on new values.

What I’m looking for:

Is there a technical or functional way to handle this scenario better?
Can we somehow delay the status update until both ACKs are received or introduce logic to allow override if a RJCT is received later?
Where exactly is the status being updated from the return file, since it's not clearly tied to the "Return format status mapping" directly?

Any guidance, workaround, or experience with similar cases would be highly appreciated!

Thanks in advance,

Categories:

Dynamics 365 Finance

Microsoft Dynamics AX

I have the same question (0)

All responses (3)

Answers (0)

VM-08071421-0 166 on at

Like (0)

Report

ER rreporting :Vendor Payment Journal Status Update from Bank Return Files (Duplicate ACK )

Hi

Did anyone faced this issue previously ?

Was this reply helpful? Yes No
Suggested answer

Navneeth Nagrajan 2,179 Super User 2025 Season 2 on at

Like (1)

Report

ER rreporting :Vendor Payment Journal Status Update from Bank Return Files (Duplicate ACK )

Hi VM-08071421-0,

Question (s):

1. In your vendor payment journal do you have only the bank return files scenario?

Worked on a scenario very close to the scenario highlighted above. Functionally, In the Generate Payments pop-up window it is hard to add filters in the "Records to Include" section would suggest point number 1, as an approach technically.

Suggestions:

Assuming you will have other type of transactions coming into the vendor payment journal would recommend the following:

1. Extend LedgerJournalTrans:: update() method and write a method similar to processPaymentDocument()

Technically, you can add multiple filters in your Generate payments section /// <summary>
/// Extension class for LedgerJournalTable to add custom methods.
/// </summary>
/// Custom class
[ExtensionOf(tableStr(LedgerJournalTable))]
final class DmoLedgerJournalTable_Extension
{

//call tstProcessBankPaymentDocument();

next update();

}

private void tstProcessBankPaymentDocument()

{

BankDocument bankDocument;

if (this.isBankDocumentPaymentProcessNeeded())
{

////Check the status of ACK1 - Can retrieve this file format through Electronic reporting parameters screen (If you are using those parameters)

switch (this.PaymentStatus)
{
case CustVendPaymStatus::Approved:

}

}

Code snippet of processBankPaymentDocument from LedgerJournalTrans standard code added.

Hope this helps. Happy to answer questions, if any.

Was this reply helpful? Yes No
VM-08071421-0 166 on at

Like (0)

Report
ER rreporting :Vendor Payment Journal Status Update from Bank Return Files (Duplicate ACK )

Hi Navneeth,

Thanks a lot for taking time to help on this :)

Yes, I am sending the payment file to the bank via the "Generate payment" process and receiving both success and failure acknowledgements in return. After the file submission, the bank sends two acknowledgement files in sequence:

ACK1

ACK2

Per ISO 20022 standards, the typical status codes are:

ACCP: Accepted Customer Profile – Technical validation successful

ACTC: Accepted Technical Validation – File is technically correct and queued for processing

RJCT: Rejected – File contains errors or issues preventing processing

The issue arises because Bank ABC is using the same status code (ACCP) for both ACK1 and ACK2. Since we’ve mapped ACCP to the status "Approved" in our system, the journal line is being marked as approved even after ACK1, without waiting for the actual final outcome from ACK2.
This causes a conflict, especially in cases where ACK2 later sends RJCT (Rejected), which should ideally override or block the approval.
I’m exploring whether we can introduce logic in the code to differentiate between ACK1 and ACK2, so that ACK1 results in a status of "Sent" instead of "Approved", and we only treat ACK2 as the final indicator for approval or rejection.
Technical Details:

I've debugged the code you mentioned. The issue is that the process is being triggered via the data entities, and currently, we don’t have any mechanism to identify whether the input is from ACK1 or ACK2, or to trace the specific status returned.
There are several ER (Electronic Reporting) related classes being invoked—for example:

ERModelMappingRunResult result = modelMappingDestinationRun.runUnattendedAndReturnResult();

These are linked to ER models and ultimately call the entity Vendor Payment Line Status to update the records. However, no context is retained at that point to distinguish the source file.
Please let me know if you’re aware of a way to intercept this process or pass additional context into the ER logic so we can handle ACK1 and ACK2 differently.

Was this reply helpful? Yes No

Join the conversation

Community site session details