In Document Basic - Document Defaults per Object, I have assigned document classes to specific Lu’s.
When creating a new document on the object, the default document class is pre-populated in the Create New Document pop up dialog. This works as expected.
If I have multiple document classes set to the same Lu. When creating a new document from the object, the “priority 1” document class is the default in the Create New Document pop up. This is also expected. However, when I click on the ellipsis to select a different document class, I expect to see only the document classes defined in the Document Defaults per Object. Instead, I see every document class in the system.
Is it possible to limit the selectable document classes to those configured in the Document Defaults per Object?
Page 1 / 1
Hi @dabele ,
This is working as per the functionality. Priority field is used to select a configuration when there are multiple applicable configurations for a particular LU. So when using document defaults per object there is always one applicable configuration which gives you a single default value for the doc class, format and language code.
So document defaults per object does not act as a filter to the document classes you can chose from the LOV when creating new documents for a LU. It simply picks out a default value when there is an applicable configuration.
As Asitha says, this functionality is not used to filter the document classes, it's used to provide a good default value such that the user don't need to select it themselves. What you need is an extension to this functionality, or some new basic data designed for this purpose. It's not impossible to design such a feature, but it's not something we have today. Feel free to add an idea in the Ideas section here on IFS Community to have our product manager consider it for a future release.
If you really want to stop users from using certain classes to be used on some objects, a custom event can be configured to do this. You need to keep the list of document classes per object type somewhere though.
Good luck!
Hi @dabele,
Have you created an idea? If so, can you link it here? I would like to vote for it, because this topic also comes up in every customer project and unfortunately this function still does not exist in IFS.
I currently use this function in the document class management page so that I can assign user groups to the individual classes. Unfortunately, it doesn't quite fulfil the desired function, but it is at least a small improvement to the situation.
Thanks, Mike
@MikeCH , can you describe the use case? It's not clear exactly what you are after, and why. Are certain users always using one or a few document classes? If you have so many classes it's hard for the users to select the right one, perhaps you have too many?
Thanks!
Hi @Mathias Dahl, yes gladly. Customers assign document classes based on various criteria. The top criterion is the assignment of authorization groups. The document types are also differentiated (e.g. customer request, customer quotation, customer order, etc.). This results in the number of areas/departments quickly times 40-50 document classes. However, it is possible to clearly define which document classes are to be used for which object. So on the one hand it can be limited that wrong classes are used and on the other hand the selection which is available becomes much clearer. E.g. with a customer order the class customer order stands to the selection, however not the class supplier quotation, since this has to look there nothing.
I did not understand until today why this possibility is not available in the standard, because this could be solved quite simply over a basis data table in which one can assign the permitted document classes if necessary per logical unit similarly as in the side Object Connection. As soon as at least one class is assigned, only the assigned class may be selected. And where nothing is assigned, all are still allowed. This would be the same logic as it is implemented on the page Document Class Management in the tab "Persons and Groups".
I hope this helps you to understand the use case better and can work on your side that something is extended in the standard.
Thanks & best regards, Mike
If no idea has been created I recommend you create one.