BPM for Order/PO First Release -- any ideas?

Sorry, I should have replied.

Rob Bucek was able to help me with this one. He provided a couple of
examples that shed a lot of light on BPM's in addition to showing me other
ways of getting around in the world of BPM's. Your direction seems to be the
same as what Rob provided.

Thanks to you all.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Calvin Dekker
Sent: Thursday, March 26, 2009 10:08 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] BPM for Order/PO First Release -- any ideas?



Sean -

Have you tried a post process update on PODetail where RowMod is A and
ttPORel.POLine = 1.

This should catch the first PO Rel being added.

HTH,

CodaBears, Inc.

Calvin Dekker

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
Of Sean McDaniel
Sent: Friday, March 20, 2009 3:16 PM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] BPM for Order/PO First Release -- any ideas?

In 8.03, possibly others, when you save the Order or PO detail line the
very
first time it also creates a release line. However, if you create a BPM
to
fire on Update or GetNewRelease they will not fire for the first release
(until you go in and modify that release after it is saved). However,
the
BPM's will fire for every release creation/save after that first one.

Epicor is trying to say that this is as designed. Are there any ideas on
how
to create a BPM that will fire on the creation/save of the first
release?

If you check the log files you can see that the .getnewrelease is never
called and the .update appears to only be for the detail.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
Can anybody tell me how I effectively control purchased parts which
are revision controlled. I am unclear about how the supplier price
list accurately reflects the revision of a part.

Imagine the following scenario:-

We purchase a bespoke, made to drawing part from a vendor, let's its
drawing number is "1234/A". As we are a contract manufacturer and we
therefore make other peoples products, its likely that our MPF part
number and the drawing number for the purchase part will be very
different numbers. Therefore our internal MPF part number might
be "XYZ:123456"

Obviously the revision is critical, and it goes without saying that
the correct drawing number must appear on any purchase order etc. We
must also preserve the revision history and we must ensure that
should we have a need to make a previous revision ( or indeed two
revisions at once ), we can handle this effectively within Vantage.

We create part "XYZ:123456" and revision within the MPF, however as
this is a purchased part, there is no real MOM required. Initially we
create the "A" revision part and approve this. We create an entry in
the supplier price list to reflect the drawing number of the part,
and therefore we set the supplier part number to "1234/A".

We run a number of jobs through the system, and all appears fine.

However as nothing in life is ever simple, the drawing is modified
and we now require to produce part "1234/B", and just to make matters
more complicated, there will be an overlap period where "A" and "B"
are both being purchased at the same time.

It is easy to create a new revision or the part in the MPF, however
the supplier price list data cannot be associated directly with a
part revision. So, I can change the supplier part number
from "1234/A" to "1234/B" but in doing so, I am unable to order
the "A" revision again as the supplier price list entry has been
permanently changed. This is dangerous as the "A" revision part will
call up the same supplier data as the "B" revision part.

So, If I need the supplier price data to be revision specific how do
I do it...? The only way I can see is to actually have different
parts in the MPF for the different revisions! This can't be right can
it...?

Any help would be gratefully received...

Thanks,

Nick
I think you are over-thinking it and making it more complicated than it needs to be.

Yes: Your internal Part Rev may be bumped up (and you might have overlapping approved revs).

You can also have overlapping active Vendor-Part prices lists (each referencing a vendor p/n and rev if this is needed for your process). The Buyer would then have to intervene and make sure they are utilizing the right price list (even if the prices for the different revs don't differ) just to insure the correct vendor part number/rev is pulled into the PO Line record.

If that proves unwieldy (or unreliable as people make mistakes) - consider using a UD field in the vendor price list table to reference the rev - and then add code to enforce search/selection of the price list so that price list ud Rev matches your PO Line Part Rev.

If overlapping effective dates of multiple revs is a rare but necessary evil (and buyers won't necessarily always be purchasing the latest rev when creating a new PO), you probably need some other more overt warning mechanism (or the buyer won't even be aware that multiple approved revs exist - and they need to make a choice).

That overt warning mechanism might be sufficient to simply trigger a human (trained) process where the vendor p/n is appended by the buyer to indicate the correct rev (assuming this enables you to stick with one price-list as the price is no different for either rev).

The 'best' method all depends upon the scope of conditions your buyers will have to contend with (and how frequently - as if it is infrequent - they will forget overly complex procedures and goof it up). That same scope/frequency array should guide you as you decide on whether a customization is worth the effort (as it will have to be maintained forever).

Rob Brown



--- On Thu, 7/31/08, nmtaylor1969 <n.taylor@...> wrote:
From: nmtaylor1969 <n.taylor@...>
Subject: [Vantage] Vantage Revision Control In 8.03.305K
To: vantage@yahoogroups.com
Date: Thursday, July 31, 2008, 2:45 AM













Can anybody tell me how I effectively control purchased parts which

are revision controlled. I am unclear about how the supplier price

list accurately reflects the revision of a part.



Imagine the following scenario:-



We purchase a bespoke, made to drawing part from a vendor, let's its

drawing number is "1234/A". As we are a contract manufacturer and we

therefore make other peoples products, its likely that our MPF part

number and the drawing number for the purchase part will be very

different numbers. Therefore our internal MPF part number might

be "XYZ:"



Obviously the revision is critical, and it goes without saying that

the correct drawing number must appear on any purchase order etc. We

must also preserve the revision history and we must ensure that

should we have a need to make a previous revision ( or indeed two

revisions at once ), we can handle this effectively within Vantage.



We create part "XYZ:" and revision within the MPF, however as

this is a purchased part, there is no real MOM required. Initially we

create the "A" revision part and approve this. We create an entry in

the supplier price list to reflect the drawing number of the part,

and therefore we set the supplier part number to "1234/A".



We run a number of jobs through the system, and all appears fine.



However as nothing in life is ever simple, the drawing is modified

and we now require to produce part "1234/B", and just to make matters

more complicated, there will be an overlap period where "A" and "B"

are both being purchased at the same time.



It is easy to create a new revision or the part in the MPF, however

the supplier price list data cannot be associated directly with a

part revision. So, I can change the supplier part number

from "1234/A" to "1234/B" but in doing so, I am unable to order

the "A" revision again as the supplier price list entry has been

permanently changed. This is dangerous as the "A" revision part will

call up the same supplier data as the "B" revision part.



So, If I need the supplier price data to be revision specific how do

I do it...? The only way I can see is to actually have different

parts in the MPF for the different revisions! This can't be right can

it...?



Any help would be gratefully received...



Thanks,



Nick
Rob, don't you ever sleep...!?

Thanks for the advice, I think this is going to be an area where we
really need to challenge what we are doing, and perhaps take a step
back and look at the process again in more detail.

I will go through your reply in detail shortly...

Do you happen to know if the "use part rev" setting in the MPF is
actually of any use...?!

Also, if you recall my post about the production planner workbench.
Epicor are now looking at this, as the rubbish that this form was
showing is down to a bug... At least I am not going mad! ;o)

As always, many thanks...

Nick


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> I think you are over-thinking it and making it more complicated
than it needs to be.
>
> Yes: Your internal Part Rev may be bumped up (and you might have
overlapping approved revs).
>
> You can also have overlapping active Vendor-Part prices lists (each
referencing a vendor p/n and rev if this is needed for your process).
The Buyer would then have to intervene and make sure they are
utilizing the right price list (even if the prices for the different
revs don't differ) just to insure the correct vendor part number/rev
is pulled into the PO Line record.
>
> If that proves unwieldy (or unreliable as people make mistakes) -
consider using a UD field in the vendor price list table to reference
the rev - and then add code to enforce search/selection of the price
list so that price list ud Rev matches your PO Line Part Rev.
>
> If overlapping effective dates of multiple revs is a rare but
necessary evil (and buyers won't necessarily always be purchasing the
latest rev when creating a new PO), you probably need some other more
overt warning mechanism (or the buyer won't even be aware that
multiple approved revs exist - and they need to make a choice).
>
> That overt warning mechanism might be sufficient to simply trigger
a human (trained) process where the vendor p/n is appended by the
buyer to indicate the correct rev (assuming this enables you to stick
with one price-list as the price is no different for either rev).
>
> The 'best' method all depends upon the scope of conditions your
buyers will have to contend with (and how frequently - as if it is
infrequent - they will forget overly complex procedures and goof it
up). That same scope/frequency array should guide you as you decide
on whether a customization is worth the effort (as it will have to be
maintained forever).
>
> Rob Brown
>
>
>
> --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@...> wrote:
> From: nmtaylor1969 <n.taylor@...>
> Subject: [Vantage] Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups.com
> Date: Thursday, July 31, 2008, 2:45 AM
>
>
>
>
>
>
>
>
>
>
>
>
>
> Can anybody tell me how I effectively control purchased parts which
>
> are revision controlled. I am unclear about how the supplier price
>
> list accurately reflects the revision of a part.
>
>
>
> Imagine the following scenario:-
>
>
>
> We purchase a bespoke, made to drawing part from a vendor, let's
its
>
> drawing number is "1234/A". As we are a contract manufacturer and
we
>
> therefore make other peoples products, its likely that our MPF part
>
> number and the drawing number for the purchase part will be very
>
> different numbers. Therefore our internal MPF part number might
>
> be "XYZ:"
>
>
>
> Obviously the revision is critical, and it goes without saying that
>
> the correct drawing number must appear on any purchase order etc.
We
>
> must also preserve the revision history and we must ensure that
>
> should we have a need to make a previous revision ( or indeed two
>
> revisions at once ), we can handle this effectively within Vantage.
>
>
>
> We create part "XYZ:" and revision within the MPF, however as
>
> this is a purchased part, there is no real MOM required. Initially
we
>
> create the "A" revision part and approve this. We create an entry
in
>
> the supplier price list to reflect the drawing number of the part,
>
> and therefore we set the supplier part number to "1234/A".
>
>
>
> We run a number of jobs through the system, and all appears fine.
>
>
>
> However as nothing in life is ever simple, the drawing is modified
>
> and we now require to produce part "1234/B", and just to make
matters
>
> more complicated, there will be an overlap period where "A" and "B"
>
> are both being purchased at the same time.
>
>
>
> It is easy to create a new revision or the part in the MPF, however
>
> the supplier price list data cannot be associated directly with a
>
> part revision. So, I can change the supplier part number
>
> from "1234/A" to "1234/B" but in doing so, I am unable to order
>
> the "A" revision again as the supplier price list entry has been
>
> permanently changed. This is dangerous as the "A" revision part
will
>
> call up the same supplier data as the "B" revision part.
>
>
>
> So, If I need the supplier price data to be revision specific how
do
>
> I do it...? The only way I can see is to actually have different
>
> parts in the MPF for the different revisions! This can't be right
can
>
> it...?
>
>
>
> Any help would be gratefully received...
>
>
>
> Thanks,
>
>
>
> Nick
>
Hi All,

I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.

For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.

So it seems I can:

-create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.

-create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?

-Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.

I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.

Cheers,

-Ramsey


--- In vantage@yahoogroups.com, "nmtaylor1969" <n.taylor@...> wrote:
>
> Rob, don't you ever sleep...!?
>
> Thanks for the advice, I think this is going to be an area where we
> really need to challenge what we are doing, and perhaps take a step
> back and look at the process again in more detail.
>
> I will go through your reply in detail shortly...
>
> Do you happen to know if the "use part rev" setting in the MPF is
> actually of any use...?!
>
> Also, if you recall my post about the production planner workbench.
> Epicor are now looking at this, as the rubbish that this form was
> showing is down to a bug... At least I am not going mad! ;o)
>
> As always, many thanks...
>
> Nick
>
>
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> wrote:
> >
> > I think you are over-thinking it and making it more complicated
> than it needs to be.
> >
> > Yes: Your internal Part Rev may be bumped up (and you might have
> overlapping approved revs).
> >
> > You can also have overlapping active Vendor-Part prices lists (each
> referencing a vendor p/n and rev if this is needed for your process).
> The Buyer would then have to intervene and make sure they are
> utilizing the right price list (even if the prices for the different
> revs don't differ) just to insure the correct vendor part number/rev
> is pulled into the PO Line record.
> >
> > If that proves unwieldy (or unreliable as people make mistakes) -
> consider using a UD field in the vendor price list table to reference
> the rev - and then add code to enforce search/selection of the price
> list so that price list ud Rev matches your PO Line Part Rev.
> >
> > If overlapping effective dates of multiple revs is a rare but
> necessary evil (and buyers won't necessarily always be purchasing the
> latest rev when creating a new PO), you probably need some other more
> overt warning mechanism (or the buyer won't even be aware that
> multiple approved revs exist - and they need to make a choice).
> >
> > That overt warning mechanism might be sufficient to simply trigger
> a human (trained) process where the vendor p/n is appended by the
> buyer to indicate the correct rev (assuming this enables you to stick
> with one price-list as the price is no different for either rev).
> >
> > The 'best' method all depends upon the scope of conditions your
> buyers will have to contend with (and how frequently - as if it is
> infrequent - they will forget overly complex procedures and goof it
> up). That same scope/frequency array should guide you as you decide
> on whether a customization is worth the effort (as it will have to be
> maintained forever).
> >
> > Rob Brown
> >
> >
> >
> > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
> > From: nmtaylor1969 <n.taylor@>
> > Subject: [Vantage] Vantage Revision Control In 8.03.305K
> > To: vantage@yahoogroups.com
> > Date: Thursday, July 31, 2008, 2:45 AM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Can anybody tell me how I effectively control purchased parts which
> >
> > are revision controlled. I am unclear about how the supplier price
> >
> > list accurately reflects the revision of a part.
> >
> >
> >
> > Imagine the following scenario:-
> >
> >
> >
> > We purchase a bespoke, made to drawing part from a vendor, let's
> its
> >
> > drawing number is "1234/A". As we are a contract manufacturer and
> we
> >
> > therefore make other peoples products, its likely that our MPF part
> >
> > number and the drawing number for the purchase part will be very
> >
> > different numbers. Therefore our internal MPF part number might
> >
> > be "XYZ:"
> >
> >
> >
> > Obviously the revision is critical, and it goes without saying that
> >
> > the correct drawing number must appear on any purchase order etc.
> We
> >
> > must also preserve the revision history and we must ensure that
> >
> > should we have a need to make a previous revision ( or indeed two
> >
> > revisions at once ), we can handle this effectively within Vantage.
> >
> >
> >
> > We create part "XYZ:" and revision within the MPF, however as
> >
> > this is a purchased part, there is no real MOM required. Initially
> we
> >
> > create the "A" revision part and approve this. We create an entry
> in
> >
> > the supplier price list to reflect the drawing number of the part,
> >
> > and therefore we set the supplier part number to "1234/A".
> >
> >
> >
> > We run a number of jobs through the system, and all appears fine.
> >
> >
> >
> > However as nothing in life is ever simple, the drawing is modified
> >
> > and we now require to produce part "1234/B", and just to make
> matters
> >
> > more complicated, there will be an overlap period where "A" and "B"
> >
> > are both being purchased at the same time.
> >
> >
> >
> > It is easy to create a new revision or the part in the MPF, however
> >
> > the supplier price list data cannot be associated directly with a
> >
> > part revision. So, I can change the supplier part number
> >
> > from "1234/A" to "1234/B" but in doing so, I am unable to order
> >
> > the "A" revision again as the supplier price list entry has been
> >
> > permanently changed. This is dangerous as the "A" revision part
> will
> >
> > call up the same supplier data as the "B" revision part.
> >
> >
> >
> > So, If I need the supplier price data to be revision specific how
> do
> >
> > I do it...? The only way I can see is to actually have different
> >
> > parts in the MPF for the different revisions! This can't be right
> can
> >
> > it...?
> >
> >
> >
> > Any help would be gratefully received...
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Nick
> >
>
Ramsey,

No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).

