We use kanban receipting and utilize phantoms in our boms. I need to be able to see the phantom part relative to the operation in job tracker. Is this possible?
1 Like
No. The phantom part is replaced by all the children in the phantom BOM on a job.
one potential way would be to turn this subassembly into an inventory item instead. Your kanban receipting can still happen and your job would consume the inventory item. You then set the view as tickbox which will allow you to see the BOM for this part. This is a big depends, ie on your setup and what you need parts defined as etc.
1 Like
Unfortunately this would get confusing on the shop floor as most of these items are built in process and by the same operator so they would need to make multiple kanban receipts.
Then it wouldnât be a phantom⌠or am I misunderstanding what youâre saying?
yes that was what I was suggesting, change the part from being a phantom part to an inventory item.
1 Like
I dont understand where the confusion would be. This part is a phantom now, so they wont see the details of it on the job, only the materials from this subassembly get rolled up into the phantoms parent.
maybe a little more infoâŚwhich part are you kanban receipting?? the current phantom part?
1 Like
No we receipting the finished part which is an inventory item with a phantom below it that is getting material and labor rolled up. It show up as op 10 on job with the finished part being op 20. I need to see the op 10 or the phantom part number to pull into a baq.
ok been a while since I have had anything to do with kanban receipts. The bit I am unsure of is if you do untick the phantom part it will then be a subassembly and if you process a kanban receipt will it also deal with the subassemblies material??
Can you use the partmtl table for your baq?? ie the actual BOM
View as is purposely not check so to see the full bom it would take a cte recursion. Also, this is to pull info on what was receipted the prior day so partmtl wouldnât have the necessary parameters.
If its a phantom part it makes no difference if it has been marked as view as because only the material of the phantom will be viewable, ie rolled up into the phantoms parent part. I think in this case you cant have bothâŚmeaning you have chosen to set the part to be phantom so it doesnât show the subassembly in a job but you want to visually see it.
If all our phantoms have distinct production stds could partmtl be joined with jobopr or jobassmbly (not sure which has prodstd as a field) to pull in the mtl part number? Join on company and prodstd and qty perâŚ
On second thought that would get scrambled up I believe. Grasping for straws here lol.
FWIW, our configurator uses a super BOM with 400 Phantoms and we keep a comma delimited list of the selections for later use similar to your request.
You would need to add a field and store the original phantom numbers related to this âJOBâ for later usage. I built a WorkOrder (JobTrav) specifically using the top level 400# phantom selections for the floor workers.
1 Like
âBY DEFINITIONâ: Phantom part numbers always disappear in the job. This is an APICS standard going back decades. (see this for some interesting discussion: Make flatter shop orders with phantom bills-of-materials | Exact )
Epicor Kinetic supports a different concept called âPull As Assemblyâ that DOES keep the parent part number. if you mark the items as Pull As Assembly instead of phantom, then you will see each part, and its BOM in the job.
I have seen this tactic used when companies wanted to show the assembly as distinct for each thing. They put one operation âIssue materialâ on each BOM so that the materials in each sub assembly is issued.
Here are some slides i created for a user group presentation on phantoms:
Kanban receipting requires both phantom and pull as to be checked to process otherwise an error is thrown.
At my first Vantage implementation, we used phantoms with the configurator like @CSmith. In order to preserve which assembly the part came from, they populated a field (in this case FindNum) with something that let us know which assembly it came from once it exploded. In this case, we were identifying parts of the product, but it could easily have been the phantom part number (up to the length of FindNum. Probably could have used a CHARACTER## field too since UD Fields didnât exist yet.)