We are also 405 CD and your scenario sounds like old home week to me
You should know that when there is an error message on bottom of BPCS
screen, there can be more than one of them, you can scroll thru them, you
can put cursor down there and F1 on the error messages for more info ... I
say this because when you did the billing, and it ignored those shipments,
in our version of 405 CD we would have got an error message explaining why
this happened, but if Jim not aware that messages can be stacked, then
might not know how to go down the stack.
There is a phenomena that can result in having serious gaps in knowing the
To put it delicately ... too many cooks working at cross-purposes and not
doing such a hot job of communicating with each other about what they all
done or not done.
The most common human error is to disregard BPCS error messages to the
point of claiming that there were none.
When we have "Jim's problem" we have to check a lot of stuff, because we
can only guess who is not telling us the whole story about what went wrong,
or who did what of relevance.
If you look in the layout of the ITH history file records for the "B"
transactions, you should find identification of the work station that did
the shipping. Now check SYS993 on that work station to find out if
shipping had a crash and did not tell anyone, so it is still in a crashed
condition. While you are in there, also check the work stations that do
the billing, just in case someone tried to invoice this before Jim got into
the act, and had a crash and not tell you. I have found it useful to send
to an *OUTFILE the contents of the BPCS Data Areas that keep track of what
is going on in these jobs that have a series of steps, because if one
crashes, it can leave debris that will cause the next run of the same job
at the same work station to also crash, and add to the debris. Thus, since
crashes can often go unreported, it can help to have a reference list of
the contents of these data areas to determine which ones have trouble
inviting another crash the next time some job runs.
Be sure when doing SYS993 resets that the work stations in question are not
actually in the middle of the applications you are fixing.
The mere fact that you had to fix the IN USE flag is an indication that
SOMETHING went haywire.
I have queries I run nitely over *FIRST and RETURN to list what's IN USE
because something haywire is commonplace.
Now use ORD300 to access the order(s) that were shipped but not invoiced.
The summary screen should have an overall status # for the order ... jot
that down whatever it is.
Next F16 then F11 will get you to the order lines that were shipped ...
check their status code (last entry last line) ... put cursor on status (in
the detail lines screen) and F1 then scroll ... you may wish to print for
reference. The question is whether the coding for the lines are in
agreement with shipped but not yet invoiced, or if someone has been mucking
with the order before the invoicing was completed.
When someone is in ORD500 trying to update a customer order, that shipping
has started work on but invoicing not yet completed, the ORD500 user ought
to get some error message that the order is in the invoicing status or
something, but then there is some command the ORD500 person to take to
basically say "I don't care ... what I need to do takes precedence over all
other activities." and by taking this command, the shipping invoicing gets
corrupted beyond ability to repair.
Check the Order Type ... there are some types of orders that are not
supposed to be invoiced.
Shipped Yes, Invoiced No
Example: DRP Resupply Orders inter-facility or inter-company as opposed to
an outside customer.
What is the order type on the shipments not invoiced?
We sometimes have orders with the wrong type.
Also look in the BBL file ... it ought to have an entry line for each
shipment not yet billed.
BBL in concert with ESH file contents will tell you which order lines were
shipped ... we sometimes have a problem when the same order lines get
partially shipped more than once before any of them invoiced.
This is regular customers orders right? not Billing Adjustments using
When you do specials do you populate the ECS lines or do people do work
arounds because they not know the right BPCS way?
Check on your work stations involved. Are they all BPCS-compatible?
When a new PC is connected to the network, it often defaults to a name like
QPDAV00009 or something, then BPCS strips off the last 2-3 characters from
the end to use in work area naming, and if you have 2 or more such devices
attached doing BPCS work, that is a prescription for disaster. Do you have
such a scenario?
Sorry, I thought that was too easy.
Subject: RE: [BPCS-L] Problems invoiceing
Thanks. Yes, the flags were at Y.I had reset these earlier with no
Dont know if there is something else that is not allowing it to be
From: Ginger, Linda
Subject: RE: [BPCS-L] Problems invoiceing
Check if the in use flag, HINUSE, in the ECH file is equal to "Y". If
so change it to be a blank and the orders should be available for
Motion Water Sports, Inc.
Subject: [BPCS-L] Problems invoiceing
In BPCS 4.05, I have several orders that shipped, but I am unable to
invoice. They were shipped, ORD570 was run(I can see the 'B' trans in
history), but when I run BIL500, system tells me that no orders exist in
range. If I run BIL660, it shows me these orders as shipped but not
invoiced. On the technical side, does anybody have any ideas as to a
status code, database file member, etc..that could affect the invoice
Al Macintyre http://www.ryze.com/go/Al9Mac
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2021 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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.