RE: Problems invoiceing -- BPCS-L

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