MAJOR ERROR: RE NXT Webview Posting into FE

Our team was discussing this very topic earlier this week. We wanted to test. Thx for flagging this issue. I have saved this post to ensure we do not miss any updates. Has anyone experienced something similar?

I came across this same issue yesterday, @Anthony Gallo , and have opened support case 020808004. Fortunately, we are still posting through DBV, which has helped us avoid a potentially serious situation with our Finance partners.
The issue appears to be occurring in the GL Distribution window, where Gift Type rows involving cash are being duplicated. One row contains the correct Debit and Credit account numbers, while the second row contains incorrect account information.
This likely explains why others are seeing duplicate transactions, as the system is processing both distribution rows.
We were looking forward to exploring the new batch functionality in Webview; however, until this issue is rectified, we will not be able to move forward with the batch rollout.

Thank you so much for sending this into support. Once we get the bug on our side we will dig in and resolve anything that looks off.

From support:

Apologies for the delay in getting back to you on this case.

Our product engineers have confirmed that in RE NXT we do limit collecting data to the first 500 gifts (which will typically generate 1000 journal entries), this is why it stops at 1000 entries.  You would need to generate the post to GL in smaller batches to avoid this issue.

I am trying to find out if there are plans to change this moving forward but I'm waiting on a response.

🤯How is this functional? We would have to post more than 10 times in a month at some times of the year??!? Please expand this ASAP.

Limiting the gift data collected to the first 500 gifts is concerning to our team. We often receive more than 500 gifts daily during the most active periods of our annual appeal. This limitation is definitely a migration blocker. Please let us know if there are plans to eliminate or at least raise the limit.

Thanks for the candid explanation, @Anthony Gallo. It’s refreshing to finally hear directly from someone in engineering.

That said, the transparency gap here is hard to ignore. None of Support knew about this 500‑gift limit, it’s not documented anywhere, and customers only find out when production postings fail. For something that directly impacts GL workflows, that’s not a great place to be. We've wasted a month and a half with trying to get this to work and troubleshooting an issue that was nothing we could fix.

What makes this more frustrating is that there is an Early Access Program specifically to test constraints like this before they hit general availability. That’s where limits like these should be surfaced, evaluated, and communicated — not discovered by users in live environments after the fact.

Glad to hear you’re looking at increasing the threshold now, but clearer documentation and proactive communication would save everyone a lot of time and avoid unnecessary troubleshooting.

Appreciate you stepping in here and being open with us.