That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).

Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.

Pass on a good word to Nick for me. (Hope that knee is mending well.)

Hope that helps

Rob

--- On Tue, 3/10/09, alldoneprojects <ramsey@...> wrote:
From: alldoneprojects <ramsey@...>
Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
To: vantage@yahoogroups.com
Date: Tuesday, March 10, 2009, 8:41 PM












Hi All,



I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.



For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.



So it seems I can:



-create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.



-create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?



-Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.



I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.



Cheers,



-Ramsey



--- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@.. .> wrote:

>

> Rob, don't you ever sleep...!?

>

> Thanks for the advice, I think this is going to be an area where we

> really need to challenge what we are doing, and perhaps take a step

> back and look at the process again in more detail.

>

> I will go through your reply in detail shortly...

>

> Do you happen to know if the "use part rev" setting in the MPF is

> actually of any use...?!

>

> Also, if you recall my post about the production planner workbench.

> Epicor are now looking at this, as the rubbish that this form was

> showing is down to a bug... At least I am not going mad! ;o)

>

> As always, many thanks...

>

> Nick

>

>

> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >

> wrote:

> >

> > I think you are over-thinking it and making it more complicated

> than it needs to be.

> >

> > Yes: Your internal Part Rev may be bumped up (and you might have

> overlapping approved revs).

> >

> > You can also have overlapping active Vendor-Part prices lists (each

> referencing a vendor p/n and rev if this is needed for your process).

> The Buyer would then have to intervene and make sure they are

> utilizing the right price list (even if the prices for the different

> revs don't differ) just to insure the correct vendor part number/rev

> is pulled into the PO Line record.

> >

> > If that proves unwieldy (or unreliable as people make mistakes) -

> consider using a UD field in the vendor price list table to reference

> the rev - and then add code to enforce search/selection of the price

> list so that price list ud Rev matches your PO Line Part Rev.

> >

> > If overlapping effective dates of multiple revs is a rare but

> necessary evil (and buyers won't necessarily always be purchasing the

> latest rev when creating a new PO), you probably need some other more

> overt warning mechanism (or the buyer won't even be aware that

> multiple approved revs exist - and they need to make a choice).

> >

> > That overt warning mechanism might be sufficient to simply trigger

> a human (trained) process where the vendor p/n is appended by the

> buyer to indicate the correct rev (assuming this enables you to stick

> with one price-list as the price is no different for either rev).

> >

> > The 'best' method all depends upon the scope of conditions your

> buyers will have to contend with (and how frequently - as if it is

> infrequent - they will forget overly complex procedures and goof it

> up). That same scope/frequency array should guide you as you decide

> on whether a customization is worth the effort (as it will have to be

> maintained forever).

> >

> > Rob Brown

> >

> >

> >

> > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:

> > From: nmtaylor1969 <n.taylor@>

> > Subject: [Vantage] Vantage Revision Control In 8.03.305K

> > To: vantage@yahoogroups .com

> > Date: Thursday, July 31, 2008, 2:45 AM

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> > Can anybody tell me how I effectively control purchased parts which

> >

> > are revision controlled. I am unclear about how the supplier price

> >

> > list accurately reflects the revision of a part.

> >

> >

> >

> > Imagine the following scenario:-

> >

> >

> >

> > We purchase a bespoke, made to drawing part from a vendor, let's

> its

> >

> > drawing number is "1234/A". As we are a contract manufacturer and

> we

> >

> > therefore make other peoples products, its likely that our MPF part

> >

> > number and the drawing number for the purchase part will be very

> >

> > different numbers. Therefore our internal MPF part number might

> >

> > be "XYZ:"

> >

> >

> >

> > Obviously the revision is critical, and it goes without saying that

> >

> > the correct drawing number must appear on any purchase order etc.

> We

> >

> > must also preserve the revision history and we must ensure that

> >

> > should we have a need to make a previous revision ( or indeed two

> >

> > revisions at once ), we can handle this effectively within Vantage.

> >

> >

> >

> > We create part "XYZ:" and revision within the MPF, however as

> >

> > this is a purchased part, there is no real MOM required. Initially

> we

> >

> > create the "A" revision part and approve this. We create an entry

> in

> >

> > the supplier price list to reflect the drawing number of the part,

> >

> > and therefore we set the supplier part number to "1234/A".

> >

> >

> >

> > We run a number of jobs through the system, and all appears fine.

> >

> >

> >

> > However as nothing in life is ever simple, the drawing is modified

> >

> > and we now require to produce part "1234/B", and just to make

> matters

> >

> > more complicated, there will be an overlap period where "A" and "B"

> >

> > are both being purchased at the same time.

> >

> >

> >

> > It is easy to create a new revision or the part in the MPF, however

> >

> > the supplier price list data cannot be associated directly with a

> >

> > part revision. So, I can change the supplier part number

> >

> > from "1234/A" to "1234/B" but in doing so, I am unable to order

> >

> > the "A" revision again as the supplier price list entry has been

> >

> > permanently changed. This is dangerous as the "A" revision part

> will

> >

> > call up the same supplier data as the "B" revision part.

> >

> >

> >

> > So, If I need the supplier price data to be revision specific how

> do

> >

> > I do it...? The only way I can see is to actually have different

> >

> > parts in the MPF for the different revisions! This can't be right

> can

> >

> > it...?

> >

> >

> >

> > Any help would be gratefully received...

> >

> >

> >

> > Thanks,

> >

> >

> >

> > Nick

> >

>
Hi Ramsey,

There is nothing to stop you entering multiple vendors against any given part number. Obviously the system will produce default buy suggestions against the primary vendor, but if that vendor doesn't have stock your buyer can select one of the alternate choices. This should would work fine for non revisioned parts.

My issue was that if I buy a part which is revison controlled, Vantage cannot differentiate this in the vendor price list. So, if I have a part number in the MPF of ABC/1 and I buy this from a vendor as part ABC/1, when I upgrade the revision to ABC/2, the vendor data must also be changed. This is ok, BUT, once I have changed it to ABC/2 should I ever want to go back and buy ABC/1 one again, the vendor data will kick out ABC/2 ( or whatever is current as of today ) as this information is not revision specific. This was an issue for us.

We are actually stopping our Vantage install at the moment, as there were just too many issues like this to deal with, however you should consider the following:-

We ended up coming to the conclusion that revisions could represent either a critical or a non-critical change. Typically critical ( i.e. functional ) changes were not backward compatible and therefore must be differentiated in MRP. In other words a revision "B" is not backward compatible with revision "A" and the two are not interchangeable. If I have stock of revision "A" this is an issue and we must consider how this is run out. Non-critical changes on the other hand ( i.e. a process tweak or some other non-functional change ) did not need to be differentiated in MRP as revision "B" will still work in the place of revision "A".

We eventually came to the conclusion that non-critical changes could be handled via the part revision within the MPF as the vendor data would remain unchanged. MRP treats these as the same part which is fine. However, where we needed isolation, we would have to create a new part in the MPF as we could then manage each revision individually within the MRP system. As they were in effect two seperate parts, each would have their own vendor data thus maintaining seperation and correct revision status.

The changing of a revision puts pressure on the off-system, human process which must be undertaken when a revision changes. How much stock/wip have I got?, what stock is due from a vendor? can I upgrade stock/wip to the latest revision ? Do I need seperation ? All this kind of stuff must be evaluated and the appropriate course of action decided upon as a controlled multi-departmental process rather than as an informal action by one specific individual.

I'm sure the above would have worked, but for the time being we are continuing to run our legacy system which does provide the vendor part revision contol that we are looking for... :o)

Hi Rob, the knee is ok thanks... Finally I am putting a little weight on it now... How's you...?

Cheers,

Nick


--- In vantage@yahoogroups.com, "alldoneprojects" <ramsey@...> wrote:
>
> Hi All,
>
> I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
>
> For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
>
> So it seems I can:
>
> -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
>
> -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
>
> -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
>
> I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
>
> Cheers,
>
> -Ramsey
>
>
> --- In vantage@yahoogroups.com, "nmtaylor1969" <n.taylor@> wrote:
> >
> > Rob, don't you ever sleep...!?
> >
> > Thanks for the advice, I think this is going to be an area where we
> > really need to challenge what we are doing, and perhaps take a step
> > back and look at the process again in more detail.
> >
> > I will go through your reply in detail shortly...
> >
> > Do you happen to know if the "use part rev" setting in the MPF is
> > actually of any use...?!
> >
> > Also, if you recall my post about the production planner workbench.
> > Epicor are now looking at this, as the rubbish that this form was
> > showing is down to a bug... At least I am not going mad! ;o)
> >
> > As always, many thanks...
> >
> > Nick
> >
> >
> > --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> > wrote:
> > >
> > > I think you are over-thinking it and making it more complicated
> > than it needs to be.
> > >
> > > Yes: Your internal Part Rev may be bumped up (and you might have
> > overlapping approved revs).
> > >
> > > You can also have overlapping active Vendor-Part prices lists (each
> > referencing a vendor p/n and rev if this is needed for your process).
> > The Buyer would then have to intervene and make sure they are
> > utilizing the right price list (even if the prices for the different
> > revs don't differ) just to insure the correct vendor part number/rev
> > is pulled into the PO Line record.
> > >
> > > If that proves unwieldy (or unreliable as people make mistakes) -
> > consider using a UD field in the vendor price list table to reference
> > the rev - and then add code to enforce search/selection of the price
> > list so that price list ud Rev matches your PO Line Part Rev.
> > >
> > > If overlapping effective dates of multiple revs is a rare but
> > necessary evil (and buyers won't necessarily always be purchasing the
> > latest rev when creating a new PO), you probably need some other more
> > overt warning mechanism (or the buyer won't even be aware that
> > multiple approved revs exist - and they need to make a choice).
> > >
> > > That overt warning mechanism might be sufficient to simply trigger
> > a human (trained) process where the vendor p/n is appended by the
> > buyer to indicate the correct rev (assuming this enables you to stick
> > with one price-list as the price is no different for either rev).
> > >
> > > The 'best' method all depends upon the scope of conditions your
> > buyers will have to contend with (and how frequently - as if it is
> > infrequent - they will forget overly complex procedures and goof it
> > up). That same scope/frequency array should guide you as you decide
> > on whether a customization is worth the effort (as it will have to be
> > maintained forever).
> > >
> > > Rob Brown
> > >
> > >
> > >
> > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
> > > From: nmtaylor1969 <n.taylor@>
> > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
> > > To: vantage@yahoogroups.com
> > > Date: Thursday, July 31, 2008, 2:45 AM
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Can anybody tell me how I effectively control purchased parts which
> > >
> > > are revision controlled. I am unclear about how the supplier price
> > >
> > > list accurately reflects the revision of a part.
> > >
> > >
> > >
> > > Imagine the following scenario:-
> > >
> > >
> > >
> > > We purchase a bespoke, made to drawing part from a vendor, let's
> > its
> > >
> > > drawing number is "1234/A". As we are a contract manufacturer and
> > we
> > >
> > > therefore make other peoples products, its likely that our MPF part
> > >
> > > number and the drawing number for the purchase part will be very
> > >
> > > different numbers. Therefore our internal MPF part number might
> > >
> > > be "XYZ:"
> > >
> > >
> > >
> > > Obviously the revision is critical, and it goes without saying that
> > >
> > > the correct drawing number must appear on any purchase order etc.
> > We
> > >
> > > must also preserve the revision history and we must ensure that
> > >
> > > should we have a need to make a previous revision ( or indeed two
> > >
> > > revisions at once ), we can handle this effectively within Vantage.
> > >
> > >
> > >
> > > We create part "XYZ:" and revision within the MPF, however as
> > >
> > > this is a purchased part, there is no real MOM required. Initially
> > we
> > >
> > > create the "A" revision part and approve this. We create an entry
> > in
> > >
> > > the supplier price list to reflect the drawing number of the part,
> > >
> > > and therefore we set the supplier part number to "1234/A".
> > >
> > >
> > >
> > > We run a number of jobs through the system, and all appears fine.
> > >
> > >
> > >
> > > However as nothing in life is ever simple, the drawing is modified
> > >
> > > and we now require to produce part "1234/B", and just to make
> > matters
> > >
> > > more complicated, there will be an overlap period where "A" and "B"
> > >
> > > are both being purchased at the same time.
> > >
> > >
> > >
> > > It is easy to create a new revision or the part in the MPF, however
> > >
> > > the supplier price list data cannot be associated directly with a
> > >
> > > part revision. So, I can change the supplier part number
> > >
> > > from "1234/A" to "1234/B" but in doing so, I am unable to order
> > >
> > > the "A" revision again as the supplier price list entry has been
> > >
> > > permanently changed. This is dangerous as the "A" revision part
> > will
> > >
> > > call up the same supplier data as the "B" revision part.
> > >
> > >
> > >
> > > So, If I need the supplier price data to be revision specific how
> > do
> > >
> > > I do it...? The only way I can see is to actually have different
> > >
> > > parts in the MPF for the different revisions! This can't be right
> > can
> > >
> > > it...?
> > >
> > >
> > >
> > > Any help would be gratefully received...
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Nick
> > >
> >
>
Hi Ramsey,

The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).

Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.

It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).

Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)

If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.

It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.

Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.

Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.

We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.

The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.

I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.

Rob

--- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:

From: alldoneprojects <ramsey@...>
Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
To: vantage@yahoogroups.com
Date: Wednesday, March 11, 2009, 9:58 AM






