|
In this case I think it is a program problem. The reason is that if you compare the FMA and VLA (Material requirement file and JIT Material Backflush Overrides) for the shop order that goes bad, the VLA is always missing parts after a certain point. In other words, if you sort the VLA by part number, parts that start with an item number greater than X are missing. The point where it stops backflushing is never consistent. This is the only consistent characteristic of this problem. The users note that it usually happens when they are very busy. In BPCS 2.7, the user was able to submit something for backflushing and then while the backflush was running, start entering additional time tickets. I changed the code so that they have to wait. Standard BPCS methodology, i.e. set values in the workstation data areas for JIT, was used. Thanks for your response. Mindaugas -----Original Message----- From: Lisa.Abney@sensient-tech.com [mailto:Lisa.Abney@sensient-tech.com] Sent: Wednesday, October 03, 2001 2:57 PM To: bpcs-l@midrange.com Subject: Re: Incomplete JIT backflushes While I've never worked on that version, my experience with 4.0.5 and JIT is that when the users claim "it's not working right", we always manage to trace it back to a data error ... materials that aren't connected to a routing, an incorrect code on the operation, a bad effective date, etc. One thing I always have the users research is whether they always have the same problem with the same production item they're jitting - if so, it just about has to be a problem with how that bill is set up. I've never had an example in JIT where the same item would work one time and not the next - a random error is always hardest to track! "Bielskus, Mindaugas" To: bpcs-l@midrange.com <Mindaugas@onea cc: c.com> Subject: Incomplete JIT backflushes Sent by: bpcs-l-admin@mi drange.com 10/03/2001 02:44 PM Please respond to bpcs-l To all, I have a situation here that occurs sporadically. Items are submitted to be backflushed and only part of the BOM is backflushed. Most of the time, there are no problems in backflushing these same items. The JIT process is used to do the backflush. The shop order is created, the time ticket entered and finally the item submitted for posting. To try to understand when and why this is happening, I have added a short program that checks whether for each FMA record there is a VLA record. The results are stored in an exception file. The BPCS version number is 2.7, the operating system 3.2. The client modifications to the backflush process that were done pertain to the assignment of the workstation ID. In all programs called by the backflush/posting process, the last part of the WSID is used instead of the first. This modification cut-down the frequency of errors. Some of the users use Client Access. We tried to assign a workstation name, but that name is disregarded on V3.2 of CA. Another modification that was done to the entire BPCS system was the Y2K correction. That was done probably 3 years ago. Other than that, the rest of the code is as SSA delivered it. I wonder if in subsequent releases of BPCS, there were any fixes to backflushing. Any ideas on how to deal with this problem, if not directly, then indirectly ? Mindaugas Bielskus _______________________________________________ This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l or email: BPCS-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. _______________________________________________ This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l or email: BPCS-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l.
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.