Customer Character02 and Character03 erased unintentionally

Gotcha Randy... When it messes with people's money, they want better answers!

I hope you do find something in the SCRs and release change notes... Knowing how vague they can be though - ugh!

Epicor support will never tell (even if they know) once they know you have already upgraded and resolved (that's for sure!)

Since all you were/are doing is displaying the fields in disabled controls, it had to have been a flaw in either a native control (invoking some misguided BO method action) or a flawed app BO method itself in 407A.

(My sympathies!)

Have a good weekend.

Rob Brown




________________________________
From: Randy Weber <rweber@...>
To: vantage@yahoogroups.com
Sent: Thursday, June 4, 2009 9:13:51 AM
Subject: RE: [Vantage] Customer Character02 and Character03 erased unintentionally





Were on Version 803.407C now, but were at 803.407A part of the time when
this occurred. Using Progress.

The table is Customer and the only customization on the form is
employing user defined fields. In this case, the fields in question were
visible but disabled. In the change log, there are a number of instances
where the Character02- 03 fields had been cleared and I am sure that the
user did not intend to change this field. I was the user in some cases.

Why I want to know? These fields are used to calculate commissions, and
it took me an entire day to recover the information. Our sales people
were not happy when I informed them that their April commission checks
were short. Though we recovered, I'd feel better having a clear
explanation rather than just 'glitch'.

I'll check out the SCRs and release notes.

Thanks,

Randy Weber

From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
Of Robert Brown
Sent: Thursday, June 04, 2009 12:09 AM
To: vantage@yahoogroups .com
Subject: Re: [Vantage] Customer Character02 and Character03 erased
unintentionally

What version? SQL or Progress? What table(s) are Char02 & 03 (and what
app is your editing point) in relative to the customer credit limit
field? Do you have an non-basic modules installed that relate to the
troublesome app(s)?

We just learned (405a, Progress, with AMM) that for PO change log
records, if you delete a PO line, the geniuses at Epicor wrote the BO
method so that it also goes and deletes all change log records for any
fields being logged for the PO line. (All history is lost... No way to
know who/when a line was created, changed in any way and ultimately
deleted.)

You may have similar issues foiling your attempt to trace what happened
and when. (At least a log entry might help you determine if it was a
manager process - BPM or some scheduled task - that did the damage
versus a human entry problem.)

We're a year live & have found some of the app BO methods have an ugly
habit of both temporarily enabling (or disabling) certain fields upon
execution - so it IS possible for users to inadvertently do something
you didn't intend to be possible.

You clearly customized (or the fields wouldn't even be displayed - via
disabled controls or not). Are your client customizations more than just
cosmetic? (Are they changing the behavior of the app(s) involved or
adding behavior(s) not in the base app?) If so, check your code as the
customization may have been the culprit.

It's not the form itself but whatever BO method(s) get executed when you
change the credit limit that might have contained a flaw prior to your
bumping up to your current patch level (assuming for sure that the
credit limit change really is related and not coincidental) .

In the end, if you can't recreate on the current release you're on, does
it matter?

If you MUST know, scour Epicor's site for release change notes (vague
though they often are) that might hint at a flaw on the release you went
live with. (Release notes up to your current release might refer to
something that catches your eye.) I'd also check SCR's to see if someone
else reported something similar.

