|
>From Al Macintyre e-back again after major home PC upgrade & struggling to learn Win 9x stuff that is old hat to everyone else. We have a bunch of Query/400 reports that were written by different people with different degrees of understanding for our BPCS 405 CD mixed mode V4R3 then the reports get run by other people who sometimes question their veracity & there are also some standard vanilla BPCS reports that are off of actual cost, when many employees are more interested in standard cost. The CFO wanted me to convert someone's Query report based on a file containing total ACTUAL costs for a month's activity to get STANDARD cost, so first I linked to CMF cost master & totaled up based on cost set cost bucket of relevance but it became obvious that I could not make it look nice in a single threaded query, so I went after IIM.ISCST instead. He randomly compared my figures for costs of items on the report, which showed some zero while INV300 had what the CFO thought was a good figure. Ok, how come ISCST is zero for some items & where does INV300 get cost? I found CST590 & decided that this was a bit too convoluted to put into a query - I know also that if I find a solution, a bunch of co-workers will try to copy it into other queries & real complexity invites human error. The CFO now has what he wanted via an SQLRPG program that I wrote. There is also a ZERO record in CMF ... is this the total of all the other buckets & is it consistently maintained at time of individual bucket update, or is it only refreshed at time of CST600? We are a make-to-order job shop in which periodically there are customer model lines identified that we'll never make anymore. We bring on-hand unique components to zero, purge any orders, remove BOM & routings, take cost out, then item can go away, except sometimes there are snags. Sporadically when trying to make item go away with INV100, there's an error message about a cost in the way, which they were sure they removed, and sure enough when they go in with CST100 there is nothing there. Now it occurs to me that there might be a security problem - if the person doing CST100 is not allowed to see everything by BPCS security, they will not see what needs to be removed so that the item can go away. Where we are at is a need for a report to list what needs to be cleaned up on items we want to go away. I suggested a Query of CMF for all hits on that item ... if none then the problem may be INV100 wherever there are flas & values from the last CST600, which we run twice a week. Where does INV100 get the story that a cost exists? Are we missing a step? CST100 has a non-functional Cmd 11 so cost removal is quite tedious. Is there a BMR on Cmd 11? > Subj: Year End Advice & tracking WIP > Date: 99-11-04 16:16:58 EST > From: ScotConslt@aol.com > > Hello all, > > I am working with a client who just went live on BPCS V6.0.04 in June. > Everything is running smoothly but one task that has them baffled is year > end processing. > I am trying to gather information to hand off to them. Any > information that anyone has as far as a job schedule, what needs to run, > what should be run etc would be very helpful. Our consultants gave us a document listing all the end-month jobs & what sequence they ought to be run in ... ie. close some applications before others. There have been earlier threads in BPCS_L where people suggested what are appropriate year-end job sequence, month-end sequence, weekly reorgs & so forth, > Also, they are having problems reconciling WIP at the end of the month. We are having troubles knowing cost of WIP in middle of month - any old time. When we do our physical, we use handwritten tags for WIP in which someone figures out what materials have gone into this WIP through prior shop order reporting ... we close out all our shop orders prior to the EOM in which the physical gets dumped in right after INV900, then subsequent MRP refigures shop orders needed based on revised inventory. We manually create shop orders for the WIP, and we do "Z" transactions to back out the inventory that went into the WIP before the physical, knowing that completion of those orders will re-report the consumption. Those handwritten WIP TAGs are never keyed into BPCS. Assuming you trust & understand BPCS data & consider any sub-set of history to be reasonably complete, check out the stuff in FLT labor history file. We use it to get reports on percentages actual vs. standard rates reported, then people want the percentage scrap reports to have the cost of scrap added, and then the fun begins. > Before going live, they did not do a physical inventory so they understand > that "some" (probably all) of their inventory balances are screwed. How did their inventory balances get into BPCS? Some kind of conversion? Was the conversion done as of EOM? > The last time they did a physical was about 5 years ago! This implies that their ACTUAL inventory - irrespective of what ended up in BPCS must have been very accurate ... we have inventory in the high 90 percentiles but our auditors insist on annual physicals any place it is below 100% in either a prior year audit or in their spot checks in which they raid us & we do not know in advance which 25 items they will check & the last few years when they did that the resulting warehouses got to skip physical for a year. When we converted to BPCS/400 we did a physical a month later in one facility then a month later in another & so forth. You do not have to do a physical at the same time as cut-over. > Any quick ways to track WIP > at the end of the month and tie back to shop orders? There are various door stop reports but they only show cost of currently open shop orders, some of ours date back to 3 months of activity, depending on time duration of the work & how backlogged the production paperwork department manages to get, and we also have shop orders that appear & disappear within a week or so, which do not show up in the vanilla reports itemizing the status of open shop orders. > > TIA > > Jeff > </XMP> Al Macintyre +--- | 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.