× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: We lost BBL records
  • From: MacWheel99@xxxxxxx
  • Date: Wed, 12 Apr 2000 04:29:03 EDT

Some damn fool ideas from Al Macintyre

>  From:    bpcsmaynez@yahoo.com (Jesus Maynez)
>  
>  We had a major failure with our AS400, 

Comiserations to you ... this sort of thing happens so rarely that most folks 
are not adequately prepared with a disaster recovery plan ... so your 
experience inspires us all to rethink our own lack of preparedness

>  we had to recover all the data from a backup, 
>  however we lost the BBL file. 

The BBL file is created by shipping then purged when you did billing, so at 
time of a backup, if you do it after billing for the day, there would be no 
records in the BBL file ... where did the AS/400 failure occur in the 
shipping billing cycle?

How do you know you lost the BBL file ... you do know it should be empty 
after billing, so if you always do backup after billing, there would be no 
data there to recover ... or are you saying you do not have the physical 
file, empty or not, which means you also do not have any logicals over it.

Is the problem that your backup media was not as complete as you thought it 
should be, in which case how do you know you have all the other files than 
BBL that you should have?

The files should be in sync as of when you did the backup ... did you restore 
all your files from your last backup, or did you have a bunch of files Ok 
after the crash, and instead of restoring everything to the last backup, you 
tried to play jigsaw puzzle with current files that were OK, and last backup 
version for files lost in the crash?

I have done that, successfully, when there was a crash during end-of-month 
... let's see now which update jobs did we do - which files did they update - 
lets restore only those files that were affected since the last backup before 
the EOM - it takes me longer to figure that out than the time saved from not 
restoring everything

And so far the only jigsaw puzzle piece problem you have stumbled over is the 
BBL file?

Or was the backup problem that you have files in different libraries, and the 
restore had trouble rebuilding links because of need to connect to files not 
yet restored, such that a pair of restores might make sense, 2nd one to 
restore anything missed by the first restore.

We are on BPCS 405 CD ... there is an option to REPRINT INVOICES from the 
shipping history files, or to change the shipping info (corrections) then 
reprint the BBL info ... we have never used that option so we don't know the 
implications.

Even if some approach affects twice the inventory, that cannot be a serious 
problem - simply cycle count all the shipping warehouses when you are done, 
or use the B transactions in ITH or the SIL SIH records to generate a program 
to create dummy transactions to reverse that inventory - how many 
transactions are involved.

You can do a physical inventory for just one warehouse, or one set of 
warehouses, but timing of update needs to be in close proximity to 
end-of-month INV900 ... my suggestion is that no matter what, you plan on a 
physical inventory in the shipping warehouses real soon after you think yout 
got this all straightened out, or else some very serious heavy duty cycle 
counting there.

Our billing & shipping process updates customer order requirements & I think 
that happens at shipping time, and it updates inventory & I think that 
happens at billing time, & it updates receivables & I am certain that happens 
at billing time, & it updates sales history files, & much of this ends up in 
the general ledger ,,, there is a lot more affected than inventory, depending 
on which applications you are using.

If the inventory is correct;
If the customer orders are correct;
If the accounts receivable is correct;
If the general ledger is correct;
why do you need to re-do the billing ... are you missing invoices that were 
on spool when the system went down?  Can you old fashioned typewriter them 
from the info on the shipping documents, or were they also lost in the gone 
spool?  Can you contact the supply chain folks (UPS & truckers) for as much 
extra detail on shipments as you can, so as to reconstruct shipping 
documents?  Can you get help from your customers ... offer them some kind of 
discount if they fax you copy of packing documents lost when your computer 
went down.

How do you know everything is correct other than the BBL file?

Do your auditors know squat about BPCS?  Do they expect some kind of audit 
trail or documentation for what went on here in the crash & recovery?

Are you on sufficiently good terms with your customers that you could tell 
them what happened & send them a copy of the orders you have in your system 
on their behalf so that they can verify that your orders are correct?

>  Well this file is two days old, and the
>  BBH and all the environment is up to date. 
>  I have been struggling what is the best way to correct
>  this. This is what I have found out so far.
>  
>  Get all the shipments made on those two dates.

Check out what is in SIH SIL invoice history files
Check out ESH ESL shipping history files

ECH ECL ECS could be a pain to reconstruct if your sales department has keyed 
in any updates since the repair effort started - our sales department has 
several full time data entry people, instead of using any automated data 
entry tools to get customer requirements to our input

...   did you in fact lose all spool file data, including ORD500 audit 
trails?  Otherwise you might be able to reconstruct what was done since the 
backup ... this is a possible argument in favor of one of the archive tools 
that backs up spool file

 ... did you know that Crowe Chizek has a customer order change history 
package that tracks changes to customer orders, including shipping history 
... something that might be nice to get before this happens the next time, or 
just on its general merits

>  Check from our reports what orders from those
>  shipments were already billed.
>  Generate an order type 7 class 8 for all the orders
>  that havent been billed.
>  
>  However, someone in my company says this order will
>  affect twice the inventory, that we should find out
>  another way to bill those orders?
>  
>  What do you think? I would appreciate any help!!

If you have the disk space to copy files to another environment & do the 
billing there then copy SOME files back but not all of them.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.