× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Here's how this works in 4.0.5 CD which may have some differences.
Also some stuff can depend on the system parameter settings.

Years ago, we could make sure everything entered on items before processing
them, but lead times have become shorter with customers clamoring for us to
start work on new items right away. So it is not unusual for us to start
production before engineering is done, order parts before they are costed,
ship to customers before priced. I have some reports that look for
mismatches such as stuff active in MRP whose cost master is null. By the
time some things are fixed, some damage has been done to our accuracy.

There is a program to update transaction effects which says where IN etc.
transactions are to go for GL, stored in ITE file, and a GL program to say
how much detail when it gets there.

We are doing IN lump sum for a whole day's input.
We are sending A adjustments to GL Journal AJ with full detail.
Some other transactions using their own Journal ID with varying detail.
We have added a lot of reason codes for adjustments, and some other kinds of
transactions.

The cost of the transaction in ITH is as of when the transaction occurs.

Suppose we have a new item, and the cost has not gone in there yet, but
there are some transactions. Those transactions occur at zero cost.
Then the cost gets fixed ... suppose you have 10,000 of the item on hand.
The cost of the quantity of inventory, jumps to 10,000 times that cost, but
nothing happens to General Ledger. So now if you were to list on-hand times
cost, it will be out of balance vs. GL.

When we do a purchase order, there is an expected cost, which comes from the
standard, but can be updated.

When the inventory is received, it goes in at the standard cost, because our
system parameters say to do things at standard cost. The opposite GL
entries are value of inventory added vs. what we owe vendors for value
received, not yet invoiced.

If the standard cost gets entered for the item after receiving, but before
invoice from vendor, then the GL is way off for both value of inventory, and
what we owe vendors for received, not yet invoiced.

When the payable invoice is entered, it goes in at actual cost, generating a
material variance for the difference between actual cost of the invoice, and
standard at the time of the invoice going in. The opposite GL entries are
what we owed vendors not yet invoiced, vs. what we now have in payables.

If the new item has not had standard cost entered by time of invoice from
vendor, we have a humongous variance, then if the standard cost entered
later, we now have $ added to on-hand, bypassing the General Ledger.

Before running CST600, we copy standard to simulation cost set.
After running CST600, we run a report that lists items that have a
difference between standard and simulation, that difference times on-hand,
to get the change in the value of our inventory, thanks to the rollup.

After running shop order purge, we run a report that calculates value of
inventory consumed by open shop orders, where the shop orders not yet
completed. I call this "black hole" of inventory "off the books." A more
politically correct name is "value of inventory between discrete items in
the factory pipeline."

We also have a TRUE MATERIAL COST which is actual copied to this cost set,
then that rolled up. This is for people who want to see impact on end items
by changes in actual cost, without waiting on shop orders to trickle it up
in production.

-
Al Mac

Happy I remain this functional: Wake up each morning; roll out of bed; feet
touch floor; I can stand up (sometimes need to push with arms); walk; get to
toilet; all familiar systems do their thing.
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Michael Perna
Sent: Wednesday, August 19, 2009 1:36 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Inventory revaluation in BPCS

Running BPCS 4.3



Issue:

We are posting inventory transactions to the G/L and there are times
when the inventory is off. We've discovered it has to do with the
changing of standard costs.

When a user changes the standard cost via CST100, an ITH record is
written with a # type and quantity is zero. When posting IN
transactions to the G/L it bypasses all records with a quantity of zero.
How does BPCS ever revalue inventory? Also, when the standard cost is
generated via CST600, the #record is not written. If the standards for
components are changed and the cost gen is run, how does the finished
good inventory get revalued?

Thank you all.



Michael Perna

Business Systems Analyst - Finance

t. 310.832.8000 | f. 310.519.2605
P.O. Box 1950 | San Pedro, CA 90733 | USA, Earth
contessa.com <http://www.contessa.com/>









As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.