Update UD Field ONCE Only

system · May 31, 2012, 11:24am

Hi Steven -

Thanks on this. As per my earlier post, I thought that I had it nailed with Customization, but it's still not quite right.

I may turn to your BPM idea if I can't tweak it ----

Thanks for the tip -
Laraine

--- In vantage@yahoogroups.com, Steven Gotschall <sgotschall@...> wrote:
>
> I have the same situation.Ã‚Â I use a BPM to copy the original reqdate to a UD field.Ã‚Â The BPM checks to see if the UD field has anything in it, if it doesn't it copies the reqdate to it.Ã‚Â This way, only the original reqdate is saved and never overwritten.
> Ã‚Â
> Steven G.
>
>
> ________________________________
> From: laraines422 <laraines422@...>
> To: vantage@yahoogroups.com
> Sent: Wednesday, May 30, 2012 2:26 PM
> Subject: [Vantage] Update UD Field ONCE Only
>
>
> Ã‚Â
> Hi All,
>
> I give up! I've searched through this site and EpicWeb, and I'm coming up blank for ideas.
>
> Here is my challenge:
> 1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK, because our Production can't seem to commit to firm completion dates (but that's a different issue).
> 2. Again, it's OK that the ReqDate is changed, but we want to track the FIRST/INITIAL "ReqDate" - we want a static date to measure our performance. (We do use the "dynamic" ReqDate for other reporting.)
> 3. No problem so far with this - I'm populating OrderRel.Date01 with the OrderRel.ReqDate with a Form Event in Customization.
>
> The question is: how do I lock down OrderRel.Date01 after it's initially populated? Obviously - with only the code in #3 applied, Date01 changes as ReqDate is changed - which defeats the purpose (I don't want the User to change this field). Do I add code in the customization, to look at the Date01 field to see if it's already populated? I also thought about a Row Rule - but the logic didn't seem to be appropriate to allow to populate on the first pass and then not to allow to populate for anything later. Or do I create a BPM at Sales Order Update? It seems like the former would be simpler (I did putz around with this), but I'm OK with a BPM, too - my code writing for both is equally weak and suspect. :-)
>
> If it matters - we're on Vantage 8.03.407c...
>
> Thanks in advance -
> Laraine
>
>
>
>
> [Non-text portions of this message have been removed]
>

system · May 30, 2012, 2:26pm

Hi All,

I give up! I've searched through this site and EpicWeb, and I'm coming up blank for ideas.

Here is my challenge:
1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK, because our Production can't seem to commit to firm completion dates (but that's a different issue).
2. Again, it's OK that the ReqDate is changed, but we want to track the FIRST/INITIAL "ReqDate" - we want a static date to measure our performance. (We do use the "dynamic" ReqDate for other reporting.)
3. No problem so far with this - I'm populating OrderRel.Date01 with the OrderRel.ReqDate with a Form Event in Customization.

The question is: how do I lock down OrderRel.Date01 after it's initially populated? Obviously - with only the code in #3 applied, Date01 changes as ReqDate is changed - which defeats the purpose (I don't want the User to change this field). Do I add code in the customization, to look at the Date01 field to see if it's already populated? I also thought about a Row Rule - but the logic didn't seem to be appropriate to allow to populate on the first pass and then not to allow to populate for anything later. Or do I create a BPM at Sales Order Update? It seems like the former would be simpler (I did putz around with this), but I'm OK with a BPM, too - my code writing for both is equally weak and suspect. :-)

If it matters - we're on Vantage 8.03.407c...

Thanks in advance -
Laraine

system · May 30, 2012, 3:33pm

Change the code in step three to not update date01 if it already has
something in it. Tada!

On Wed, May 30, 2012 at 2:26 PM, laraines422 <laraines422@...> wrote:

