Recursive crc error

Sorry for the delay.
How I would do it depends on whether that 1 pc of product (being made) is usable (ultimately received from your job as a good finished pc to stock) or lost (scrap) after using it to test the processing solution (or if it variable and you can lose more than 1 pc until you deem the solution ok to process the rest of the job).

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

Sent from Yahoo Mail on Android



From: Adam Riffer <ariffer@...>;
To: <vantage@yahoogroups.com>;
Subject: RE: [Vantage] recursive crc error
Sent: Thu, Dec 12, 2013 3:03:24 PM

Â
<div id="ygrps-yiv-190601972ygrp-text">
  
  
  <p>

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

Â

If I follow correctly, why not just set the method for 1 pc fixed qty scrap of whatever the ttue raw material(s) are.

Job yield cost will represent reality as I assume the pc is a loss (destructive testing) or I fail to understand the need for the circular ref BOM.

- OR: Insert an OP representing the inspection labor 1 pc nonconforming where you can then use inspect processing to systemically document results AND have costs flow differently but still accurately. Balance reported on the op as good (if/when tested/inspected as OK).

If I misunderstand you don’t necessarily lose the test pc in the process, inspect pass returns it to the job.

Not an MRP engine I've ever encountered that would put up with circular BOMs

Rob Brown
Versa Products

Sent from Yahoo Mail on Android



From: ariffer@... <ariffer@...>;
To: <vantage@yahoogroups.com>;
Subject: [Vantage] recursive crc error
Sent: Wed, Dec 11, 2013 9:57:32 PM

Â

We have gotten a recursive crc check error because a material on the bom calls out the parent. Â This was done on purpose. Â We make a batch of the component and use one of the assembly for testing the component so the cyclical reference is correct. Â Is there any know work arounds for this problem? Â 8.03.403c.


thank you,

adam




This email is free from viruses and malware because avast! Antivirus protection is active.


</div>
 


<div class="ygrps-yiv-190601972yqt5044194946" id="ygrps-yiv-190601972yqt45162"><div style="color:#fff;height:0;"></div></div>
We have gotten a recursive crc check error because a material on the bom calls out the parent.  This was done on purpose.  We make a batch of the component and use one of the assembly for testing the component so the cyclical reference is correct.  Is there any know work arounds for this problem?  8.03.403c.

thank you,

adam

If I follow correctly, why not just set the method for 1 pc fixed qty scrap of whatever the ttue raw material(s) are.

Job yield & cost will represent reality as I assume the pc is a loss (destructive testing) or I fail to understand the need for the circular ref BOM.

- OR: Insert an OP representing the inspection & labor 1 pc nonconforming where you can then use inspect processing to systemically document results AND have costs flow differently but still accurately. Balance reported on the op as good (if/when tested/inspected as OK).

If I misunderstand & you don’t necessarily lose the test pc in the process, inspect pass returns it to the job.

Not an MRP engine I've ever encountered that would put up with circular BOMs

Rob Brown
Versa Products

Sent from Yahoo Mail on Android



From: ariffer@... <ariffer@...>;
To: <vantage@yahoogroups.com>;
Subject: [Vantage] recursive crc error
Sent: Wed, Dec 11, 2013 9:57:32 PM

Â
<div id="ygrps-yiv-1344708335ygrp-text">
  
  
  <p>We have gotten a recursive crc check error because a material on the bom calls out the parent. Â This was done on purpose. Â We make a batch of the component and use one of the assembly for testing the component so the cyclical reference is correct. Â Is there any know work arounds for this problem? Â 8.03.403c.</p><p></p><div><br clear="none"></div><div>thank you,</div><div><br clear="none"></div><div>adam</div>

</div>
 


<div style="color:#fff;height:0;"></div></div>
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

 

If I follow correctly, why not just set the method for 1 pc fixed qty scrap of whatever the ttue raw material(s) are.

Job yield cost will represent reality as I assume the pc is a loss (destructive testing) or I fail to understand the need for the circular ref BOM.

- OR: Insert an OP representing the inspection labor 1 pc nonconforming where you can then use inspect processing to systemically document results AND have costs flow differently but still accurately. Balance reported on the op as good (if/when tested/inspected as OK).

If I misunderstand you don’t necessarily lose the test pc in the process, inspect pass returns it to the job.

Not an MRP engine I've ever encountered that would put up with circular BOMs

Rob Brown
Versa Products

Sent from Yahoo Mail on Android



From: ariffer@... <ariffer@...>;
To: <vantage@yahoogroups.com>;
Subject: [Vantage] recursive crc error
Sent: Wed, Dec 11, 2013 9:57:32 PM

 

We have gotten a recursive crc check error because a material on the bom calls out the parent.  This was done on purpose.  We make a batch of the component and use one of the assembly for testing the component so the cyclical reference is correct.  Is there any know work arounds for this problem?  8.03.403c.


thank you,

adam




This email is free from viruses and malware because avast! Antivirus protection is active.