The order lines should also be in a status of "C" not "E" for entered.

-----Original Message-----
From: bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+dsweeney=phoenixbcinc.com@xxxxxxxxxxxx] On Behalf
Of Jim
Sent: Thursday, December 30, 2004 10:39 AM
To: SSA's BPCS ERP System
Subject: RE: [BPCS-L] Problems invoiceing

We do the Ship Confirm on a different workstation than the one we use
for
invoicing. Looking at SYS993, it looks ok.
The status of the 4 orders in question is 'C' = Confirmed(at the header
level). At the detail level(ecl) the status is 'E'.

Order type is OK.

There are records in the BBL file(the 4 orders in question), nothing in
the
ESH file.

Any ideas?




-----Original Message-----
From: bpcs-l-bounces+jmergen=pctcnet.net@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+jmergen=pctcnet.net@xxxxxxxxxxxx]On Behalf Of
Alister Wm Macintyre
Sent: Wednesday, December 29, 2004 9:21 PM
To: SSA's BPCS ERP System
Subject: RE: [BPCS-L] Problems invoiceing


We are also 405 CD and your scenario sounds like old home week to me
(familiar territory).

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
whole story.
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
member RETURN.
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?

Al Mac
Global Wire

  you wrote:
>Sorry, I thought that was too easy.
>
>  -----Original Message-----
>From:Jim
>Subject: RE: [BPCS-L] Problems invoiceing
>
>Thanks. Yes, the flags were at Y.I had reset these earlier with no
>success.
>Dont know if there is something else that is not allowing it to be
>invoiced.
>
>-----Original Message-----
>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
>invoicing.
>
>Linda Ginger
>Motion Water Sports, Inc.
>
>
>-----Original Message-----
>From:  Jim
>Subject: [BPCS-L] Problems invoiceing
>
>Hello,
>
>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
>flag,
>status code, database file member, etc..that could affect the invoice
>printing?
>
>Thanks
>
>Jim

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
--
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: jmergen@xxxxxxxxxxx

-- 
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: dsweeney@xxxxxxxxxxxxxxxx


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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 [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.