|
Once again I discover that I thought I knew something but seek clarification. User-A describes two scenarios that occur entirely two frequently for which I thought the solution was simple. Scenario-1 We have a shop order with one operation for say 6,000 One day they do 600 and in error the labor reporting is marked "complete" (The person was complete for what they doing that day, unaware of lots more to be done ... a lapse in training the people who fill out these labor tickets.) this closes the order we do regular CST900 shop order purges & now it is gone there is still paperwork on the shop floor to get the other 5,400 done & of course trouble when try to enter that labor reporting Scenario # 2 We have shop order with several operations One day they finish first 1,200 of 6,000 and in error the labor reporting is marked "complete" this makes first operation appear complete on SFC300 shop supervisors pick some other orders on same item to work on this one remains alive with one foot in grave in perpetuity due to no work on subsequent operations Bit Al Big Mouth Suggested Solution I believe that when completed quantity greater than or equal to ordered quantity, BPCS does an implied "Y" that operation is finished. This comes from quantity needed at time of labor reporting. If you lowere quantity needed, to actual done, you must run a zero labor transaction through SFC600 to recognize finished lowered quantity. Therefore I propose a policy change. Let's quit entering "Y" complete. User-B = "Al got it wrong again." User-B has scenarios where operations are at least ordered quantity & the orders hang out forever, until missing "Y" complete is entered. User-B swears that these orders have not altered quantity needed. Thus the "Y" is an essential part of labor reporting. Well either my theory is flawed, or we have multiple cooks in which the quantity reported was less than the quantity ordered, then the order quantity lowered to match actually made, without doing zero transaction to acknowlege done matches new quantity. After all there is no history showing changes in order requirements. Please help me improve my score getting it right more often than I get it wrong. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax interactive & batch) @ http://www.cen-elec.com Central Industries of Indiana--->Quality manufacturer of wire harnesses and electrical sub-assemblies - fax # 812-424-6838 +--- | 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.