Is there a good reason that I am not aware of why it would be preferable to create a job using a part on the fly? Many of our jobs are created to build a part on the fly. This creates an issue when receiving a completed assembly on a job to inventory where upon scanning the job# on the traveler Epicor just hourglasses and eventually crashes.
I get the general benefits from the part on the fly concept, but I am not sure whether the top level part on a job should be one.
Thanks!
Paul
When you have a make to order job they are useful when itâs a one time thing and you donât want to save the history.
Anything going into inventory needs a part in part master.
Are you receiving sub-assemblies on the job into inventory? What does that do to your costing?
In my post I meant to say âŚreceiving job to inventory. Our jobs are often (sub)assembliesâŚ
At any rate I found an answer as to why the entry persons are using Part on the Fly: because their instructions say so. I am changing the instructions so the Jobs are for actual parts. I am wondering now what DMTâing the top level part to a real part will do to the hundreds of jobs that are already out there; any words of wisdom? Or would it be better to put the change in for new jobs and let the older ones work their way through the system?
Paul
You shouldnât be able to receive on the fly parts to inventory, or make a demand link to inventory. Something is fishy here. Are you sure your arenât receiving from job to job? Or something else?
What does your demand link look like on these jobs?
To add on to @Banderson comments, the Part must also be âQty Bearingâ of its job to be make to Stock.
One bug to lookout forâŚ
If a Qty Bearing part is a component of a BOM or Job, and then that component is changed to non-Qty Bearing, a Mass Issue will create part transactions and drive the QOH negative. (The QOH of that part had to be zero, from when it was changed to non-Qty Bearing)
Thatâs not true. It wonât actually plus up the inventory, but you need the job to account for the materials and labor used to make it.
I learn something new every day.
So in a scenario where the parent part is non-Qty Bearing, you can receive it into inventory?
And does it create a PartBin record?
And is all this the intended functionality or a bug? If intended, then maybe the âbugâ I mentioned above is really a âfeatureâ
yes,
no
Itâs intended, it has to do with costing/accounting. You can make non-quantity bearing parts, and you can issue them. There is never an inventory quantity, but the dollars can go in and out of the GL. Sometimes itâs not worth keeping a count of certain item.
This changes EVERYTHING!!! I must do some testing.
Before I do, there isnât some Company wide setting that controls this in any way, is there?
I donât knowâŚ
ÂŻ\_(ă)_/ÂŻ
All,
I am enjoying the discussion⌠and learning a fair bit as well. I would love to have had the luxury of an implementation consultant that would have explained all these types of details along the way⌠Unfortunately I have inherited a botched implementation and will be cleaning up the mess for a long time. Just trying to figure out what the thinking was when nothing is documented is a tall order.
I have decided to play it safe and let the jobs in the system be the way they were created. It is just a matter of time before they are flushed through. As of today we will be using regular parts as the source for jobsâŚ
P.
Can you look at the job entry screen for me and look at the demand link? I am curious what it shows.
Meh⌠Unless you get a really good one, most of this stuff you learn along the way anyways. Thatâs what I did. (edit: am doing)
I favorite saying of mine âŚ
âWisdom comes from experience, and experience from mistakes. So if you want to gain wisdom, be prepared to make lots of mistakesâ
