|
We on BPCS version 4.0.5.CD - PTF-2 + Y2K bundle but have some experience with earlier versions. Is this the only problem you been having? Sometimes BPCS programs are abnormally terminated, the users attempt to recover & botch the job & do not know it, then the resulting errors are not attributed to the abnormal termination recovery. I suspect that you either have a bug at a particular point in the process, which you have not previously noticed because of intermittent nature, or date related volume, or that you have a new pattern of human error. In either case you need to narrow down to at what point or step this is going wrong. Is this something that was working fine last year or last month & then sudden like everything seems to go wrong? ... If so I would primarily suspect a Y2K related bug ... and a way to test this would be to run some back-dating ... process an order all the way through using a date back when it was working fine & if nothing goes wrong, my suspicion would include software that does not work right associated with some date, such as the handling of leap years - something totally bogus that is Y2K related. Is this something that fails on some orders, while others are processed perfectly? In other words it is an intermittent problem? Our BIL500 uses as its input, not the ORD500's ECH ECL ECS data, but COPIES of that data that were made at ORD570 or ORD590 shipping process, so it is conceivable that prior to the Billing, some error messed up the ECH record, without placing BIL500 at risk. However, a series of files are populated leading to other files being populated, so it is easy to misdiagnose the reason why some files not populated correctly. Are you able to follow one order all the way through the process? Stop right before each step & inspect what the order type is, to make sure it is correct, so that you can identify which step is the one in which it gets wrongfully changed? I would suggest creating a query/400 report that dumps the contents of orders due to be shipped today, showing order type. Run this right before each step & write on the print-out what step it was right after / right before ... check off or circle order types as being 100% correct or having some problems at that point in the process. Is someone on vacation of off sick with personnel other than the usual staff handling some of the steps? We have experienced problems with the substitute personnel not having the proper training in how to do the work properly, leading to human errors that get initially misdiagnosed as computer errors. > We are on BPCS version 3.1 release 2. > > Recently, during our Billing Process (BIL500), orders that have been entered > into our system as an Order Type 1 > Which should affect inventory, affect sales, and affect A/R, G/L. But after > the processing is complete > and the Invoice Register prints, it shows the order as an Order Type 3. Not > affecting Sales, and A/R, G/L. > Thus are not getting invoiced or posted to General Ledger. > Is this a BPCS glitch or is something wrong with the order for the system to > do this? > > Paul Zaksheske > American Meter Company > Erie, PA MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated http://www.globalwiretechnologies.com = new name same quality wire engineering company: fax # 812-424-6838
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.