> **
>
>
> Hi All,
>
> I give up! I've searched through this site and EpicWeb, and I'm coming up
> blank for ideas.
>
> Here is my challenge:
> 1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK,
> because our Production can't seem to commit to firm completion dates (but
> that's a different issue).
> 2. Again, it's OK that the ReqDate is changed, but we want to track the
> FIRST/INITIAL "ReqDate" - we want a static date to measure our performance.
> (We do use the "dynamic" ReqDate for other reporting.)
> 3. No problem so far with this - I'm populating OrderRel.Date01 with the
> OrderRel.ReqDate with a Form Event in Customization.
>
> The question is: how do I lock down OrderRel.Date01 after it's initially
> populated? Obviously - with only the code in #3 applied, Date01 changes as
> ReqDate is changed - which defeats the purpose (I don't want the User to
> change this field). Do I add code in the customization, to look at the
> Date01 field to see if it's already populated? I also thought about a Row
> Rule - but the logic didn't seem to be appropriate to allow to populate on
> the first pass and then not to allow to populate for anything later. Or do
> I create a BPM at Sales Order Update? It seems like the former would be
> simpler (I did putz around with this), but I'm OK with a BPM, too - my code
> writing for both is equally weak and suspect. :-)
>
> If it matters - we're on Vantage 8.03.407c...
>
> Thanks in advance -
> Laraine
>
>
>

--
*John Driggers*
*High End Dev, System Design, Profit Drinking*
*
**:: 904.404.9233*
*:: waffqle@...*
*:: NO FAXES*

*

*

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

system · May 30, 2012, 3:35pm

Sent that last one a bit quicker than I intended to. Just wrap a little if
statement around the code where you assign date01. Something like the
following:

if (row["Date01"] == null)
{
row["Date01"] = <my ReqDate>;
}

On Wed, May 30, 2012 at 3:33 PM, John Driggers <waffqle@...> wrote:

> Change the code in step three to not update date01 if it already has
> something in it. Tada!
>
>
> On Wed, May 30, 2012 at 2:26 PM, laraines422 <laraines422@...>wrote:
>
>> **
>>
>>
>> Hi All,
>>
>> I give up! I've searched through this site and EpicWeb, and I'm coming up
>> blank for ideas.
>>
>> Here is my challenge:
>> 1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK,
>> because our Production can't seem to commit to firm completion dates (but
>> that's a different issue).
>> 2. Again, it's OK that the ReqDate is changed, but we want to track the
>> FIRST/INITIAL "ReqDate" - we want a static date to measure our performance.
>> (We do use the "dynamic" ReqDate for other reporting.)
>> 3. No problem so far with this - I'm populating OrderRel.Date01 with the
>> OrderRel.ReqDate with a Form Event in Customization.
>>
>> The question is: how do I lock down OrderRel.Date01 after it's initially
>> populated? Obviously - with only the code in #3 applied, Date01 changes as
>> ReqDate is changed - which defeats the purpose (I don't want the User to
>> change this field). Do I add code in the customization, to look at the
>> Date01 field to see if it's already populated? I also thought about a Row
>> Rule - but the logic didn't seem to be appropriate to allow to populate on
>> the first pass and then not to allow to populate for anything later. Or do
>> I create a BPM at Sales Order Update? It seems like the former would be
>> simpler (I did putz around with this), but I'm OK with a BPM, too - my code
>> writing for both is equally weak and suspect. :-)
>>
>> If it matters - we're on Vantage 8.03.407c...
>>
>> Thanks in advance -
>> Laraine
>>
>>
>>
>
>
>
> --
> *John Driggers*
> *High End Dev, System Design, Profit Drinking*
> *
> **:: 904.404.9233*
> *:: waffqle@...*
> *:: NO FAXES*
>
> *
>
> *
>
>

--
*John Driggers*
*High End Dev, System Design, Profit Drinking*
*
**:: 904.404.9233*
*:: waffqle@...*
*:: NO FAXES*

*

*

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

system · May 30, 2012, 7:16pm

Hi John,

Thanks for the tip! It set me on the right path - here's the final code:

>Case "ReqDate"

>if (edv.dataView(edv.Row)("Date01").ToString() = "") Then
>edv.dataView(edv.Row)("Date01") = edv.dataView(edv.Row)("ReqDate")
>end if

I had to add the ".ToString()", because it didn't like "null", or "" on its own, etc. I'm not sure if its the Date01 data format, or the customization element or what - I'm just glad that it finally works!!

Thanks again for pointing the way -
Laraine

