Hi Tony,
The dispatch report looks at each operation -- no problems there. In our world Stock = bad, WIP = good. WIP is scheduled to ship, stock may never ship. About 75% of our jobs are make-to-order. The goal is to plan the job to be completed just-in-time to ship to the customer. In a perfect world it all works out. ;)
It sounds like you're on the right track with make-to-order, this is exactly what it's designed for.
Jill
The dispatch report looks at each operation -- no problems there. In our world Stock = bad, WIP = good. WIP is scheduled to ship, stock may never ship. About 75% of our jobs are make-to-order. The goal is to plan the job to be completed just-in-time to ship to the customer. In a perfect world it all works out. ;)
It sounds like you're on the right track with make-to-order, this is exactly what it's designed for.
Jill
--- In vantage@yahoogroups.com, Tony Hughes <thughes281@...> wrote:
>
> Thanks, that clears something up for me. "parts remain in WIP the entire time"
> So, even if last operation is complete, I notice the job still shows no completed quantity, and I guess, never will until you literally ship.
>
> Do the Priority dispatches take this in to account? we use the default one. (probably only one of the 3-4 default reports that no one has asked to change yet!)
>
> I may not want to use Make to Order, in this case.
> What if customer won't take partials, and they have a couple other pieces for their order that we did a MtO job on.
> That job sits in WIP for a long time.
> If considered from Finance's point of view - WIP = Bad, Finished Goods = Good.
>
> But, also, from a technical standpoint, I don't like that Vantage sees the job in WIP, when the job really isn't in WIP.
>
> Maybe I am approaching the solution in the wrong way.
>
> What we are trying to do is review our part catalog, and in process, we are removing a lot of minimums on slow moving parts.
> We want to make them non-stock items. We'll must make them when someone orders them.
>
> If I am making a part only because someone ordered it, I want that job connected to that order. If order is canceled, we then cancel the job, and along with our policies on non-stock cancellations, the customer is charged a fee. But to enforce this, need to maintain that connection between order and job.
>
>
> Anyone have any advice on how I might better approach our problem?
>
> Thank you for all the help.
>
>
>
>
>
>
>
> ________________________________
> From: Aaron Hoyt <aaron.hoyt@...>
> To: vantage@yahoogroups.com
> Sent: Friday, March 13, 2009 2:25:13 PM
> Subject: Re: [Vantage] Make to Order
>
>
> Tony,
> Do you have AMM?
> We do and when the part being built is finished, it creates a wip move
> transaction request (Material Request Queue). This transaction is a
> MFG-CUS and in our system requests that the parts be moved from the
> Resource Group out bin to the Finished Goods bin. I believe it pulls
> the Finished Goods bin from the Order Release. This transaction, when
> processed changes the part location without removing them from the job
> or placing them into "inventory". When they ship from this new
> location, parts remain in the job WIP the entire time and you ship from MFG.
> We find this very helpful except when people make mistakes as they
> do...then it gets difficult to tell how many parts are where. We
> instituted an automatic labeling based on this final move processing and
> that helped a bunch, but as with everything with a human at the
> keyboard, it's still not perfect.
> Vantage is well designed to handle Make to Order, but you won't find
> much documentation on this method. We are having a tough time with the
> "Epicor Manufacturing and Distribution Users Guide" as it is so heavily
> slanted to make to stock. I also find it surprising that Epicor
> suggested you "receive to stock" a make to order part. It's not necessary.
> Let me know if I can be of more assistance.
> Best of luck,
> Aaron Hoyt
> Vantage Plastics
>
> Tony Hughes wrote:
> >
> >
> > We have never used make to order, always just make to stock, receive
> > in to stock, then ship out of stock.
> > With make to stock, last operation requests a material move, forklift
> > comes, drives it to warehouse, puts on the shelf and does job receipt.
> > Easy.
> >
> > But with make to order, how is this supposed to work?
> >
> > We don't literally pull the truck up to the last job operation and
> > ship the product from right there.
> > The quantity will be moved to a shipping area, we might not even ship
> > the whole order until a couple days, that's common.
> >
> > Meantime, what do you do with the make to order parts, in terms of in
> > the system? They still show as WIP until you ship them, but you might
> > not be shipping for days?
> > And anyone looking for the parts in the system will be looking for
> > them at the final operation, they won't know which Shipping dock
> > they're at, or which of the many bins at the dock.
> >
> > Epicor suggesting doing job receipt to inventory, and yes, you sure
> > can, but AMAZINGLY this doesn't do anything to WIP nor does it even
> > register as part of the make to order quantity.
> > It just adds parts to inventory off of that job... I cannot believe
> > that is not a "bug". I can see that you'd allow completed quantity
> > greater than job quantity - when you're stamping thousands of parts,
> > you're bound to make a couple extra, but receive more in to inventory
> > than the job shows as a completed quantity??? why the @#$*(& would you
> > ever do that?
> >
> > The help desk of Epicor is suggesting you go in to the job, change the
> > quantity to make to stock, then receive in to stock, then ship from
> > stock at the time you're ready.
> > This seems nuts, as I'd have to go change the Order to remove the
> > demand, then change the job's Make to Order, get rid of it, and do
> > make to stock.
> >
> > Sorry for the ranting, any advice on how this works? if I'm going
> > about it all the wrong way?
> >
> > Thank you
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>