BPM for changing Print Order as flags

Yahoo Archive
1
I reported this problem a long time ago. It used to work and then
it stopped during one of the patches. Even in the help of my
version I think it stated that it would change. The answer to me
was that it is an error in the help file and they will fix the help
file in a later relase. Go figure.
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Well - I can't put it any more bluntly than to say development is
lying to you. It has nothing to do with print performance.
>
> If you look at the table schema that makes up a PO, you'll see it
is littered with fields that hold last price, qty, date, etc., all
the way down to the release level. There are also related boolean
fields that are intended to drive the change notice process. (Did
something change? If so what? - and what did it change from?)
>
> On 403, just enough of these worked to drive the change notice
process.
>
> In 405a, MORE of these fields are finally being populated by the
BO - but a handful of critical ones necessary to really print an
accurate change notice (that were being updated properly on prior
versions 403 & 404) were broken with the fairly significant
underlying code rewrite on 405a.
>
> We had some pretty significant customizations in place on 403 to
compensate for application bugs (U/M's and conversion factors not
being populated, problematic behavior of Misc type lines, no
validation of whether a Part Rev was approved... etc., etc., ad
nauseum). This customization survived the 404 upgrade but completely
broke on 405. This lead to our discovery of just how significant 405
(a) was changed.
>
> Most changes to PO Entry on 405 were for the better... However, as
always seems to be the case, they fixed a half a dozen things and
broke about half that many new things (previously working) in the
process.
>
>
> I've never tried it, but I suppose you could try an after method
event trigger on Epicor.Mfg.BO.ReportMonitor (method Update). Then
look at table.column SysRptLst.RptDescription and if it matches your
PO form's description (I think default is "PURCHASE ORDER"), then
set the POhead field to change notice (for the next time).
>
> Total stab in the dark on my part. Hope it helps in some way.
>
> Rob
>
> --- On Fri, 10/31/08, bw2868bond <bwalker@...> wrote:
>
> From: bw2868bond <bwalker@...>
> Subject: [Vantage] BPM for changing Print Order as flags
> To: vantage@yahoogroups.com
> Date: Friday, October 31, 2008, 8:00 AM
>
>
>
>
>
>
> Vantage 8.00.811 would automatically set the Print Order as
Changed
> flag whenever a printed PO was altered. Vantage 8.0.405 does not.
(we
> never really tested 8.03.305 as it was too buggy so I dont know if
it
> changed there)
>
> I logged a call with support - after being verified and kicked up
to
> development, the response has been:
> "Wanted to let you know that I already received a response from
> development regarding this issue, they responded that as of
8.03.4xx
> this is working as design, Vantage is now leaving this radio
button
> up to the customer."
>
> I suggested that there should be an option in company setup to
allow
> the customer to choose and received this response:
> "Their response is that for printing performance reasons the
design
> was left open for the customer to decide."
>
> I am totally confused by that statement as print as flag is a
boolean
> field that is sent to the Crystal data regardless.
>
> So, with all that off my chest, Has anyone developed a BPM to
> automatically switch the Print as Changed flag when a printed PO
is
> altered that I could use *or* is anyone privy to the logic that
could
> be used to create such a BPM?
>
> How can one tell if a PO has been Printed as New so that when
> something is changed on the PO and it is updated (saved) then the
> Print Order as Changed can be set? I am sure that must have been
done
> in the back end progress procedure running on the server in
8.00.811
>
> ,
> _))._
> /`'---'`\
> | <\ /> |
> | \ ^ / |
> \ '-'-' /
> jgs '--'----'
>
2
Vantage 8.00.811 would automatically set the Print Order as Changed
flag whenever a printed PO was altered. Vantage 8.0.405 does not. (we
never really tested 8.03.305 as it was too buggy so I dont know if it
changed there)

