RE: Problems invoiceing -- BPCS-L

Hello Jim, Are you sure the Ship Confirm process has gone OK. I don´t know in your version of BPCS, but in other versions, when having the Pick/ship confirm process all together, the system doesn't give you any message but the ship confirm doesn't finished. This is most of the time because the Means of Transportation and the carrier are not filled in in the load (OLM02, OPTION 2, 9 in front of the load, and then option 24). Please check this information. If it is not filled, filled it in and try to process again the Ship Confirm.

Good Luck
Enrique

From: "Jim" <jmergen@xxxxxxxxxxx> Reply-To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx> To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx> Subject: RE: [BPCS-L] Problems invoiceing Date: Thu, 30 Dec 2004 09:38:43 -0600 MIME-Version: 1.0 Received: from mail.midrange.com ([69.3.23.26]) by mc7-f16.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 30 Dec 2004 07:45:00 -0800 Received: from linux.midrange.com (localhost [127.0.0.1])by mail.midrange.com (8.13.1/8.13.1) with ESMTP id iBUFdIgj010928for <enriquecalvin@xxxxxxxxxxx>; Thu, 30 Dec 2004 09:39:44 -0600 Received: from sa-4.airstreamcomm.net (sa-4.airstreamcomm.net [64.33.192.164])by mail.midrange.com (8.13.1/8.13.1) with ESMTP id iBUFcoZF010885for <bpcs-l@xxxxxxxxxxxx>; Thu, 30 Dec 2004 09:39:02 -0600 Received: from SMIMOBILE4 (phi-broadband-pppoe2-ws-3.dsl.airstreamcomm.net[64.33.189.132])by sa-4.airstreamcomm.net (Postfix) with SMTP id DD995223D3Afor <bpcs-l@xxxxxxxxxxxx>; Thu, 30 Dec 2004 09:38:39 -0600 (CST) X-Message-Info: JGTYoYF78jGOA3bTrliIqoiufz2J58gb X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 13:53:11 2004clamav-milter version 0.80j on linux.midrange.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.2 (mail.midrange.com [0.0.0.0]); Thu, 30 Dec 2004 09:39:44 -0600 (CST) X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-1.7.2(mail.midrange.com [69.3.23.26]);Thu, 30 Dec 2004 09:39:03 -0600 (CST) X-BeenThere: bpcs-l@xxxxxxxxxxxx X-Mailman-Version: 2.1.5 Precedence: list List-Id: SSA's BPCS ERP System <bpcs-l.midrange.com> List-Unsubscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,<mailto:bpcs-l-request@xxxxxxxxxxxx?subject=unsubscribe> List-Archive: <http://archive.midrange.com/bpcs-l> List-Post: <mailto:bpcs-l@xxxxxxxxxxxx> List-Help: <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=help> List-Subscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,<mailto:bpcs-l-request@xxxxxxxxxxxx?subject=subscribe> Errors-To: bpcs-l-bounces+enriquecalvin=hotmail.com@xxxxxxxxxxxx Return-Path: bpcs-l-bounces+enriquecalvin=hotmail.com@xxxxxxxxxxxx X-OriginalArrivalTime: 30 Dec 2004 15:45:01.0296 (UTC) FILETIME=[85EA2700:01C4EE86]

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: enriquecalvin@xxxxxxxxxxx