This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
:ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
Any ideas on why the condition passes for the Escalation but not for the status change condition?
Hi,
To restrict the status change you apply the condition in the security group not in an escalation.
I have a condition OSCTOOLSANCH that checks to see if the QA check boxes (our added fields) have been correctly filled in. Then that condition is applied to the EVERYONE security group for the WORKORDER COMPLETE WORKORDER option. So if they have not correctly filled in the check boxes they cannot complete the work order. Only when the condition is true can they complete a work order.
So you use the condition not in an escalation but in a condition on the security group(s).
Hopefully you have one group that everyone is granted so you can apply universal changes. By default that should be the EVERYONE group.
Dave Bone
--- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@...> wrote:
>
> I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
>
> historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
>
> So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
>
> :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
>
> Any ideas on why the condition passes for the Escalation but not for the status change condition?
>
I was trying to apply the 2nd condition against the POSTATUS domain so if the condition is not met, a user cannot change the status of the PO. I am just perplexed on why the condition will work in one part of Maximo, the Escalation/Notification, but won't work in another part, the restriction on the POSTATUS domain.
I'll take a look and see what can be done from the Sec Grp.
--- In MAXIMO@yahoogroups.com, "in2data" <in2data@...> wrote:
>
> Hi,
>
> To restrict the status change you apply the condition in the security group not in an escalation.
>
> I have a condition OSCTOOLSANCH that checks to see if the QA check boxes (our added fields) have been correctly filled in. Then that condition is applied to the EVERYONE security group for the WORKORDER COMPLETE WORKORDER option. So if they have not correctly filled in the check boxes they cannot complete the work order. Only when the condition is true can they complete a work order.
>
> So you use the condition not in an escalation but in a condition on the security group(s).
>
> Hopefully you have one group that everyone is granted so you can apply universal changes. By default that should be the EVERYONE group.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> >
> > I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
> >
> > historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
> >
> > So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
> >
> > :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
> >
> > Any ideas on why the condition passes for the Escalation but not for the status change condition?
> >
>
Hi,
You want to keep them from approving a PO you do it in the security groups by putting a condition on the approval rights.
Dave Bone
--- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@...> wrote:
>
> I was trying to apply the 2nd condition against the POSTATUS domain so if the condition is not met, a user cannot change the status of the PO. I am just perplexed on why the condition will work in one part of Maximo, the Escalation/Notification, but won't work in another part, the restriction on the POSTATUS domain.
>
> I'll take a look and see what can be done from the Sec Grp.
>
> --- In MAXIMO@yahoogroups.com, "in2data" <in2data@> wrote:
> >
> > Hi,
> >
> > To restrict the status change you apply the condition in the security group not in an escalation.
> >
> > I have a condition OSCTOOLSANCH that checks to see if the QA check boxes (our added fields) have been correctly filled in. Then that condition is applied to the EVERYONE security group for the WORKORDER COMPLETE WORKORDER option. So if they have not correctly filled in the check boxes they cannot complete the work order. Only when the condition is true can they complete a work order.
> >
> > So you use the condition not in an escalation but in a condition on the security group(s).
> >
> > Hopefully you have one group that everyone is granted so you can apply universal changes. By default that should be the EVERYONE group.
> >
> > Dave Bone
> >
> > --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> > >
> > > I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
> > >
> > > historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
> > >
> > > So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
> > >
> > > :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
> > >
> > > Any ideas on why the condition passes for the Escalation but not for the status change condition?
> > >
> >
>
I tried playing around with that last night and still can't get the approval to be suppressed with a PO Line of 3.34 EA. I tried the following versions of the conditional expression:
:ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
not exists(select 1 from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=:po.ponum and siteid=:po.siteid)
Both were applied to the 'Approve Purchase Order' and 'Change Status' security options under the 'Purchase Order' application.
Do you think I'm missing something in my conditional expression?
--- In MAXIMO@yahoogroups.com, "in2data" <in2data@...> wrote:
>
> Hi,
>
> You want to keep them from approving a PO you do it in the security groups by putting a condition on the approval rights.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> >
> > I was trying to apply the 2nd condition against the POSTATUS domain so if the condition is not met, a user cannot change the status of the PO. I am just perplexed on why the condition will work in one part of Maximo, the Escalation/Notification, but won't work in another part, the restriction on the POSTATUS domain.
> >
> > I'll take a look and see what can be done from the Sec Grp.
> >
> > --- In MAXIMO@yahoogroups.com, "in2data" <in2data@> wrote:
> > >
> > > Hi,
> > >
> > > To restrict the status change you apply the condition in the security group not in an escalation.
> > >
> > > I have a condition OSCTOOLSANCH that checks to see if the QA check boxes (our added fields) have been correctly filled in. Then that condition is applied to the EVERYONE security group for the WORKORDER COMPLETE WORKORDER option. So if they have not correctly filled in the check boxes they cannot complete the work order. Only when the condition is true can they complete a work order.
> > >
> > > So you use the condition not in an escalation but in a condition on the security group(s).
> > >
> > > Hopefully you have one group that everyone is granted so you can apply universal changes. By default that should be the EVERYONE group.
> > >
> > > Dave Bone
> > >
> > > --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> > > >
> > > > I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
> > > >
> > > > historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
> > > >
> > > > So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
> > > >
> > > > :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
> > > >
> > > > Any ideas on why the condition passes for the Escalation but not for the status change condition?
> > > >
> > >
> >
>
Hi,
Your condition will be against the po table not the poline table. Remove the :po. and use just :ponum and :siteid.
Dave Bone
--- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@...> wrote:
>
>
> I tried playing around with that last night and still can't get the approval to be suppressed with a PO Line of 3.34 EA. I tried the following versions of the conditional expression:
>
> :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
>
> not exists(select 1 from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=:po.ponum and siteid=:po.siteid)
>
> Both were applied to the 'Approve Purchase Order' and 'Change Status' security options under the 'Purchase Order' application.
>
> Do you think I'm missing something in my conditional expression?
>
>
>
> --- In MAXIMO@yahoogroups.com, "in2data" <in2data@> wrote:
> >
> > Hi,
> >
> > You want to keep them from approving a PO you do it in the security groups by putting a condition on the approval rights.
> >
> > Dave Bone
> >
> > --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> > >
> > > I was trying to apply the 2nd condition against the POSTATUS domain so if the condition is not met, a user cannot change the status of the PO. I am just perplexed on why the condition will work in one part of Maximo, the Escalation/Notification, but won't work in another part, the restriction on the POSTATUS domain.
> > >
> > > I'll take a look and see what can be done from the Sec Grp.
> > >
> > > --- In MAXIMO@yahoogroups.com, "in2data" <in2data@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > To restrict the status change you apply the condition in the security group not in an escalation.
> > > >
> > > > I have a condition OSCTOOLSANCH that checks to see if the QA check boxes (our added fields) have been correctly filled in. Then that condition is applied to the EVERYONE security group for the WORKORDER COMPLETE WORKORDER option. So if they have not correctly filled in the check boxes they cannot complete the work order. Only when the condition is true can they complete a work order.
> > > >
> > > > So you use the condition not in an escalation but in a condition on the security group(s).
> > > >
> > > > Hopefully you have one group that everyone is granted so you can apply universal changes. By default that should be the EVERYONE group.
> > > >
> > > > Dave Bone
> > > >
> > > > --- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@> wrote:
> > > > >
> > > > > I have a conditional expression that I've been using to notify Purchasing Depts, via a Notification in Escalations, when they have a PO with a PO Line that has a Ordery Units of 'EA', but has a decimal order qty - 3.34 EA. The condition in Escalations is:
> > > > >
> > > > > historyflag=0 and exists(select 1 from poline where ponum=po.ponum and siteid=po.siteid and orderunit='EA' and orderqty % 1 <> 0) and getdate()-statusdate < 1.0/24.0
> > > > >
> > > > > So when this condition is met, the site Purchasing Dept gets an email of the PO and the status is changed back to WAPPR. I now want to try and have the condition applied to the POSTATUS domain so they cannot approve the PO in the first place. So I created a new conditional expression:
> > > > >
> > > > > :ponum not in (select ponum from poline where orderqty % 1 <> 0 and orderunit = 'EA' and ponum=po.ponum and siteid=po.siteid)
> > > > >
> > > > > Any ideas on why the condition passes for the Escalation but not for the status change condition?
> > > > >
> > > >
> > >
> >
>