Choices include:
. Your scheme, sounds like DRP to me
. Safety Stock
. FOR / MRP100 / ORD-Coded
. How we sometimes do parts needing repair-or version conversion
Each method has advantages and disadvantages to be weighed.
This installment tries to explain how we use fake customer orders to manage
some realities, where other systems might be better, for other companies
trade-offs.
Our company management has sticker shock with some computer vendor pricing,
which leads to some applications being dropped, if there is a sense that the
value we are getting from them, does not justify the costs. This dropping
can occur when upgrading from one version of BPCS to another, or when
SSA-INFOR records get screwed up, and it is simpler (cheaper) to let their
error stand, than to fight it.
There is also an issue of personnel training. There are people who
understand ORD MRP INV other topics. The less applications a company is
using, the less training needed.
FOR is very sophisticated, but if you don't need that sophistication, there
is a simpler MRP100 reality.
I do not know what happens if you have same items in BOTH FOR and MRP100.
I know with DRP, which we are no longer using, that DRP requirements are
added to others, and there can be input to DRP without ever running any DRP
programs, once the relationships are setup.
In our reality, we have problems with personnel viewing categories of BPCS
data, ignoring a bigger picture, and other issues I don't want to get into.
Bottom line, we have real customer orders, and fake customer orders. The
fake customer orders are "identified" in one or more of several alternative
ways:
. We have bogus customers, which we never ship to. In fact the
address is designed so that if someone accidentally tries to ship to that
customer, the product is not going to go anywhere. The purpose of these
customers is to generate demand thru MRP, while we have no intention of ever
shipping that product. It could be like your pre-build. Additional
maintenance is needed to lower the volume of orders on the bogus customer
accounts, when the right circumstances come along. There is an added
complication of those orders needing a due date which is MRP meaningful,
which requires appropriate maintenance.
. We have bogus customer orders on valid customers.
. Most have a customer purchase order # of FORECAST. We plan our
production orders 3-4 weeks out, and our purchase orders 5 or more weeks
out. The FORECAST bogus customer orders have a due date which is at least 5
weeks out, and less than or equal to however far out purchase planning is
going. We use these to plan safety inventory of raw materials whose lead
times are much longer than how much advance warning the customers give us
for confirmed orders. This system means that every week, someone has to
adjust the due dates on all this stuff. Maybe they need a program
modification, which will run every week, and automatically advance 100%
customer orders which have FORECAST in CPO, by one week.
. We also have certain customers which have pledged to buy some
annual quantity from us, and need us to have sufficient inventory to meet
their short lead time demands, where the raw materials might need 60+ days
lead time, and the customer changes requirements which are to be shipped
next week. For them we have a bogus order, with a due date at end of year,
using a non-working day, which everyone is supposed to know to ignore
requirements due on that holiday. As real confirmed orders get processed,
someone subtracts their quantity from the full-year quantity pledge, then as
end year approaches, the whole system gets redone for the next fiscal year.
. We do not have AS/Set so modifying some programs is not practical.
I would love for the bogus customer orders to never show up on the shipping
screens, so they never get accidentally shipped.
Our bogus customer order system works, most of the time, but it is high
manual interaction, to keep it working.
Alister William Macintyre (Al Mac)
-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of Weston, Jeff
BIS
Sent: Tuesday, June 10, 2014 3:41 PM
To: BPCS ERP System
Subject: [BPCS-L] Prebuild Inventory in BPCS
Hello All,
Were on an old version of BPCS (6.0.2) and I was posed a question from one
of our planners, that I was hoping someone on this list could give me
suggestions on how to go about doing it.
There is going to be a prebuild of extra inventory this year. We do not want
this inventory to be netted out in BPCS MRP in future planning periods. The
thought was to create a transfer order that matches exactly to the pre build
production and subsequent prebuild inventory. The transfer order would
allocate against the prebuild inventory. Here is the desired scenario:
Production/Inv +150 (50 prebuild)
Customer orders -25
Transfer order -50
Qty available to plan +75
Without the transfer order, +125 are netted in MRP planning and the prebuild
disappears.
Production/Inv +150 (50 prebuild)
Customer orders -25
Qty available to plan +125
The transfer order would be created to ship from 37 to a non-nettable
warehouse. The transfer order would never be received or shipped. It would
be reduced as the inventory was sold off against future customer orders
tagged as prebuild.
Thanks
--
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
