× 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.



Milt is 90% right. There are a lot of things which can cause inventory to
go negative, outside of BPCS. However, here's some ways we get inventory
negative, and live with it.

We process labor reporting JIT600 in batches, because efficient use of our
personnel is important to management. At end of shift, we do billing for
what was shipped. At that point in time, the last hour or so of labor
reporting has not yet been posted, so we drive into the negative, the
inventory which was completed, and shipped at end of day. Then when the
last hour of production work is processed, via JIT600, those negatives are
wiped out.

There used to be a phenomena in banking called float, where we would write
checks for products and services, and it would take a few days for that
money to change in our bank accounts. We called the time between writing
the financial transaction, and it showing up in our bank account, as FLOAT.
Similarly in a factory there is FLOAT between the time of an action in the
factory, and the data about it getting into BPCS. Some inventory negatives
can be due to that float. The record of inventory creation, and
consumption, might not get into BPCS in the same sequence as they occurred
in the factory.

We have second shift factory workers, but only first shift clerical. First
thing next morning, JIT600 batch goes in for last night factory work, and
the last hour or so of prior day work before the billing. That means that
we have negative inventory for whatever got shipped and billed, which was
the last stuff made in the factory each day.

When MRP runs in the evening, we have that negative inventory, on parts
fixed by next morning JIT600.
If an item has negative 1,000, MRP tells you to make 1,000 even if there are
no other requirements.

Listing, and fixing, negative inventory, either should be after you are all
caught up with relevant transactions, after factory has stopped working,
like at end of week, or if you have some way to tell that the inventory has
been negative for more than a few hours.

We are in V4.5CD. In that reality, JIT600 batches update BPCS in sequence
of shop orders included in the batch, not in BOM sequence of production.

We have part# system as follows:
Part ABC for some customer.
Part ABC-A ABC-B ABC_C etc. for major components of that part.
Then components of those have more characters appended, where the add-ons
are not arbitrary, but describe the nature of the components, or combining.

Thus when we run MRP to see what we need to make for a customer, and its
components, then use that in turn to drive shop order release, the BOM
components end up getting higher number shop orders, than the parent parts,
because the shop orders are released in item # sequence.

Then if all of that ended up in the same JIT600 batch, the labor tickets are
processed in shop order# sequence, so the parent parts are driven negative
inventory, before BPCS processes the BOM work which made those parent parts.

There is no easy way to fix this.
We could change our number system .... unacceptable.
We could modify JIT600 update processing system, or how shop orders are
released. We have modified the latter to a small degree, by releasing
orders based on type of item ... child items then parent items.

Any ERP works great if there is 100% accuracy in reporting, data entry,
engineering, no bugs in the software. But there can be errors in all of
that.

There are places where inspection spot checking is enough, and places where
100% inspection is essential. We have found the latter to be true for
receiving from some vendors. Their claimed quantity and quality for
contents of some containers are often off.

Some BPCS data entry often does not have good systems for verification.
Users end up checking to see if the results are as expected. Suppose a
transaction was entered incorrectly. They don't see the results where
expected, so they re-enter correctly. This means the system accumulates bad
input, which is not detected at data entry time. This can happen with
customer orders, purchase orders, shop orders, engineering, shipping,
receiving, physical inventory, software modifying, just about anywhere.

There are bugs in how BPCS handles scrap, compared to how we deal with
scrap. Basically BPCS lacks granularity that we need. We have adjusted
yield to deal with this, but it is not a perfect solution.

We have found that there can be errors in our engineering. Our labor
tickets have been modified from vanilla BPCS, to include, among other
things, a parts list associated with each thing to be made. If the workers
or inspectors see an error in the routings and BOM associated with what they
are making, they are to bring this to the attention of engineering. This is
a continuing process.

We have found that there can be errors in our processing of engineering
changes. If how the part was actually made, diverges from how BPCS thinks
it is made, then what inventory is consumed in reality, diverges from what
BPCS eats.

For the parts BPCS is consuming, in excess of reality, then come physical
inventory time, we find we have purchased astronomical volume compared to
what we really needed. For the parts being consumed that BPCS does not know
about, this shows up in the shortage reports landing on the inventory
manager's desk. We have a little slip of paper, which identifies the part,
how many we needed, how many we found, signature of the factory supervisor
who verified it. The inventory manager receives a small pile of these slips
every day.

Al Mac (WOW) = Alister William Macintyre
via WOW WAY.com ISP
2012 April I had a serious PC melt down, from which I am still recovering

Note: messages sent to this discussion group end up in archives which anyone
may access, to help with future problem-solving.
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Kobie Jooste
Sent: Tuesday, August 07, 2012 7:37 AM
To: BPCS-L@xxxxxxxxxxxx
Subject: [BPCS-L] BPCS V4.5CD / ERP Lx - Minimum Inventory Levels.

We have a Clients running from BPCS V4.5CD up to ERP Lx (BPCS V8.3.04)
and the Client running 4.5CD asked if there are any setting to stop
inventory transactions if the Stock On-hand goes into a Negative.



I have looked in Inventory Management / System Parameters / Facility and
Warehouse Management, but could not found any settings, any ideas?





Kind Regards,

Kobie Jooste - Snr. Consultant

cell: +27 79 884 0161 | tel: +27 11 607 8100 | fax: +27 86 233 2146

Kobie.Jooste@xxxxxxxxxxxxxxx <mailto:Kobie.Jooste@xxxxxxxxxxxxxxx> |
www.esoftworx.co.za <http://www.esoftworx.co.za/>











Note:
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. EOH and any of its subsidiaries each reserve the right to monitor
all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized to
state them to be the views of any such entity.
Thank You.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.