web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Season of Giving Solutions is Here!
News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Small and medium business | Business Central, N... / Customer Payment Concu...
Small and medium business | Business Central, N...
Answered

Customer Payment Concurrency Issues?

(3) ShareShare
ReportReport
Posted on by Greg Kujawa 613
Using BC SaaS v26.5. We have found when our business is busier processing customer payments, there are cases where the documents and payments aren't being fully applied against the customer ledger. There are no runtime errors being thrown. But drilling into the detailed customer ledger entries, it appears as if everything isn't being fully posted. The processes involve base BC posting codeunit procedures, without custom mods coming into play. Looking at the timestamps, the issue usually occurs when two separate payment transactions are being posted within the same second or so.
 
Does anyone know if Microsoft changed the behavior when it comes to posting payments? In other words, if there are newer try blocks that might just be silently allowing the posting process to complete without flagging any issues? It's not until we review the customer ledger entries that we notice that the payments weren't completely applying through.
 
I can provide some examples if need be. Just wondering at this point if this is a known quirk.
Categories:
Dynamics 365 Business Central
I have the same question (0)
  • Greg Kujawa Profile Picture
    Greg Kujawa 613 on at
    Here is a link where I walk through what we are (not) seeing. Specifically the Application line is not being created in the Detailed Customer Ledger Entries. Just posting payments alongside the document using the base BC posting process. No runtime error.
  • Suggested answer
    RockwithNav Profile Picture
    RockwithNav 8,689 Super User 2025 Season 2 on at

    Is this something you are encountering every time?

    I am assuming you might be using two different batches for multiple payments processed at the same time. Ideally, this should not happen. We also used to process payments on the same day by multiple users using different batches, and we never encountered this issue.

    I would suggest trying a few more transactions—perhaps in a different tenant—to ensure everything is working as expected.

    Also, please try uninstalling any additional extensions, if there are any, and then verify again.

     
  • Greg Kujawa Profile Picture
    Greg Kujawa 613 on at
    This issue doesn't happen 100% of the time. Or even 10% of the time for that matter. I have narrowed the issue down to it happening when two users are posting payments right around the same time. Looking at timestamps, within the same second or two.
     
    The posting process is using the same payment journal batch for any sales invoice and payment being processed. Regardless of the user. I just find it surprising there isn't any runtime error being thrown. When I assume there is some sort of concurrency taking place with two users hitting that around the same time. 
     
    I did look at the AL source for the base BC codeunits 980 and 12, which are used for posting to the customer ledger. Didn't see any procedures wrapped in [TryFunction], so still have no idea how/why no runtime error is being thrown.
  • Verified answer
    OussamaSabbouh Profile Picture
    OussamaSabbouh 6,738 on at
    Hello,
     
    this isn’t a behavior change or silent TRY blocks. In BC SaaS v26+, payment posting logic is the same, but under high concurrency (two payments posted for the same customer within the same second), locking/timing issues can cause the apply step to partially or fully skip while the posting itself still succeeds. No error is thrown, and you only see it in Detailed Cust. Ledger Entries. It’s a known SaaS concurrency quirk; mitigation is serializing payment posting per customer or batching/queuing payments.
     
    Regards,
    Oussama Sabbouh
  • Suggested answer
    YUN ZHU Profile Picture
    YUN ZHU 95,918 Super User 2025 Season 2 on at
    As far as I know, this doesn't happen in the standard because the standard code locks the table before posting.
    Microsoft implemented Concurrent Inventory Posting in a recent version, but GL has not yet implemented it, so when posting simultaneously, another user has to wait.
    More details:
    What's new: Concurrent inventory posting
     
    Hope this helps.
    Thanks.
    ZHU
  • Greg Kujawa Profile Picture
    Greg Kujawa 613 on at
    I think Oussama has touched upon what's going on. The way we are processing these payments is posting them one at a time, along with posting the sales invoice. Each time the payment is hitting a default batch. So one user posts, hits that batch, their transaction is posted, and then the batch is clear for the next user to post something. Rather than this real-time processing, a more logical approach would presumably be for all payment entries to accumulate throughout the day in this batch. Then at the end of the business day, a back-office user would post the entire batch. Each journal line would be processed serially, and we would avoid this snag.
  • Greg Kujawa Profile Picture
    Greg Kujawa 613 on at
    One last footnote to this. I realize that legacy NAV was based on a proprietary DBMS. But ever since Y2K I think Microsoft has geared it to work with SQL Server. 
     
    That being the case, I find it puzzling how there isn't some sort of SQL Server transaction logic going on under the covers. Especially since posting to the GL and then posting to various sub-ledgers is a multi-step process. In pseudo-code:
     
    BEGIN TRANSACTION
     
    -- post to the first subledger
    -- post to the second subledger
    -- post to the third subledger
    -- post to the GL
     
    COMMIT TRANSACTION
     
    So if one of these steps fails, everything is rolled back and the user would be presented with some form of an error informing them of such. Based on this discussion thread, I don't believe this is taking place. And this is just very basic SQL conventions. I realize that BC blurs the lines between the application and database layers, but still...

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

News and Announcements

Season of Giving Solutions is Here!

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 1,688

#2
Khushbu Rajvi. Profile Picture

Khushbu Rajvi. 784 Super User 2025 Season 2

#3
YUN ZHU Profile Picture

YUN ZHU 595 Super User 2025 Season 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans