Re: RE: Negative Invoice Number on RAR

[Al Mac <macwheel99@xxxxxxxxxxx>]

There's another scenario worth checking.
It may be that the scenario I go into in this e-mail has nothing to do with 
your problem, but this is at the stage of eliminating the usual suspects, 
or finding what is responsible so it can be fixed.

Billing occurs via a batch process.  If that process got interrupted, and 
not properly cleared before restarting, you have guaranteed garbage.

Run a query over ECH.HINUSE to find out whether there are customer orders 
in use ... also do this for member RETURN
If you are lucky, there are only a few, which can be fixed with DFU.
We have a scenario where shipping PC goes down, and it leaves 100% of the 
orders for one customer in that condition, so we have a mass fixit program
1. tell everyone to get off of customer orders
2. use GO CMDLCK vs. ECH to verify they all offf
3. run the mass fixit program

1. Try to determine what work station address(es) have been used to do the 
Billing involving the problems.  Get those work station names changed, or 
get the people doing the billing to use different ones, and see if the 
problem goes away (stops happening).  While you are at it, WRKSYSCFG *DEV 
make sure all work station addresses in use are BPCS compliant (7 
characters or less).  We have had some incidents of weirdness where people 
setup Client Access with addresses valid for AS/400 but invalid for BPCS, 
had some orders in a batch, then deleted one of the orders before the batch 
to a conclusion.

2. Take a look at where BPCS stores billing, and other data outside of BBL 
file, but also in work areas associated with the files of work stations.  A 
physical file can have infinite members, but I think the ceiling on a 
logical is 32.  We have had some problems with files having excess numbers 
of members.  Use *OUTFILE to get a dump of your BPCS file definitions, then 
run a query to identify which files have multiple members, then look at the 
actual lists of what they are called for files that have more than a 
handful ... I predict you will find customer order and billing files with 
excess numbers of members of unfinished work that needs some kind of 
cleaning up.

Work station members is something that there is a lot about in BPCS 
archives, not discussed recently.  There may be other stuff of relevance in 
the archives ... various things that can go wrong with BIL500 and how best 
to use SYS993.

Also use DSPOBJD type *DTAARA in BPCS libraries to an *OUTFILE then compare 
contents to try to identify scenarios in a crashed condition.

You see what happens is
1. work station has a crash ... user not tell anyone in IT computer services
2. we how have incomplete batch work files sitting out there on that work 
station
3. someone uses that work station for the same kind of job
4. we have another crash, with the work areas setup with the conditions to 
have yet another crash

IT needs to be able to find work stations in that condition, without the 
end users involved having volunteering that they have this kind of 
situation.  Because even though you will have users who tell IT when 
strange stuff happens, other times IT not find out for a while, so it helps 
to have diagnostics you can run regularly to identify where there are 
problem areas.

We copied a few options off SYS/23 menu to other menus for reorganization 
steps, to regularly clean up negative requirements which can contribute to 
on-hand not adding up right, and other problems, also a menu for general 
fixing.  SYS993C is used to reset a work station's batches after a 
crash.  There's a lot of end users who might be in the middle of some BPCS 
task and their PC goes down.  They reboot, sign back onto BPCS, and restart 
whatever they were doing, and think nothing of it, but that practice can be 
the cause of a lot of garbage into BPCS.  You can ask, but the odds are, 
the people involved may have no memory of these kinds of events.

SYS/23/21 we copied to FXS/50 so less chance of typo with IT person fixing 
stuff and taking wrong SYS menu option.  If there are other repairs needed, 
this should be the last step of the repairs, because sometimes it blanks 
out info you need to navigate the other repairs.

SYS/4 check parameters last correct invoice #

In addition to "recovering" the batch status check point using SYS993, you 
also need to look at where the process is within the individual records of 
the batch ... look at BBL under a microscope, especially "invoice status" 
which may need to be blanked out so when the batch restarts, it not get 
hung on the same places it was hung the prior time.

3. There may need to be an audit effort to make sure that what went on SIH 
SIL is correct.  Much of that info comes from BBL (which is now gone), ECH 
ECL ECS ESH ESL  DSBDBR will tell you if you have any messed up connections 
like Kasp suggested  Also look at RTX file which gets populated before RAR 
file ... one may look right, while the other is messed up.

We found it expedient to add a few more logicals to help when cleaning up 
this kind of problem

4. Check modification history vs. patterns of data.  We modified our 
billing, and everything ran fine for years, and then the pattern of data 
changed, invalidating several assumptions of the modifications.

The kinds of problems we have with 405 CD may not be same as you
* Flakey ma bell connection
* Flakey electrical company, particularly during weather fronts (heavy 
wooded area with seasonal wind directions tree limbs vs. public utilities 
lines)
* PCs with more "stuff" on board than the gas for them all
* non-IBM network which sometimes drops AS/400 connections
* conflicts with other users, who trying to update some order at same time 
as we trying to bill it GO CMDLCK option 8 & know how to navigate this
* shipping dept tells accounting "we are done shipping for the day" and 
they go home, then some rush situation, and the people handling it do not 
have shipping how-to handy, which includes notifying accounting NOT so we 
have a humongous conflict created
* Incomplete customer orders that get shipped
* customer orders used for stuff other than customer orders that get 
shipped by accident
* people checking shipping paperwork say "oops" we picked wrong quantity, 
order line, item, you name it ... and ask that we fix the data stream 
before invoicing
* modifications that cause decimal data errors (I hope all of these fixed)
* bugs in BPCS (many we have now fixed)

We run a process we call "pre-billing" to look for standard common oops 
that can be fixed before doing the invoicing, such as profit center out of 
sync with facility, pricing out of whack, the list of possibilities almost 
infinite

