There are several ways to tackle this kind of scenario. However, such errors might not be unusual. A company ought to have a standard set of processes to handle corrections, with minimal hassles for everyone. The sooner an error is detected, the easier it is to fix. You have no doubt discovered that each transaction generates a cascade of records, now potentially messed up.
· Item costs … files CMF CIC IIM
· Inventory Transactions via ITH to G/L
· Inventory quantities in IIM IWI ILE maybe more
· Shop Order FSO FOD FMA, FLT labor history and I forget what file has the JIT300 data
· Customer Order ECH ECL
· Billing Invoice SIH SIL
· Sales History SSD SSH
· Accounts Receivable
· General ledger
· MRP not generating replenishment correctly
On the above list there are things we would never bother to fix, because it is too much trouble.
We would focus on accuracy moving forwards. We might put some explanatory notes with any General Ledger adjustment journal entry. Some things should not be “fixed” unless you know exactly what you are doing, or risk messing stuff up even worse.
Whatever method is used, it needs to avoid annoying corporate departments which can have conflicting interests:
· Accounting might not want anyone entering corrections to fiscal periods which are now completed.
· Production might not want anyone updating shop orders, whose paperwork is on the shop floor with information contrary to after the changes.
· Customer Service might not want any corrections conducted in such a way that info is broadcast to our customers that we made some mistake, in addition to those they already know about.
· Some people want the data made correct. Others want audit trails such that later auditors can see what updates might have been made.
You might check your Unit of Measure for stocking, receiving, and shipping.
We also have 405 CD, and sometimes there is a mis-match between vendor invoice and what we received, involving UM, which can cause wrong cost to be entered for item received. This leads to what we call a material variance, where the cost is different from expected.
I am no longer involved in Payables … there’s a bunch of files impacted.
HPH HPO HVH for Purchase Orders, then there are the unpaid and paid invoice files.
There are the general ledger accounts which track the mismatched PO vendor delivery, vendor invoice.
Upper management gets a daily score card listing unusual spikes in a variety of topics, and you betcha they will question an error of the magnitude you reported, within a day or two after it being posted.
We have made some modifications, so your reality might not match ours.
When something is messed up with our shop orders, we typically fix the master records, close out the shop orders, run MRP, then relaunch the shop orders with the correct data. If you want to fix the shop orders without closing them, then look at what SFC540 lets you do.
We report most of our transactions to shop orders via JIT600 series, which backflushes the inventory based on labor reporting, but if we need to back out an incorrect transaction, JIT600 will not let us do anything with negative inventory consequences, so in that case we use SFC600 series to back out the labor side, and INV500 to back out the inventory side.
However, once the reported quantity completed for any operation is greater than or equal to the quantity ordered, that operation becomes closed, then when all operations are that way, in FOD file, the whole order is coded complete in FSO file. Shop Order Purge CST900 won’t remove an order until the reported inventory agrees with what was needed to make the end item.
When we have unresolved problems in our shop orders, we delay the purge until they are resolved.
Inventory with incorrect cost can be fixed with CST100, which sends inventory transaction of “#” to the ITH audit trail, showing which cost set bucket facility etc. of the item was impacted. Use CST300 and BOM300 to explore the product structure of parts which conceivably got their costs contaminated because of the one messed up that you already know about.
We use “A” adjustment transaction for correcting inventory quantities, thru INV500, with various reason codes for WHY the inventory was being corrected, such as CC for Cycle Count. BPCS permits the addition of inventory transaction codes, and reason codes, to handle common scenarios.
Our accounting department is hostile to anyone entering transactions dated in a past fiscal month, after we have run end-fiscal-month for that month. But sometimes, they will approve General Ledger adjustment entries. You may need this to correct the General Ledger account which tracks the value of your inventory. BPCS also supports the addition of Journal codes to support scenarios which we want to track independent of what flows from the other BPCS applications.
Alister William Macintyre (Al Mac)
-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of Colette Coates
Sent: Thursday, May 15, 2014 6:01 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] BPCS 405CD: MS inventory transaction issue
Hi All,
I need to correct a shop order ‘MS’ transaction involving an incorrect quantity for a finished good item (case pack 24). The quantity should have been 233 but instead 5592 (233*24) was posted. It occurred a couple of weeks ago (April) but it has only come to light now, so in the meantime there have been a couple of transfers (April), and one billed sales order shipment (May) which all carry an incorrect cost. The inventory levels for the item are also incorrect.
How do I go about correcting not only the initial quantity error on the MS transaction, but also fix the inaccurate costs associated with the subsequent transactions?
Any help would be appreciated.
Sent from Windows Mail
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email: <mailto:BPCS-L@xxxxxxxxxxxx> BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: <
http://lists.midrange.com/mailman/listinfo/bpcs-l>
http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: <mailto:BPCS-L-request@xxxxxxxxxxxx> BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at <
http://archive.midrange.com/bpcs-l>
http://archive.midrange.com/bpcs-l.
midrange.com