Hi Rob,

Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.

My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?

We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.

Thanks to you both,

-Ramsey

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
>
> Ramsey,
>
> No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).
>
> That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).
>
> Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.
>
> Pass on a good word to Nick for me. (Hope that knee is mending well.)
>
> Hope that helps
>
> Rob
>
> --- On Tue, 3/10/09, alldoneprojects <ramsey@...> wrote:
> From: alldoneprojects <ramsey@...>
> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups .com
> Date: Tuesday, March 10, 2009, 8:41 PM
>
>
>
>
>
>
>
>
>
>
>
>
> Hi All,
>
>
>
> I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
>
>
>
> For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
>
>
>
> So it seems I can:
>
>
>
> -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
>
>
>
> -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
>
>
>
> -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
>
>
>
> I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
>
>
>
> Cheers,
>
>
>
> -Ramsey
>
>
>
> --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:
>
> >
>
> > Rob, don't you ever sleep...!?
>
> >
>
> > Thanks for the advice, I think this is going to be an area where we
>
> > really need to challenge what we are doing, and perhaps take a step
>
> > back and look at the process again in more detail.
>
> >
>
> > I will go through your reply in detail shortly...
>
> >
>
> > Do you happen to know if the "use part rev" setting in the MPF is
>
> > actually of any use...?!
>
> >
>
> > Also, if you recall my post about the production planner workbench.
>
> > Epicor are now looking at this, as the rubbish that this form was
>
> > showing is down to a bug... At least I am not going mad! ;o)
>
> >
>
> > As always, many thanks...
>
> >
>
> > Nick
>
> >
>
> >
>
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
>
> > wrote:
>
> > >
>
> > > I think you are over-thinking it and making it more complicated
>
> > than it needs to be.
>
> > >
>
> > > Yes: Your internal Part Rev may be bumped up (and you might have
>
> > overlapping approved revs).
>
> > >
>
> > > You can also have overlapping active Vendor-Part prices lists (each
>
> > referencing a vendor p/n and rev if this is needed for your process).
>
> > The Buyer would then have to intervene and make sure they are
>
> > utilizing the right price list (even if the prices for the different
>
> > revs don't differ) just to insure the correct vendor part number/rev
>
> > is pulled into the PO Line record.
>
> > >
>
> > > If that proves unwieldy (or unreliable as people make mistakes) -
>
> > consider using a UD field in the vendor price list table to reference
>
> > the rev - and then add code to enforce search/selection of the price
>
> > list so that price list ud Rev matches your PO Line Part Rev.
>
> > >
>
> > > If overlapping effective dates of multiple revs is a rare but
>
> > necessary evil (and buyers won't necessarily always be purchasing the
>
> > latest rev when creating a new PO), you probably need some other more
>
> > overt warning mechanism (or the buyer won't even be aware that
>
> > multiple approved revs exist - and they need to make a choice).
>
> > >
>
> > > That overt warning mechanism might be sufficient to simply trigger
>
> > a human (trained) process where the vendor p/n is appended by the
>
> > buyer to indicate the correct rev (assuming this enables you to stick
>
> > with one price-list as the price is no different for either rev).
>
> > >
>
> > > The 'best' method all depends upon the scope of conditions your
>
> > buyers will have to contend with (and how frequently - as if it is
>
> > infrequent - they will forget overly complex procedures and goof it
>
> > up). That same scope/frequency array should guide you as you decide
>
> > on whether a customization is worth the effort (as it will have to be
>
> > maintained forever).
>
> > >
>
> > > Rob Brown
>
> > >
>
> > >
>
> > >
>
> > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
>
> > > From: nmtaylor1969 <n.taylor@>
>
> > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
>
> > > To: vantage@yahoogroups .com
>
> > > Date: Thursday, July 31, 2008, 2:45 AM
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > Can anybody tell me how I effectively control purchased parts which
>
> > >
>
> > > are revision controlled. I am unclear about how the supplier price
>
> > >
>
> > > list accurately reflects the revision of a part.
>
> > >
>
> > >
>
> > >
>
> > > Imagine the following scenario:-
>
> > >
>
> > >
>
> > >
>
> > > We purchase a bespoke, made to drawing part from a vendor, let's
>
> > its
>
> > >
>
> > > drawing number is "1234/A". As we are a contract manufacturer and
>
> > we
>
> > >
>
> > > therefore make other peoples products, its likely that our MPF part
>
> > >
>
> > > number and the drawing number for the purchase part will be very
>
> > >
>
> > > different numbers. Therefore our internal MPF part number might
>
> > >
>
> > > be "XYZ:"
>
> > >
>
> > >
>
> > >
>
> > > Obviously the revision is critical, and it goes without saying that
>
> > >
>
> > > the correct drawing number must appear on any purchase order etc.
>
> > We
>
> > >
>
> > > must also preserve the revision history and we must ensure that
>
> > >
>
> > > should we have a need to make a previous revision ( or indeed two
>
> > >
>
> > > revisions at once ), we can handle this effectively within Vantage.
>
> > >
>
> > >
>
> > >
>
> > > We create part "XYZ:" and revision within the MPF, however as
>
> > >
>
> > > this is a purchased part, there is no real MOM required. Initially
>
> > we
>
> > >
>
> > > create the "A" revision part and approve this. We create an entry
>
> > in
>
> > >
>
> > > the supplier price list to reflect the drawing number of the part,
>
> > >
>
> > > and therefore we set the supplier part number to "1234/A".
>
> > >
>
> > >
>
> > >
>
> > > We run a number of jobs through the system, and all appears fine.
>
> > >
>
> > >
>
> > >
>
> > > However as nothing in life is ever simple, the drawing is modified
>
> > >
>
> > > and we now require to produce part "1234/B", and just to make
>
> > matters
>
> > >
>
> > > more complicated, there will be an overlap period where "A" and "B"
>
> > >
>
> > > are both being purchased at the same time.
>
> > >
>
> > >
>
> > >
>
> > > It is easy to create a new revision or the part in the MPF, however
>
> > >
>
> > > the supplier price list data cannot be associated directly with a
>
> > >
>
> > > part revision. So, I can change the supplier part number
>
> > >
>
> > > from "1234/A" to "1234/B" but in doing so, I am unable to order
>
> > >
>
> > > the "A" revision again as the supplier price list entry has been
>
> > >
>
> > > permanently changed. This is dangerous as the "A" revision part
>
> > will
>
> > >
>
> > > call up the same supplier data as the "B" revision part.
>
> > >
>
> > >
>
> > >
>
> > > So, If I need the supplier price data to be revision specific how
>
> > do
>
> > >
>
> > > I do it...? The only way I can see is to actually have different
>
> > >
>
> > > parts in the MPF for the different revisions! This can't be right
>
> > can
>
> > >
>
> > > it...?
>
> > >
>
> > >
>
> > >
>
> > > Any help would be gratefully received...
>
> > >
>
> > >
>
> > >
>
> > > Thanks,
>
> > >
>
> > >
>
> > >
>
> > > Nick
>
> > >
>
> >
>
Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.

So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?

Why the field I need behaves this way yet hundereds of others you can copy??

-Ramsey

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
>
> Hi Ramsey,
>
> The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).
>
> Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.
>
> It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).
>
> Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)
>
> If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.
>
> It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.
>
> Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.
>
> Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.
>
> We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.
>
> The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.
>
> I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.
>
> Rob
>
> --- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:
>
> From: alldoneprojects <ramsey@...>
> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups.com
> Date: Wednesday, March 11, 2009, 9:58 AM
>
>
>
>
>
>
> Hi Rob,
>
> Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.
>
> My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?
>
> We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.
>
> Thanks to you both,
>
> -Ramsey
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
> >
> >
> > Ramsey,
> >
> > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).
> >
> > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).
> >
> > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.
> >
> > Pass on a good word to Nick for me. (Hope that knee is mending well.)
> >
> > Hope that helps
> >
> > Rob
> >
> > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:
> > From: alldoneprojects <ramsey@>
> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> > To: vantage@yahoogroups .com
> > Date: Tuesday, March 10, 2009, 8:41 PM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi All,
> >
> >
> >
> > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
> >
> >
> >
> > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
> >
> >
> >
> > So it seems I can:
> >
> >
> >
> > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
> >
> >
> >
> > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
> >
> >
> >
> > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
> >
> >
> >
> > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
> >
> >
> >
> > Cheers,
> >
> >
> >
> > -Ramsey
> >
> >
> >
> > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:
> >
> > >
> >
> > > Rob, don't you ever sleep...!?
> >
> > >
> >
> > > Thanks for the advice, I think this is going to be an area where we
> >
> > > really need to challenge what we are doing, and perhaps take a step
> >
> > > back and look at the process again in more detail.
> >
> > >
> >
> > > I will go through your reply in detail shortly...
> >
> > >
> >
> > > Do you happen to know if the "use part rev" setting in the MPF is
> >
> > > actually of any use...?!
> >
> > >
> >
> > > Also, if you recall my post about the production planner workbench.
> >
> > > Epicor are now looking at this, as the rubbish that this form was
> >
> > > showing is down to a bug... At least I am not going mad! ;o)
> >
> > >
> >
> > > As always, many thanks...
> >
> > >
> >
> > > Nick
> >
> > >
> >
> > >
> >
> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> >
> > > wrote:
> >
> > > >
> >
> > > > I think you are over-thinking it and making it more complicated
> >
> > > than it needs to be.
> >
> > > >
> >
> > > > Yes: Your internal Part Rev may be bumped up (and you might have
> >
> > > overlapping approved revs).
> >
> > > >
> >
> > > > You can also have overlapping active Vendor-Part prices lists (each
> >
> > > referencing a vendor p/n and rev if this is needed for your process).
> >
> > > The Buyer would then have to intervene and make sure they are
> >
> > > utilizing the right price list (even if the prices for the different
> >
> > > revs don't differ) just to insure the correct vendor part number/rev
> >
> > > is pulled into the PO Line record.
> >
> > > >
> >
> > > > If that proves unwieldy (or unreliable as people make mistakes) -
> >
> > > consider using a UD field in the vendor price list table to reference
> >
> > > the rev - and then add code to enforce search/selection of the price
> >
> > > list so that price list ud Rev matches your PO Line Part Rev.
> >
> > > >
> >
> > > > If overlapping effective dates of multiple revs is a rare but
> >
> > > necessary evil (and buyers won't necessarily always be purchasing the
> >
> > > latest rev when creating a new PO), you probably need some other more
> >
> > > overt warning mechanism (or the buyer won't even be aware that
> >
> > > multiple approved revs exist - and they need to make a choice).
> >
> > > >
> >
> > > > That overt warning mechanism might be sufficient to simply trigger
> >
> > > a human (trained) process where the vendor p/n is appended by the
> >
> > > buyer to indicate the correct rev (assuming this enables you to stick
> >
> > > with one price-list as the price is no different for either rev).
> >
> > > >
> >
> > > > The 'best' method all depends upon the scope of conditions your
> >
> > > buyers will have to contend with (and how frequently - as if it is
> >
> > > infrequent - they will forget overly complex procedures and goof it
> >
> > > up). That same scope/frequency array should guide you as you decide
> >
> > > on whether a customization is worth the effort (as it will have to be
> >
> > > maintained forever).
> >
> > > >
> >
> > > > Rob Brown
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
> >
> > > > From: nmtaylor1969 <n.taylor@>
> >
> > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
> >
> > > > To: vantage@yahoogroups .com
> >
> > > > Date: Thursday, July 31, 2008, 2:45 AM
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Can anybody tell me how I effectively control purchased parts which
> >
> > > >
> >
> > > > are revision controlled. I am unclear about how the supplier price
> >
> > > >
> >
> > > > list accurately reflects the revision of a part.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Imagine the following scenario:-
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > We purchase a bespoke, made to drawing part from a vendor, let's
> >
> > > its
> >
> > > >
> >
> > > > drawing number is "1234/A". As we are a contract manufacturer and
> >
> > > we
> >
> > > >
> >
> > > > therefore make other peoples products, its likely that our MPF part
> >
> > > >
> >
> > > > number and the drawing number for the purchase part will be very
> >
> > > >
> >
> > > > different numbers. Therefore our internal MPF part number might
> >
> > > >
> >
> > > > be "XYZ:"
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Obviously the revision is critical, and it goes without saying that
> >
> > > >
> >
> > > > the correct drawing number must appear on any purchase order etc.
> >
> > > We
> >
> > > >
> >
> > > > must also preserve the revision history and we must ensure that
> >
> > > >
> >
> > > > should we have a need to make a previous revision ( or indeed two
> >
> > > >
> >
> > > > revisions at once ), we can handle this effectively within Vantage.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > We create part "XYZ:" and revision within the MPF, however as
> >
> > > >
> >
> > > > this is a purchased part, there is no real MOM required. Initially
> >
> > > we
> >
> > > >
> >
> > > > create the "A" revision part and approve this. We create an entry
> >
> > > in
> >
> > > >
> >
> > > > the supplier price list to reflect the drawing number of the part,
> >
> > > >
> >
> > > > and therefore we set the supplier part number to "1234/A".
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > We run a number of jobs through the system, and all appears fine.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > However as nothing in life is ever simple, the drawing is modified
> >
> > > >
> >
> > > > and we now require to produce part "1234/B", and just to make
> >
> > > matters
> >
> > > >
> >
> > > > more complicated, there will be an overlap period where "A" and "B"
> >
> > > >
> >
> > > > are both being purchased at the same time.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > It is easy to create a new revision or the part in the MPF, however
> >
> > > >
> >
> > > > the supplier price list data cannot be associated directly with a
> >
> > > >
> >
> > > > part revision. So, I can change the supplier part number
> >
> > > >
> >
> > > > from "1234/A" to "1234/B" but in doing so, I am unable to order
> >
> > > >
> >
> > > > the "A" revision again as the supplier price list entry has been
> >
> > > >
> >
> > > > permanently changed. This is dangerous as the "A" revision part
> >
> > > will
> >
> > > >
> >
> > > > call up the same supplier data as the "B" revision part.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > So, If I need the supplier price data to be revision specific how
> >
> > > do
> >
> > > >
> >
> > > > I do it...? The only way I can see is to actually have different
> >
> > > >
> >
> > > > parts in the MPF for the different revisions! This can't be right
> >
> > > can
> >
> > > >
> >
> > > > it...?
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Any help would be gratefully received...
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Thanks,
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Nick
> >
> > > >
> >
> > >
> >
>
No qty breaks is good!

Weird about the no copy/paste... Never ran into that (even with read only columns). Must be something they did to that specific grid control. (It sounds like they made the column you want to copy from inactive - not just readonly.)

I've never tried it on a grid, but you can create a SetExtendedProperties Sub that (on every other type of control) has never failed to allow me to force a normally readonly or inactive control to be editable.

If you have the programming user guide (well worth it if you don't), it explains the syntax pretty well. Not connected to work right now or I could give you a quick example. (Let me know if you need it... Be glad to do so tomorrow.)

Instead of Purchasing advisor (really just a Tracker), maybe you should set up right click menu access (if not already there natively) to Supplier-Part Price list. It would definitely be copyable from there.

If you really want to get slick about it, see what assemblies & business objects are used in supplier-part price list (and data views) & add them to PO Entry. Dateviews can be brought in as foreign key views or using searchbyID VB code... FKVs easier to maintain if you can create a clear path to the right table - often takes several table connections to get to the one you really want (which end up being subtable views from the FKV(s)) - but worth it as then you don't have to worry about code breaking when you upgrade.

Doing this would allow you to make the selection right in PO entry w/ no copy/paste & extra windows open.

(All depends if that is really a time saver in the long haul as nearly all customizations are doomed to break eventually after enough upgrades... Same with BPMs.)

Rob

--- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:
From: alldoneprojects <ramsey@...>
Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
To: vantage@yahoogroups.com
Date: Wednesday, March 11, 2009, 6:58 PM














Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.



So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?



Why the field I need behaves this way yet hundereds of others you can copy??



-Ramsey



--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

>

>

> Hi Ramsey,

>

> The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).

>

> Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.

>

> It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).

