The Achilles-heel of most ERP solutions

Logged In: YES
user_id=1150252

A) The basics of a FIFO-engine

Let's assume you have a table where you have all your
inventory movements. I will call it inventory ledger.

First you need anothe table, I will call it FIFO application
table. The FIFO-application table shows N:N relationships
between incoming and outgoing inventory movements. When
something moves out of your inventory, you should not even
try to calculate FIFO cost - it will be bloody slow.
Instead, create a field in the item table called last FIFO
cost, and update it at every running of the FIFO adjustment
batch job (discussed later). All outgoing inventory
movements simply take this cost. You also need a field in
your inventory ledger called remaining FIFO quantity. It is
redundant, but you need it for speed.

So, all outgoing inventory movements move out on the last
FIFO cost field in the item table, and you write a double
WHILE-cycle, that takes all incoming entries to the same
warehouse, checks the remaining FIFO quantity field, sets it
to zero or to the outgoing quantity, and creates entries in
the FIFO application table showing what incoming entry is
applied to what outgoing entry, and the quantity and date.
The cycle ends when either all your outgoing entries are
applied or you are out of inventory. In the later case, if
you allow negative inventory, then the outgoing entry should
have a negative remaining FIFO amount and should be tried to
apply it again later with the FIFO adjustment batch job.

Then you need a FIFO adjustment batch job, that can be run
by the user or they can set it up to run automatically f.e.
every day at midnight.

The batch job first tries to apply all unapplied (negative
remaining FIFO quantity) outgoing inventory movements. Then
it takes the FIFO application table, and adjust the cost of
outgoing entries.

Ideally, you would have a table, maybe called inventory
ledger costs, with N records for every 1 record of inventory
ledger, where you have the values, and in the inventory
ledger the cost fields have no actual data but just SQL
queries or something like it, to read the inventory ledger
costs table. If it works this way, the the adjustment batch
just needs to create new records in the inventory ledger
costs table.

What to take care:

- reservations must be "stronger" than FIFO
- You need to allow the user to make manual applications and
actually they MUST do it when doing credit notes / return
shipments - it must be MANDATORY or else you will have a mess!
- These manual application must not be item number -
dependent. For example a user may change item numbers if the
make some technical modifications to their goods: then they
move out from the inventory the old goods and move in the
inventory new item numbers. Then they apply the incoming
movement to the outgoing one and this way they can ensure
correct costs.
- take care of unit of measure conversions

Logged In: YES
user_id=1150252

B) Additional costing issues 1

1) If you have functionality to move goods within a
warehouse , from one shelf to another, then please take care
to not use you inventory ledger table but make another one.
Make a totally separate shelf-level inventory application
area. If you don't do this, you FIFO adjustment batch job
will be too slow.

2) Actually it is a very good idea to have N inventory
cost/value records for 1 inventory movement record. ERP
software who don't have look really stupid compared to the
ones that have it. Assume the following scenario: you buy
something for 10 EUR. Then you have a shipping charge of 2
EUR, and you have to add it to the cost of the previous
items. It should be booked by a vendor invoice, and the cost
to be assigned to the original movement. To help the user,
you should make automatic cost distribution funtions: they
select the movement records they want to assign the shipping
charge (or other costs), and then they can choose to
distribute the cost 1) evenly 2) by value 3) by weight
(typical for shipping charge) 4) by volume (also for
shipping charges) 5) by approximate tariff (duty) amount.

The later one is for tariffs (duties). It is very important.
If you have an import purchase, the tariff is usually
calculated by "total landed cost on the border" * tariff
percentage. "Total landed cost on the border" means purchase
price + the shipping charge until the border. It means you
must have a boolean field in your inventory cost/value
records showing it is a shipping charge until the border,
and an SQL-query field in your inventory movement table
called landed cost on the border, summing up purchase price
and these records, and then when you post a vendor invoice
which is actually a duty (tariff), then you multiply this
value by the tariff % in you item table and make this value
the base of automatic cost distribution.

3) You must allow your user to manually revalue wrong
entries. Typically much of the starting inventory at going
line is wrong, as users often can't get out correct cost
from their old software. Then they have to revalue the
entries. Revaluation is simply a new item cost/value record.
You revalue incoming entries and the FIFO adjustment batch
job will take care of the outgoing ones.

4) Please lean back and think over how your users can mes up
their inventory values and COGS. There are 5 kinds of
typical incoming inventory movements: 1) from a vendor with
invoice 2) from manufacturing 3) by a manual inventory
adjustment 4) from a sales return/credit note 5) transfer
form another warehouse.
1) Vendor invoice: no problem, if they mess it up, it is
their fault. They must correct it with a vendor credit
note.
2) Manufacturing: you don't have it yet, so don't worry.
3) Manual inventory adjustment: the BIGGEST mess! A
typical situation is when the warehouse wants to ship
something but there is not enough inventory, because
they forgot to receive something. Then they make a
incoming adjustment and usually don't care about the
costs... suggestion: use the last FIFO cost.
4) Return / credit note. Users MUST apply it to ensure
the exact reversal of costs.
5) Movements between warehouses: no problem, just
make 4 records for all movements: out from the first
warehouse, into the truck upon shipping, out from
the truck, into the second warehouse upon receiving.
Apply all of them to each other and everything
should be right.

Logged In: YES
user_id=1157624

http://www.compiere.co.uk/modules.php?name=News&file=article&sid=1
# Post-ERP depression

ERP systems often wreak cause havoc in the companies that
install them. In a recent Deloitte Consulting survey of 64
Fortune 500 companies, one in four admitted that they
suffered a drop in performance when their ERP system went
live. The true percentage is undoubtedly much higher. The
most common reason for the performance problems is that
everything looks and works differently from the way it did
before. When people can't do their jobs in the familiar way
and haven't yet mastered the new way, they panic, and the
business goes into spasms.

Why do ERP projects fail so often?

At its simplest level, ERP is a set of best practices for
performing different duties in your company, including
finance, manufacturing and the warehouse. To get the most
from the software, you have to get people inside your
company to adopt the work methods outlined in the software.
If the people in the different departments that will use ERP
don't agree that the work methods embedded in the software
are better than the ones they currently use, they will
resist using the software or will want IT to change the
software to match the ways they currently do things. This is
where ERP projects break down. Political fights break out
over howor even whetherthe software will be installed. IT
gets bogged down in long, expensive customization efforts to
modify the ERP software to fit with powerful business
barons' wishes. Customizations make the software more
unstable and harder to maintain when it finally does come to
life. The horror stories you hear in the press about ERP can
usually be traced to the changes the company made in the
core ERP software to fit its own work methods. Because ERP
covers so much of what a business does, a failure in the
software can bring a company to a halt, literally.

But IT can fix the bugs pretty quickly in most cases, and
besides, few big companies can avoid customizing ERP in some
fashionevery business is different and is bound to have
unique work methods that a vendor cannot account for when
developing its software. The mistake companies make is
assuming that changing people's habits will be easier than
customizing the software. It's not. Getting people inside
your company to use the software to improve the ways they do
their jobs is by far the harder challenge. If your company
is resistant to change, then your ERP project is more likely
to fail.

Logged In: YES
user_id=1150252

WTF?

Logged In: YES
user_id=1150252

Is anyone actually interested in this stuff? Should I write
more?

Logged In: YES
user_id=1150252

Jorg, Kathy, anyone...

please say something, should I continue this or not?... Do
you need my ideas or not?...

Logged In: YES
user_id=195397

Hi shenpen,

Please continue with your thoughs.
I'm interested.

Regards,
Trfion

Logged In: YES
user_id=329831
Originator: NO

costing is included in current release