Welcome to Epicor! (:o

Seriously, with more detail (even post your customization code), you
have an even odds shot of someone on the Yahoo VUG knowing (or having) a
similar experience.

This group has never let me down (and sometimes "no one knows" is an
important clue) so, with enough detail we'll aim to please.

Rob Brown

____________ _________ _________ __
From: Randy <rweber@tlcelectroni cs.com
<mailto:rweber% 40tlcelectronics .com> >
To: vantage@yahoogroups .com <mailto:vantage% 40yahoogroups. com>
Sent: Wednesday, June 3, 2009 2:04:37 PM
Subject: [Vantage] Customer Character02 and Character03 erased
unintentionally

We use the user defined fields; Character02 and Character03
in the customer table to track inside and outside sales people.

We just discovered that the data in those fields had been erased
while editing a different field. For example, when we increased the
credit limit on a customer, the change log also shows Character02
changed from John Doe to an empty_string, though the user definitely
did not change that field. I know this because the customer form has
those fields disabled.

This happened on various dates in April and May. We went live on
March 29th.

I haven't been able to recreate the error, but we have patched
since then so it's hard to tell.

Does anybody know of a bug that might have caused this?

Are there any other fields that also could have been effected?

Could a poorly designed form cause an error like this?

Thanks in advance,

Randy Weber

[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]
We use the user defined fields; Character02 and Character03
in the customer table to track inside and outside sales people.

We just discovered that the data in those fields had been erased
while editing a different field. For example, when we increased the
credit limit on a customer, the change log also shows Character02
changed from John Doe to an empty_string, though the user definitely
did not change that field. I know this because the customer form has
those fields disabled.

This happened on various dates in April and May. We went live on
March 29th.

I haven't been able to recreate the error, but we have patched
since then so it's hard to tell.

Does anybody know of a bug that might have caused this?

Are there any other fields that also could have been effected?

Could a poorly designed form cause an error like this?

Thanks in advance,

Randy Weber
What version? SQL or Progress? What table(s) are Char02 & 03 (and what app is your editing point) in relative to the customer credit limit field? Do you have an non-basic modules installed that relate to the troublesome app(s)?

We just learned (405a, Progress, with AMM) that for PO change log records, if you delete a PO line, the geniuses at Epicor wrote the BO method so that it also goes and deletes all change log records for any fields being logged for the PO line. (All history is lost... No way to know who/when a line was created, changed in any way and ultimately deleted.)

You may have similar issues foiling your attempt to trace what happened and when. (At least a log entry might help you determine if it was a manager process - BPM or some scheduled task - that did the damage versus a human entry problem.)

We're a year live & have found some of the app BO methods have an ugly habit of both temporarily enabling (or disabling) certain fields upon execution - so it IS possible for users to inadvertently do something you didn't intend to be possible.

You clearly customized (or the fields wouldn't even be displayed - via disabled controls or not). Are your client customizations more than just cosmetic? (Are they changing the behavior of the app(s) involved or adding behavior(s) not in the base app?) If so, check your code as the customization may have been the culprit.

It's not the form itself but whatever BO method(s) get executed when you change the credit limit that might have contained a flaw prior to your bumping up to your current patch level (assuming for sure that the credit limit change really is related and not coincidental).

In the end, if you can't recreate on the current release you're on, does it matter?

If you MUST know, scour Epicor's site for release change notes (vague though they often are) that might hint at a flaw on the release you went live with. (Release notes up to your current release might refer to something that catches your eye.) I'd also check SCR's to see if someone else reported something similar.

Welcome to Epicor! (:o

Seriously, with more detail (even post your customization code), you have an even odds shot of someone on the Yahoo VUG knowing (or having) a similar experience.

This group has never let me down (and sometimes "no one knows" is an important clue) so, with enough detail we'll aim to please.

Rob Brown









________________________________
From: Randy <rweber@...>
To: vantage@yahoogroups.com
Sent: Wednesday, June 3, 2009 2:04:37 PM
Subject: [Vantage] Customer Character02 and Character03 erased unintentionally





We use the user defined fields; Character02 and Character03
in the customer table to track inside and outside sales people.

We just discovered that the data in those fields had been erased
while editing a different field. For example, when we increased the
credit limit on a customer, the change log also shows Character02
changed from John Doe to an empty_string, though the user definitely
did not change that field. I know this because the customer form has
those fields disabled.

This happened on various dates in April and May. We went live on
March 29th.

I haven't been able to recreate the error, but we have patched
since then so it's hard to tell.

Does anybody know of a bug that might have caused this?

Are there any other fields that also could have been effected?

Could a poorly designed form cause an error like this?

Thanks in advance,

Randy Weber







[Non-text portions of this message have been removed]
Were on Version 803.407C now, but were at 803.407A part of the time when
this occurred. Using Progress.



The table is Customer and the only customization on the form is
employing user defined fields. In this case, the fields in question were
visible but disabled. In the change log, there are a number of instances
where the Character02-03 fields had been cleared and I am sure that the
user did not intend to change this field. I was the user in some cases.



Why I want to know? These fields are used to calculate commissions, and
it took me an entire day to recover the information. Our sales people
were not happy when I informed them that their April commission checks
were short. Though we recovered, I'd feel better having a clear
explanation rather than just 'glitch'.



I'll check out the SCRs and release notes.



Thanks,



Randy Weber



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Thursday, June 04, 2009 12:09 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Customer Character02 and Character03 erased
unintentionally








What version? SQL or Progress? What table(s) are Char02 & 03 (and what
app is your editing point) in relative to the customer credit limit
field? Do you have an non-basic modules installed that relate to the
troublesome app(s)?

We just learned (405a, Progress, with AMM) that for PO change log
records, if you delete a PO line, the geniuses at Epicor wrote the BO
method so that it also goes and deletes all change log records for any
fields being logged for the PO line. (All history is lost... No way to
know who/when a line was created, changed in any way and ultimately
deleted.)

You may have similar issues foiling your attempt to trace what happened
and when. (At least a log entry might help you determine if it was a
manager process - BPM or some scheduled task - that did the damage
versus a human entry problem.)

We're a year live & have found some of the app BO methods have an ugly
habit of both temporarily enabling (or disabling) certain fields upon
execution - so it IS possible for users to inadvertently do something
you didn't intend to be possible.

You clearly customized (or the fields wouldn't even be displayed - via
disabled controls or not). Are your client customizations more than just
cosmetic? (Are they changing the behavior of the app(s) involved or
adding behavior(s) not in the base app?) If so, check your code as the
customization may have been the culprit.

It's not the form itself but whatever BO method(s) get executed when you
change the credit limit that might have contained a flaw prior to your
bumping up to your current patch level (assuming for sure that the
credit limit change really is related and not coincidental).

In the end, if you can't recreate on the current release you're on, does
it matter?

If you MUST know, scour Epicor's site for release change notes (vague
though they often are) that might hint at a flaw on the release you went
live with. (Release notes up to your current release might refer to
something that catches your eye.) I'd also check SCR's to see if someone
else reported something similar.

Welcome to Epicor! (:o

Seriously, with more detail (even post your customization code), you
have an even odds shot of someone on the Yahoo VUG knowing (or having) a
similar experience.

This group has never let me down (and sometimes "no one knows" is an
important clue) so, with enough detail we'll aim to please.

Rob Brown

________________________________
From: Randy <rweber@...
<mailto:rweber%40tlcelectronics.com> >
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Sent: Wednesday, June 3, 2009 2:04:37 PM
Subject: [Vantage] Customer Character02 and Character03 erased
unintentionally

We use the user defined fields; Character02 and Character03
in the customer table to track inside and outside sales people.

We just discovered that the data in those fields had been erased
while editing a different field. For example, when we increased the
credit limit on a customer, the change log also shows Character02
changed from John Doe to an empty_string, though the user definitely
did not change that field. I know this because the customer form has
those fields disabled.

This happened on various dates in April and May. We went live on
March 29th.

I haven't been able to recreate the error, but we have patched
since then so it's hard to tell.

Does anybody know of a bug that might have caused this?

Are there any other fields that also could have been effected?

Could a poorly designed form cause an error like this?

Thanks in advance,

Randy Weber

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





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