>

> Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)

>

> If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.

>

> It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.

>

> Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.

>

> Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.

>

> We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.

>

> The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.

>

> I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.

>

> Rob

>

> --- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:

>

> From: alldoneprojects <ramsey@...>

> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> To: vantage@yahoogroups .com

> Date: Wednesday, March 11, 2009, 9:58 AM

>

>

>

>

>

>

> Hi Rob,

>

> Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.

>

> My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?

>

> We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.

>

> Thanks to you both,

>

> -Ramsey

>

> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

> >

> >

> > Ramsey,

> >

> > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).

> >

> > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).

> >

> > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.

> >

> > Pass on a good word to Nick for me. (Hope that knee is mending well.)

> >

> > Hope that helps

> >

> > Rob

> >

> > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:

> > From: alldoneprojects <ramsey@>

> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> > To: vantage@yahoogroups .com

> > Date: Tuesday, March 10, 2009, 8:41 PM

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> > Hi All,

> >

> >

> >

> > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.

> >

> >

> >

> > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.

> >

> >

> >

> > So it seems I can:

> >

> >

> >

> > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.

> >

> >

> >

> > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?

> >

> >

> >

> > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.

> >

> >

> >

> > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.

> >

> >

> >

> > Cheers,

> >

> >

> >

> > -Ramsey

> >

> >

> >

> > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:

> >

> > >

> >

> > > Rob, don't you ever sleep...!?

> >

> > >

> >

> > > Thanks for the advice, I think this is going to be an area where we

> >

> > > really need to challenge what we are doing, and perhaps take a step

> >

> > > back and look at the process again in more detail.

> >

> > >

> >

> > > I will go through your reply in detail shortly...

> >

> > >

> >

> > > Do you happen to know if the "use part rev" setting in the MPF is

> >

> > > actually of any use...?!

> >

> > >

> >

> > > Also, if you recall my post about the production planner workbench.

> >

> > > Epicor are now looking at this, as the rubbish that this form was

> >

> > > showing is down to a bug... At least I am not going mad! ;o)

> >

> > >

> >

> > > As always, many thanks...

> >

> > >

> >

> > > Nick

> >

> > >

> >

> > >

> >

> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >

> >

> > > wrote:

> >

> > > >

> >

> > > > I think you are over-thinking it and making it more complicated

> >

> > > than it needs to be.

> >

> > > >

> >

> > > > Yes: Your internal Part Rev may be bumped up (and you might have

> >

> > > overlapping approved revs).

> >

> > > >

> >

> > > > You can also have overlapping active Vendor-Part prices lists (each

> >

> > > referencing a vendor p/n and rev if this is needed for your process).

> >

> > > The Buyer would then have to intervene and make sure they are

> >

> > > utilizing the right price list (even if the prices for the different

> >

> > > revs don't differ) just to insure the correct vendor part number/rev

> >

> > > is pulled into the PO Line record.

> >

> > > >

> >

> > > > If that proves unwieldy (or unreliable as people make mistakes) -

> >

> > > consider using a UD field in the vendor price list table to reference

> >

> > > the rev - and then add code to enforce search/selection of the price

> >

> > > list so that price list ud Rev matches your PO Line Part Rev.

> >

> > > >

> >

> > > > If overlapping effective dates of multiple revs is a rare but

> >

> > > necessary evil (and buyers won't necessarily always be purchasing the

> >

> > > latest rev when creating a new PO), you probably need some other more

> >

> > > overt warning mechanism (or the buyer won't even be aware that

> >

> > > multiple approved revs exist - and they need to make a choice).

> >

> > > >

> >

> > > > That overt warning mechanism might be sufficient to simply trigger

> >

> > > a human (trained) process where the vendor p/n is appended by the

> >

> > > buyer to indicate the correct rev (assuming this enables you to stick

> >

> > > with one price-list as the price is no different for either rev).

> >

> > > >

> >

> > > > The 'best' method all depends upon the scope of conditions your

> >

> > > buyers will have to contend with (and how frequently - as if it is

> >

> > > infrequent - they will forget overly complex procedures and goof it

> >

> > > up). That same scope/frequency array should guide you as you decide

> >

> > > on whether a customization is worth the effort (as it will have to be

> >

> > > maintained forever).

> >

> > > >

> >

> > > > Rob Brown

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:

> >

> > > > From: nmtaylor1969 <n.taylor@>

> >

> > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K

> >

> > > > To: vantage@yahoogroups .com

> >

> > > > Date: Thursday, July 31, 2008, 2:45 AM

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Can anybody tell me how I effectively control purchased parts which

> >

> > > >

> >

> > > > are revision controlled. I am unclear about how the supplier price

> >

> > > >

> >

> > > > list accurately reflects the revision of a part.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Imagine the following scenario:-

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > We purchase a bespoke, made to drawing part from a vendor, let's

> >

> > > its

> >

> > > >

> >

> > > > drawing number is "1234/A". As we are a contract manufacturer and

> >

> > > we

> >

> > > >

> >

> > > > therefore make other peoples products, its likely that our MPF part

> >

> > > >

> >

> > > > number and the drawing number for the purchase part will be very

> >

> > > >

> >

> > > > different numbers. Therefore our internal MPF part number might

> >

> > > >

> >

> > > > be "XYZ:"

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Obviously the revision is critical, and it goes without saying that

> >

> > > >

> >

> > > > the correct drawing number must appear on any purchase order etc.

> >

> > > We

> >

> > > >

> >

> > > > must also preserve the revision history and we must ensure that

> >

> > > >

> >

> > > > should we have a need to make a previous revision ( or indeed two

> >

> > > >

> >

> > > > revisions at once ), we can handle this effectively within Vantage.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > We create part "XYZ:" and revision within the MPF, however as

> >

> > > >

> >

> > > > this is a purchased part, there is no real MOM required. Initially

> >

> > > we

> >

> > > >

> >

> > > > create the "A" revision part and approve this. We create an entry

> >

> > > in

> >

> > > >

> >

> > > > the supplier price list to reflect the drawing number of the part,

> >

> > > >

> >

> > > > and therefore we set the supplier part number to "1234/A".

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > We run a number of jobs through the system, and all appears fine.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > However as nothing in life is ever simple, the drawing is modified

> >

> > > >

> >

> > > > and we now require to produce part "1234/B", and just to make

> >

> > > matters

> >

> > > >

> >

> > > > more complicated, there will be an overlap period where "A" and "B"

> >

> > > >

> >

> > > > are both being purchased at the same time.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > It is easy to create a new revision or the part in the MPF, however

> >

> > > >

> >

> > > > the supplier price list data cannot be associated directly with a

> >

> > > >

> >

> > > > part revision. So, I can change the supplier part number

> >

> > > >

> >

> > > > from "1234/A" to "1234/B" but in doing so, I am unable to order

> >

> > > >

> >

> > > > the "A" revision again as the supplier price list entry has been

> >

> > > >

> >

> > > > permanently changed. This is dangerous as the "A" revision part

> >

> > > will

> >

> > > >

> >

> > > > call up the same supplier data as the "B" revision part.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > So, If I need the supplier price data to be revision specific how

> >

> > > do

> >

> > > >

> >

> > > > I do it...? The only way I can see is to actually have different

> >

> > > >

> >

> > > > parts in the MPF for the different revisions! This can't be right

> >

> > > can

> >

> > > >

> >

> > > > it...?

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Any help would be gratefully received...

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Thanks,

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Nick

> >

> > > >

> >

> > >

> >

>
Hi Rob,

Those are some good ideas and I'm into making it slick but for this part my scope is to keep it as vanilla as possible.
Would you say the SetExtendedProperties would be the most upgrade-resistant method? If so an example would be greatly appreciated!

Cheers,

-Ramsey


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
>
> No qty breaks is good!
>
> Weird about the no copy/paste... Never ran into that (even with read only columns). Must be something they did to that specific grid control. (It sounds like they made the column you want to copy from inactive - not just readonly.)
>
> I've never tried it on a grid, but you can create a SetExtendedProperties Sub that (on every other type of control) has never failed to allow me to force a normally readonly or inactive control to be editable.
>
> If you have the programming user guide (well worth it if you don't), it explains the syntax pretty well. Not connected to work right now or I could give you a quick example. (Let me know if you need it... Be glad to do so tomorrow.)
>
> Instead of Purchasing advisor (really just a Tracker), maybe you should set up right click menu access (if not already there natively) to Supplier-Part Price list. It would definitely be copyable from there.
>
> If you really want to get slick about it, see what assemblies & business objects are used in supplier-part price list (and data views) & add them to PO Entry. Dateviews can be brought in as foreign key views or using searchbyID VB code... FKVs easier to maintain if you can create a clear path to the right table - often takes several table connections to get to the one you really want (which end up being subtable views from the FKV(s)) - but worth it as then you don't have to worry about code breaking when you upgrade.
>
> Doing this would allow you to make the selection right in PO entry w/ no copy/paste & extra windows open.
>
> (All depends if that is really a time saver in the long haul as nearly all customizations are doomed to break eventually after enough upgrades... Same with BPMs.)
>
> Rob
>
> --- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:
> From: alldoneprojects <ramsey@...>
> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups.com
> Date: Wednesday, March 11, 2009, 6:58 PM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.
>
>
>
> So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?
>
>
>
> Why the field I need behaves this way yet hundereds of others you can copy??
>
>
>
> -Ramsey
>
>
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> >
>
> >
>
> > Hi Ramsey,
>
> >
>
> > The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).
>
> >
>
> > Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.
>
> >
>
> > It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).
>
> >
>
> > Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)
>
> >
>
> > If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.
>
> >
>
> > It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.
>
> >
>
> > Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.
>
> >
>
> > Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.
>
> >
>
> > We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.
>
> >
>
> > The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.
>
> >
>
> > I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.
>
> >
>
> > Rob
>
> >
>
> > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:
>
> >
>
> > From: alldoneprojects <ramsey@>
>
> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
>
> > To: vantage@yahoogroups .com
>
> > Date: Wednesday, March 11, 2009, 9:58 AM
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Hi Rob,
>
> >
>
> > Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.
>
> >
>
> > My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?
>
> >
>
> > We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.
>
> >
>
> > Thanks to you both,
>
> >
>
> > -Ramsey
>
> >
>
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> > >
>
> > >
>
> > > Ramsey,
>
> > >
>
> > > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).
>
> > >
>
> > > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).
>
> > >
>
> > > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.
>
> > >
>
> > > Pass on a good word to Nick for me. (Hope that knee is mending well.)
>
> > >
>
> > > Hope that helps
>
> > >
>
> > > Rob
>
> > >
>
> > > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:
>
> > > From: alldoneprojects <ramsey@>
>
> > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
>
> > > To: vantage@yahoogroups .com
>
> > > Date: Tuesday, March 10, 2009, 8:41 PM
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > Hi All,
>
> > >
>
> > >
>
> > >
>
> > > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
>
> > >
>
> > >
>
> > >
>
> > > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
>
> > >
>
> > >
>
> > >
>
> > > So it seems I can:
>
> > >
>
> > >
>
> > >
>
> > > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
>
> > >
>
> > >
>
> > >
>
> > > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
>
> > >
>
> > >
>
> > >
>
> > > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
>
> > >
>
> > >
>
> > >
>
> > > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
>
> > >
>
> > >
>
> > >
>
> > > Cheers,
>
> > >
>
> > >
>
> > >
>
> > > -Ramsey
>
> > >
>
> > >
>
> > >
>
> > > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:
>
> > >
>
> > > >
>
> > >
>
> > > > Rob, don't you ever sleep...!?
>
> > >
>
> > > >
>
> > >
>
> > > > Thanks for the advice, I think this is going to be an area where we
>
> > >
>
> > > > really need to challenge what we are doing, and perhaps take a step
>
> > >
>
> > > > back and look at the process again in more detail.
>
> > >
>
> > > >
>
> > >
>
> > > > I will go through your reply in detail shortly...
>
> > >
>
> > > >
>
> > >
>
> > > > Do you happen to know if the "use part rev" setting in the MPF is
>
> > >
>
> > > > actually of any use...?!
>
> > >
>
> > > >
>
> > >
>
> > > > Also, if you recall my post about the production planner workbench.
>
> > >
>
> > > > Epicor are now looking at this, as the rubbish that this form was
>
> > >
>
> > > > showing is down to a bug... At least I am not going mad! ;o)
>
> > >
>
> > > >
>
> > >
>
> > > > As always, many thanks...
>
> > >
>
> > > >
>
> > >
>
> > > > Nick
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
>
> > >
>
> > > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > I think you are over-thinking it and making it more complicated
>
> > >
>
> > > > than it needs to be.
>
> > >
>
> > > > >
>
> > >
>
> > > > > Yes: Your internal Part Rev may be bumped up (and you might have
>
> > >
>
> > > > overlapping approved revs).
>
> > >
>
> > > > >
>
> > >
>
> > > > > You can also have overlapping active Vendor-Part prices lists (each
>
> > >
>
> > > > referencing a vendor p/n and rev if this is needed for your process).
>
> > >
>
> > > > The Buyer would then have to intervene and make sure they are
>
> > >
>
> > > > utilizing the right price list (even if the prices for the different
>
> > >
>
> > > > revs don't differ) just to insure the correct vendor part number/rev
>
> > >
>
> > > > is pulled into the PO Line record.
>
> > >
>
> > > > >
>
> > >
>
> > > > > If that proves unwieldy (or unreliable as people make mistakes) -
>
> > >
>
> > > > consider using a UD field in the vendor price list table to reference
>
> > >
>
> > > > the rev - and then add code to enforce search/selection of the price
>
> > >
>
> > > > list so that price list ud Rev matches your PO Line Part Rev.
>
> > >
>
> > > > >
>
> > >
>
> > > > > If overlapping effective dates of multiple revs is a rare but
>
> > >
>
> > > > necessary evil (and buyers won't necessarily always be purchasing the
>
> > >
>
> > > > latest rev when creating a new PO), you probably need some other more
>
> > >
>
> > > > overt warning mechanism (or the buyer won't even be aware that
>
> > >
>
> > > > multiple approved revs exist - and they need to make a choice).
>
> > >
>
> > > > >
>
> > >
>
> > > > > That overt warning mechanism might be sufficient to simply trigger
>
> > >
>
> > > > a human (trained) process where the vendor p/n is appended by the
>
> > >
>
> > > > buyer to indicate the correct rev (assuming this enables you to stick
>
> > >
>
> > > > with one price-list as the price is no different for either rev).
>
> > >
>
> > > > >
>
> > >
>
> > > > > The 'best' method all depends upon the scope of conditions your
>
> > >
>
> > > > buyers will have to contend with (and how frequently - as if it is
>
> > >
>
> > > > infrequent - they will forget overly complex procedures and goof it
>
> > >
>
> > > > up). That same scope/frequency array should guide you as you decide
>
> > >
>
> > > > on whether a customization is worth the effort (as it will have to be
>
> > >
>
> > > > maintained forever).
>
> > >
>
> > > > >
>
> > >
>
> > > > > Rob Brown
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
>
> > >
>
> > > > > From: nmtaylor1969 <n.taylor@>
>
> > >
>
> > > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
>
> > >
>
> > > > > To: vantage@yahoogroups .com
>
> > >
>
> > > > > Date: Thursday, July 31, 2008, 2:45 AM
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Can anybody tell me how I effectively control purchased parts which
>
> > >
>
> > > > >
>
> > >
>
> > > > > are revision controlled. I am unclear about how the supplier price
>
> > >
>
> > > > >
>
> > >
>
> > > > > list accurately reflects the revision of a part.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Imagine the following scenario:-
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We purchase a bespoke, made to drawing part from a vendor, let's
>
> > >
>
> > > > its
>
> > >
>
> > > > >
>
> > >
>
> > > > > drawing number is "1234/A". As we are a contract manufacturer and
>
> > >
>
> > > > we
>
> > >
>
> > > > >
>
> > >
>
> > > > > therefore make other peoples products, its likely that our MPF part
>
> > >
>
> > > > >
>
> > >
>
> > > > > number and the drawing number for the purchase part will be very
>
> > >
>
> > > > >
>
> > >
>
> > > > > different numbers. Therefore our internal MPF part number might
>
> > >
>
> > > > >
>
> > >
>
> > > > > be "XYZ:"
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Obviously the revision is critical, and it goes without saying that
>
> > >
>
> > > > >
>
> > >
>
> > > > > the correct drawing number must appear on any purchase order etc.
>
> > >
>
> > > > We
>
> > >
>
> > > > >
>
> > >
>
> > > > > must also preserve the revision history and we must ensure that
>
> > >
>
> > > > >
>
> > >
>
> > > > > should we have a need to make a previous revision ( or indeed two
>
> > >
>
> > > > >
>
> > >
>
> > > > > revisions at once ), we can handle this effectively within Vantage.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We create part "XYZ:" and revision within the MPF, however as
>
> > >
>
> > > > >
>
> > >
>
> > > > > this is a purchased part, there is no real MOM required. Initially
>
> > >
>
> > > > we
>
> > >
>
> > > > >
>
> > >
>
> > > > > create the "A" revision part and approve this. We create an entry
>
> > >
>
> > > > in
>
> > >
>
> > > > >
>
> > >
>
> > > > > the supplier price list to reflect the drawing number of the part,
>
> > >
>
> > > > >
>
> > >
>
> > > > > and therefore we set the supplier part number to "1234/A".
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We run a number of jobs through the system, and all appears fine.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > However as nothing in life is ever simple, the drawing is modified
>
> > >
>
> > > > >
>
> > >
>
> > > > > and we now require to produce part "1234/B", and just to make
>
> > >
>
> > > > matters
>
> > >
>
> > > > >
>
> > >
>
> > > > > more complicated, there will be an overlap period where "A" and "B"
>
> > >
>
> > > > >
>
> > >
>
> > > > > are both being purchased at the same time.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > It is easy to create a new revision or the part in the MPF, however
>
> > >
>
> > > > >
>
> > >
>
> > > > > the supplier price list data cannot be associated directly with a
>
> > >
>
> > > > >
>
> > >
>
> > > > > part revision. So, I can change the supplier part number
>
> > >
>
> > > > >
>
> > >
>
> > > > > from "1234/A" to "1234/B" but in doing so, I am unable to order
>
> > >
>
> > > > >
>
> > >
>
> > > > > the "A" revision again as the supplier price list entry has been
>
> > >
>
> > > > >
>
> > >
>
> > > > > permanently changed. This is dangerous as the "A" revision part
>
> > >
>
> > > > will
>
> > >
>
> > > > >
>
> > >
>
> > > > > call up the same supplier data as the "B" revision part.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > So, If I need the supplier price data to be revision specific how
>
> > >
>
> > > > do
>
> > >
>
> > > > >
>
> > >
>
> > > > > I do it...? The only way I can see is to actually have different
>
> > >
>
> > > > >
>
> > >
>
> > > > > parts in the MPF for the different revisions! This can't be right
>
> > >
>
> > > > can
>
> > >
>
> > > > >
>
> > >
>
> > > > > it...?
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Any help would be gratefully received...
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Thanks,
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Nick
>
> > >
>
> > > > >
>
> > >
>
> > > >
>
> > >
>
> >
>
Ramsey,

SetExtendedProperties should be sufficiently 'upgrade-resistant' as it is dealing with the properties of a specific native application dataview column (displayed in a UI control field).

If (or should I say when?) Epicor fundamentally changes a dataview, there is always risk that the dataview.field you are manipulating may have been changed.

However, it is LESS sensitive than direct manipulation of UI control properties as the native controls tend to have much more frequent changes made to the BO/methods tied to them.

Use of VB net before/after BO method event triggers (and, even worse, EpiDateViewNotifications based on record changes) are easily broken - so when ever possible, this 'trigger type' of application behavior modification is better done on the server withs BPMs. (Not always practical unfortunately.)

In the days that have passed, I've kind of lost the thread of what you are doing (but I seem to recall it was a copy/paste issue from a grid control displaying SupplierPriceList data in Purchasing Advisor... Yes?)

I haven't tested, but try this:

In the application module's InitializeCustomCode() Sub, add a call to a SetExtendedProps() Sub as shown below:


Sub InitializeCustomCode()


'// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Variable Intialization' lines **
'// Begin Wizard Added Variable Intialization


'// End Wizard Added Variable Intialization

'// Begin Custom Method Calls

'// End Custom Method Calls

SetExtendedProps()

End Sub

Now create the Sub being called - something like this:

'////////////
Private Sub SetExtendedProps()

Dim edvSupPrcLst As EpiDataView = CType(oTrans.EpiDataViews("SupplierPriceList"), EpiDataView)

If edvSupPrcLst.dataView.Table.Columns.Contains("VendorID") Then

edvSupPrcLst.dataView.Table.Columns("VendorID").ExtendedProperties("ReadOnly") = False
edvSupPrcLst.dataView.Table.Columns("VenPartNum").ExtendedProperties("ReadOnly") = False

End If

End Sub
'///////////

That code should set the VendorID & VenPartNum fields to readonly=false as long as you haven't over-ridden it at the db or BO/method level using user role security.

Give it a go in your test db. As long as the app's controls (or BO/methods) don't get too much in the way, it should work.

If it doesn't work (and sometimes it doesn't - because of those pesky controls), you may have to set up a Sub that is triggered by the event of specific data.column changes in readonly properties. (Custom Object Explorer gives decent basic code examples.)