--- In vantage@yahoogroups.com, John Driggers <waffqle@...> wrote:
>
> Sent that last one a bit quicker than I intended to. Just wrap a little if
> statement around the code where you assign date01. Something like the
> following:
>
> if (row["Date01"] == null)
> {
> row["Date01"] = <my ReqDate>;
> }
>
>
>
>
> On Wed, May 30, 2012 at 3:33 PM, John Driggers <waffqle@...> wrote:
>
> > Change the code in step three to not update date01 if it already has
> > something in it. Tada!
> >
> >
> > On Wed, May 30, 2012 at 2:26 PM, laraines422 <laraines422@...>wrote:
> >
> >> **
> >>
> >>
> >> Hi All,
> >>
> >> I give up! I've searched through this site and EpicWeb, and I'm coming up
> >> blank for ideas.
> >>
> >> Here is my challenge:
> >> 1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK,
> >> because our Production can't seem to commit to firm completion dates (but
> >> that's a different issue).
> >> 2. Again, it's OK that the ReqDate is changed, but we want to track the
> >> FIRST/INITIAL "ReqDate" - we want a static date to measure our performance.
> >> (We do use the "dynamic" ReqDate for other reporting.)
> >> 3. No problem so far with this - I'm populating OrderRel.Date01 with the
> >> OrderRel.ReqDate with a Form Event in Customization.
> >>
> >> The question is: how do I lock down OrderRel.Date01 after it's initially
> >> populated? Obviously - with only the code in #3 applied, Date01 changes as
> >> ReqDate is changed - which defeats the purpose (I don't want the User to
> >> change this field). Do I add code in the customization, to look at the
> >> Date01 field to see if it's already populated? I also thought about a Row
> >> Rule - but the logic didn't seem to be appropriate to allow to populate on
> >> the first pass and then not to allow to populate for anything later. Or do
> >> I create a BPM at Sales Order Update? It seems like the former would be
> >> simpler (I did putz around with this), but I'm OK with a BPM, too - my code
> >> writing for both is equally weak and suspect. :-)
> >>
> >> If it matters - we're on Vantage 8.03.407c...
> >>
> >> Thanks in advance -
> >> Laraine
> >>
> >>
> >>
> >
> >
> >
> > --
> > *John Driggers*
> > *High End Dev, System Design, Profit Drinking*
> > *
> > **:: 904.404.9233*
> > *:: waffqle@...*
> > *:: NO FAXES*
> >
> > *
> >
> > *
> >
> >
>
>
> --
> *John Driggers*
> *High End Dev, System Design, Profit Drinking*
> *
> **:: 904.404.9233*
> *:: waffqle@...*
> *:: NO FAXES*
>
> *
>
> *
>
>
> [Non-text portions of this message have been removed]
>

system · May 30, 2012, 8:01pm

Excellent! Glad you got it worked out!

On Wed, May 30, 2012 at 7:12 PM, laraines422 <laraines422@...> wrote:

