Hopefully in my collection of stories, of what can go wrong with PO's, you
find one that clicks to help you solve your situation.
You might check the PO's involved to see if 100% of the items listed there
have had quantity received greater than or equal to quantity ordered ... so
if a PO ordered 20 items, and 1 of them not yet fully received, that could
hold the other 19 "active" as far as MRP & other areas are concerned.
You might check to see if your ancient orders are "completed" from
perspective of the invoicing cycle. We have some vendors that I do not
understand how they are able to stay in business ... they take like six
months to bill us for what they shipped us ... this means the POs have to
stay open after inventory received, waiting on the ACP500 entry which
updates the quantity costed.
You might review all the ways that PO's can be created ... via PUR DRP
Outside Operations ... if a PO is coded to be involved in a non-standard
application, which has not yet gone through its complete cycle of
Performance or whatever closings, that could be causing it to be hung. We
do not have lot control, but someone made some mistake and got some
inventory coded with lot control & it took me forever to untangle that.
You might review how each person in the loop is coping with all the
different exceptions to the rules. For example BPCS insists that we only
have one copy of same invoice# on any given vendor, in the system at a
time, and expects each invoice from a vendor to be for one particular PO#,
but we have several vendors that insist on sending us invoices that are for
several different PO#s on the same invoice. Our accounting lady is able to
cope, and I have not modified anything there to help her cope, other than
various reports to illuminate what the heck is going on.
We receive PO's via "U" inventory transaaction into ITH
The ACP500 generates a "C" inventory transaction into ITH
I created a Query/400 to summarize by Item PO# vendor
one work file U's in a date range
another work file C's in date range
recognizing the C's can come any number of dates after the U's
comparing the two files found for me all sorts of discrepancies like
* we paid more than once for the same purchase
* the cost variance, in what we paid for, was not due to a cost variance
from the vendor
the discrepancies fell into various "this cannot possibly be happening" beliefs
a lot of people were shocked, including me, when we tracked down the detail
to substantiate what I found ... the problem is a combination of human
error, BPCS not able to post corrections to PO's after certain points in
the cycle, and the collection of vanilla reports have blind spots with
respect to what can go wrong
I recently changed GL on the U transactions to capture detail ... this
means the GJD file is now getting, in the various reference fields, the
item # vendor# PO# of the inventory received. The "C" transaction is
already copying vendor # vendor invoice # to GJD ... I modified our GLD230
report to look up vendor invoice # (if it still exists in payables) and
include PO# there. Actually I did that to help trace freight expenses, but
it will also help reconcile PO invoicing discrepancies, once we have decent
detail captured after my GL change. The ITE rules say where ITH
transactions go to GL Journal, while GL journal rules say how much detail
to accept.
I also have P.O.'s where I do not understand how come they have not got
closed & purged. They were created years ago. All the requirements of all
the items on the PO's have been received. All of them have been
invoiced. There is no mismatch between quantity ordered, received,
invoiced. All dates in there are long past any conditions for save some #
days.
I have a concern that any old orders, messed up in whatever way, may be
interfering with MRP ability to properly plan current needs for those same
items, so that we should always work towards a "clean" data base.
I suspect something is not right in some of these status codes I do not
fully understand.
We do periodically have people's PCs go down in middle of just about
everything & afterwards, if people think BPCS working Ok on whatever the go
down, we move on forwards as if all is well.
I seek permission of the folks in charge of PO's and other areas of BPCS to
force delete order & history stuff that I think we are done with, when it
is older than some historical cut-off ... typically 2 years.
BPCS has order #s go up to 999,999 then restart at 0 again ... we have gone
through the cycle on SO's many many times, on CO's a few times ... I do not
believe PO's yet. We sometimes reset back to 1 again, long before they get
to 999,999, and have found it can be a disaster to reach some order # again
when there is history in the system, of the last time the same order # was
used the last time.
Al Macintyre
BPCS troubleshooter, data forensics miner
I show a group of P.O.' s as having been all received earlier this
year. If I query those P.O.s, I see that there is an MRP reschedule date
field which contains dates for this October and into the future.
When I go to the MRP Planning/Pegging Inquiry for the part number on these
P.O.'s, the P.O.s' show up and with the "DX" in front of them. This is
not making any sense. Can anyone add some reasoning regarding how this
could show on the Planning/Pegging Inquiry when they are closed P.O.s??
TIA
Don F. Cavaiani
IT Manager
Amerequip Corp.
920-894-7063
"It's amazing what you can accomplish if you don't care who gets the
credit." Harry S. Truman
--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
Delivered-To: macwheel99@xxxxxxxxxxx
midrange.com