You can also attempt to use (really - trick) the row rules wizard to get the desired behavior. (Too messy for an email without knowing specifically what you are trying to do.)

The last resort is to manipulate the grid control itself with hand written code - making sure it can be selected by user (CanSelect = true), IsEnabled, etc.,.

...Much messier (if required to 'defeat' the native application behavior)... Try forcing readonly=false 1st - and keep your fingers crossed for luck that it works! (;o

Rob



--- On Thu, 3/12/09, alldoneprojects <ramsey@...> wrote:

From: alldoneprojects <ramsey@...>
Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
To: vantage@yahoogroups.com
Date: Thursday, March 12, 2009, 8:04 PM

Hi Rob,

Those are some good ideas and I'm into making it slick but for this part my scope is to keep it as vanilla as possible.
Would you say the SetExtendedProperti es would be the most upgrade-resistant method? If so an example would be greatly appreciated!

Cheers,

-Ramsey

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
>
> No qty breaks is good!
>
> Weird about the no copy/paste.. . Never ran into that (even with read only columns). Must be something they did to that specific grid control. (It sounds like they made the column you want to copy from inactive - not just readonly.)
>
> I've never tried it on a grid, but you can create a SetExtendedProperti es Sub that (on every other type of control) has never failed to allow me to force a normally readonly or inactive control to be editable.
>
> If you have the programming user guide (well worth it if you don't), it explains the syntax pretty well. Not connected to work right now or I could give you a quick example. (Let me know if you need it... Be glad to do so tomorrow.)
>
> Instead of Purchasing advisor (really just a Tracker), maybe you should set up right click menu access (if not already there natively) to Supplier-Part Price list. It would definitely be copyable from there.
>
> If you really want to get slick about it, see what assemblies & business objects are used in supplier-part price list (and data views) & add them to PO Entry. Dateviews can be brought in as foreign key views or using searchbyID VB code... FKVs easier to maintain if you can create a clear path to the right table - often takes several table connections to get to the one you really want (which end up being subtable views from the FKV(s)) - but worth it as then you don't have to worry about code breaking when you upgrade.
>
> Doing this would allow you to make the selection right in PO entry w/ no copy/paste & extra windows open.
>
> (All depends if that is really a time saver in the long haul as nearly all customizations are doomed to break eventually after enough upgrades... Same with BPMs.)
>
> Rob
>
> --- On Wed, 3/11/09, alldoneprojects <ramsey@...> wrote:
> From: alldoneprojects <ramsey@...>
> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups .com
> Date: Wednesday, March 11, 2009, 6:58 PM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.
>
>
>
> So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?
>
>
>
> Why the field I need behaves this way yet hundereds of others you can copy??
>
>
>
> -Ramsey
>
>
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> >
>
> >
>
> > Hi Ramsey,
>
> >
>
> > The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).
>
> >
>
> > Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.
>
> >
>
> > It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).
>
> >
>
> > Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)
>
> >
>
> > If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.
>
> >
>
> > It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.
>
> >
>
> > Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.
>
> >
>
> > Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.
>
> >
>
> > We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.
>
> >
>
> > The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.
>
> >
>
> > I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.
>
> >
>
> > Rob
>
> >
>
> > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:
>
> >
>
> > From: alldoneprojects <ramsey@>
>
> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
>
> > To: vantage@yahoogroups .com
>
> > Date: Wednesday, March 11, 2009, 9:58 AM
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Hi Rob,
>
> >
>
> > Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.
>
> >
>
> > My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?
>
> >
>
> > We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.
>
> >
>
> > Thanks to you both,
>
> >
>
> > -Ramsey
>
> >
>
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> > >
>
> > >
>
> > > Ramsey,
>
> > >
>
> > > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).
>
> > >
>
> > > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).
>
> > >
>
> > > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.
>
> > >
>
> > > Pass on a good word to Nick for me. (Hope that knee is mending well.)
>
> > >
>
> > > Hope that helps
>
> > >
>
> > > Rob
>
> > >
>
> > > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:
>
> > > From: alldoneprojects <ramsey@>
>
> > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
>
> > > To: vantage@yahoogroups .com
>
> > > Date: Tuesday, March 10, 2009, 8:41 PM
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > Hi All,
>
> > >
>
> > >
>
> > >
>
> > > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
>
> > >
>
> > >
>
> > >
>
> > > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
>
> > >
>
> > >
>
> > >
>
> > > So it seems I can:
>
> > >
>
> > >
>
> > >
>
> > > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
>
> > >
>
> > >
>
> > >
>
> > > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
>
> > >
>
> > >
>
> > >
>
> > > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
>
> > >
>
> > >
>
> > >
>
> > > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
>
> > >
>
> > >
>
> > >
>
> > > Cheers,
>
> > >
>
> > >
>
> > >
>
> > > -Ramsey
>
> > >
>
> > >
>
> > >
>
> > > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:
>
> > >
>
> > > >
>
> > >
>
> > > > Rob, don't you ever sleep...!?
>
> > >
>
> > > >
>
> > >
>
> > > > Thanks for the advice, I think this is going to be an area where we
>
> > >
>
> > > > really need to challenge what we are doing, and perhaps take a step
>
> > >
>
> > > > back and look at the process again in more detail.
>
> > >
>
> > > >
>
> > >
>
> > > > I will go through your reply in detail shortly...
>
> > >
>
> > > >
>
> > >
>
> > > > Do you happen to know if the "use part rev" setting in the MPF is
>
> > >
>
> > > > actually of any use...?!
>
> > >
>
> > > >
>
> > >
>
> > > > Also, if you recall my post about the production planner workbench.
>
> > >
>
> > > > Epicor are now looking at this, as the rubbish that this form was
>
> > >
>
> > > > showing is down to a bug... At least I am not going mad! ;o)
>
> > >
>
> > > >
>
> > >
>
> > > > As always, many thanks...
>
> > >
>
> > > >
>
> > >
>
> > > > Nick
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
>
> > >
>
> > > > wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > I think you are over-thinking it and making it more complicated
>
> > >
>
> > > > than it needs to be.
>
> > >
>
> > > > >
>
> > >
>
> > > > > Yes: Your internal Part Rev may be bumped up (and you might have
>
> > >
>
> > > > overlapping approved revs).
>
> > >
>
> > > > >
>
> > >
>
> > > > > You can also have overlapping active Vendor-Part prices lists (each
>
> > >
>
> > > > referencing a vendor p/n and rev if this is needed for your process).
>
> > >
>
> > > > The Buyer would then have to intervene and make sure they are
>
> > >
>
> > > > utilizing the right price list (even if the prices for the different
>
> > >
>
> > > > revs don't differ) just to insure the correct vendor part number/rev
>
> > >
>
> > > > is pulled into the PO Line record.
>
> > >
>
> > > > >
>
> > >
>
> > > > > If that proves unwieldy (or unreliable as people make mistakes) -
>
> > >
>
> > > > consider using a UD field in the vendor price list table to reference
>
> > >
>
> > > > the rev - and then add code to enforce search/selection of the price
>
> > >
>
> > > > list so that price list ud Rev matches your PO Line Part Rev.
>
> > >
>
> > > > >
>
> > >
>
> > > > > If overlapping effective dates of multiple revs is a rare but
>
> > >
>
> > > > necessary evil (and buyers won't necessarily always be purchasing the
>
> > >
>
> > > > latest rev when creating a new PO), you probably need some other more
>
> > >
>
> > > > overt warning mechanism (or the buyer won't even be aware that
>
> > >
>
> > > > multiple approved revs exist - and they need to make a choice).
>
> > >
>
> > > > >
>
> > >
>
> > > > > That overt warning mechanism might be sufficient to simply trigger
>
> > >
>
> > > > a human (trained) process where the vendor p/n is appended by the
>
> > >
>
> > > > buyer to indicate the correct rev (assuming this enables you to stick
>
> > >
>
> > > > with one price-list as the price is no different for either rev).
>
> > >
>
> > > > >
>
> > >
>
> > > > > The 'best' method all depends upon the scope of conditions your
>
> > >
>
> > > > buyers will have to contend with (and how frequently - as if it is
>
> > >
>
> > > > infrequent - they will forget overly complex procedures and goof it
>
> > >
>
> > > > up). That same scope/frequency array should guide you as you decide
>
> > >
>
> > > > on whether a customization is worth the effort (as it will have to be
>
> > >
>
> > > > maintained forever).
>
> > >
>
> > > > >
>
> > >
>
> > > > > Rob Brown
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
>
> > >
>
> > > > > From: nmtaylor1969 <n.taylor@>
>
> > >
>
> > > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
>
> > >
>
> > > > > To: vantage@yahoogroups .com
>
> > >
>
> > > > > Date: Thursday, July 31, 2008, 2:45 AM
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Can anybody tell me how I effectively control purchased parts which
>
> > >
>
> > > > >
>
> > >
>
> > > > > are revision controlled. I am unclear about how the supplier price
>
> > >
>
> > > > >
>
> > >
>
> > > > > list accurately reflects the revision of a part.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Imagine the following scenario:-
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We purchase a bespoke, made to drawing part from a vendor, let's
>
> > >
>
> > > > its
>
> > >
>
> > > > >
>
> > >
>
> > > > > drawing number is "1234/A". As we are a contract manufacturer and
>
> > >
>
> > > > we
>
> > >
>
> > > > >
>
> > >
>
> > > > > therefore make other peoples products, its likely that our MPF part
>
> > >
>
> > > > >
>
> > >
>
> > > > > number and the drawing number for the purchase part will be very
>
> > >
>
> > > > >
>
> > >
>
> > > > > different numbers. Therefore our internal MPF part number might
>
> > >
>
> > > > >
>
> > >
>
> > > > > be "XYZ:"
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Obviously the revision is critical, and it goes without saying that
>
> > >
>
> > > > >
>
> > >
>
> > > > > the correct drawing number must appear on any purchase order etc.
>
> > >
>
> > > > We
>
> > >
>
> > > > >
>
> > >
>
> > > > > must also preserve the revision history and we must ensure that
>
> > >
>
> > > > >
>
> > >
>
> > > > > should we have a need to make a previous revision ( or indeed two
>
> > >
>
> > > > >
>
> > >
>
> > > > > revisions at once ), we can handle this effectively within Vantage.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We create part "XYZ:" and revision within the MPF, however as
>
> > >
>
> > > > >
>
> > >
>
> > > > > this is a purchased part, there is no real MOM required. Initially
>
> > >
>
> > > > we
>
> > >
>
> > > > >
>
> > >
>
> > > > > create the "A" revision part and approve this. We create an entry
>
> > >
>
> > > > in
>
> > >
>
> > > > >
>
> > >
>
> > > > > the supplier price list to reflect the drawing number of the part,
>
> > >
>
> > > > >
>
> > >
>
> > > > > and therefore we set the supplier part number to "1234/A".
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > We run a number of jobs through the system, and all appears fine.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > However as nothing in life is ever simple, the drawing is modified
>
> > >
>
> > > > >
>
> > >
>
> > > > > and we now require to produce part "1234/B", and just to make
>
> > >
>
> > > > matters
>
> > >
>
> > > > >
>
> > >
>
> > > > > more complicated, there will be an overlap period where "A" and "B"
>
> > >
>
> > > > >
>
> > >
>
> > > > > are both being purchased at the same time.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > It is easy to create a new revision or the part in the MPF, however
>
> > >
>
> > > > >
>
> > >
>
> > > > > the supplier price list data cannot be associated directly with a
>
> > >
>
> > > > >
>
> > >
>
> > > > > part revision. So, I can change the supplier part number
>
> > >
>
> > > > >
>
> > >
>
> > > > > from "1234/A" to "1234/B" but in doing so, I am unable to order
>
> > >
>
> > > > >
>
> > >
>
> > > > > the "A" revision again as the supplier price list entry has been
>
> > >
>
> > > > >
>
> > >
>
> > > > > permanently changed. This is dangerous as the "A" revision part
>
> > >
>
> > > > will
>
> > >
>
> > > > >
>
> > >
>
> > > > > call up the same supplier data as the "B" revision part.
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > So, If I need the supplier price data to be revision specific how
>
> > >
>
> > > > do
>
> > >
>
> > > > >
>
> > >
>
> > > > > I do it...? The only way I can see is to actually have different
>
> > >
>
> > > > >
>
> > >
>
> > > > > parts in the MPF for the different revisions! This can't be right
>
> > >
>
> > > > can
>
> > >
>
> > > > >
>
> > >
>
> > > > > it...?
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Any help would be gratefully received...
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Thanks,
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > Nick
>
> > >
>
> > > > >
>
> > >
>
> > > >
>
> > >
>
> >
>
Hi Rob,

Well, after beating my head against the wall for a while I finally found out this is a known bug:

1139ESC/SCR 48333
3217BRK/SCR 51689
(please chime in to Epicor anybody else that would like this fixed!)

I actually did try to find out more info about this on Epicweb first but due to their (in my opinion) confusing search capabilities I didn't find it before.

So I don't know whether I really ever got your sub set up right with my hack programming skills, but anyway it seems not much to be done.

Many thanks for your example it has given me some useful experience with customizations.

Cheers,

-Ramsey


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
>
> Ramsey,
>
> SetExtendedProperties should be sufficiently 'upgrade-resistant' as it is dealing with the properties of a specific native application dataview column (displayed in a UI control field).
>
> If (or should I say when?) Epicor fundamentally changes a dataview, there is always risk that the dataview.field you are manipulating may have been changed.
>
> However, it is LESS sensitive than direct manipulation of UI control properties as the native controls tend to have much more frequent changes made to the BO/methods tied to them.
>
> Use of VB net before/after BO method event triggers (and, even worse, EpiDateViewNotifications based on record changes) are easily broken - so when ever possible, this 'trigger type' of application behavior modification is better done on the server withs BPMs. (Not always practical unfortunately.)
>
> In the days that have passed, I've kind of lost the thread of what you are doing (but I seem to recall it was a copy/paste issue from a grid control displaying SupplierPriceList data in Purchasing Advisor... Yes?)
>
> I haven't tested, but try this:
>
> In the application module's InitializeCustomCode() Sub, add a call to a SetExtendedProps() Sub as shown below:
>
>
> Sub InitializeCustomCode()
>
>
> '// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Variable Intialization' lines **
> '// Begin Wizard Added Variable Intialization
>
>
> '// End Wizard Added Variable Intialization
>
> '// Begin Custom Method Calls
>
> '// End Custom Method Calls
>
> SetExtendedProps()
>
> End Sub
>
> Now create the Sub being called - something like this:
>
> '////////////
> Private Sub SetExtendedProps()
>
> Dim edvSupPrcLst As EpiDataView = CType(oTrans.EpiDataViews("SupplierPriceList"), EpiDataView)
>
> If edvSupPrcLst.dataView.Table.Columns.Contains("VendorID") Then
>
> edvSupPrcLst.dataView.Table.Columns("VendorID").ExtendedProperties("ReadOnly") = False
> edvSupPrcLst.dataView.Table.Columns("VenPartNum").ExtendedProperties("ReadOnly") = False
>
> End If
>
> End Sub
> '///////////
>
> That code should set the VendorID & VenPartNum fields to readonly=false as long as you haven't over-ridden it at the db or BO/method level using user role security.
>
> Give it a go in your test db. As long as the app's controls (or BO/methods) don't get too much in the way, it should work.
>
> If it doesn't work (and sometimes it doesn't - because of those pesky controls), you may have to set up a Sub that is triggered by the event of specific data.column changes in readonly properties. (Custom Object Explorer gives decent basic code examples.)
>
> You can also attempt to use (really - trick) the row rules wizard to get the desired behavior. (Too messy for an email without knowing specifically what you are trying to do.)
>
> The last resort is to manipulate the grid control itself with hand written code - making sure it can be selected by user (CanSelect = true), IsEnabled, etc.,.
>
> ...Much messier (if required to 'defeat' the native application behavior)... Try forcing readonly=false 1st - and keep your fingers crossed for luck that it works! (;o
>
> Rob
>
>
>
> --- On Thu, 3/12/09, alldoneprojects <ramsey@...> wrote:
>
> From: alldoneprojects <ramsey@...>
> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> To: vantage@yahoogroups.com
> Date: Thursday, March 12, 2009, 8:04 PM
>
> Hi Rob,
>
> Those are some good ideas and I'm into making it slick but for this part my scope is to keep it as vanilla as possible.
> Would you say the SetExtendedProperti es would be the most upgrade-resistant method? If so an example would be greatly appreciated!
>
> Cheers,
>
> -Ramsey
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
> >
> >
> > No qty breaks is good!
> >
> > Weird about the no copy/paste.. . Never ran into that (even with read only columns). Must be something they did to that specific grid control. (It sounds like they made the column you want to copy from inactive - not just readonly.)
> >
> > I've never tried it on a grid, but you can create a SetExtendedProperti es Sub that (on every other type of control) has never failed to allow me to force a normally readonly or inactive control to be editable.
> >
> > If you have the programming user guide (well worth it if you don't), it explains the syntax pretty well. Not connected to work right now or I could give you a quick example. (Let me know if you need it... Be glad to do so tomorrow.)
> >
> > Instead of Purchasing advisor (really just a Tracker), maybe you should set up right click menu access (if not already there natively) to Supplier-Part Price list. It would definitely be copyable from there.
> >
> > If you really want to get slick about it, see what assemblies & business objects are used in supplier-part price list (and data views) & add them to PO Entry. Dateviews can be brought in as foreign key views or using searchbyID VB code... FKVs easier to maintain if you can create a clear path to the right table - often takes several table connections to get to the one you really want (which end up being subtable views from the FKV(s)) - but worth it as then you don't have to worry about code breaking when you upgrade.
> >
> > Doing this would allow you to make the selection right in PO entry w/ no copy/paste & extra windows open.
> >
> > (All depends if that is really a time saver in the long haul as nearly all customizations are doomed to break eventually after enough upgrades... Same with BPMs.)
> >
> > Rob
> >
> > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:
> > From: alldoneprojects <ramsey@>
> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> > To: vantage@yahoogroups .com
> > Date: Wednesday, March 11, 2009, 6:58 PM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.
> >
> >
> >
> > So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?
> >
> >
> >
> > Why the field I need behaves this way yet hundereds of others you can copy??
> >
> >
> >
> > -Ramsey
> >
> >
> >
> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
> >
> > >
> >
> > >
> >
> > > Hi Ramsey,
> >
> > >
> >
> > > The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).
> >
> > >
> >
> > > Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.
> >
> > >
> >
> > > It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).
> >
> > >
> >
> > > Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)
> >
> > >
> >
> > > If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.
> >
> > >
> >
> > > It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.
> >
> > >
> >
> > > Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.
> >
> > >
> >
> > > Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.
> >
> > >
> >
> > > We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.
> >
> > >
> >
> > > The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.
> >
> > >
> >
> > > I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.
> >
> > >
> >
> > > Rob
> >
> > >
> >
> > > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:
> >
> > >
> >
> > > From: alldoneprojects <ramsey@>
> >
> > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> >
> > > To: vantage@yahoogroups .com
> >
> > > Date: Wednesday, March 11, 2009, 9:58 AM
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > Hi Rob,
> >
> > >
> >
> > > Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.
> >
> > >
> >
> > > My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?
> >
> > >
> >
> > > We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.
> >
> > >
> >
> > > Thanks to you both,
> >
> > >
> >
> > > -Ramsey
> >
> > >
> >
> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
> >
> > > >
> >
> > > >
> >
> > > > Ramsey,
> >
> > > >
> >
> > > > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).
> >
> > > >
> >
> > > > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).
> >
> > > >
> >
> > > > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.
> >
> > > >
> >
> > > > Pass on a good word to Nick for me. (Hope that knee is mending well.)
> >
> > > >
> >
> > > > Hope that helps
> >
> > > >
> >
> > > > Rob
> >
> > > >
> >
> > > > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:
> >
> > > > From: alldoneprojects <ramsey@>
> >
> > > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K
> >
> > > > To: vantage@yahoogroups .com
> >
> > > > Date: Tuesday, March 10, 2009, 8:41 PM
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Hi All,
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > So it seems I can:
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Cheers,
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -Ramsey
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Rob, don't you ever sleep...!?
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Thanks for the advice, I think this is going to be an area where we
> >
> > > >
> >
> > > > > really need to challenge what we are doing, and perhaps take a step
> >
> > > >
> >
> > > > > back and look at the process again in more detail.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > I will go through your reply in detail shortly...
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Do you happen to know if the "use part rev" setting in the MPF is
> >
> > > >
> >
> > > > > actually of any use...?!
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Also, if you recall my post about the production planner workbench.
> >
> > > >
> >
> > > > > Epicor are now looking at this, as the rubbish that this form was
> >
> > > >
> >
> > > > > showing is down to a bug... At least I am not going mad! ;o)
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > As always, many thanks...
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Nick
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >
> >
> > > >
> >
> > > > > wrote:
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > I think you are over-thinking it and making it more complicated
> >
> > > >
> >
> > > > > than it needs to be.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Yes: Your internal Part Rev may be bumped up (and you might have
> >
> > > >
> >
> > > > > overlapping approved revs).
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > You can also have overlapping active Vendor-Part prices lists (each
> >
> > > >
> >
> > > > > referencing a vendor p/n and rev if this is needed for your process).
> >
> > > >
> >
> > > > > The Buyer would then have to intervene and make sure they are
> >
> > > >
> >
> > > > > utilizing the right price list (even if the prices for the different
> >
> > > >
> >
> > > > > revs don't differ) just to insure the correct vendor part number/rev
> >
> > > >
> >
> > > > > is pulled into the PO Line record.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > If that proves unwieldy (or unreliable as people make mistakes) -
> >
> > > >
> >
> > > > > consider using a UD field in the vendor price list table to reference
> >
> > > >
> >
> > > > > the rev - and then add code to enforce search/selection of the price
> >
> > > >
> >
> > > > > list so that price list ud Rev matches your PO Line Part Rev.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > If overlapping effective dates of multiple revs is a rare but
> >
> > > >
> >
> > > > > necessary evil (and buyers won't necessarily always be purchasing the
> >
> > > >
> >
> > > > > latest rev when creating a new PO), you probably need some other more
> >
> > > >
> >
> > > > > overt warning mechanism (or the buyer won't even be aware that
> >
> > > >
> >
> > > > > multiple approved revs exist - and they need to make a choice).
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > That overt warning mechanism might be sufficient to simply trigger
> >
> > > >
> >
> > > > > a human (trained) process where the vendor p/n is appended by the
> >
> > > >
> >
> > > > > buyer to indicate the correct rev (assuming this enables you to stick
> >
> > > >
> >
> > > > > with one price-list as the price is no different for either rev).
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > The 'best' method all depends upon the scope of conditions your
> >
> > > >
> >
> > > > > buyers will have to contend with (and how frequently - as if it is
> >
> > > >
> >
> > > > > infrequent - they will forget overly complex procedures and goof it
> >
> > > >
> >
> > > > > up). That same scope/frequency array should guide you as you decide
> >
> > > >
> >
> > > > > on whether a customization is worth the effort (as it will have to be
> >
> > > >
> >
> > > > > maintained forever).
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Rob Brown
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:
> >
> > > >
> >
> > > > > > From: nmtaylor1969 <n.taylor@>
> >
> > > >
> >
> > > > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K
> >
> > > >
> >
> > > > > > To: vantage@yahoogroups .com
> >
> > > >
> >
> > > > > > Date: Thursday, July 31, 2008, 2:45 AM
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Can anybody tell me how I effectively control purchased parts which
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > are revision controlled. I am unclear about how the supplier price
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > list accurately reflects the revision of a part.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Imagine the following scenario:-
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > We purchase a bespoke, made to drawing part from a vendor, let's
> >
> > > >
> >
> > > > > its
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > drawing number is "1234/A". As we are a contract manufacturer and
> >
> > > >
> >
> > > > > we
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > therefore make other peoples products, its likely that our MPF part
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > number and the drawing number for the purchase part will be very
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > different numbers. Therefore our internal MPF part number might
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > be "XYZ:"
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Obviously the revision is critical, and it goes without saying that
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > the correct drawing number must appear on any purchase order etc.
> >
> > > >
> >
> > > > > We
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > must also preserve the revision history and we must ensure that
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > should we have a need to make a previous revision ( or indeed two
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > revisions at once ), we can handle this effectively within Vantage.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > We create part "XYZ:" and revision within the MPF, however as
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > this is a purchased part, there is no real MOM required. Initially
> >
> > > >
> >
> > > > > we
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > create the "A" revision part and approve this. We create an entry
> >
> > > >
> >
> > > > > in
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > the supplier price list to reflect the drawing number of the part,
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > and therefore we set the supplier part number to "1234/A".
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > We run a number of jobs through the system, and all appears fine.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > However as nothing in life is ever simple, the drawing is modified
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > and we now require to produce part "1234/B", and just to make
> >
> > > >
> >
> > > > > matters
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > more complicated, there will be an overlap period where "A" and "B"
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > are both being purchased at the same time.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > It is easy to create a new revision or the part in the MPF, however
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > the supplier price list data cannot be associated directly with a
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > part revision. So, I can change the supplier part number
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > from "1234/A" to "1234/B" but in doing so, I am unable to order
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > the "A" revision again as the supplier price list entry has been
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > permanently changed. This is dangerous as the "A" revision part
> >
> > > >
> >
> > > > > will
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > call up the same supplier data as the "B" revision part.
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > So, If I need the supplier price data to be revision specific how
> >
> > > >
> >
> > > > > do
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > I do it...? The only way I can see is to actually have different
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > parts in the MPF for the different revisions! This can't be right
> >
> > > >
> >
> > > > > can
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > it...?
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Any help would be gratefully received...
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Thanks,
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > Nick
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > >
> >
>
In 8.03, possibly others, when you save the Order or PO detail line the very
first time it also creates a release line. However, if you create a BPM to
fire on Update or GetNewRelease they will not fire for the first release
(until you go in and modify that release after it is saved). However, the
BPM's will fire for every release creation/save after that first one.

Epicor is trying to say that this is as designed. Are there any ideas on how
to create a BPM that will fire on the creation/save of the first release?

If you check the log files you can see that the .getnewrelease is never
called and the .update appears to only be for the detail.



[Non-text portions of this message have been removed]
How about a pre process condition on the update method that is basically: for each ttpodtl where rowmod = 'A'

then enable post process directive as action

in post process you can then work with the ttporel data because it has been created


??


--- In vantage@yahoogroups.com, "Sean McDaniel" <smcdanie@...> wrote:
>
> In 8.03, possibly others, when you save the Order or PO detail line the very
> first time it also creates a release line. However, if you create a BPM to
> fire on Update or GetNewRelease they will not fire for the first release
> (until you go in and modify that release after it is saved). However, the
> BPM's will fire for every release creation/save after that first one.
>
> Epicor is trying to say that this is as designed. Are there any ideas on how
> to create a BPM that will fire on the creation/save of the first release?
>
> If you check the log files you can see that the .getnewrelease is never
> called and the .update appears to only be for the detail.
>
>
>
> [Non-text portions of this message have been removed]
>
Tried pre process and post process and was checking the rowmod condition. The logs told me that the update was called for the deteil but never for the release and the getnewrelease isn't called at all until the second release

-----Original Message-----
From: bw2868bond <bwalker@...>
Sent: Friday, March 20, 2009 7:08 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: BPM for Order/PO First Release -- any ideas?

How about a pre process condition on the update method that is basically: for each ttpodtl where rowmod = 'A'

then enable post process directive as action

in post process you can then work with the ttporel data because it has been created


??


--- In vantage@yahoogroups.com, "Sean McDaniel" <smcdanie@...> wrote:
>
> In 8.03, possibly others, when you save the Order or PO detail line the very
> first time it also creates a release line. However, if you create a BPM to
> fire on Update or GetNewRelease they will not fire for the first release
> (until you go in and modify that release after it is saved). However, the
> BPM's will fire for every release creation/save after that first one.


[The entire original message is not included]
Ramsey.
Sorry you didn't get satisfaction (desired results) - but at least you know you don't have to waste time on it now (with the SCRs pending).

Have you considered upgrading to 4xx? 305 was seriously buggy and brain dead when we were piloting.

305i was I believe our last 305 until jumping to 403C - then quickly 404b prior to going live - only to have to jump to 405a within 2 months to overcome the new wonderful bugs introduced :)

