Update PartPlant via BPM

Karl, you are correct on the true false that is why you will need to set all the existing parts check box to true so the BAM will only fire on new record entry. I did a mass update on the data base to set all partplant.checkboxxx to true. Now every time a new record is entered the BAM's fire and update the new records.

Steve


--- In vantage@yahoogroups.com, Karl Dash <dashkarl@...> wrote:
>
> Steve,
> Because this BAM relies solely on the true/false value of the checkbox, wouldn't it fire on any update to a partplant record? I was interested in only a newly added part where I wanted to ensure that the person set (i.e. leadtime) to be a certain value in the absence of info to the contrary. I wouldn't want to override anyone updating the leadtime and then finding it reset to the .p program's level.
> Â
> True?
> Â
> Thanks,
> -Karl
>
> --- On Fri, 7/17/09, vantage03 <vantage@...> wrote:
>
>
> From: vantage03 <vantage@...>
> Subject: [Vantage] Re: Update PartPlant via BPM
> To: vantage@yahoogroups.com
> Date: Friday, July 17, 2009, 5:27 AM
>
>
> Â
>
>
>
> Karl,
>
> I am setting plant default values when a new part is created by using two BAM alerts running .p programs. This works with no operator intervention in the process.
>
> The first one looks at the PartPlant checkbox05 for not true. The BAM then runs an alert to set Part.checkbox05 to true. The second alert looks for Part.checkbox05 to true then runs .p program to set the plant field you want to change then sets the Part.checkbox05 to false. Unsettling the Part checkbox05 keeps you from getting the record has been updated by another user error message.
>
> A couple of things to note:
>
> In both of the BAM .p programs cancel the e-mail after the values are updated.
>
> You will have to set all the existing PartPlant.checkbox0 5 records to true.. If you don't when a part is duplicated it will set the defaults to the values to the defaults on the copied part.
>
> Steve
>
> --- In vantage@yahoogroups .com, "Nigel Kerley" <nigel.kerley@ ...> wrote:
> >
> > Hi Karl,
> >
> > The problem is that you have to use Part.Update as the BO. But if you use a pre-processing directive, then the ttPartPlant table isn't filed in yet; and if you use a post-processing directive then ttPart.RowMod is empty - instead of showing 'U' or 'A' - so you can't tell if you're dealing with a new part.
> >
> > So, off the top of my head:
> > * create a pre-processing directive on Part.Update
> > * add conditions to determine if the part is being created and is one that you want to change PartPlant on
> > * if so, set (say) ttPart.CheckBox20 = true
> >
> > * then create a post-processing directive on Part.Update
> > * add a condition to check if CheckBox20 = true
> > * if so, ttPartPlant should now be available for you to change the values..
> >
> > HTH,
> >
> > Nigel.
> >
> >
> > --- In vantage@yahoogroups .com, Karl Dash <dashkarl@> wrote:
> > >
> > > I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
> > > Â
> > > Thanks,
> > > -Karl
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
Â
Thanks,
-Karl




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

The problem is that you have to use Part.Update as the BO. But if you use a pre-processing directive, then the ttPartPlant table isn't filed in yet; and if you use a post-processing directive then ttPart.RowMod is empty - instead of showing 'U' or 'A' - so you can't tell if you're dealing with a new part.

So, off the top of my head:
* create a pre-processing directive on Part.Update
* add conditions to determine if the part is being created and is one that you want to change PartPlant on
* if so, set (say) ttPart.CheckBox20 = true

* then create a post-processing directive on Part.Update
* add a condition to check if CheckBox20 = true
* if so, ttPartPlant should now be available for you to change the values.

HTH,

Nigel.


--- In vantage@yahoogroups.com, Karl Dash <dashkarl@...> wrote:
>
> I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
> Â
> Thanks,
> -Karl
>
>
>
>
> [Non-text portions of this message have been removed]
>
Karl,

I am setting plant default values when a new part is created by using two BAM alerts running .p programs. This works with no operator intervention in the process.

The first one looks at the PartPlant checkbox05 for not true. The BAM then runs an alert to set Part.checkbox05 to true. The second alert looks for Part.checkbox05 to true then runs .p program to set the plant field you want to change then sets the Part.checkbox05 to false. Unsettling the Part checkbox05 keeps you from getting the record has been updated by another user error message.

A couple of things to note:

In both of the BAM .p programs cancel the e-mail after the values are updated.

You will have to set all the existing PartPlant.checkbox05 records to true. If you don't when a part is duplicated it will set the defaults to the values to the defaults on the copied part.

Steve

