Disappearing PartMtl/BOM Entries

Yahoo Archive
1
If it makes you feel any better, I submitted it as an enhancement
request almost 1 yr ago, and it is now slated as an enhancement for
9.1.

Thanks for the BPM suggestion.
Craig

--- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
>
> > Just an FYI... We had similar complaints about materials dropping
off
> > the BOM of jobs, and I learned the hard way that if a material is
> > deleted, it's records in the change log go with it. So don't go
> > looking in the change log to determine how a material got
deleted. I
> > haven't checked the chglog table to see if the records are still
> > there, but you definitely can't look at them in the GUI.
>
> Wow.
>
> <regains composure />
>
> Well, this might be a job for a BPM. You could capture the Update
method and
> log who did what and search for ROWMOD="D" and log that to a file
or even
> send an email. It might be a little more work but you could capture
the
> CheckIn method and you could dump the PartMtl and EcoMtl records to
a file
> as well as the username.
>
> Mark W.
>
2
My engineering folks report to me today that they've seen some
instances of parts "disappearing" off of PartMtl/BOMs for assemblies.

This *could* be pilot error based on what I've heard, as the user
reporting the issue says he didn't verify the part after checkin, and
maybe there was some problem during the Engineering Workbench revision
checkin/approval process. That would be a different issue than things
that were checked in and stable suddenly getting changed.

We don't see any evidence of changes to the Parts in the ChangeLog.

Have folks seen anything similar? This is troubling (and a little
frustrating given that apparently this has been a Known Problem for a
month now!)
3
What version are you on?

Some apps on older versions didn't auto save after apparent record data editing or new entry (as perceived by the user). The user is just seeing the form populated with temp data that hadn't yet been written to the db.

You would have to press save.

Watch the user who reported it repeat their process (more than once). At some point, they will break into an entry/editing pattern different than how they started ("the right way" knowing you are looking over their shoulder). It is perfectly natural for people to do this (always looking for an easier way).

Once you ID the entry/editing sequence that is NOT resulting in a true save, test the theory by having them repeat it exactly, interrupt them and hit refresh. If you've found that right spot, their changes will revert (proving the changes were ever actually saved).

