Re: Hung Invoices

>  From:    cmassoglia@voyager.net
 
>  We have a number of invoices which appear to be hung.  

We have some problems but not the same as yours ... we do not use L* files 
for example.  Some of our solutions may be applicable to your scenarios.

If there was no problem, the data in many files should be in total agreement.
Reports, that compare data that should be in agreement, and only print when 
there is disagreement, become lists of scenarios still waiting to be fixed, a 
check list of sorts.
When we compare data in two or more places, representing billing data in 
transition, and assuming our software written correctly, then the only 
differences should be any data that is in transition right now, and mess ups 
not yet cleaned up.

At our site, daily shipments are supposed to be 100% billed that evening, so 
any of our discrepancy reports run after billing should only show list of 
problems not yet fixed.  We have many such reports using Query/400.

The data flow that interests us are the files EC* to ES* & ITH to BB* to SI* 
& RAR ... the asterisk represents more than one file with that same prefix 
... links between these files include customer order, shipping document, 
billing invoice

ECL has totals so far picked to ship, shipped, invoiced, received (resupply 
orders)
We have a query to list item lines whose totals are not in sync & to math 
what the difference is.  In theory, if this is run after billing done for the 
day, and resupply orders excluded from the report (still in transition), then 
the only discrepancies should be mess-ups that have not yet been fixed.

IYH transaction code "B" means billing, but it is really populated by shipping

Query/400 has capability of no-match ... list ONLY the records of this file 
that have no corresponding match in that other file ... the query/400 
documentation is a bit obtuse on how to work this, so you need to experiment 
a bit to be sure you doing it right.

If you have an ES* record on a shipping document with no corresponding SI* 
record on that same document, that gives you a list of shipments that never 
got invoiced.  However, you also need to review manual activities that go 
outside the system.  Sometimes we have problems in which this has to go out 
right now, but the shipping PC is down, or some other problem, so we end up 
with a shipment on paper but not in BPCS yet.

If you have an ITH_B transaction with no corresponding SIL invoice on that 
item, that is another way to list items that got shipped but not billed.  
Query/400 tip ... ITH is a monster file.  Any query lists of it must go via 
JOBQ.

Because of risk of independent bombs in shipping & billing or reporting 
errors many different people, it may be constructive to produce a daily "ship 
sheet" shared across all corporate departments.  We generate ours off of BB* 
& ES* files on eve of billing.  Recipients of our "ship sheet" are supposed 
to do various checks & promptly report to accounting when

This price is wrong
This quantity is wrong
Something is missing
This should have been voided
Freight did not get billed to customer
or whatever the scenario is, so that corrections can be made promptly

Because you do not know exactly where in a process records got messed up, it 
may be smarter to have a check list that identifies a mess up, fix customer 
billing via post ship billing, delete the mess up remnants from BPCS to save 
time of any future employees independently discovering the problem & 
researching from the evidence left behind.  

It is possible to add a general comment to the inventory history so that 
someone scrolling through can see where we fixed what kind of problem.

Something to bear in mind when there is abnormal termination of somebody's 
session.  Many applications create a "batch" of work associated with that 
person's work station address & do not handle the stuff consistently.

If a shipping or billing or JIT6* session is disrupted & no action taken to 
repair the session, the next user of that application at that workstation 
will "reprocess" the work in the batch, which can lead to duplicate postings.

If an ORD500 session is disrupted, there is work session member information 
of value in ECH & ECL files that can help diagnose the situation, but the 
moment the user starts another session, the contents are totally wiped.

It is useful to know which applications use which methods.

Folks connected via PC network sessions had better be using addresses that 
are truely unique in the first 8 characters because that is combined with 
application codes in batch creation.  You will have big time corruption of 
BPCS data if you let 2 or more users have identical first 8 character work 
station addresses.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| 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
+---