> **
>
>
> Hi John,
>
> Thanks for the tip! It set me on the right path - here's the final code:
>
> >Case "ReqDate"
>
> >if (edv.dataView(edv.Row)("Date01").ToString() = "") Then
> >edv.dataView(edv.Row)("Date01") = edv.dataView(edv.Row)("ReqDate")
> >end if
>
> I had to add the ".ToString()", because it didn't like "null", or "" on
> its own, etc. I'm not sure if its the Date01 data format, or the
> customization element or what - I'm just glad that it finally works!!
>
> Thanks again for pointing the way -
> Laraine
>
>
> --- In vantage@yahoogroups.com, John Driggers <waffqle@...> wrote:
> >
> > Sent that last one a bit quicker than I intended to. Just wrap a little
> if
> > statement around the code where you assign date01. Something like the
> > following:
> >
> > if (row["Date01"] == null)
> > {
> > row["Date01"] = <my ReqDate>;
> > }
> >
> >
> >
> >
> > On Wed, May 30, 2012 at 3:33 PM, John Driggers <waffqle@...> wrote:
> >
> > > Change the code in step three to not update date01 if it already has
> > > something in it. Tada!
> > >
> > >
> > > On Wed, May 30, 2012 at 2:26 PM, laraines422 <laraines422@...>wrote:
> > >
> > >> **
>
> > >>
> > >>
> > >> Hi All,
> > >>
> > >> I give up! I've searched through this site and EpicWeb, and I'm
> coming up
> > >> blank for ideas.
> > >>
> > >> Here is my challenge:
> > >> 1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK,
> > >> because our Production can't seem to commit to firm completion dates
> (but
> > >> that's a different issue).
> > >> 2. Again, it's OK that the ReqDate is changed, but we want to track
> the
> > >> FIRST/INITIAL "ReqDate" - we want a static date to measure our
> performance.
> > >> (We do use the "dynamic" ReqDate for other reporting.)
> > >> 3. No problem so far with this - I'm populating OrderRel.Date01 with
> the
> > >> OrderRel.ReqDate with a Form Event in Customization.
> > >>
> > >> The question is: how do I lock down OrderRel.Date01 after it's
> initially
> > >> populated? Obviously - with only the code in #3 applied, Date01
> changes as
> > >> ReqDate is changed - which defeats the purpose (I don't want the User
> to
> > >> change this field). Do I add code in the customization, to look at the
> > >> Date01 field to see if it's already populated? I also thought about a
> Row
> > >> Rule - but the logic didn't seem to be appropriate to allow to
> populate on
> > >> the first pass and then not to allow to populate for anything later.
> Or do
> > >> I create a BPM at Sales Order Update? It seems like the former would
> be
> > >> simpler (I did putz around with this), but I'm OK with a BPM, too -
> my code
> > >> writing for both is equally weak and suspect. :-)
> > >>
> > >> If it matters - we're on Vantage 8.03.407c...
> > >>
> > >> Thanks in advance -
> > >> Laraine
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > *John Driggers*
> > > *High End Dev, System Design, Profit Drinking*
> > > *
> > > **:: 904.404.9233*
> > > *:: waffqle@...*
> > > *:: NO FAXES*
> > >
> > > *
> > >
> > > *
> > >
> > >
> >
> >
> > --
> > *John Driggers*
> > *High End Dev, System Design, Profit Drinking*
> > *
> > **:: 904.404.9233*
> > *:: waffqle@...*
> > *:: NO FAXES*
> >
> > *
> >
> > *
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>

--
*John Driggers*
*High End Dev, System Design, Profit Drinking*
*
**:: 904.404.9233*
*:: waffqle@...*
*:: NO FAXES*

*

*

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

system · May 31, 2012, 8:59am

I have the same situation.Â I use a BPM to copy the original reqdate to a UD field.Â The BPM checks to see if the UD field has anything in it, if it doesn't it copies the reqdate to it.Â This way, only the original reqdate is saved and never overwritten.
Â
Steven G.

________________________________
From: laraines422 <laraines422@...>
To: vantage@yahoogroups.com
Sent: Wednesday, May 30, 2012 2:26 PM
Subject: [Vantage] Update UD Field ONCE Only

Â
Hi All,

I give up! I've searched through this site and EpicWeb, and I'm coming up blank for ideas.

Here is my challenge:
1. Our OrderRel.ReqDate is constantly changed by our Users. That's OK, because our Production can't seem to commit to firm completion dates (but that's a different issue).
2. Again, it's OK that the ReqDate is changed, but we want to track the FIRST/INITIAL "ReqDate" - we want a static date to measure our performance. (We do use the "dynamic" ReqDate for other reporting.)
3. No problem so far with this - I'm populating OrderRel.Date01 with the OrderRel.ReqDate with a Form Event in Customization.

The question is: how do I lock down OrderRel.Date01 after it's initially populated? Obviously - with only the code in #3 applied, Date01 changes as ReqDate is changed - which defeats the purpose (I don't want the User to change this field). Do I add code in the customization, to look at the Date01 field to see if it's already populated? I also thought about a Row Rule - but the logic didn't seem to be appropriate to allow to populate on the first pass and then not to allow to populate for anything later. Or do I create a BPM at Sales Order Update? It seems like the former would be simpler (I did putz around with this), but I'm OK with a BPM, too - my code writing for both is equally weak and suspect. :-)

If it matters - we're on Vantage 8.03.407c...

Thanks in advance -
Laraine

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