I logged a call with support - after being verified and kicked up to
development, the response has been:
"Wanted to let you know that I already received a response from
development regarding this issue, they responded that as of 8.03.4xx
this is working as design, Vantage is now leaving this radio button
up to the customer."

I suggested that there should be an option in company setup to allow
the customer to choose and received this response:
"Their response is that for printing performance reasons the design
was left open for the customer to decide."

I am totally confused by that statement as print as flag is a boolean
field that is sent to the Crystal data regardless.

So, with all that off my chest, Has anyone developed a BPM to
automatically switch the Print as Changed flag when a printed PO is
altered that I could use *or* is anyone privy to the logic that could
be used to create such a BPM?

How can one tell if a PO has been Printed as New so that when
something is changed on the PO and it is updated (saved) then the
Print Order as Changed can be set? I am sure that must have been done
in the back end progress procedure running on the server in 8.00.811

,
_))._
/`'---'`\
| <\ /> |
| \ ^ / |
\ '-'-' /
jgs '--'----'
3
Well - I can't put it any more bluntly than to say development is lying to you. It has nothing to do with print performance.

If you look at the table schema that makes up a PO, you'll see it is littered with fields that hold last price, qty, date, etc., all the way down to the release level. There are also related boolean fields that are intended to drive the change notice process. (Did something change? If so what? - and what did it change from?)

On 403, just enough of these worked to drive the change notice process.

In 405a, MORE of these fields are finally being populated by the BO - but a handful of critical ones necessary to really print an accurate change notice (that were being updated properly on prior versions 403 & 404) were broken with the fairly significant underlying code rewrite on 405a.

We had some pretty significant customizations in place on 403 to compensate for application bugs (U/M's and conversion factors not being populated, problematic behavior of Misc type lines, no validation of whether a Part Rev was approved... etc., etc., ad nauseum). This customization survived the 404 upgrade but completely broke on 405. This lead to our discovery of just how significant 405(a) was changed.

Most changes to PO Entry on 405 were for the better... However, as always seems to be the case, they fixed a half a dozen things and broke about half that many new things (previously working) in the process.


I've never tried it, but I suppose you could try an after method event trigger on Epicor.Mfg.BO.ReportMonitor (method Update). Then look at table.column SysRptLst.RptDescription and if it matches your PO form's description (I think default is "PURCHASE ORDER"), then set the POhead field to change notice (for the next time).

Total stab in the dark on my part. Hope it helps in some way.

Rob

--- On Fri, 10/31/08, bw2868bond <bwalker@...> wrote:

From: bw2868bond <bwalker@...>
Subject: [Vantage] BPM for changing Print Order as flags
To: vantage@yahoogroups.com
Date: Friday, October 31, 2008, 8:00 AM






Vantage 8.00.811 would automatically set the Print Order as Changed
flag whenever a printed PO was altered. Vantage 8.0.405 does not. (we
never really tested 8.03.305 as it was too buggy so I dont know if it
changed there)

I logged a call with support - after being verified and kicked up to
development, the response has been:
"Wanted to let you know that I already received a response from
development regarding this issue, they responded that as of 8.03.4xx
this is working as design, Vantage is now leaving this radio button
up to the customer."

I suggested that there should be an option in company setup to allow
the customer to choose and received this response:
"Their response is that for printing performance reasons the design
was left open for the customer to decide."

I am totally confused by that statement as print as flag is a boolean
field that is sent to the Crystal data regardless.

So, with all that off my chest, Has anyone developed a BPM to
automatically switch the Print as Changed flag when a printed PO is
altered that I could use *or* is anyone privy to the logic that could
be used to create such a BPM?

How can one tell if a PO has been Printed as New so that when
something is changed on the PO and it is updated (saved) then the
Print Order as Changed can be set? I am sure that must have been done
in the back end progress procedure running on the server in 8.00.811

,
_))._
/`'---'`\
| <\ /> |
| \ ^ / |
\ '-'-' /
jgs '--'----'