I seem to have a problem with the RNI report matching our GL for the AP Clearing account. After digging into the weeds, I realize the RNI is inherently flawed. So I am designing a dashboard with multiple BAQs to try to reconcile which Receipts were processed with invoices, fully or partially and which were not. Any suggestions? I often feel like I am the only client of Epicor’s that experiences the severity of their financial miscoding within their system. This is one of them. Job costing is the other.
Michele,
What version are you on? We are in the process of implementing and these sorts of snippets are useful. Have you got any more details? Have you logged case/enhancement with Epicor?
There is power in numbers, If this is a big issue and we all log enhancement requests it should elevate the visibility of what some may think is minor. Of course they need to have sensible detail and business cases that support the change.
I guess one of the big issue around this processes is the fact that one of Epicors big features is one of its biggest caveats. You have identified a flaw, and are going to the effort to design some dashboards to resolve your problem. once you have it working you won’t need the enhancement request and for you the problem goes away. Epicor loses the visibility and the problem is never fixed. Add that onto the fact the there is no really simple and easy way to log these issues (or even vote on them) compounds the problem.
I see this as one of the bigger challenges that Epicor has. They have come a long way with product in recent years, now if we can fix this area it is going to make things sooooooooo much better.
Cheers
10.2.100.15. Through extreme pain staking effort and time I have uncovered 2 very large coding problems with Epicor with regard to Job Costing. They are adding it to their list of development needs but in the interim, I am forced to pay a consultant to fix it. No kidding. I am not a fan and would change in a heartbeat if we could afford it. I am the CFO here and the financial results of their coding errors costs me thousands. I would not recommend them at all but until our company can afford to transition, I have to make the best of it. If you decide to go with Epicor, I highly suggest you hire a dedicated sql developer as you will be spending lots of money and lots of time, not customizingas much, but fixing and correcting their “not-thought-through” coding.
What are the issues you found with the RNI report? It is a time sensitive report that updates with each new PO receipt and each matching of an invoice to a receipt. The only time it could tie to the GL is right after the month-end Capture. Are you seeing something different?
Hi Michele,
yus we had issues with the reports, also we needed to be able to go back in time and see the grni position as of. I have got a baq/dashboard that reconciles to out dashboard. Happy to share if you like
1 Like
@michele Can you elaborate on the 2 very large coding problems? How can I replicate this issue and see if I am losing millions of dollars as well?
Anya - Yes please. if you wouldn’t mind sharing your baq, I would greatly appreciate it. I have spent days trying to narrow down the IJs and PJs and using Power BI (MS) to reconcile them faster.
Claudia - The primary issues we are seeing are when there are multiple invoices to one PO. For example, if we purchase 1 item (no matter if to inventory or other) but are required to pay in installments after receipt. If i purchase the item on the PO for $60k but I can pay in 6 monthly installments, the 1st invoice for $10k will wipe the PO clearly off the RNI Report so it never shows again. However, the remaining invoices are no longer allowed to pull from Receipt line so we have to use Misc Line. This means if we are not careful, the remaining $50k will never come out of the AP Clearing account. We learned the hard way through trial and error that we have to make sure the AP invoice GL is manually set to AP Clearing in order for the Balance Sheet to be accurate. However, during the 5 months of payments, the RNI will never match our AP Clearing account.
Other issues so far surround AP invoices NOT properly posting to AP Clearing at all. This is a case# that we had to get a Fix for. Even though the invoice was setup as receipt line and we brought in the detail as such, when it actually posted, it changed the GL. We are about $185k off between our RNI report and our AP Clearing account.
Hasokeric - this is one of the coding issues. The other is labor costs in the job costing engine.
I have spent more than a year attempting to narrow down why our job costs are so out of sync and inaccurate. I have made many change internally to help reduce and eliminate. This issue does not exist in standard costing environment, only ALL of the other ones. We are Avg costing which pushes the job costing and job management directly onto the production manager proactively instead of re-actively to the staff accountant.
What I uncovered is ALL Labor entries will post to a job immediately. This means all “entered”, “submitted”, “approved” and “Rejected” labor entries will always post to the job costing engine whether or not the entry has hit the INVWIP report or the GL. (We do not use the MES) For ex, an employee enters in their time for 99 hours instead of 9 and for qty 9 but only clicks on save. The manager cannot see this entry to approve which means it is not on the INVWIP report to be captured but this cost will post a transaction to the job cost table. So if the top asm gets moved out to another job or to a customer or to stock, that “entered” time is included in the costs of that part. Then lets say the employee notices it (via payroll controls) and clicks submit. The manager can now see it and rejects it because they should have entered in 9 hours, not 99 hours. Now the job costing table has replaced the “entered” time with the “rejected” time. Yes, the 99 hour rejected time is now permanently costed in the job and will remain as so. Change it up. Lets say the manager did NOT reject it but told the employee to change it and resubmit for 9 hours. The job costing engine will not replace the “entered” 99 hours with the “submitted” 9 hours BUT BUT BUT the top part already moved out already costed with the “entered” hours of 99. Not only is this allowed, but incredibly difficult to find because essentially the original 99 hours are erased and replaced with the 9 but you know the original shipment must have included 99 hours when you back into it. That is how I found it.
After many many conversations, Support sent this to development to update and review and sent me a consultant to implement a BPM that has increased from 12 hours to now 20 hours because it is a bigger impact than originally expected. And they want me to pay for this. Not happy!
Michelle, did you resolve your GL/RNI Report discrepancy issue?