Change Write-off Distribution for RM Apply Transactions
This works perfectly IF I can use the default write-offs distribution from posting accounts setup. Unfortunately, my employer needs to post the write-off to a different GL string based on the debit distribution from the original invoice.
Is there any way to add a GL distribution node to the Apply Transactions node?
I’ve tried using the taRMDistribution node, but that fails. (It returns an error indicating that I haven’t included either a GL Account or a GL Account Index. I’ve tried hard-coding each of these – one at a time – to a known value but still get the error.)
I don’t see why you couldn’t add the taRMDistribution node to this taRMApply node – no reason you couldn’t. And also no reason why you shouldn’t then be able to call it successfully. So if you get the missing account/account index error but had hard coded them – then I would be puzzled. You could do a SQL Profile trace so you can see the call to SQL that eConnect makes and/or output the SC output to Dynamics GP – File to verify the data being sent to eConnect.
I’m not sure I’d bother as I don’t believe this approach is going to (easily) work. The reason is that the distributions are going to go into Work status (since the assumption for that node is a new work status transaction).
But you could potentially adjust the distribution in an after map task directly in SQL. But you’d be on your own in any “business logic ramifications” of doing so.
So i’d ask you – how are you handling this today since GP doesn’t allow this? The only thing I can think of is to make a GL Adjusting Entry to net out the previous Write Off Account with the value to the actual account you wanted it to go to.
So assuming so, then you’d just run an ‘after map success’ task if there is a writeoff amount and you need to switch the account.
Have that 2nd map task create that 2 line GL Entry. So not exactly what you want but would be recreating what you are likely doing manually now.
Yeah… “this approach won’t (easily) work”… you have a gift for understatement, Phillip.
Fortunately for me it turned out to be fairly easy to write and run an ‘after document succeeds’ SQL Script to piece together the appropriate account string, grab the index from GL00105 and use that to update both RM10101 and GL10001.
Thanks for looking into it for me!
If you would like to submit an answer or comment, please sign in to the eOne portal.