Custom Objects works on a large majority of pages in IFS Applications, but not everywhere. Custom objects require that the implementation of pages and their underlying storage conform to framework guidelines and best practices. Architectural decisions taken when implementing a page can make it impossible to associate a custom object with it.
Note: This page lists a number of situations that is important to be aware of in order to work efficiently with Custom Objects. There are actually more situations that can be considered as a limitation than listed here.
To be able extend a View with Custom Fields or Information Cards, all records in the view must have a rowkey which correspond to a record in the base table. There are views defined which are created using joins or unions where this is not the case. Custom fields and Information Cards functionality would not work on these views.
Due to architectural design decisions some logical units or some application forms may not be extended with Custom objects functionality. In such a case, such logical units and application pages should be explicitly excluded from Custom Objects logic so that a user will not be misguided. Refer Excluded LUs and Exclude Application Form from Having Custom Fields pages for more details.
When managing many of IFS Applications business objects (like Customer Order, Product Structure and so on) you commonly want to copy one business object when you create another new business object. This can be done in two ways:
- Client copy
A client copy is done by using the duplicate button (F6). This functionality makes a duplicate of the current highlighted record. It does not copy a complete business object, only the current record. If you do a client copy this will also copy all “enabled and visible” custom fields.- Server copy
This is usually done from the context menu "Copy [business object]". This functionality is done in the server and usually copies the full structure of a business object (e.g. Customer Order Header, lines and deliveries). This is business logic that is written by IFS. A server copy does not copy Custom Fields unless the server logic makes a call to the Custom Fields copy APICustom_Objects_SYS.Copy_Cf_Instance.To copy between different LU's, the method
Custom_Objects_SYS.Copy_Between_Lu_Cf_Instanceshould be used instead. This API is dependent on the names of the custom fields being exactly the same in the different LU’s (e.g. between Active Work Orders and Historical Work Orders). So only if it exists two attributes with the same name in both of the LUs a copy of the custom fields will be done. If an error occurs when copying custom fields the whole transaction is rolled back.
It is not possible to add business logic directly to a custom field, e.g., validations. It is possible to achieve some logic and flow by referencing custom fields from conditional fields, custom defined events or custom menus. Referencing custom fields from static source code is however not supported.
New development or customizations of application source code should never make use of custom fields. There are technical limitations as well as maintenance issues with such an approach. Writing business logic including a custom field is not supported by IFS or IFS development and deployment tools. In other words, writing static code that references configured objects is not supported.
Custom Defined Events can be used as a means to add some minor business logic to custom fields, e.g., validations. For this to work it is important to place the event on the generated custom fields table. If the event is attached to the standard logical unit table the value of the custom field attribute will not be updated. This is because the insert on the standard table is done before the custom fields table, hence when a trigger is executed for the standard table the value of the custom field attribute is null. Same thing happens on an update, when the standard table fires the update trigger, the value of the custom field attribute is not yet updated and contains the previous value.
Unlike ordinary application pages that have a straight forward interaction pattern where typically a user searches for data, update or add information and then explicitly save, dialogs provide much more flexible implementation to suit the task at hand. Under these circumstances, it is not currently possible to provide custom fields on dialogs or wizards; even for dialogs with tables included in them.
When a Select statement is set up for a Read-Only field, the arguments must exist in the base view or the base table for the LU, as well as in all approved detail views on that LU.
Similar to the arguments for Select statements, any attribute selected for a custom field of "Local" implementation type must exist in the base view or the base table for the LU, as well as in all approved detail views on that LU.
Maximum character length for a Custom Enumeration is 4000 characters. This amount includes the character length of all the items in the Enumeration.
Enumeration type+ fields will not be listed in Record selector or Update Record Selector dialog.
Custom Objects legacy Export/Import functionality does not support for translations. Normally, Applications Configuration Packages should be used to handle export/import translations for Custom Objects. However, ACPs does not support for Local Custom Fields. Therefore the translations for Local Custom Fields should be exported and imported using Translation Manager. See Administrate Custom Objects for information on how to Translate Custom Objects.
As Custom References are actually stored as rowkey values, not as the display value, Find and Replace functionality does not work with Custom references.
When a search or populate operation is performed on an application page that has custom fields, etc enabled, the form will use a custom view such as &AO.<XXXX>_CFV instead of the normal view that is bound to the form. This switching is handled by the framework code. So, in the case of application code overriding the framework code, custom objects functionality might not work properly unless application code explicitly handles custom objects. See Overriding Framework Functionality.
When adding a Custom Field to a form, it calculates the position according to the form layout and the controls available in that specific form. Custom Fields can not be placed on top of a cPanel since cPanels do not support with the positioning. This is a framework limitation. We do not recommend enabling Custom Fields functionality in such forms which are designed with "cPanels".
For logical units without a base table but have a base view, only Read Only Custom Fields will be supported. The views of the LU (Base or Detail view) should have a Rowkey column with unique values. Therefore if a Utility Package has a Base View or a Detail View then Custom Fields will be enabled for those Utility Packages. Read Only Custom Fields will only be supported since there is no Base Table for Utility packages.
Custom Tabs Parent Key- Child Key relationship does not work on pages that are populated from a Tree Navigator. For a tab to have Parent Key-Child Key relationship it must have a proper parent. But adding a Custom Tab is not limited in these pages but adding a Parent-Child relationship is avoided. Since there is no proper parent, navigating from Custom Tabs overview pages might run into errors in this scenario.
(examples for pages populated with tree navigator: Project Forecast/Marketing Campaign/Project Navigator etc. )
Initially, when creating a Custom tab, a Page needs to have at least one standard or Custom Tab to map the Parent Key-Child Key relationship. You can create a Custom Tab without a Parent-Key mapping at the initial stage. But to add a parent-key relationship you need to save the custom tab and edit it again after performing Reload Configuration.
LU Modifications between IFS Application versions will be handled by custom_obj_sys.Handle_Lu_Modification. This method will update the Objects related to Custom Logical Units, Custom Fields and Information Cards. The user will need to manually update other Custom Objects.
Not all the columns in the underlying view of the form are mapped to visible fields. As the custom menu condition dialog loads the list of columns directly through the view definition, there can be a subset of columns unbounded to fields in the form. Setting conditions for a fields which are not included in the form through the conditional dialog, will result the custom menu to be remain disabled.
Custom menu conditions only support simple conditions (e.g. QTY > 50, COMPANY = IFS Racing). It is not possible to reference other fields (Custom or base) in conditions. (e.g. QTY > CF$_AV_QTY will not work as expected).