Re: backflush / scap / and the general ledger

* I checked out some stuff and looks like same deal on 405 CD.
* I tried to explain what we call a BLACK HOLE of Inventory Costs.
* I suggested some areas where errors in Engineering can complicate this.
* I speculated about various ways for programs to be developed to solve this.
* I shared info on some related problems we have.

version 6.1

i'll try to be brief but this requires some level of explanation. we're trying to keep our inventory qty's correct and also keep the WIP value correct in the general ledger when we scrap parts that are issued via back flushing.

the situation:

suppose we cut a work order for 10 pieces. the component parts in the b/m are coded to backflush at various operations as the operations get reported via SFC650. if every thing works ok, fine.

but now suppose we put some parts together at operation 10 and we find out that one of the 10 items being built won't work and needs to be scrapped. if we go to SFC650 and report 9 in qty food and 1 in qty bad bpcs does the following: - generates CI transactions to issue 10 set of components from the perpetual to WIP. these transactions get booked to the general ledger and not the perpetual inventory account is decreased and the WIP inventory account is increased by the value of the components issued. the on-hand qtys of the components parts are ok. - updates the shop order header to show 1 in qty finished. this tells MRP that the most it can plan to get from this work order now is 9 units. - generates an RJ transaction using the shop order parent part number for a qty of 1. this transaction get booked to the general ledger and reduces the WIP inventory account and increase the value of the scrap expense account by the value of the parent part. this is the problem. we may only have issued a few components to the shop order (and to WIP inventory account) but the RJ decreases this account by the total value of a fully completed parent part. this greatly inflates the value of the scrap expense account.

what do we think should happen? we think that bpcs should generate the following transaction for this scenario -generate a RJ transaction for the qty bad reported on the operation for every CI transaction it generates via back flushing. thus in the example above it would issue 10 sets of component part from perpetual to WIP and then it would remove the value of 1 set of these components from the WIP account - go ahead and update the shop order header to reflect a qty of 1 in qty finished. MRP needs to know that it is now only going to get 9 units. - go ahead and generate the RJ transaction for the parent part number. this would be for tracking purposes only. this RJ transaction would have to be coded to NOT book to the general ledger.

if you understand this, do you have any thoughts, experiences, or prayers you can share with us? how do other companies do the accounting for situations like this?

--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: macwheel99@xxxxxxxxxxx