The IFS Applications 9 release delivers pre-defined system templates, associated with the Create Company concept, containing basic data that after installation can be used when creating a new company. The templates enables an easy and quick way of creating a company and associated basic data, thus reducing the time to get started with company related functionality.
The supported and currently installed system templates can always be found using RMB View Reserved System Template Ids... in the Company Templates window.
The Create Company concept functionality can be summarized as follows,
The company template files are executed during the installation and create system templates consisting of information related to one or more components.
The installed information is kept in the template storage in Enterprise component.
Note: Even if template translations can be exported as well as imported from Create Company specific windows, these files should not be stored in the version handling system for a component.
The basic principle is to use the power of the application to define a company with suitable setup of basic data and then create a template from this company. The created template can be used for the following purposes,
The exported files can also be sent by e.g. e-mail to a subsidiary where they can be imported and used as source for creation of new companies.
In order to utilize the functionality in the concept it is important to perform the implementation correctly.
Use this document as implementation guidelines for the Create Company concept.
This sections covers general instructions for an IFS Applications component that supports the Create Company concept.
The following is important with respect to Company Template validity,
The reason is that template components data might not be compatible with the business logic of the installed component versions.
- Delete all non-valid company templates that definitely should not be used anymore.
- For all other non-valid templates the following can be done to make the templates valid again:
- Find the template in the Company Templates window.
- Mark the template and select the RMB Mark as Valid Template.
- The action will set all component versions in the template to the actual version of the components in the installation. The template will also be marked as valid.
Note: The data in the templates might still not be compatible with the business logic of the installed component versions
- Create a new company to test if the template is correct or not.
- Correct all errors in the template and continue creating new companies until there are no more errors. Now the template is valid and consistent.
- All temporary companies created during the test phase can be removed by using the RMB Remove Company in the Overview Companies window.
In order to handle Posting Control in a component it is required to create the following new Logical Units,
Note: The mentioned Logical Units are necessary if the component handles financial transactions and uses posting control definitions in Accounting Rules to create the transactions.
After having defined the new Logical Units some files representing these Logical Units have to be added to the source code of the component. The only thing that has to be done to make things work is to perform the following in the template files below:
The template files are:
File Name | Comment |
---|---|
InvoicPostingCtrl.utility | Template model file for a posting ctrl master LU. Module=INVOIC in this case. |
InvoicPostingCtrl.views | Template for all views defined by the entity for a posting ctrl master LU. Module=INVOIC in this case. |
InvoicPostingCtrl.plsql | Template for all business logic PL/SQL code implementation for a posting ctrl master LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetail.utility | Template model file for a posting ctrl detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetail.views | Template for all views defined by the entity for a posting ctrl detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetail.plsql | Template for all business logic PL/SQL code implementation for a posting ctrl detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetSpec.utility | Template model file for a posting ctrl detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetSpec.views | Template for all views defined by the entity for a posting ctrl detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetSpec.plsql | Template for all business logic PL/SQL code implementation for a posting ctrl detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlCombDet.utility | Template model file for a posting ctrl combination detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCombDet.views | Template for all views defined by the entity for a posting ctrl combination detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCombDet.plsql | Template for all business logic PL/SQL code implementation for a posting ctrl combination detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCDetSpec.utility | Template model file for a posting ctrl combination detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlCDetSpec.views | Template for all views defined by the entity for a posting ctrl combination detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlCDetSpec.plsql | Template for all business logic PL/SQL code implementation for a posting ctrl combination detail specification LU. Module=INVOIC in this case. |
Also note that it must be checked if a new release of IFS Applications contains a new version of the template files. If so the existing files in each component must be replaced by the new template versions.
In order to handle Footer in a component it is required to create the following new Logical Units,
After having defined the new Logical Units some files representing these Logical Units have to be added to the source code of the component. The only thing that has to be done to make things work is to perform the following in the template files below:
The template files are:
File Name | Comment |
---|---|
InvoicFooterConnection.utility | Template model file for a footer connection master LU. Module=INVOIC in this case. |
InvoicFooterConnection.views | Template for all views defined by the entity for a footer connection master LU. Module=INVOIC in this case. |
InvoicFooterConnection.plsql | Template for all business logic PL/SQL code implementation for a footer connection master LU. Module=INVOIC in this case. |
InvoicFooterField.utility | Template model file for a footer field master LU. Module=INVOIC in this case. |
InvoicFooterField.views | Template for all views defined by the entity for a footer field master LU. Module=INVOIC in this case. |
InvoicFooterField.plsql | Template for all business logic PL/SQL code implementation for a footer field master LU. Module=INVOIC in this case. |
Also note that it must be checked if a new release of IFS Applications contains a new version of the template files. If so the existing files in each component must be replaced by the new template versions.
A registration file must be included in all components supporting the new Create Company concept. It is named according to CreateCompanyReg<Component>.ins. The purpose with the file is to register information regarding the component in Enterprise.
The file consists of the following parts:
Some of the interfaces defined by the file EnterpCompConnectV170.plsql are described here: example5.ins
Two component registration file example are provided:
Start with setting the codegenproperties DbImplementation to "make-company" in the entity file.
For each attribute that is a part of the create company concept the property CompanyCopyColumnName should be set. This property sets the name of the make-company database table column. Columns are named Cx, Nx or Dx, where x is a number. E.g. C15, N2, D6.
Following methods are automatically generated when "make-company" property is set:
Import___
Import___
method is used
when creating a new company from a template.
Import___
method should read the template data and call
a validation method before inserting the data to the table.
Import_Assign___
... newrec_.valid_from := crecomp_rec_.valid_from; ...
This is done by
overriding the
Import_Assign___
method. See
example6.plsql
For both cases it might be necessary to consider special logic.
Copy___
Copy___
method is used when creating a new company from an existing company.
Copy_Assign___
... newrec_.valid_from := crecomp_rec_.valid_from; ...
This is done by overriding the
Copy_Assign___
method. See
example6.plsql
For both cases it might be necessary to consider special logic.
Export___
Export___
method is used when a template is created from a company.
Enterp_Comp_Connect_V170_API.Tem_Insert_Detail_Data
is used to define
the template data.Export_Assign___
Exist_Any___
Check_If_Do_Create_Company___
Create_Company_Reg__
Create_Client_Mapping__
Make_Company
make_company_='MODIFY_KEY_DATE'.
To facilitate this the Make_Company method needs to be overridden. See
example6.plsqlIn the current version of Create Company, data in Logical Units Currency Type and Currency Rate are never supplied via templates or companies. The default data will instead be taken from the tables Currency_Rate_Def_Tab and Currency_Type_Def_Tab.
User Related Data, i.e. data containing user identities, will be handled according to the following:
During internal import, i.e. when a company is created from a template or a company, then User Related Data is defined exactly as in the source template or company.
During internal export, i.e. when a template is created from a company then it is possible to choose if User Related Data should be taken from:
It is recommended to use a template as source for User Related Data and the default template will also be suggested as the source.
Note: When a new template file is created through the Export Company Template to File Assistant it is not very likely that user identities and user identity related data should be a part of the file, since these identities are specific for the current installation. For that reason it is recommended that another template should be used as source for creation of user identity related data when creating a user defined template from a company.
So if a new Logical Unit handles User Related Data, i.e. the Logical Unit has a reference to user or user_group, then
this case must be handled in a slightly different way than for other Logical Units.
The client attribute string that is sent to the Export___
method
will contain an attribute that defines the source for the user data and this
attribute must be considered.
One example is Logical Unit UserGroupFinance in Accounting Rules. The default user related data for the Logical Unit is stored in a template. The data in the template for the specific Logical Unit is used if the user so requests else the data in the source company is used. For implementation guidelines please look in the file UserGroupFinance.plsql in Accounting Rules. See section How to handle special implementation for different implementation guidelines for LU's with special implementations.
In order to create a template file the following cases must be considered first:
The first case is typical when developing new basic data Logical Units in a new component version. There is no old basic data available that can be used to fill the template with data for the Logical Unit. The following can be performed in this case:
In the second case the existing Logical Units are the same in the new component versions. However we may want to modify the contents in some of these Logical Units. The following can be performed in this case:
If the purpose is to create template files for a new component release then one template file per component should be created.
This sections covers specific implementation instructions like e.g. adding new data in Payment and how to handle special implementations.
If a new Payment Type has to be added to component Payment then the following can serve as a guideline:
This is an enumeration LU. The new type must be added to the list of types.
Specify a Payment Series ID for each Payment Type Code.
Note: Upgrade scripts should NOT handle definition of Series Id or the link between Payment Type Code and Series Id. After an upgrade data, the necessary data can be added via the Update Company functionality.
If special implementation is needed for the LU there are several ways to handle this:
Following methods are automatically generated when "make-company-abstract" property is set:
Make_Company
Create_Client_Mapping__
Create_Company_Reg__
Check_If_Do_Create_Company___
Exist_Any___
Following methods are automatically generated, but empty and code needs to be manually written:
Import___
Copy___
Export___
The current Create Company concept solves a lot of problems related to basic data setup for companies. The following considerations/limitations are worth mentioning:
By default all code part related Logical Units
are inactive. This means that values for e.g. Logical Unit "CodeB" (code
part B) are not stored in a delivered template, are not handled during
export of template and not copied when a company is created from another
company. This may lead to errors when posting control data is handled if the
posting control refers to code part values that are not available. It is
possible to activate these Logical Units but it must be done with care since
it is not at all sure that code part values can be "copied" from one company
to another, e.g. if a code part represents objects in the Fixed Asset
Accounting module.
If a code part is activated then it will still not be possible to import
data for the code part from the template to a company or to export data for
the code part from a company to a template, if the code part in the company
is associated with a code part function.
Translations of descriptions are supported and can thus be defined in any language. Note however that a Company Template may contain identities that must be modified with respect to language to fit the country or region that the template is supposed to support