Received Not Invoiced Question

[prog_0927]

Progression 7.9.310

We have an issue with Received not Invoiced on how to clear these out that shouldn't be on there. If we back out it appears that is just takes it out of inventory and if just mark it as history it doesn't seem to move the dollar amount (correct me if I am wrong on those two statements). What is the best way to clear these out, we have a few years worth. Any help is greatly appreciated!

 

[dgillz]

This happens when the AP voucher is entered without using the PO and Receiver. You should look at the "Force use of Receiver" checkbox in AP Setup or this issue will perpetuate itself.

But in order to clean up existing invalid data on the Received Not Invoiced report, you need to update the POORDLIN_SQL and possibly the IMRECHST_SQL table. Make the qty-inv = the qty_received. If you are using Receiving Inspection, this may not be quite as simple. I do not have access to a database where Receiving Inspection is in use so i cannot test it.

 

[prog_0927]

Thank you for the response! We do not use Receiving Inspection, do you know what the SQL would like for identifying these? I can correct the qty_inv = qty_inv via SQL, just trying to make sure I understand all the report parameters used to pull the data; also, does this just affect what is on the report or will it also correct inventory and dollars as well (assuming another process would need to be run)?

 

[NEmacGuy]

Could you just manually close the PO and not include closed PO's on the report ?

 

[dgillz]

Sorry for the late reply. What I described will not correct inventory. Presumably these vouchers debited inventory, as did the PO receipt itself. So the correcting entry, assuming no purchase price variance, is debit accrued receipts and credit inventory. You may also have fixed asset purchases or expensed item that were received bit not invoiced. Also, you may have multiple inventory accounts based on the material cost/type location record. And if the material cost/type location record changed between PO receipt and vouching, that is another consideration.

So the SQL to do this is not easy.