--- In vantage@yahoogroups.com, "Nigel Kerley" <nigel.kerley@...> wrote:
>
> Hi Karl,
>
> The problem is that you have to use Part.Update as the BO. But if you use a pre-processing directive, then the ttPartPlant table isn't filed in yet; and if you use a post-processing directive then ttPart.RowMod is empty - instead of showing 'U' or 'A' - so you can't tell if you're dealing with a new part.
>
> So, off the top of my head:
> * create a pre-processing directive on Part.Update
> * add conditions to determine if the part is being created and is one that you want to change PartPlant on
> * if so, set (say) ttPart.CheckBox20 = true
>
> * then create a post-processing directive on Part.Update
> * add a condition to check if CheckBox20 = true
> * if so, ttPartPlant should now be available for you to change the values.
>
> HTH,
>
> Nigel.
>
>
> --- In vantage@yahoogroups.com, Karl Dash <dashkarl@> wrote:
> >
> > I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
> > Â
> > Thanks,
> > -Karl
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
Brilliant! That sounds like a plan.
Â
Thanks,
-Karl-

--- On Fri, 7/17/09, Nigel Kerley <nigel.kerley@...> wrote:


From: Nigel Kerley <nigel.kerley@...>
Subject: [Vantage] Re: Update PartPlant via BPM
To: vantage@yahoogroups.com
Date: Friday, July 17, 2009, 1:56 AM


Â



Hi Karl,

The problem is that you have to use Part.Update as the BO. But if you use a pre-processing directive, then the ttPartPlant table isn't filed in yet; and if you use a post-processing directive then ttPart.RowMod is empty - instead of showing 'U' or 'A' - so you can't tell if you're dealing with a new part.

So, off the top of my head:
* create a pre-processing directive on Part.Update
* add conditions to determine if the part is being created and is one that you want to change PartPlant on
* if so, set (say) ttPart.CheckBox20 = true

* then create a post-processing directive on Part.Update
* add a condition to check if CheckBox20 = true
* if so, ttPartPlant should now be available for you to change the values.

HTH,

Nigel.

--- In vantage@yahoogroups .com, Karl Dash <dashkarl@.. .> wrote:
>
> I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
> Â
> Thanks,
> -Karl
>
>
>
>
> [Non-text portions of this message have been removed]
>



















[Non-text portions of this message have been removed]
Steve,
Because this BAM relies solely on the true/false value of the checkbox, wouldn't it fire on any update to a partplant record? I was interested in only a newly added part where I wanted to ensure that the person set (i.e. leadtime) to be a certain value in the absence of info to the contrary. I wouldn't want to override anyone updating the leadtime and then finding it reset to the .p program's level.
Â
True?
Â
Thanks,
-Karl

--- On Fri, 7/17/09, vantage03 <vantage@...> wrote:


From: vantage03 <vantage@...>
Subject: [Vantage] Re: Update PartPlant via BPM
To: vantage@yahoogroups.com
Date: Friday, July 17, 2009, 5:27 AM


Â



Karl,

I am setting plant default values when a new part is created by using two BAM alerts running .p programs. This works with no operator intervention in the process.

The first one looks at the PartPlant checkbox05 for not true. The BAM then runs an alert to set Part.checkbox05 to true. The second alert looks for Part.checkbox05 to true then runs .p program to set the plant field you want to change then sets the Part.checkbox05 to false. Unsettling the Part checkbox05 keeps you from getting the record has been updated by another user error message.

A couple of things to note:

In both of the BAM .p programs cancel the e-mail after the values are updated.

You will have to set all the existing PartPlant.checkbox0 5 records to true.. If you don't when a part is duplicated it will set the defaults to the values to the defaults on the copied part.

Steve

--- In vantage@yahoogroups .com, "Nigel Kerley" <nigel.kerley@ ...> wrote:
>
> Hi Karl,
>
> The problem is that you have to use Part.Update as the BO. But if you use a pre-processing directive, then the ttPartPlant table isn't filed in yet; and if you use a post-processing directive then ttPart.RowMod is empty - instead of showing 'U' or 'A' - so you can't tell if you're dealing with a new part.
>
> So, off the top of my head:
> * create a pre-processing directive on Part.Update
> * add conditions to determine if the part is being created and is one that you want to change PartPlant on
> * if so, set (say) ttPart.CheckBox20 = true
>
> * then create a post-processing directive on Part.Update
> * add a condition to check if CheckBox20 = true
> * if so, ttPartPlant should now be available for you to change the values..
>
> HTH,
>
> Nigel.
>
>
> --- In vantage@yahoogroups .com, Karl Dash <dashkarl@> wrote:
> >
> > I read some of the past postings on the difficulty with doing a BPM on the PartPlant table due to the timing of when a new row gets added to it. Has anyone successfuly overcome this limitation. I want to force values into the partplant table for all new purchased parts but have come across the same wall as others.
> > Â
> > Thanks,
> > -Karl
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>



















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