(Sloppy programming on Vantage's part but true - and not uncommon in object oriented interfaces as users always find ways to do things not anticipated by programmers.)

Once you know the spot, enable full tracing and have them repeat up to that same point. Stop and read the trace log to see what the last event was that you can leverage to force on save via an after_event subroutine with a simple otrans.update() statement as its guts.

Easy to overcome via a customization but annoying to track down - and even more annoying still that you have to do Epicor's software QC for them.

Rob



--- On Thu, 10/16/08, Brian W. Spolarich <bspolarich@...> wrote:
From: Brian W. Spolarich <bspolarich@...>
Subject: [Vantage] Disappearing PartMtl/BOM Entries
To: vantage@yahoogroups.com
Date: Thursday, October 16, 2008, 5:46 PM











My engineering folks report to me today that they've seen some

instances of parts "disappearing" off of PartMtl/BOMs for assemblies.



This *could* be pilot error based on what I've heard, as the user

reporting the issue says he didn't verify the part after checkin, and

maybe there was some problem during the Engineering Workbench revision

checkin/approval process. That would be a different issue than things

that were checked in and stable suddenly getting changed.



We don't see any evidence of changes to the Parts in the ChangeLog.



Have folks seen anything similar? This is troubling (and a little

frustrating given that apparently this has been a Known Problem for a

month now!)


























__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
4
We're running 8.03.405 SQL.



Internally we have a similar suspicion, that this is indeed "pilot
error", or at least an unexpected result based on some UI behavior. I'm
going to first suggest that he verify every BOM/PartRev after he commits
it to the system via method tracker to make sure he got what he
expected.



Just wanted to poll this group to see if there's some Known Issue that
we need to be aware of. The notion that Vantage would actually somehow
magically be deleting committed data is a little shocking and dubious,
but it doesn't surprise me if the transaction didn't get saved in the
way the user suspected (the Engineering Workbench is a reasonably
complicated UI and Epicor's QA definitely isn't perfect).



Thanks!



-brian



--

Brian W. Spolarich ~ Manager, Information Services ~ Advanced Photonix /
Picometrix

bspolarich@... ~ 734-864-5618 ~
www.advancedphotonix.com



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Thursday, October 16, 2008 11:55 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Disappearing PartMtl/BOM Entries



What version are you on?

Some apps on older versions didn't auto save after apparent record data
editing or new entry (as perceived by the user). The user is just seeing
the form populated with temp data that hadn't yet been written to the
db.

You would have to press save.

Watch the user who reported it repeat their process (more than once). At
some point, they will break into an entry/editing pattern different than
how they started ("the right way" knowing you are looking over their
shoulder). It is perfectly natural for people to do this (always looking
for an easier way).

Once you ID the entry/editing sequence that is NOT resulting in a true
save, test the theory by having them repeat it exactly, interrupt them
and hit refresh. If you've found that right spot, their changes will
revert (proving the changes were ever actually saved).

(Sloppy programming on Vantage's part but true - and not uncommon in
object oriented interfaces as users always find ways to do things not
anticipated by programmers.)

Once you know the spot, enable full tracing and have them repeat up to
that same point. Stop and read the trace log to see what the last event
was that you can leverage to force on save via an after_event subroutine
with a simple otrans.update() statement as its guts.

Easy to overcome via a customization but annoying to track down - and
even more annoying still that you have to do Epicor's software QC for
them.

Rob

--- On Thu, 10/16/08, Brian W. Spolarich
<bspolarich@...
<mailto:bspolarich%40advancedphotonix.com> > wrote:
From: Brian W. Spolarich <bspolarich@...
<mailto:bspolarich%40advancedphotonix.com> >
Subject: [Vantage] Disappearing PartMtl/BOM Entries
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Date: Thursday, October 16, 2008, 5:46 PM

My engineering folks report to me today that they've seen some

instances of parts "disappearing" off of PartMtl/BOMs for assemblies.

This *could* be pilot error based on what I've heard, as the user

reporting the issue says he didn't verify the part after checkin, and

maybe there was some problem during the Engineering Workbench revision

checkin/approval process. That would be a different issue than things

that were checked in and stable suddenly getting changed.

We don't see any evidence of changes to the Parts in the ChangeLog.

Have folks seen anything similar? This is troubling (and a little

frustrating given that apparently this has been a Known Problem for a

month now!)











__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com





[Non-text portions of this message have been removed]
5
Just an FYI... We had similar complaints about materials dropping off
the BOM of jobs, and I learned the hard way that if a material is
deleted, it's records in the change log go with it. So don't go
looking in the change log to determine how a material got deleted. I
haven't checked the chglog table to see if the records are still
there, but you definitely can't look at them in the GUI.

Craig
--- In vantage@yahoogroups.com, "Brian W. Spolarich "
<bspolarich@...> wrote:
>
> We're running 8.03.405 SQL.
>
>
>
> Internally we have a similar suspicion, that this is indeed "pilot
> error", or at least an unexpected result based on some UI
behavior. I'm
> going to first suggest that he verify every BOM/PartRev after he
commits
> it to the system via method tracker to make sure he got what he
> expected.
>
>
>
> Just wanted to poll this group to see if there's some Known Issue
that
> we need to be aware of. The notion that Vantage would actually
somehow
> magically be deleting committed data is a little shocking and
dubious,
> but it doesn't surprise me if the transaction didn't get saved in
the
> way the user suspected (the Engineering Workbench is a reasonably
> complicated UI and Epicor's QA definitely isn't perfect).
>
>
>
> Thanks!
>
>
>
> -brian
>
>
>
> --
>
> Brian W. Spolarich ~ Manager, Information Services ~ Advanced
Photonix /
> Picometrix
>
> bspolarich@... ~ 734-864-5618 ~
> www.advancedphotonix.com
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Robert Brown
> Sent: Thursday, October 16, 2008 11:55 PM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] Disappearing PartMtl/BOM Entries
>
>
>
> What version are you on?
>
> Some apps on older versions didn't auto save after apparent record
data
> editing or new entry (as perceived by the user). The user is just
seeing
> the form populated with temp data that hadn't yet been written to
the
> db.
>
> You would have to press save.
>
> Watch the user who reported it repeat their process (more than
once). At
> some point, they will break into an entry/editing pattern different
than
> how they started ("the right way" knowing you are looking over their
> shoulder). It is perfectly natural for people to do this (always
looking
> for an easier way).
>
> Once you ID the entry/editing sequence that is NOT resulting in a
true
> save, test the theory by having them repeat it exactly, interrupt
them
> and hit refresh. If you've found that right spot, their changes will
> revert (proving the changes were ever actually saved).
>
> (Sloppy programming on Vantage's part but true - and not uncommon in
> object oriented interfaces as users always find ways to do things
not
> anticipated by programmers.)
>
> Once you know the spot, enable full tracing and have them repeat up
to
> that same point. Stop and read the trace log to see what the last
event
> was that you can leverage to force on save via an after_event
subroutine
> with a simple otrans.update() statement as its guts.
>
> Easy to overcome via a customization but annoying to track down -
and
> even more annoying still that you have to do Epicor's software QC
for
> them.
>
> Rob
>
> --- On Thu, 10/16/08, Brian W. Spolarich
> <bspolarich@...
> <mailto:bspolarich%40advancedphotonix.com> > wrote:
> From: Brian W. Spolarich <bspolarich@...
> <mailto:bspolarich%40advancedphotonix.com> >
> Subject: [Vantage] Disappearing PartMtl/BOM Entries
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Date: Thursday, October 16, 2008, 5:46 PM
>
> My engineering folks report to me today that they've seen some
>
> instances of parts "disappearing" off of PartMtl/BOMs for
assemblies.
>
> This *could* be pilot error based on what I've heard, as the user
>
> reporting the issue says he didn't verify the part after checkin,
and
>
> maybe there was some problem during the Engineering Workbench
revision
>
> checkin/approval process. That would be a different issue than
things
>
> that were checked in and stable suddenly getting changed.
>
> We don't see any evidence of changes to the Parts in the ChangeLog.
>
> Have folks seen anything similar? This is troubling (and a little
>
> frustrating given that apparently this has been a Known Problem for
a
>
> month now!)
>
>
>
>
>
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
6
> Just an FYI... We had similar complaints about materials dropping off
> the BOM of jobs, and I learned the hard way that if a material is
> deleted, it's records in the change log go with it. So don't go
> looking in the change log to determine how a material got deleted. I
> haven't checked the chglog table to see if the records are still
> there, but you definitely can't look at them in the GUI.

Wow.

<regains composure />

Well, this might be a job for a BPM. You could capture the Update method and
log who did what and search for ROWMOD="D" and log that to a file or even
send an email. It might be a little more work but you could capture the
CheckIn method and you could dump the PartMtl and EcoMtl records to a file
as well as the username.

Mark W.