|
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 program1. 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 services2. 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 job4. 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>
midrange.com
----------------------------------------------------------------------
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
