Change Write-off Distribution for RM Apply Transactions
Tom asked 5 years ago
I’m creating a SmartConnect map to apply cash receipts. The Cash Receipts were imported and posted earlier. The apply map will read the same data set as was used to import the Cash Receipts in order to apply the transactions. A few apply transactions will include write-offs.
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.)
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.)
Answers
Patrick Roth Staff answered 5 years ago
In GP, you can’t change the write off account either if you take a writeoff. So that would probably be why you can’t change the default on the taRMApply node (although MSFT certainly could have added it here).
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.
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.
Tom replied 5 years ago 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!