|
from Al Macintyre We use BPCS 405 CD mixed mode AS/436 V4R3 with intermittent problems with apparently losing customer orders ... is your pattern odd ball, in that most customer orders are keyed in & show up where they belong, while some go missing & you do not have a clue? Do you have evidence that they did exist after the order entry person went to end of job? We suspect that some people who do order entry occasionally take a wrong command key & do not realize that they have done so ... ie. they go through the motions of entering an order, then there is some command key to delete their entire effort that does not pop up with "are you sure" and they do not realize they have done that with some of their daily effort. I suspect that ORD500 feeds data to some work file, so that command "wipe out my effort" means that no evidence gets to the master files, not even soft deleted. All our paperwork associated with entering the customer order is initialled & stamped & etc. including the order # reference written there, but the person who just killed the order is oblivious to the fact that they did so. We have people who are keying in customer orders & changes to customer orders all day long & what passes for BPCS audit trails are unreadable unusable to them. Are there any fields in ECH ECL with something like "last activity by whom at some work station session" so we could generate a report ... here's all the orders you entered / changed today ... so you can check off if anything is missing. ie. original paperwork wait until this report is generated before filing it away, possibly even with an attached order report that is meaningful to that personnel ORD990 is the clean up of ECL ECH mismatches, but it does not get everything that is relevant. We run a query report before ORD990 which lists ECL active records that do not have a corresponding ECH active ... there's stuff there that ORD990 does not touch. In other words ORD990 is not catching active ECL records that are connected to a soft deleted ECH or vica versa. ORD990 generates ORD991 audit trail which we print & feel tempted to modify to add more information about the lines that got deleted. Our printed copy goes to the sales dept - sometimes they recognize numbers ... oh yes we know the story here, that order should go away ... what"s this ... a new problem for them to check out. Depending on how you try to access mismatches between ECH & ECL, sometimes if one does not exist, you do not get to see the others. This is because of how BPCS programs access records & sometimes choice of logical excludes certain kinds of records such as soft deleted, or query says "match" excluding no-match. There is a scenario in which the ECH key gets magically changed to some other order #, without a satisfactory audit trail of this unauthorized & unwanted event ... all the ECL records are still there, but it appears like the order has disappeared. If you can locate this & change it back (we use DFU to do this) then you are back in business no problem on that order, but suppose you do not catch it ... clean up is going to erase the orphans, unless the ECH was changed to the same order # as some other order # in the system, which has happened to us several times, and then we have another problem with some programs accessing the wrong header to process the other order. We have not yet mastered what triggers this scenario, or what kind of reporting tools are appropriate to locating such events ... I suspect that the contents of the raw physical ECH between reorgs should be in the sequence in which orders were added, so that a sequential listing of the file, before next reorg, to find any out of sequence, might be an approach to try, to find suspects that might need fixing before any reorg. Check BPCS security ... who all is authorized to be changing or deleting customer orders ... do they have appropriate training, such as who to tell when they have an oops? Check who has command line authority ... we have had some accidents with inappropriate use of DFU & possibly other areas. For jobs that should be run when no one is on the system, such as ORD990, how do you enforce that? We have had some oops with people signing on in the middle of jobs that should have been restricted. We have a rule that billing & shipping should not be at same time & that customer order maintenance is supposed to stay out of orders that are currently in shipping or billing ... rules get broken. How about at your company? Someone mentioned BIL620 ... There are a bunch of BMRs on that program which I am struggling to merge with our modifications (mainly appearance of invoice, but there are some fields we mucked with) ... check OSG for the latest. Our System Parameters say to save completed customer orders for a while, but not forever ... what end-of-month step is supposed to get rid of the soft-deleted ECH & ECL records of which we have thousands dated so old we think we are missing a step some place. Al Macintyre > From: KUSMAN@TAKEDA-ID.com (KUSMAN) > > Dear BPCS Professional > > We use V6002 C/S plf cum March 98 in AS/400 v3r7. > > We have entered 3 customer order after we accept the order was missing. I > check in ECH & ECL file, there was not recorded. > > Please help us. > > Thanks > > Kusman Lim > MIS Department +--- | 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 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.