2546
Points
Questions
6
Answers
146
-
Nelly –
The only curious thing that I see in your attachment is that the first screen displays D06139 at Rev 01 and the last screen shows the same Doc at Rev 02 (in the 003208 BOM).
My suspicion here is that 003208 may have been on a change that was unreleased at some point (possibly even C24493). I would check the change history to verify if this is the case.Bad News: There is a bug which causes the incorrect BOM flags to be set when a change object is unreleased.
Good News: There is a patch for this available through Oracle SupportPatch: 17577831 – 9.3.1.0.134: WHERE USED TAB DOES NOT SHOW ALL PARENTS
I hope this helps!
This answer accepted by nelly_risdon. on December 22, 2024 Earned 15 points.
- 5428 views
- 6 answers
- 0 votes
-
Nelly –
I was experiencing the same issue a while back and found that there is a design flaw when it comes to the “All Changes During the Time Period” criterion.Even though the system may send notifications to the transfer user when the approval is required – it will only allow the TA user to actually approve/reject if the change was CREATED during the Transfer Authority period.
Unless there is some compelling reason to do otherwise – I would suggest using “All Changes” instead “All Changes During the Time Period” to avoid this issue.
- 4377 views
- 5 answers
- 0 votes
-
- 1939 views
- 1 answers
- 0 votes
-
One thing to remember is that even IF you assign a team member the Program Administrator role – they are only granted that role for that specific PPM object.
I.E. – even though the Program Admin Role may have a privilege such as ‘modify all projects’ – if the team member doesn’t normally have this role – he/she will only be able to modify that specific project in which the role was granted and not other projects in the system.To your point – It still may be considered a security breach for your system if proper training is not in place, but it is not as far reaching as many often think.
- 2391 views
- 3 answers
- 0 votes
-
Nelly –
The problem here is that you are using a “read-through” field in your search Criteria.
This is not always a problem and can be a very useful feature, however – it can also lead to undesirable results as there is no distinction between Parts and Documents when setting up these ITEM read-through fields on the Affected Items tab.
For example – Lets Say:
– Page_Two.List01 is ‘Item Category’ for the PARTS class
-Page_Two.List01 is ‘Document Type’ for the DOCUMENTS classIf the read-through field (Item P2 List01) is enabled on the Affected Items Tab –
– the ‘Item Category’ value is displayed (from the Item record) if the affected item is a PART
– the ‘Document Type’ value is displayed (from the Item record) if the affected item is a DOCUMENTIt gets even more confusing if I’ve renamed the Read-through field “Item Category” since that isn’t what it is actually being displayed for a Document Affected Item.
Even if Page_Two.List01 is “Item Category” for both Parts and Documents – if they use different lists (which appears to be the case for you) the Advanced Search will not merge the values of the separate lists.
This is a design flaw, in my opinion. I’ve never really heard this addressed nor am I aware of it being fixed in any recent updates (currently on 9.3.2). I have done a lot of testing on read-through fields, however, and there is a lot that does and doesn’t work that isn’t mentioned anywhere in the manuals.
If you do use ITEM read-through fields on the affected items tab – I would highly recommend using an attribute that is either not used by both Parts and Documents or – if it is used by both – make sure that the attribute is the same and uses the same list.
Please let me know if you have any further questions on this.
- 2166 views
- 2 answers
- 0 votes
-
- 2422 views
- 4 answers
- 0 votes