We've stayed on 405a since (?7? months) as it has problems - but we have workarounds.

408 is what we are waiting for (& I'd prefer to wait for a b or c) as it is to contain fixes to some pretty significant global finite scheduling bugs.


Might be worth looking at 4xx. I never hear raves about 406 & 407 - but everyone uses the system differently so problems to others may be non-events for you (and vice-versa of course!)

Rob

--- On Fri, 3/20/09, alldoneprojects <ramsey@...> wrote:
From: alldoneprojects <ramsey@...>
Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K/Purchase advisior can't copy VenPtNum
To: vantage@yahoogroups.com
Date: Friday, March 20, 2009, 3:27 PM












Hi Rob,



Well, after beating my head against the wall for a while I finally found out this is a known bug:



1139ESC/SCR 48333

3217BRK/SCR 51689

(please chime in to Epicor anybody else that would like this fixed!)



I actually did try to find out more info about this on Epicweb first but due to their (in my opinion) confusing search capabilities I didn't find it before.



So I don't know whether I really ever got your sub set up right with my hack programming skills, but anyway it seems not much to be done.



Many thanks for your example it has given me some useful experience with customizations.



Cheers,



-Ramsey



--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

>

>

> Ramsey,

>

> SetExtendedProperti es should be sufficiently 'upgrade-resistant' as it is dealing with the properties of a specific native application dataview column (displayed in a UI control field).

>

> If (or should I say when?) Epicor fundamentally changes a dataview, there is always risk that the dataview.field you are manipulating may have been changed.

>

> However, it is LESS sensitive than direct manipulation of UI control properties as the native controls tend to have much more frequent changes made to the BO/methods tied to them.

>

> Use of VB net before/after BO method event triggers (and, even worse, EpiDateViewNotifica tions based on record changes) are easily broken - so when ever possible, this 'trigger type' of application behavior modification is better done on the server withs BPMs. (Not always practical unfortunately. )

>

> In the days that have passed, I've kind of lost the thread of what you are doing (but I seem to recall it was a copy/paste issue from a grid control displaying SupplierPriceList data in Purchasing Advisor... Yes?)

>

> I haven't tested, but try this:

>

> In the application module's InitializeCustomCod e() Sub, add a call to a SetExtendedProps( ) Sub as shown below:

>

>

> Sub InitializeCustomCod e()

>

>

> '// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Variable Intialization' lines **

> '// Begin Wizard Added Variable Intialization

>

>

> '// End Wizard Added Variable Intialization

>

> '// Begin Custom Method Calls

>

> '// End Custom Method Calls

>

> SetExtendedProps( )

>

> End Sub

>

> Now create the Sub being called - something like this:

>

> '/////////// /

> Private Sub SetExtendedProps( )

>

> Dim edvSupPrcLst As EpiDataView = CType(oTrans. EpiDataViews( "SupplierPriceLi st"), EpiDataView)

>

> If edvSupPrcLst. dataView. Table.Columns. Contains( "VendorID" ) Then

>

> edvSupPrcLst. dataView. Table.Columns( "VendorID" ).ExtendedProper ties("ReadOnly" ) = False

> edvSupPrcLst. dataView. Table.Columns( "VenPartNum" ).ExtendedProper ties("ReadOnly" ) = False

>

> End If

>

> End Sub

> '///////////

>

> That code should set the VendorID & VenPartNum fields to readonly=false as long as you haven't over-ridden it at the db or BO/method level using user role security.

>

> Give it a go in your test db. As long as the app's controls (or BO/methods) don't get too much in the way, it should work.

>

> If it doesn't work (and sometimes it doesn't - because of those pesky controls), you may have to set up a Sub that is triggered by the event of specific data.column changes in readonly properties. (Custom Object Explorer gives decent basic code examples.)

