Sorry for the delay. Depends as well on whether you are licensed for inspection processing (basic quality module) or perhaps enhanced quality (which may only be 9.05: you didn't indicate what version you are running) or perhaps IQS' package (marketed as advanced quality). Lastly, what kind of systemic documentation of the process is required and auditable transaction trail (internally or to provide to your customers as proof of process compliance or a cert of some kind?) What you describe sounds like effectively a first article inspection triggered by the setup. The basic quality module would support that. Whether you lose none, one or perhaps several pc's testing the solution lends itself to a labor reporting process (particularly if outcome is variable). No need to use circ ref boms for this as labor reporting would cost the job properly (reporting a unit of scrap qty via labor entry would shuttle 1 finished unit's job estimated (at time of job creation) entire labor, burden, subc and material cost off to whatever GL acct is set for wip scrap) & if you configure to utilize job qty yield processing (a scheduled recurring process like backflushing), all the better as the job will adjust prodqty down as losses occur (further improving job cost accuracy as you won't have cost left in wip - and planning/scheduling will be based on more accurate job (and remaining op) prodqty. Using 1st article would give you a separate process quality record in whatever qty you deem is valid for the process before production commences (or records if resubmittals deemed required by the inspector if initial submitted pc (s) not to spec). 1st article failures don't consume wip. They are just quality records that for MES reported time snd quantity labor entry method ops: start & end activity labor reports measuring elapsed time - BLOCK Start reporting of production until 1st articles in qty specified in methods op & resulting joboper data are reported in 1st article inspection as approved. Actual wip (scrap) losses would still be done via labor entry of them. It all depends on how stringently you need job related data records to be (although to use for spc to keep process in control and gleen patterns over time where waste can be reduced (& ALL setup time/cost is waste in the customers eyes and from a standpoint of inproving process efficiency and cost reduction). Certainly other ways (not circ bom refs: the fact that the sytem (any system) chokes on this tells you to find another way to achieve your intent), or excessively detailed routings (that would be a costly bear to maintain) to detail the process set up/test procedure such as (source/relationship) linked paper docs attached to paper travelers (as engineering or manufacturing dwgs might be in a machine shop) - or full blown knowledge base revision/change logged attachment references to full blown multimedia process aids (in high velocity config to order order fulfillment biz processes are just two examples on the same axis of need (or anticipated need if you are growing and old solutions don't/won't scale. If there IS some truly critical need to do this through materials (boms and parttran records) your 'placeholder' component in your bom idea could work (although I think it is needlessly complex and potentially botches cost a bit) - just use Misc Issue to transact the actual part into your placeholder requirement (& deal with it on the job completion/close side as the exception it will be). Hope that helps (& even makes sense tapping all that in to an email on this little phone keyboard). Let me know what you end up doing. Thx Rob Brown |
From: Adam Riffer <ariffer@...>;
To: <vantage@yahoogroups.com>;
Subject: RE: [Vantage] recursive crc error
Sent: Thu, Dec 12, 2013 3:03:24 PM
Â
Rob-
Â
 The problem is it is at 2 different levels. We
use 1 of the product to test the chemical that goes into the product. In
reality it works, but in Bom it is potentially infinite at low volumes. if
I put a place holder # in bom then just issue the cyclical ref in place of place
holder will it work? I am not so worried about forecasting the upper level
from this usage because it is likely going to use orphan inventory anyhow, but
would allow costs to be tracked.
Â
Any thoughts?
Â
Adam Riffer Purchasing IQuum, Inc. 508-970-0099x506 ******************************************************************** This message, including any attachments, is intended only for the designated recipient(s). It contains CONFIDENTIAL and/or PROPRIETARY information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient, you may not review, use, copy or distribute this message. If you received this in error, please notify the sender by reply e-mail and delete this message. Thank you. Â
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Robert Brown Sent: Wednesday, December 11, 2013 9:35 PM To: vantage@yahoogroups.com Subject: Re: [Vantage] recursive crc error
From: ariffer@... <ariffer@...>; To: <vantage@yahoogroups.com>; Subject: [Vantage] recursive crc error Sent: Wed, Dec 11, 2013 9:57:32 PM
|