|
midrange.com
Al is correct. If you are on V4.04, you must be modified with millennium
changes. The problem could be there.
He is also correct that the order processing cycle is complicated and has
many opportunities to go wrong.
This is the type of problems we solve on a daily basis. In trying to
resolve this, consider the following:
Try to find a pattern.
How long has this problem been occurring? Did something change just
prior to its first appearance as a problem?
Is there a pattern of the same items or same customers always having
this problem?
Is it happening on the same item type, such as kits?
Does it always occur with the same user, but other users don't have
the problem?
Verify the process
Are you confirming by order or line?
How are allocations done?
Are allocations being changed or deleted?
Are allocations being left behind after this process?
Can you duplicate the problem? Can you duplicate it in your test
environment? (It might be specific to your production environment)
Check for modifications.
The answers to the above should point you in the right direction and assist
you in resolving this issue. Good luck.
Mike Bloom
Manager, Help Desk Services
Nexgen Software Technologies, Inc.
(630) 300-6082
MacWheel99@aol.
com To: BPCS-L@midrange.com
Sent by: cc:
owner-bpcs-l@mi Subject: Re: BPCS V404 ORD570
Order
drange.com Confirmation
10/05/00 03:47
AM
Please respond
to BPCS-L
From Al Macintyre V405 CD
How long have you been operating on V404 as a company & is this a
relatively
new problem, or something you just noticed & narrowed down to this cause?
You might also check the BPCS_L archives. I seem to recall that other
people
ahve reported inconsistent random problems with customer orders
experiencing
weird glitches in which various people tracked them down to particular
programs.
There are actually several steps to shipping ... pick confirm ... and woe
betide you if you do them in the wrong sequence. There are many
opportunities for human error. This process is not exactly user friendly.
It could be human error that is causing your problems, especially if the
people hired for the shipping department were hired for reasons other than
their computer interfacing skills.
Does anyone do any validation that the totals they get from BPCS are
correct?
Like total cartons out the shipping dock to various trucking companies vs.
total cartons BPCS says went out the door & billed to our various
customers?
It seems to me that there is an enormous volume of people trying to do
their
jobs & the suspicion of bad data various places ... how do we know the
total
dollars this place or that place is in fact the correct figure?
Since you are not on an officially Y2K fixed version of BPCS, could you
tell
us what you did instead to survive? There were literally thousands of
fixes
that I saw after base 405 CD that were date related. Something was done to
make your V404 survive-Y2K, or you did a typo & you really referring to
V606.
or V604 or something.
What I am hinting at is that you cannot possibly be on a vanilla unmodified
version of BPCS if in fact you are V404. You either must have used one of
the 3rd party outfits out there to make your V404 work through the Y2K
distraction, or you are using ridiculously low volume of total BPCS modules
... like no inventory, no MRP, no shop orders.
I am assuming that V404 is very similar to V405 CD ,,, we never ran on 404
... we came from BPCS/36 ... in any case, our shipping creates a "B" record
in ITH & a related record in BBL from which we get the Billing. Are you
saying that you do not get an ITH record, or that you get one but the
values
in there are not correct?
We have some legitimate zero price records related to inter-facility
shipments that go through our system as a re-supply order. Now we do have
some internal company politics problems due to purchasing dept insisting on
copying resupply requirements as purchasing requirements for convenience of
their reports, and then recieving resupply against purchase orders, so the
resupply never gets relieved, but we have been able to narrow down the
cause
of zero times one equals 0.001 to BIL522 where it does the unit of measure
conversion without a big enough work field for RPG, which I consider to be
a
systemic problem all through BPCS.
In other words, RPG has a maximum size of numeric values of 30.9 (30
digits,
9 decimal) and many BPCS fields are pushing that size, and they multipliy &
divide each other such that there is no space for the numeric overflow.
Now
the RPG manual will tell you that unpredictable results come from
mathematics
in which the work field is too small to contain all the digits required,
like
trunctation in a calculator not to enough decmal places only worse because
the program loses track of where it was in the math, but RPG is not big
enough for BPCS to do straight multiplication & division on many fields.
There needs to be some more involved calculations to handle the numeric
overflow, but SSA programmers have not yet aquired that skill, and besides,
the definition of field sizes is so far removed from the actual math that
it
is non-obvious when fields are inappropriately sized for the operations.
I am amazed at the code that has been accomplished here ... how many
million
man years of programming does BPCS represent ... but there are some
patterns
of programming practices that are asking for trouble.
My management has not seen fit to make AS/Set available to me & I predict
that if your programmer does not have AS/Set either, then 4 weeks is an
awful
short time ... allow for perhaps 4 years to solve this problem due to the
sheer size of ORD570 & the nature of the "source" code generated by As/Set.
ORD570 & ORD500 are two programs that I have had to give up trying to debug
without As/Set.
Al Macintyre
Programmer & etc.
> From: SavoyG@troycorp.com (Savoy, Gregg)
>
> We are experiencing significant problems with Order Confirmation. The
> problems are inconsistent. Our shipping person runs ORD570 several
times
> each day (start and stop). It appears with each "batch" there are
shipped
> lines that are not costed nor updated to the ITH file. In addition, we
have
> had zero cost updated inconsistently either from this problem or
another.
> Based on our research this problem has been occurring since the system
was
> installed. These programs are "vanilla" except for Bill of Lading
layout
> changes.
>
> My programmer has been debugging this program (and its called programs)
for
> about 4 weeks (he is interrupted several times each day) but he has not
been
> able to identify specifically what is causing the problem.
>
> Can anyone provide some insight into what might be at the root of the
> problem? It appears this problem is in the base code so others must
have
> encountered it.
>
> Thanks,
>
> Gregg E Savoy
> Director Information Technology
> Troy Corporation
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---
As an Amazon Associate we earn from qualifying purchases.
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.