>

> You can also attempt to use (really - trick) the row rules wizard to get the desired behavior. (Too messy for an email without knowing specifically what you are trying to do.)

>

> The last resort is to manipulate the grid control itself with hand written code - making sure it can be selected by user (CanSelect = true), IsEnabled, etc.,.

>

> ...Much messier (if required to 'defeat' the native application behavior)... Try forcing readonly=false 1st - and keep your fingers crossed for luck that it works! (;o

>

> Rob

>

>

>

> --- On Thu, 3/12/09, alldoneprojects <ramsey@...> wrote:

>

> From: alldoneprojects <ramsey@...>

> Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> To: vantage@yahoogroups .com

> Date: Thursday, March 12, 2009, 8:04 PM

>

> Hi Rob,

>

> Those are some good ideas and I'm into making it slick but for this part my scope is to keep it as vanilla as possible.

> Would you say the SetExtendedProperti es would be the most upgrade-resistant method? If so an example would be greatly appreciated!

>

> Cheers,

>

> -Ramsey

>

> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

> >

> >

> > No qty breaks is good!

> >

> > Weird about the no copy/paste.. . Never ran into that (even with read only columns). Must be something they did to that specific grid control. (It sounds like they made the column you want to copy from inactive - not just readonly.)

> >

> > I've never tried it on a grid, but you can create a SetExtendedProperti es Sub that (on every other type of control) has never failed to allow me to force a normally readonly or inactive control to be editable.

> >

> > If you have the programming user guide (well worth it if you don't), it explains the syntax pretty well. Not connected to work right now or I could give you a quick example. (Let me know if you need it... Be glad to do so tomorrow.)

> >

> > Instead of Purchasing advisor (really just a Tracker), maybe you should set up right click menu access (if not already there natively) to Supplier-Part Price list. It would definitely be copyable from there.

> >

> > If you really want to get slick about it, see what assemblies & business objects are used in supplier-part price list (and data views) & add them to PO Entry. Dateviews can be brought in as foreign key views or using searchbyID VB code... FKVs easier to maintain if you can create a clear path to the right table - often takes several table connections to get to the one you really want (which end up being subtable views from the FKV(s)) - but worth it as then you don't have to worry about code breaking when you upgrade.

> >

> > Doing this would allow you to make the selection right in PO entry w/ no copy/paste & extra windows open.

> >

> > (All depends if that is really a time saver in the long haul as nearly all customizations are doomed to break eventually after enough upgrades... Same with BPMs.)

> >

> > Rob

> >

> > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:

> > From: alldoneprojects <ramsey@>

> > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> > To: vantage@yahoogroups .com

> > Date: Wednesday, March 11, 2009, 6:58 PM

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> >

> > Thankfully we don't rely on the price breaks as we in one way or another wind up getting a quote from the supplier for each PO.

> >

> >

> >

> > So, being able to access the supplier price list from Purchase Advisor should suffice for now...BUT, in yet another example of what seems to be attacks aimed directly at me by the developers, you can't copy the Supplier Part Number field from Purchase Advisor! I've gone so far as to cusotmize it visible and not read-only in the grid list (not there at all by default), but you can't copy it from the grid or the detail under it (value shows but it's greyed out) any ideas?

> >

> >

> >

> > Why the field I need behaves this way yet hundereds of others you can copy??

> >

> >

> >

> > -Ramsey

> >

> >

> >

> > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

> >

> > >

> >

> > >

> >

> > > Hi Ramsey,

> >

> > >

> >

> > > The rev control problem is as Nick said: Only really a manual process solution where when an ECN goes out (bumping a Rev), buyers must be on copy so they can review open POs and do a change notice if it is a critical change (or if the supplier can absorb a non-critical change without creating cost-waste for you or them to absorb).

> >

> > >

> >

> > > Same with the Purchase Advisor: No real systemic way to select a supplier part record and then have it update a new PO suggestion in the process of being converted to an approved PO.

> >

> > >

> >

> > > It becomes manual. Convert the suggestion to a PO, then change vendor & insert the appropriate vendor p/n (along with the correct price).

> >

> > >

> >

> > > Note: If you are using qty price breaks in supplier price list this WILL NOT work as the PO Entry business object methods will endlessly recalculate the unit price (and repopulate the vendor p/n) every time you edit the PO - and it takes an alphanumeric ascending record sort approach for 'deciding' which supplier price list to use for a vendor-part when two are active. (I don't recal if this osrt is based on effective date or simply the price list record creation date - but it is a pain in the neck.)

> >

> > >

> >

> > > If you DO have this situation, it get's messy if you really want to do everything IN Vantage. Your (only) option is to modify the effective & discontinue dates of the multiple supplier price lists so they match the specific PO Header Entry date for the price list you want to use.

> >

> > >

> >

> > > It is more trouble than it is worth (for us) & we found it to much non-value added work for buyers to reliaby manage - so we only use qty price break tables on a very small subset of parts where it HELPS us instead of hurts our planning efficiency.

> >

> > >

> >

> > > Perhaps Epicor will hire someone in development who has actually USED these systems and add an option at the PO line to Lock Price.

> >

> > >

> >

> > > Until then, with the frequency PO Entry seems to get rewritten, it is almost impossible to keep any customizations or BPMs to add that capability working.

> >

> > >

> >

> > > We tried: 305 to 404 broke them but we recovered, 404 to 405 broke them and the BO's are now so screwed up we couldn't recover so gave up on it. I have no doubt 406 & 407 would reveal even further changes as PO Entry seems very much a work in progress.

> >

> > >

> >

> > > The data tables reveal lots of 'automated housekeeping' fields - 'housekeeping' in the sense that they auto change manually set prices, etc., - that were unused in early versions & incrementally were implemented for use with each release change. On 405a there are still 'unused' fields that no doubt will eventually be implemented (or have been on 406 or 407) and some underlying BO had to be changed to make it happen.

> >

> > >

> >

> > > I'd keep it simple and assess if the feature is worth using (qty price breaks) in your environment and use offline tools (like a simple Word doc) where it is more trouble than it's worth.

> >

> > >

> >

> > > Rob

> >

> > >

> >

> > > --- On Wed, 3/11/09, alldoneprojects <ramsey@> wrote:

> >

> > >

> >

> > > From: alldoneprojects <ramsey@>

> >

> > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> >

> > > To: vantage@yahoogroups .com

> >

> > > Date: Wednesday, March 11, 2009, 9:58 AM

> >

> > >

> >

> > >

> >

> > >

> >

> > >

> >

> > >

> >

> > >

> >

> > > Hi Rob,

> >

> > >

> >

> > > Now I see that I indeed can have the same part multiple times in the Supplier Price List. I tried it before but just wound up modifiying the existing, but guess I flubbed it somehow.

> >

> > >

> >

> > > My only question now is how to pull in the alternate part number from the Purchase Advisor? I suppose I could customize the grid view and copy/paste from advisor to PO-Lines?

> >

> > >

> >

> > > We're still going to have issues about revisions same as Nick, but at this makes it at least this gets me past one hump.

> >

> > >

> >

> > > Thanks to you both,

> >

> > >

> >

> > > -Ramsey

> >

> > >

> >

> > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:

> >

> > > >

> >

> > > >

> >

> > > > Ramsey,

> >

> > > >

> >

> > > > No reason you can't have multiple price list records for the same supplier and part. (The system doesn't prohibit it.) They can also both be active (no discontinue date and effective dates within 'today's range).

> >

> > > >

> >

> > > > That would allow you to set up supplier A for your partX as both their p/n 'aaa' & 'bbb' (2 records - both active) & for supplier B set up a price list for 'bbb' and 'ccc' (2 more active records).

> >

> > > >

> >

> > > > Generate PO suggestions will choose the primary vendor (if you've set one) and the price list with the earliest effective date - But that is what the purchasing assistant app is for: The Buyer can over-ride what generate PO suggestions suggested when they actually create the PO.

> >

> > > >

> >

> > > > Pass on a good word to Nick for me. (Hope that knee is mending well.)

> >

> > > >

> >

> > > > Hope that helps

> >

> > > >

> >

> > > > Rob

> >

> > > >

> >

> > > > --- On Tue, 3/10/09, alldoneprojects <ramsey@> wrote:

> >

> > > > From: alldoneprojects <ramsey@>

> >

> > > > Subject: [Vantage] Re: Vantage Revision Control In 8.03.305K

> >

> > > > To: vantage@yahoogroups .com

> >

> > > > Date: Tuesday, March 10, 2009, 8:41 PM

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Hi All,

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > I'm faced with a similar situation to Nick so his final solution or other ideas are appreciated.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > For the electronics being manufactured here engineering will pick a component that is manufactured by several places. These components can then in turn be purchased from any number of suppliers that have one or more of the acceptable components. Thus we have a component with in-house p/n of 123 supplier 'A' may stock 'aaa' and 'bbb' which are both acceptable. Supplier 'B' may stock 'bbb' and 'ccc' which are acceptable (of course the supplier p/n that references these parts can be totally random). Depending on lead time and cost at the moment, the purchaser may want to buy from A or B at any given time.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > So it seems I can:

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > -create multiple price lists for a vendor, but I don't really see how to do this without creating a different vendor record (Vendor 123-a, Vendor 123-b). The advantage is that I only have one part number/rev in my part record and BOM.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > -create a part revision for each acceptable part (123 rev A,B,C etc.) And I suppose through some fancy footwork this can be put into the vendor price list/Purchase order (somehow)?

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > -Engineering enters the possible parts in the purchasing comments field and the purchaser has to manually change the supplier part number if the primary (p/n stored in price list) isn't available.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > I can think of many other ways I'd like it to work, but these seem to be the options closest to what is available. My dream is a supplier price list that is more like a matrix with Manufacturer P/N, Supplier and Supplier P/N which may be doable but it seems pretty far off from what's offered in the program. This is version 407.

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > Cheers,

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > -Ramsey

> >

> > > >

> >

> > > >

> >

> > > >

> >

> > > > --- In vantage@yahoogroups .com, "nmtaylor1969" <n.taylor@ .> wrote:

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > Rob, don't you ever sleep...!?

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > Thanks for the advice, I think this is going to be an area where we

> >

> > > >

> >

> > > > > really need to challenge what we are doing, and perhaps take a step

> >

> > > >

> >

> > > > > back and look at the process again in more detail.

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > I will go through your reply in detail shortly...

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > Do you happen to know if the "use part rev" setting in the MPF is

> >

> > > >

> >

> > > > > actually of any use...?!

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > Also, if you recall my post about the production planner workbench.

> >

> > > >

> >

> > > > > Epicor are now looking at this, as the rubbish that this form was

> >

> > > >

> >

> > > > > showing is down to a bug... At least I am not going mad! ;o)

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > As always, many thanks...

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > Nick

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > > > > --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ >

> >

> > > >

> >

> > > > > wrote:

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > I think you are over-thinking it and making it more complicated

> >

> > > >

> >

> > > > > than it needs to be.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Yes: Your internal Part Rev may be bumped up (and you might have

> >

> > > >

> >

> > > > > overlapping approved revs).

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > You can also have overlapping active Vendor-Part prices lists (each

> >

> > > >

> >

> > > > > referencing a vendor p/n and rev if this is needed for your process).

> >

> > > >

> >

> > > > > The Buyer would then have to intervene and make sure they are

> >

> > > >

> >

> > > > > utilizing the right price list (even if the prices for the different

> >

> > > >

> >

> > > > > revs don't differ) just to insure the correct vendor part number/rev

> >

> > > >

> >

> > > > > is pulled into the PO Line record.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > If that proves unwieldy (or unreliable as people make mistakes) -

> >

> > > >

> >

> > > > > consider using a UD field in the vendor price list table to reference

> >

> > > >

> >

> > > > > the rev - and then add code to enforce search/selection of the price

> >

> > > >

> >

> > > > > list so that price list ud Rev matches your PO Line Part Rev.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > If overlapping effective dates of multiple revs is a rare but

> >

> > > >

> >

> > > > > necessary evil (and buyers won't necessarily always be purchasing the

> >

> > > >

> >

> > > > > latest rev when creating a new PO), you probably need some other more

> >

> > > >

> >

> > > > > overt warning mechanism (or the buyer won't even be aware that

> >

> > > >

> >

> > > > > multiple approved revs exist - and they need to make a choice).

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > That overt warning mechanism might be sufficient to simply trigger

> >

> > > >

> >

> > > > > a human (trained) process where the vendor p/n is appended by the

> >

> > > >

> >

> > > > > buyer to indicate the correct rev (assuming this enables you to stick

> >

> > > >

> >

> > > > > with one price-list as the price is no different for either rev).

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > The 'best' method all depends upon the scope of conditions your

> >

> > > >

> >

> > > > > buyers will have to contend with (and how frequently - as if it is

> >

> > > >

> >

> > > > > infrequent - they will forget overly complex procedures and goof it

> >

> > > >

> >

> > > > > up). That same scope/frequency array should guide you as you decide

> >

> > > >

> >

> > > > > on whether a customization is worth the effort (as it will have to be

> >

> > > >

> >

> > > > > maintained forever).

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Rob Brown

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > --- On Thu, 7/31/08, nmtaylor1969 <n.taylor@> wrote:

> >

> > > >

> >

> > > > > > From: nmtaylor1969 <n.taylor@>

> >

> > > >

> >

> > > > > > Subject: [Vantage] Vantage Revision Control In 8.03.305K

> >

> > > >

> >

> > > > > > To: vantage@yahoogroups .com

> >

> > > >

> >

> > > > > > Date: Thursday, July 31, 2008, 2:45 AM

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Can anybody tell me how I effectively control purchased parts which

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > are revision controlled. I am unclear about how the supplier price

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > list accurately reflects the revision of a part.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Imagine the following scenario:-

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > We purchase a bespoke, made to drawing part from a vendor, let's

> >

> > > >

> >

> > > > > its

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > drawing number is "1234/A". As we are a contract manufacturer and

> >

> > > >

> >

> > > > > we

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > therefore make other peoples products, its likely that our MPF part

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > number and the drawing number for the purchase part will be very

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > different numbers. Therefore our internal MPF part number might

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > be "XYZ:"

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Obviously the revision is critical, and it goes without saying that

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > the correct drawing number must appear on any purchase order etc.

> >

> > > >

> >

> > > > > We

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > must also preserve the revision history and we must ensure that

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > should we have a need to make a previous revision ( or indeed two

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > revisions at once ), we can handle this effectively within Vantage.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > We create part "XYZ:" and revision within the MPF, however as

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > this is a purchased part, there is no real MOM required. Initially

> >

> > > >

> >

> > > > > we

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > create the "A" revision part and approve this. We create an entry

> >

> > > >

> >

> > > > > in

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > the supplier price list to reflect the drawing number of the part,

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > and therefore we set the supplier part number to "1234/A".

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > We run a number of jobs through the system, and all appears fine.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > However as nothing in life is ever simple, the drawing is modified

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > and we now require to produce part "1234/B", and just to make

> >

> > > >

> >

> > > > > matters

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > more complicated, there will be an overlap period where "A" and "B"

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > are both being purchased at the same time.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > It is easy to create a new revision or the part in the MPF, however

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > the supplier price list data cannot be associated directly with a

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > part revision. So, I can change the supplier part number

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > from "1234/A" to "1234/B" but in doing so, I am unable to order

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > the "A" revision again as the supplier price list entry has been

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > permanently changed. This is dangerous as the "A" revision part

> >

> > > >

> >

> > > > > will

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > call up the same supplier data as the "B" revision part.

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > So, If I need the supplier price data to be revision specific how

> >

> > > >

> >

> > > > > do

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > I do it...? The only way I can see is to actually have different

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > parts in the MPF for the different revisions! This can't be right

> >

> > > >

> >

> > > > > can

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > it...?

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Any help would be gratefully received...

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Thanks,

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > > > Nick

> >

> > > >

> >

> > > > > >

> >

> > > >

> >

> > > > >

> >

> > > >

> >

> > >

> >

>
Actually we have 407, I just picked up this thread beacause it was a simliar problem.

I'm trying to work with what we have so hopefully we'll stick with this for a while unless this one gets fixed or another major bug comes up.

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
>
> Ramsey.
> Sorry you didn't get satisfaction (desired results) - but at least you know you don't have to waste time on it now (with the SCRs pending).
>
> Have you considered upgrading to 4xx? 305 was seriously buggy and brain dead when we were piloting.
>
> 305i was I believe our last 305 until jumping to 403C - then quickly 404b prior to going live - only to have to jump to 405a within 2 months to overcome the new wonderful bugs introduced :)
>
> We've stayed on 405a since (?7? months) as it has problems - but we have workarounds.
>
> 408 is what we are waiting for (& I'd prefer to wait for a b or c) as it is to contain fixes to some pretty significant global finite scheduling bugs.
>
>
> Might be worth looking at 4xx. I never hear raves about 406 & 407 - but everyone uses the system differently so problems to others may be non-events for you (and vice-versa of course!)
>
> Rob
>
Sean -



Have you tried a post process update on PODetail where RowMod is A and
ttPORel.POLine = 1.

This should catch the first PO Rel being added.



HTH,

CodaBears, Inc.

Calvin Dekker



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Sean McDaniel
Sent: Friday, March 20, 2009 3:16 PM
To: vantage@yahoogroups.com
Subject: [Vantage] BPM for Order/PO First Release -- any ideas?



In 8.03, possibly others, when you save the Order or PO detail line the
very
first time it also creates a release line. However, if you create a BPM
to
fire on Update or GetNewRelease they will not fire for the first release
(until you go in and modify that release after it is saved). However,
the
BPM's will fire for every release creation/save after that first one.

Epicor is trying to say that this is as designed. Are there any ideas on
how
to create a BPM that will fire on the creation/save of the first
release?

If you check the log files you can see that the .getnewrelease is never
called and the .update appears to only be for the detail.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]