Perhaps in a future e-mail, you can let us know what version of BPCS you are
on, because some details can be version specific. I had to modify this
stuff on a S/36 version years ago, and it was incredibly complex. We are
now on version 4.05 CD.
I don?t run this stuff personally, rather I get called upon to help figure
it out when somehow things get messed up.
My understanding is that MRP500 looks at independent requirements from CO,
safety stock, forecast, etc., then MRP600 looks at requirements which are
dependent on the MRP500 needs, based on BOM etc. These do NOT create firm
planned MRP orders. Similarly CAP gets its info from the MRP runs. The MRP
runs create MRP planned orders.
Firm planned MRP orders are created by:
Ø Human beings can manually turn planned orders into firm planned orders via
maintenance like MRP510
Ø Or when an order is created ? SO PO RO etc. ? the act of doing so, makes
that a firm planned released order
Ø I believe that SO PO RO etc. can be created where there is no MRP planned
order, and that also creates one, although a later MRP regen or net change
may update the MRP date in the order to read all 9?s which means MRP thinks
we do not need it.
Running MRP250 MRP540 MRP550 etc. creates a list of suggested orders, which
humans can ignore, or act on, either by looking at a humongous report, or by
viewing the info on screen. It is only if you tell BPCS to release 100% of
the suggested orders as real orders, or release some by other means, do the
SO PO etc. actually come into existence.
There are job streams to create SO PO etc. They can be launched from the
MRP, or manually.
In the midst of the run there are work file members which have like 1 2 3 4
5 for the sequence of orders being created, then somewhere in the middle of
the run, the actual order #s get created.
It has been a long time since I drilled down into the nuts & bolts of the
many nested programs involved.
All BPCS files have a member with the same name as the file. This gets the
physical file meaningful contents. Several files have work members, whose
names are based on the work station involved. For example two or more
people might be creating the same kind of order at the same time. The work
products, of the two people, are in members named using most of the letters
of their work stations, with last few letters truncated, then a few letters
in front, identifying the software steps they are on. There?s a few
exceptions to this, such as customer returns, explained in BPCSDOC. You
might want to take a look at which BPCS files have multiple members.
The ZPA file has records remembering the last # assigned for CO SO PO RO
invoice, post-ship, anything which needs incrementing. When BPCS needs #s
to be assigned, it goes to ZPA to look up that reference, then looks at
what?s out there to find the next open #, assign it, and update ZPA
appropriately.
I don?t remember if the # there is the last assigned, or the next to try.
Our ZPA file has just over 500 records.
One of them has file key PUR500NN containing 045769 then a bunch of other
data ? we have an order 45768 but no 45769, then a bunch in the 180k series.
It is possible that 45769 existed, and has been ended. (I checked our HPO
file for this.)
One of them has file key SFC520SO containing 035377 ? we get our SO via
SFC520 and 35,377 tells BPCS where we left off assigning SO #s. We do have
an SO for 35377. (I checked our FSO file for this.)
Contents of ZPA file can be updated via SYS100 = System Parameters
Maintenance.
You can also page thru everything, just to see what?s there, without
changing the story.
Some parameters are accounting related, and are updated by other programs
like ACP180 and ACR120
Warning, you better know what you are doing if you modify the #s involved in
the incrementing.
Suppose you reset next # to say 100, and there?s ten thousand orders out
there from 101 onwards, BPCS will look at them all, one at a time, until it
finds that some # like 10,001 is available to use.
Warning, when BPCS gets up to 9999999 however many digits the field allows,
the next # assigned is ZERO ? some people do not like that as a # for
invoice, order, etc.
Warning: At EOY, we often roll back some counters to ONE. If later in the
new year, we get to some # which has history from the last time that # was
used, but the old order has been purged, it makes inquiry almost impossible
to make sense of. So if you are going to purge old orders, also look into
purging history activity on those orders.
Alister Wm Macintyre (Al Mac)
Linked In
https://www.linkedin.com/in/almacintyre
reminds me I hit 30 year anniversary with my day job
Aug 1984 - 2014
-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of
gvarvaressos@xxxxxxxxxxxxxx
Sent: Friday, September 26, 2014 10:42 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Planned Orders becoming Purchase Orders and Shop Orders
Could someone please explain this to me from a file/field perspective.
My understanding is that MRP600 creates planned and firm planned
orders and MRP540 turns them into released planned orders.
Does MRP540/JIT540 take KFP/KOR records and add them to HPH/HPM, with
records id = FP?
Where do the new PO numbers come from?
Thanks in advance?
--
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