5. Check security on who can change, and change back the controls 
involved.  I have used GO CMDREF to create an *OUTFILE of BPCS connections 
for the purpose of a query to identify what all programs can update a given 
file, to catch the unexpected linkages

If the problem is on-going, you might want to journal or log the file(s) 
getting garbage, to make sure that all programs writing to those files are 
the ones you expect to be doing so. (last resort)

Al Macintyre

Doug wrote:
> It seems odd that such wildly strange data is showing up in your
> production data.
>
> Do you have a dev/test environment that is being actively used ? Is it
> possible that someone copied LFs from prod to test and they is still
> pointing back to the prod PFs ?
>
> I have seen it happen and it would explain why garbage is showing up in
> the prod data.
>
>
> Doug McLauchlan
>
> Kylea White <kylea.white@xxxxxxxxxxxxx>
> Subject
> [BPCS-L] RE: Negative Invoice Number on RAR
>
> Hi Al,
>
> It is actually a little more messy than that.  No-one has touched any of
> the numbering.  As I dug deeper yesterday I noticed that the information
> for the invoices on RAR contained some other strange information also.
> i.e.  The corporate customer linked to the sold-to customer was not the
> one specified on the customer master (no one has changed this either) and
> the records with the negative invoice numbers also appear with a customer
> type which is currently not used.
>
> The invoice was not the result of post ship billing - it is a Type 1
> invoice.  It is like the system has grabbed another invoice from somewhere
> or details when creating the invoice, - but I am only clutching at straws.
>
>
> All I can think to do now is
> 1)               Run a query over SIH & SIL to look for invoice and
> document
> numbers that are less than zero.
> 2)               Go to the Sys menu and run option 14 to re number the
> corp
> customer details and then 7 to recalculate the balances.
>
> Any other thoughts on this one.......
>
> Regards,
>
>
> Kylea White
> Technical Consultant
> KAZ Technology Services
> Switch: +61 8 6212 0100
> Fax:      +61 8 9225 6748
>
> Email     kylea.white@xxxxxxxxxxxxx
> Web      www.focalsystems.com.au
>
> A KAZ Technology Services Company - visit our website at
> http://www.kaz-group.com
>
>
>
> -----Original Message-----
> Sent: Friday, 19 August 2005 1:02 AM
> Subject: BPCS-L Digest, Vol 3, Issue 179
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of BPCS-L digest..."
>
>
> Today's Topics:
>
>    1. Re: WRKQRY (BBilgen@xxxxxxx)
>    2. Re: Negative Invoice Number on RAR (Al Mac)

<snip>

> ----------------------------------------------------------------------
>
> message: 1
> date: Thu, 18 Aug 2005 09:14:38 EDT
> from: BBilgen@xxxxxxx
>
> ------------------------------
>
> message: 2
> date: Thu, 18 Aug 2005 09:30:13 -0500
> from: Al Mac <macwheel99@xxxxxxxxxxx>
> subject: Re: [BPCS-L] Negative Invoice Number on RAR
>
> In our implementation of BPCS 405 CD, you have to be a BPCS Security
> officer to get into most SYS functions, such as SYS800 which can change
> many system parameters, tracking #s, how long some data is stored, etc.
>
> On screen SYS800-04 you can alter the last invoice # used ... you might
> want to increment it a chunk at some end fiscal moment to make it easier
> for some people to see what got posted which month.  There's also
> something
> there about document sequencing, and post shipment invoicing.
>
> Here's the Help on that
> field
>
>
>       Last Invoice Number Used
> (8,0):
>
>       This field displays the last invoice number assigned by the
> system
>       during billing (BIL500).  Be CAREFUL if you have to change
> this
>       parameter.  Since the system adds one (1) to this number
> when
>       assigning the next number, changing it back could cause
> invoice
>       number duplication later, or create unused invoice
> numbers.  This
>       number is only utilized when the company/prefix document
> sequencing
>       flag is
> "blank".
>
> I believe this data is stored some place in the ZPA file which people can
> get at other ways, depending on how your security is setup.  See if you
> can
> access BIL520IN in ZPA ... I think that is the relevant parameter file
> key.
>
> You do NOT want this to be a negative number, unless you truely want your
> Billing Invoices to be negative numbers.  When it gets to all 9's it
> should
> wrap around to 0 then 1 (You may not want an invoice # that is all
> zeros)  Are you at risk of running out of numbers here?  There are ways to
>
> structure your customer orders so as to have consolidation of your
> shipping
> onto less invoices to the same customers, depending on the nature of your
> customers.
>
> We have modified our billing software, but not in this respect ... the
> main
> reasons for our modifications were how data to appear on the invoices, and
>
> to fix a systemic SSA bug with respect to rounding.
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> BPCS/400 Computer Janitor ... see
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
>
> >
> >
> >Hi all,
> >
> >
> >
> >Using BPCS 4.05 and for some really weird reason some invoices have come
> >through on the RAR file  field RINVC with a negative on them.
> >
> >
> >
> >They appear to be using sequencing to get the invoice numbers.
> >
> >
> >
> >Is there anywhere in BPCS that possibly determines there is a duplicate
> >invoice with the number and then reverses it to make it unique.
> >
> >
> >
> >Any ideas would be great.
> >
> >
> >
> >Regards,
> >
> >
> >
> >
> >Kylea White
> >Technical Consultant
> >KAZ Technology Services
> >Switch: +61 8 6212 0100
> >Fax:      +61 8 9225 6748
> >
> >
> >
> >Email     kylea.white@xxxxxxxxxxxxx
> >Web      www.focalsystems.com.au
> >
> >
> >
> >A KAZ Technology Services Company - visit our website at
> >http://www.kaz-group.com
> >t