I tried to do this in test but I can’t seem to replicate it, so I apologize in advance for all of the noise in the screenshots.
Has anyone ever seen this, where you do a DMR-REJ and it goes to one account (based on reason code, as desired) and then you delete it (especially after running capture cos/wip) and it credits the wrong account - it uses the part class or company account for DMR Write Off instead of re-using the reason code account?
I found KB0049234 and clearly the person wasn’t just complaining that the reversing transaction went nowhere - the point is that obviously the initial rejection went somewhere, so where did the reversal go?! I think the tech missed the point there and said “just slap an account on the part class GL and move on with life.” Well that’s probably what we did, too, years ago (actually we used the company GL, but same idea). But it’s still wrong.
If I can’t replicate it, I’ll get nowhere with support (and I understand), so I’m hoping there is someone that knows how to replicate the issue.
In real life it went like this. At 2b, it went into 1316 (sixteen) in August, and at 3a it comes out of 1315 (fifteen) in October.
1316 is the reason code account in this case (I triple checked) while 1315 is the company GL account for DMR Write Off.
So, it dawns on me that I (myself) cannot determine from TranGLC what was the previous reason code.
And I think that means that the posting engine makes the same bad assumption I did, which is to join the current DMR action to the GL control (through the reason code) to determine the credit account for posting.
We expect it will dig up the original reason code (through PartTran, would be the only way), but that’s not realistic. The posting engine just is not that sophisticated, I don’t think.
I’ll have to test this (later), but I think that’s it.
My biggest complaint with GL Controls is that there’s no warnings about exists transaction, or possibly orphaning costs.
Like if you want to have a separate GL account for a specific type of inventory. So you create a part class, and a GLC, then assign that Part Class to the part.
Now all future transactions will use that GLC for the parts inventory. But any current inventory for that part debited the original inventory account. Those costs are effectively orphaned. The proper way is to Qty Adj to zero, change the Part or GLC, then Qty Adj back to the original QOH. Making sure to use the same reason code for each Qty Adj.
I guess a method to track your issue of a reason code or GLC change would be to archive the Inv/WIP Recon report each month. Then you’d have a record of the GL accounts each part transaction used.
Change GL for part somehow to account 1400 no money moves.
Issue part money out of account 1400
Conclusion: money left a different bucket than it went into (with no transfer of money in between)
I thought of my situation differently, since I am not changing the GL on the reason code - I changed the reason code on the DMR - but that’s shorthand for a lie, because you can’t change the reason code on a DMR, you have to delete and re-add through transactions. So I assumed the transactions would bind it. But I know from experiences like yours that transactions are never committed to accounts except at running a capture.
I guess it still irks me, since I did a transaction with a reason code and that reason code’s GL didn’t change.
First reject goes to debit 1316 (per reason code 91000)
Run capture to lock in the account
Delete the rejection
Reject for a different reason
Both transactions (since the capture) hit account 7545, per reason code 99350
a. WRONG!
b. Credit should hit 1316, per reason code 91000
c. Debit should hit 7545, per reason code 99350
So it does all the math on the current reason code for action # 1, not the transaction reason code.
Well, I imagine it will lock both DMR-REJ into 1316 at that point.
Case in point, I did the process again with no capture in between but I used a third different reason code, and ALL unposted transactions for that DMR action went to the account tied to the most recent reason code.
(It’s subtle - the third segment went from 24 to 50.)
But the History Tracker shows the different reasons.
I opened a ticket, now that I can replicate it. We shall see.
Since the reason code for the DMR-REJ is on the PartTran table, I feel it should use that reason code and accompanying GL. (It’s field PartTran.InvAdjReason, even for a DMR.)
I can’t quite crack the logic of the posting engine.
I have proved by testing that it uses the DMR reason code rather than the PartTran reason code.
I opened PE Log viewer for my Inv-WIP report. It creates 4 “Part Entities” called DMR Reason and slaps all of them with the reason of 99240. (Wrong, there are 3 different ones…)
GL Transaction Type Maintenance only shows that it pulls from the “Reason” entity. Well, no kidding. But what’s the OTHER side of the join? I don’t think I can drill any further than that.
I wanted to update this, but mostly I want to clarify my thoughts since they were kind of all over the place as I worked through the problem with everyone’s help.
While I started out ambivalent, I now see that this really is a bug and you all should be aware of it.
The update: my EpicCare case was pushed to development on PRB0229300 a month ago but I have not received any updates. So there’s that.
But to summarize the issue, DMR-REJ transactions are posted to the account tied to the current reason code for that DMR action number. “Current” meaning at time of posting, not time of transaction.
This is bad logic. DMR-REJ transactions have a reason code all by themselves - there is no need (or good reason) to go and reference the DMR action to get the code.
This causes problems.
Basically it’s only a problem if you create the DMR-REJ in one period, then capture to lock in the transaction, then delete the DMR-REJ after the capture
Deleting a DMR rejection action - with no replacement - makes the transaction post to some other account (Part Class or Company) in the hierarchy
Deleting the rejection and replacing it with a rejection to a different account (all in the same period) makes an in and out of the same new account - the one for the reason code on the DMR now - rather than a credit to the original and a debit to the new
In none of these scenarios am I changing the GL code (or contents) on any reason codes. This is simply assigning a reason to a DMR-REJ transaction.
This is a first for me, I think. They say this fix is complete now. It says “resolution” is 11.2.100. (Kinetic 2021.2, right?) I have not confirmed it myself, though.
money into account 1300
