Like what you see? Discover the benefits of the GPUG Community. Learn More
We recently upgraded to GP2015 and are running into a strange, intermittent issue with Enter/Match PO Invoices. If you review the transaction in history, only the credit entry booking the amount of the invoice to A/P has defaulted. The remaining debit to Goods Received, Not Invoiced is not included in the distribution window. However, when the transaction posted to the general ledger, two transactions resulted; one with a debit to Goods Received, Not Invoiced and the other to A/P; but they are in two separate incomplete journal entries. These, of course, hang up because they are incomplete, with one entry needing to be completed and the other deleted.
Has anyone else run into this issue and have you determined what is causing the split in the debit and credit portion of these transactions into two incomplete journal entries?
Goods are received:
Debit to Inventory, Credit to Goods Received, Not Invoiced.
Invoice matched to receipt and vouchered:
Debit to Goods Received, Not Invoiced; Credit to Accounts Payable
Financial Batch hangs up:
GL Transaction number 1: Debit to Goods Received, Not Invoiced; no offsetting Credit
GL Transaction number 2: Credit to Accounts Payable; no offsetting Debit
Again, this is intermittent.
We had the same issue at my previous company. We were running GP 2013 R2 and used a third party PO system. Unfortunately, we did not find a solution while I was there. We assumed it was a problem in the communication between the third party system and GP. I'd be interested in hearing the solution. Sorry I couldn't be of any help other then letting you know you are not alone.
Thank you for letting me know that I am not alone and, better yet, understood. I just don't understand how posting a purchasing transaction can result in two partial general ledger transactions with the debit on the first transaction and the credit on the second.
I have not heard of this happening with out-of-the-box GP and I am really not sure how it even could. Something has to be interfering with the normal processing. I suspect, as in Spring's case, you have some customization or 3rd party add-on that may be causing this to happen. Can you let us know what, if any, customizations/add-ons you have? That may ring some bells for someone.
I am actually working on this right now with one of my clients. Are you using a third party Requisitioning Application? My customer is using Paramount and we are in the process of elimination on what is causing this issue. This is what we have discovered so far.
1. Decimal Places on the item is 4
2. Decimal Places setup in Paramount is 2
3. Invoice is received and when matching the dollar amounts by line the Extended Price is off by a penny or two.
4. Payables Clerk changes the Extended Price to match the invoice
5. Saves the transaction
The Invoice Posts without any errors on the Purchasing side but it creates two journal entries in the Financial Series. You will have to manually adjust one of the entries and delete the other.
I would love to know if you are only using GP and this is happening. That would allow me to eliminate Paramount and focus only on GP.
I look forward to hearing from you on your PO Enter/Match and Requisitioning process.
We use SalesPad for purchase orders and receiving, so yes there is a third party product involved.
Hi Anne & Nancy,
We also use a third party requisition program, ReQlogic. We are experiencing issues with the decimal places between ReQlogic and GP, but have not experienced the financial batch issue. We process our receiving batches different from your processes. We post a Shipment/Invoice, not a Shipment, then a separate Enter/Match invoice. Is it possible that the order of operations could be causing the issue?
I have a client that is experiencing this same issue. Was a resolution ever found on what was causing this and how to resolve?
Site designed by Brightfind
Powered by Cobalt xRM and Higher Logic