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 thought I had mastered revisions with job plan revisions way back in 6.2, but PO revisions are a whole new level of "Wait, which one am I talking about?"
Here's a nifty day at the office. Maybe you do this at your sites. Someone says, "For every PO, tell me how long it takes to go from PR to PO, and then how long it takes to approve the PO".
So on my first attempt I forgot about revisions, just plain ignored them, and managed to produce more or less what the users expected. Lucky, not good.
Since we're looking for PR-to-PO time, we can check only POs with a related PR. Of course, Maximo doesn't have a nifty helper table for that, so I'm left with looking for any PR lines with a PO entry. And, sure enough, the PO on that record doesn't have its revision number with it. You get *that* by looking at the PO line (at least I can get the PO line ID) and locating that line's PO and revision pair.
To sum up, if I want to show the PR for a specific PO revision, I have to traverse the PR line table, then the PO line table, and come back to the PO. That seems torturous, so if anyone has a better way, let me know.
Once I have the PR for that revision, then it's just a matter of getting the approvals. Oh, which approval? The first one? The second? Because now we're into the age-old "Workorder status spinning" question.
It's no wonder everyone looks at me cross-eyed when I start talking about this.
How are you handling things like this out there?
-C
It may be helpful to know the prline table has persistent columns ponum, porevisionnum, polinenum, positeid, and polineid (the best one of all).
Wasn't sure if you are using SQL or mbo. But if using MSSQL, I have queried the status table using row_number or rank to find the first or last time something was approved.
row_number() over (partition by ponum,revisionnum order by (case status when 'APPR' then 1 else 9 end) asc, changedate asc)
I would join the prline, poline, and postatus tables and use row_number to filter for the approval record I desire. Which approval is required depends on how they want to calculate the time.
Luckily I haven't been asked to do this specifically. It's a PITA. Good luck to you.
---In MAXIMO@yahoogroups.com, <maximal@...> wrote :
I thought I had mastered revisions with job plan revisions way back in 6.2, but PO revisions are a whole new level of "Wait, which one am I talking about?"
Here's a nifty day at the office. Maybe you do this at your sites. Someone says, "For every PO, tell me how long it takes to go from PR to PO, and then how long it takes to approve the PO".
So on my first attempt I forgot about revisions, just plain ignored them, and managed to produce more or less what the users expected. Lucky, not good.
Since we're looking for PR-to-PO time, we can check only POs with a related PR. Of course, Maximo doesn't have a nifty helper table for that, so I'm left with looking for any PR lines with a PO entry. And, sure enough, the PO on that record doesn't have its revision number with it. You get *that* by looking at the PO line (at least I can get the PO line ID) and locating that line's PO and revision pair.
To sum up, if I want to show the PR for a specific PO revision, I have to traverse the PR line table, then the PO line table, and come back to the PO. That seems torturous, so if anyone has a better way, let me know.
Once I have the PR for that revision, then it's just a matter of getting the approvals. Oh, which approval? The first one? The second? Because now we're into the age-old "Workorder status spinning" question.
It's no wonder everyone looks at me cross-eyed when I start talking about this.
How are you handling things like this out there?
-C
Hi Chris: There's no other way to link from the PR to the PO other than
using the PRLINE.PONUM and PRLINE.POLINENUM fields - sorry! As for which
revision: I find that generally when users ask for these stats, they're
asking for the first revision since that's the one where the line was
originally added from the PR.
So the answer is: I don't think you can get the stats for PR vs. PO very
precisely. You COULD, however, do PR Line vs. PO line stats a lot more
precisely.
This is what I use at one client, and the users seem to be fine with it:
select pr.siteid, pr.prnum, pr.description, pr.issuedate, prlinenum,
appr.ponum, appr.apprdate, purchaseagent
from pr inner join prline
on pr.prnum = prline.prnum
left join (select ponum, min(changedate) as apprdate from postatus where
status = 'APPR' and revisionnum = 0 group by ponum) appr
on prline.ponum = appr.ponum
where pr.status != 'CAN' and issuedate > '01-JAN-2016'
order by pr.prnum, prlinenum)
Shannon
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com]
Sent: Thursday, August 18, 2016 6:55 AM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Reeeeeeeeeeeeevisions!
I thought I had mastered revisions with job plan revisions way back in 6.2,
but PO revisions are a whole new level of "Wait, which one am I talking
about?"
Here's a nifty day at the office. Maybe you do this at your sites. Someone
says, "For every PO, tell me how long it takes to go from PR to PO, and then
how long it takes to approve the PO".
So on my first attempt I forgot about revisions, just plain ignored them,
and managed to produce more or less what the users expected. Lucky, not
good.
Since we're looking for PR-to-PO time, we can check only POs with a related
PR. Of course, Maximo doesn't have a nifty helper table for that, so I'm
left with looking for any PR lines with a PO entry. And, sure enough, the PO
on that record doesn't have its revision number with it. You get *that* by
looking at the PO line (at least I can get the PO line ID) and locating that
line's PO and revision pair.
To sum up, if I want to show the PR for a specific PO revision, I have to
traverse the PR line table, then the PO line table, and come back to the PO.
That seems torturous, so if anyone has a better way, let me know.
Once I have the PR for that revision, then it's just a matter of getting the
approvals. Oh, which approval? The first one? The second? Because now we're
into the age-old "Workorder status spinning" question.
It's no wonder everyone looks at me cross-eyed when I start talking about
this.
How are you handling things like this out there?
-C
---In MAXIMO@yahoogroups.com, <incomm@shaw.ca> wrote :
Hi Chris: There's no other way to link from the PR to the PO other than
using the PRLINE.PONUM and PRLINE.POLINENUM fields - sorry! As for which
revision: I find that generally when users ask for these stats, they're
asking for the first revision since that's the one where the line was
originally added from the PR.
Yeah, well, I guess validation does count for something. Thanks for checking.
Now you wrote something interesting here:
>>
select pr.siteid, pr.prnum, pr.description, pr.issuedate, prlinenum,
appr.ponum, appr.apprdate, purchaseagent
from pr
inner join prline on pr.prnum = prline.prnum
left join (select ponum, min(changedate) as apprdate from postatus where
status = 'APPR' and revisionnum = 0 group by ponum) appr
on prline.ponum = appr.ponum
where pr.status != 'CAN' and issuedate > '01-JAN-2016'
order by pr.prnum, prlinenum)
>>
You are relying on the implication that a revision 0 PO will be approved, hence first approval, nice.
-C