Glad it may be of some help Ken. (Just trying to put it into words helped me to crystalize my own understanding of the new developing process.)
In/Out: Deltas (Yes). Had a (hopefully brief) 'senior moment' yesterday ;)
If you pursue, fire away with questions/alternate ideas... (Sad to say?)- "Manufacturing is my life" (:o
Rob
In/Out: Deltas (Yes). Had a (hopefully brief) 'senior moment' yesterday ;)
If you pursue, fire away with questions/alternate ideas... (Sad to say?)- "Manufacturing is my life" (:o
Rob
--- On Thu, 2/12/09, Ken Williams <ken@...> wrote:
From: Ken Williams <ken@...>
Subject: RE: [Vantage] Blanket Purchase Orders
To: vantage@yahoogroups.com
Date: Thursday, February 12, 2009, 9:24 AM
As always, you've provided a wealth of information.
It does make sense. The in/out I believe you're referring to is the
reschedule in/out delta's. This could prove useful for a few different
purchasing headaches we have with noise.
I've done a lot of programming & customization, but have yet to create a
UD table. I'll likely begin playing with this to see what we can do, I
appreciate your detail immensely and may be following up in a few weeks
with more questions.
Thanks,
Ken
From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
Of Robert Brown
Sent: Wednesday, February 11, 2009 3:38 PM
To: vantage@yahoogroups .com
Subject: Re: [Vantage] Blanket Purchase Orders
I feel for you Ken.
Professed "Contract" PO functionality was an important driver in our
decision to go with Vantage (and of course, like most of those important
drivers - the reality failed to meet the promise).
(Yes: Contract PO process does not work even when only using one
supplier per part - let alone multiple suppliers.)
We've come upon another way to handle a similar situation to yours.
PO Header form is customized to remove all the Contract PO gobbledygook
& a simple checkbox control labeled "Blanket PO" is added and tied to an
available POHeader.checkbox# # field.
PO line form is modified similarly except each line have date controls
labeled Blanket Effective Start & Blanket Max Purch By dates tied to
PODtl.Date## fields.
In Supplier Price List maintenance, we added a ud numeric field control
that indicates the lead time required to negotiate a blanket contract
renewal. (In our Biz, we deal with brass forging houses that require up
to six month advanced contract renewal in order to get into their
schedules.)
This enables us to run a report that indicates which open Blanket POs
are within the lead time needed for renewal. (Once we start
renewal/negotiation s, as soon as firm enough, we enter an unapproved
blanket PO that then also shows on the report as an in process
negotiation. .. Keeps people from chasing their tails.)
This also means the Part LT can then be set to a REAL (mrp) lead time
that reflects the terms of your negotiated blanket (deliveries are made
daily, weekly, bi-monthly, etc., so that is the 'real' lead time of the
part once a blanket PO agreement is made).
We then set up our Min order qty's to reflect (in typical package size
multiples) what we expect about 75% of our typical historical usage
within the delivery terms (daily, weekly, monthly, etc.,) we'd expect
that tiem frames typical requirements are.
Multi order qty is the package size.
Min O/H is set based upon JUST how far out each vendor requires hard and
semi-hard schedules in order to fulfill our needs. If they need 3 weeks
of schedule, our Min is based upon 3 weeks of average demand. (Routinely
must adjust this but it is easier to be proactive with the tools we've
provided and DO so instead of being clobbered with B.S. MRP messages
daily.)
Now the trick that makes it all work: We initially place a single
release per line that represents the entire blanket agreement qty over
the negotiated time frame.
The date represents when we currently THINK (at current demand rates)
we'll consume the blanket. This almost assuredly differs from the PODtl
ud field that represents the negotiated "Blanket Max Purch By" date on
the line detail form. (It will also be sooner than that date as that
date must be carefully risk calculated in advance at the time of
contract agreement so both we and the vendor know contractually when we
MUST take remaining open line balances by... In recession times like
these with all the unknowns of future demand that result, it is as
heavily padded as we can get away with so we don't get stuck with
inventory no longer needed when initially expected because of a demand
slow down.)
That single blanket PO line balance release is not qty or date locked.
Run MRP (or PO suggestions - full regen for either) and the preset Min
O/H's an Min/Multi order qty's result in suggestions to pull in partials
from that initial single release - ONLY AS FAR OUT AS NEEDED (so you
aren;t constantly doing change notices with predefined lines that might
have 52 releases spread over a year).
We haven't formalized this yet (but suspect we soon will) - but our
buyers currently 'know' how far out releases must be qty & date locked
for their vendors. (Example: Sea shipments: Once it's on the boat you
can't ask for a qty or date change).
The remaining MRP suggested releases are consider 'soft' (not yet qty or
date locked) so if we get a spike in demand, MRP will suggest an
expedite (unless we are on fixed delivery schedules - in which case due
date is ALWAYS locked) or qty increase (in multiples of the package size
& drawing down from the end release total balance due).
To keep the MRP noise down to a minimum, we also use partplant In/out
MRP tolerance fields (forgot their real name) so, for example: If L/T
for that part is 10 working days, we might tell MRP to ignore date
mismatches of demand to supply of 10 days early before MRP starts
bugging us with suggestions. If we 'know' the vendor needs 30 firm
working days of releases, that In value will be 30 and out will be a
hefty percentage (different for different commodities and vendors) of
the part LT.
That makes the MRP messaging suddenly useful as now it doesn't tells us
to do things we can't do within the contract terms anyway.
We wasted 6 weeks trying to get 'real' Vantage contract POs to work at
the end of last year and this was our 'plan B' (as our wise purchasing
manager once did something like this a few decades ago an a now defunct
MRP system.) Concurrently, my pal in the UK Nick was also struggling
with this very same issue and almost to the day we arrived at the
conclusion Contract POs don't work (buggy software) - Nick with the
ultimate confirmation after even an Epicor consultant couldn't get it to
work. We also arrived at a nearly identical 'plan B' that I've described
above.
We put ONE PART on the process 1st week of January (and so far no
hiccups) and by the end of this week will have about a 1/2 dozen (same
commodity type and same vendor) on the process.
We are also simultaneously quite aggressively going KanBan in our
internal machine shop that supplies aboyt 30% of our parts used in our
assembly area (where we make to order the products that actually pay the
bills)... Simple processes first and moving on to more complex as I
write this.
We purposefully are using the purchased brass forgings consumed in these
KanBans as the parts to 'go deep' with Lean and also put on this new
home-brewed Blanket PO process.
In true kanban flow systems, you'd normally turn off MRP on the parts
converted to 'KanBan Receipts' processing (in Vantage-speak) - but in
our business (being make to order with millions of potential product
configurations sold at any time), we set MRP up on the fabricated KanBan
parts to mimic what the kanban process WILL be doing in the days ahead
(based upon actual live future schedule customer order and make-direct
jobs to fulfill them in our assembly area). To prevent our production
control planners from inadvertently Firming any of the resulting MRP
-pass through-demand intended only jobs, we have Part.checkbox# # ud
field marked these parts on Fab KanBan Receipts processing andfilter out
the unfirmed jobs from the production control planners by a default BAQ
search in Job Entry.
This pass through of demand (via full regen nightly MRP) on KanBan
Receipt processed fab parts gives necessary visibility to real future
demand to our home-brewed Blanket POs. This prevents purchasing from
being blindsided if we experience demand spikes (and demand is never
smooth so it is critical to us).
Does that make sense (and am I understanding your needs right)? -
Is it potentially applicable to YOUR situation with some tweaks to make
it fit the nuances of your particular business needs?
I hope the long explanation doesn't scare you off from thinking about
it... It is really a quite simple process once you get the big picture
concept. The nitty gritty details then make sense.
Hope that helps (someone)!
Rob
--- On Wed, 2/11/09, Ken Williams <ken@intermountainel ectronics. com
<mailto:ken% 40intermountaine lectronics. com> > wrote:
From: Ken Williams <ken@intermountainel ectronics. com
<mailto:ken% 40intermountaine lectronics. com> >
Subject: [Vantage] Blanket Purchase Orders
To: vantage@yahoogroups .com <mailto:vantage% 40yahoogroups. com>
Date: Wednesday, February 11, 2009, 1:32 PM
We have an agreement with a vendor that we renew each year for a very
large sum of parts distributed over 12 months. Vantage doesn't handle
these transactions quite as well as we might hope, here's how we've done
it previously.. ..I'm hoping someone might have some tweaks to suggest
to
our process to make it a little cleaner. The PO releases are firm and
we need to be able to get information when we need to order additional
parts for short term demand. I'll discuss a single line item, but this
PO generally has dozens.
1. Create PO & Line. Add releases monthly over 12 months with
agreed quantity 10 of part ABC
2. Setup ABC to have a min/max of 10/120 (twelve months) and
uncheck reorder to max
Simple enough, but here's the issues we run into:
1. Change suggestions go nuts over the year.
a. Suggestions to cancel one release
b. Increase qty in another
c. Change the date on another
2. Short term extra demand doesn't show, as it shows up in change
suggestions to modify your existing releases.
I guess what I'm asking is, is there a way to lock in a blanket PO so it
doesn't show up on change suggestions, but still have it take into
account the quantity for future jobs.
Thanks for any suggestions,
Ken
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]