Robert, like always you've offered a wealth of information.
Unfortunately I'm heavy into some other projects and won't be able to
get back on this problem for a couple of weeks. However, I do plan on
getting in their deep once I do and I'll definitely be in touch in the
hopes the "other side" might offer insight for yourself.
Thanks,
Ken
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Monday, August 04, 2008 7:40 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] PO Pricing Order
Ken,
I can't offer any personal knowledge on your specific issue but can
relate a change in behavior in POs in general after upgrading from 305
to 403.
Obvious question first: Are these parts set to purchase direct or are
they general buy to stock parts that on 305 you are were able to force
to behave (perhaps selectively on a requirement by requirement basis)
like a purchase direct part (as needed) by selective editing of job
details?
Similar behavior we've experienced:
Prior to 403, once a price (either from a price list or a manually
over-ridden one time PO line price entry) was entered and the PO
approved, the price was locked in. (As it should be as, once confirmed &
accepted by the vendor, it is a legally binding contract.)
After 305, an approved PO line price would silently change in the
background if:
(1) the buyer edited the order and changed net line qty enough to break
through a price list vendor price tier. (I assume the same would be true
if our vendors used discount tiers but they don't.)
OR
(2) the buyer established a new active price list for that part-vendor &
the effectivity date of the price list overlaps the due dates of any
open releases scheduled for any open PO line for that part-vendor.
This behavior occurs ONLY when the PO is loaded into PO Entry (so it is
clearly a BO method being invoked by the PO Entry client app - and not
some 'housekeeping' server process updating the db).
I ended up putting in a customization to trap the unit price change via
a before change epinotification, temporarily storing the value in an
in-memory variable, and then restoring the unit price value from the
variable after the BO completes its insidious autochange to the unit
price.
I also added a checkbox (defaulted to checked) to allow the user to
'lock the price' by tying full execution of the 'guts' of my price
restoration subroutine to whether the checkbox value is true or false.
When I was doing my precustomization investgation, I also found the PO
tables are littered with fields that (by their naming convention) imply
that they should be holding pre-change price, qty & due date values
after a legitimate user edited change is made. My assumption is that
these structures were intended to enable powerful, desirable (efficient
for both the buyer and vendor) Net Change notices. Unfortunately, all
but one of these fields is little more than dead db space and are never
updated.
There are also a slew of Enable (price update, date update, qty update,
etc.,) named fields in PO Entry's dataviews - That I had hoped could be
manipulated via customization to prevent these 'silent' price list
driven unit price changes from occurring. (They also failed to appear to
have impact on 403+ PO Entry behavior - although I've yet to test 405.)
...Like I said - Not exactly what you are experiencing but suspiciously
similar enough (as it all seems to be price list driven behavior) that
it might help you resolve, or at least understand better, your issue.
If you learn anything, please share... I have a feeling any insights you
gain (coming at it from this 'other direction' of yours) might help us
on our issue (and perhaps lead to either a more efficient customization
or a replacement BPM to overcome the behavior).
Good luck!
Rob Brown
--- On Mon, 8/4/08, Ken Williams <ken@...
<mailto:ken%40intermountainelectronics.com> > wrote:
From: Ken Williams <ken@...
<mailto:ken%40intermountainelectronics.com> >
Subject: [Vantage] PO Pricing Order
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Date: Monday, August 4, 2008, 7:34 PM
We're having an issue where certain parts at the job level get special
pricing and the special pricing isn't pushing through to the PO
suggestion. For example:
1. Enter Job 1111
2. Add Non-Stock item ABWidget @ a price of $300 (ABWidget is setup with
a default supplier & and a price list of $350)
3. Run PO Suggestions
4. Suggestion is to order one @ $350, not $300.
This also happens if the PO is manually tied to the job (bypassing PO
Suggestions) .
I'm not sure when this changed, but this is the status in 403c & 405. I
am quite certain this was not happening in .305, but who knows when it
changed. Can anyone verify this works on a different version level or
am I up in the night? Is there system flag somewhere to take what's on
the job instead of the supplier price list (an override of some sort
perhaps?).
Thanks for any tips,
Ken
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
Unfortunately I'm heavy into some other projects and won't be able to
get back on this problem for a couple of weeks. However, I do plan on
getting in their deep once I do and I'll definitely be in touch in the
hopes the "other side" might offer insight for yourself.
Thanks,
Ken
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Monday, August 04, 2008 7:40 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] PO Pricing Order
Ken,
I can't offer any personal knowledge on your specific issue but can
relate a change in behavior in POs in general after upgrading from 305
to 403.
Obvious question first: Are these parts set to purchase direct or are
they general buy to stock parts that on 305 you are were able to force
to behave (perhaps selectively on a requirement by requirement basis)
like a purchase direct part (as needed) by selective editing of job
details?
Similar behavior we've experienced:
Prior to 403, once a price (either from a price list or a manually
over-ridden one time PO line price entry) was entered and the PO
approved, the price was locked in. (As it should be as, once confirmed &
accepted by the vendor, it is a legally binding contract.)
After 305, an approved PO line price would silently change in the
background if:
(1) the buyer edited the order and changed net line qty enough to break
through a price list vendor price tier. (I assume the same would be true
if our vendors used discount tiers but they don't.)
OR
(2) the buyer established a new active price list for that part-vendor &
the effectivity date of the price list overlaps the due dates of any
open releases scheduled for any open PO line for that part-vendor.
This behavior occurs ONLY when the PO is loaded into PO Entry (so it is
clearly a BO method being invoked by the PO Entry client app - and not
some 'housekeeping' server process updating the db).
I ended up putting in a customization to trap the unit price change via
a before change epinotification, temporarily storing the value in an
in-memory variable, and then restoring the unit price value from the
variable after the BO completes its insidious autochange to the unit
price.
I also added a checkbox (defaulted to checked) to allow the user to
'lock the price' by tying full execution of the 'guts' of my price
restoration subroutine to whether the checkbox value is true or false.
When I was doing my precustomization investgation, I also found the PO
tables are littered with fields that (by their naming convention) imply
that they should be holding pre-change price, qty & due date values
after a legitimate user edited change is made. My assumption is that
these structures were intended to enable powerful, desirable (efficient
for both the buyer and vendor) Net Change notices. Unfortunately, all
but one of these fields is little more than dead db space and are never
updated.
There are also a slew of Enable (price update, date update, qty update,
etc.,) named fields in PO Entry's dataviews - That I had hoped could be
manipulated via customization to prevent these 'silent' price list
driven unit price changes from occurring. (They also failed to appear to
have impact on 403+ PO Entry behavior - although I've yet to test 405.)
...Like I said - Not exactly what you are experiencing but suspiciously
similar enough (as it all seems to be price list driven behavior) that
it might help you resolve, or at least understand better, your issue.
If you learn anything, please share... I have a feeling any insights you
gain (coming at it from this 'other direction' of yours) might help us
on our issue (and perhaps lead to either a more efficient customization
or a replacement BPM to overcome the behavior).
Good luck!
Rob Brown
--- On Mon, 8/4/08, Ken Williams <ken@...
<mailto:ken%40intermountainelectronics.com> > wrote:
From: Ken Williams <ken@...
<mailto:ken%40intermountainelectronics.com> >
Subject: [Vantage] PO Pricing Order
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Date: Monday, August 4, 2008, 7:34 PM
We're having an issue where certain parts at the job level get special
pricing and the special pricing isn't pushing through to the PO
suggestion. For example:
1. Enter Job 1111
2. Add Non-Stock item ABWidget @ a price of $300 (ABWidget is setup with
a default supplier & and a price list of $350)
3. Run PO Suggestions
4. Suggestion is to order one @ $350, not $300.
This also happens if the PO is manually tied to the job (bypassing PO
Suggestions) .
I'm not sure when this changed, but this is the status in 403c & 405. I
am quite certain this was not happening in .305, but who knows when it
changed. Can anyone verify this works on a different version level or
am I up in the night? Is there system flag somewhere to take what's on
the job instead of the supplier price list (an override of some sort
perhaps?).
Thanks for any tips,
Ken
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]