Between application 7.5 (or 8?! I am not sure...) and 9 I have seen a difference regarding object transformation. In the old release of IFS application an entry was made in the object connection list if a document was passed on from a source LU to a taget LU. Now it seems to be only displayed online. Can someone explain the benefit?
Solved
Document Management - Object Transformation
Best answer by Mathias Dahl
Ah, now I understand.
The reason there is a difference is that, before we had OCT (Object Connection Transformation), we had code, in different product areas, that added extra links between related records and documents. So, in your case, there were code in the purchase order functionality that would copy any document links to the purchase order lines, at some point. So, the link (or connection, as we say) was really there, in the database table. Therefore, you could also see the connection from the Document Revision screen.
One drawback of the old approach was that it was up to R&D to make sure to copy these links wherever we thought it was useful. The customer could not get these links copied if they wanted.
With OCT, this changed. Now a lot of the old code was replaced by OCT rules that would to more or less the same thing, except that there is no copying going on. Instead of copying the links, the system finds “related” documents at runtime instead. There are some drawbacks with the new approach as well, mostly related to performance, but the solution is more flexible. For example, once you add a new OCT rule, it works right away, with no need for copying links.
Another drawback is that you cannot see, from the document’s point of view, what objects the user can see the document from. It would be impossible, or very hard, or very slow, to show what objects might see the document, based on the OCT rules. And, no one has asked for it, so it cannot be very important.
So, the benefits are more flexibility for the customer (they can add their own rules), and less code (good for R&D) and less data duplication (copying the links around).
+32Are you talking about the LU name shown in parenthesis in the tool-tip if you hover above a connected document in the Attachments panel (in Icon mode)? As with the little curved arrow, it’s meant to tell the user that the document is really connected to some other object. How important this is, I’m not sure…
If you meant something else, you need to elaborate a bit.
Hi Matthias,
thank you for your response :-)
I make an example:
- Connect a new document to purchase part “ABC1"
- Go with RMB to the document revision of this new document
- Look at the tab “object”
- one object connection is shown: purchase part “ABC1”
- create a new purchase order line for part “ABC1”
- Look at the attached documents
- Your document is shown at the purchase order line (because of object transformation)
- Go with RMB to document revision
- Look at the tab “object”
- still only one object connection is shown: purchase part “ABC1”. The purchase order line is not shown. In old versions of IFS the purchase order line was shown. I am wondering why it has changed. There must be some benefits.
Thank you and best regards,
Sarah
+32Ah, now I understand.
The reason there is a difference is that, before we had OCT (Object Connection Transformation), we had code, in different product areas, that added extra links between related records and documents. So, in your case, there were code in the purchase order functionality that would copy any document links to the purchase order lines, at some point. So, the link (or connection, as we say) was really there, in the database table. Therefore, you could also see the connection from the Document Revision screen.
One drawback of the old approach was that it was up to R&D to make sure to copy these links wherever we thought it was useful. The customer could not get these links copied if they wanted.
With OCT, this changed. Now a lot of the old code was replaced by OCT rules that would to more or less the same thing, except that there is no copying going on. Instead of copying the links, the system finds “related” documents at runtime instead. There are some drawbacks with the new approach as well, mostly related to performance, but the solution is more flexible. For example, once you add a new OCT rule, it works right away, with no need for copying links.
Another drawback is that you cannot see, from the document’s point of view, what objects the user can see the document from. It would be impossible, or very hard, or very slow, to show what objects might see the document, based on the OCT rules. And, no one has asked for it, so it cannot be very important.
So, the benefits are more flexibility for the customer (they can add their own rules), and less code (good for R&D) and less data duplication (copying the links around).
Mathias Dahl wrote:
Ah, now I understand.
The reason there is a difference is that, before we had OCT (Object Connection Transformation), we had code, in different product areas, that added extra links between related records and documents. So, in your case, there were code in the purchase order functionality that would copy any document links to the purchase order lines, at some point. So, the link (or connection, as we say) was really there, in the database table. Therefore, you could also see the connection from the Document Revision screen.
One drawback of the old approach was that it was up to R&D to make sure to copy these links wherever we thought it was useful. The customer could not get these links copied if they wanted.
With OCT, this changed. Now a lot of the old code was replaced by OCT rules that would to more or less the same thing, except that there is no copying going on. Instead of copying the links, the system finds “related” documents at runtime instead. There are some drawbacks with the new approach as well, mostly related to performance, but the solution is more flexible. For example, once you add a new OCT rule, it works right away, with no need for copying links.
Another drawback is that you cannot see, from the document’s point of view, what objects the user can see the document from. It would be impossible, or very hard, or very slow, to show what objects might see the document, based on the OCT rules. And, no one has asked for it, so it cannot be very important.
So, the benefits are more flexibility for the customer (they can add their own rules), and less code (good for R&D) and less data duplication (copying the links around).
Thank you for your answer. We had some trouble regarding this with an upgrade customer. They did some customizing in their old IFS revision: the attached documents to a purchase order could easy been printed with one RMB. They have a lot of documents attached to one purchase order (coming from several object transformations). In the end we made a customization to find all related documents… But it was really hard to make a concept and get it working ;-)
1 person likes this
+32Yes, I can see how such a customization must be changed. Since some of the link/connection records are not there anymore you need to find them via the OCT rules.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.