The IFS Applications 8 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 Application Base Setup / Enterprise / Company / Company Template / 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.api | Template package specification for a posting ctrl master LU. Module=INVOIC in this case. |
InvoicPostingCtrl.apy | Template package body specification for a posting ctrl master LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetail.api | Template package specification for a posting ctrl detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetail.apy | Template package body specification for a posting ctrl detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCombDet.api | Template package specification for a posting ctrl combination detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCombDet.apy | Template package body specification for a posting ctrl combination detail LU. Module=INVOIC in this case. |
InvoicPostingCtrlCDetSpec.api | Template package specification for a posting ctrl combination detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlCDetSpec.apy | Template package body specification for a posting ctrl combination detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetSpec.api | Template package specification for a posting ctrl detail specification LU. Module=INVOIC in this case. |
InvoicPostingCtrlDetSpec.apy | Template package body specification for a posting ctrl 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.
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 files EnterpCompConnectV170.api and EnterpCompConnectV170.apy and are described here: example5.ins
Two component registration file example are provided:
Start with creating a new so called PCT view
Each Logical
Unit has a PCT view that selects the data from the Logical Unit that can be a part of a template. The view
is used internally by a the method Export___
during the export process.
The view is named according to <LUVIEW>_PCT, where <LUVIEW> is e.g. VOUCHER_TYPE for Logical Unit VoucherType.
Note the following:
- The PCT view should only contain the items in the Logical Unit that supports Company Templates.
- There might be data that is not 100% related to one single Logical Unit. If so the view should be defined in the most appropriate Logical Unit.
The data for the Logical Unit is sent to the Company Template framework via the public method
Enterp_Comp_Connect_V170_API.Tem_Insert_Detail_Data
An example of a PCT view is found here: example6.apy
Next step will be to add some new methods in each Logical Unit.
Import___
This method is used when creating a new company from a template.
The Import___
method should read the template data and call
a validation method before inserting the data to the table.
If the Logical Unit is using a date attribute as <ValidFrom> that defines a starting from date, then:
... newrec_.valid_from := crecomp_rec_.valid_from; ...
For both cases it might be necessary to consider special logic.
Copy___
The Copy___
method is used when creating a new company from an existing company.
Validations are necessary even if the data in the source company most likely is consistent
If the Logical Unit is using a date attribute as <ValidFrom> that defines a starting from date, then:
... newrec_.valid_from := crecomp_rec_.valid_from; ...
For both cases it might be necessary to consider special logic.
Export___
The export method is used when a template is created from a company.
The PCT view is used to fetch the appropriate information from the
Logical Unit and then the public interface
Enterp_Comp_Connect_V170_API.Tem_Insert_Detail_Data
is used to define
the template data.
Make_Company
This public method is called when creating a new company and also for updating a Difference Template when the Logical Unit has a date as a part of the key.
When a company is created then the procedure is called with make_company_= 'IMPORT'
action_= 'NEW'
action_='DUPLICATE'
When creating a company template then the procedure is called with make_company_='EXPORT'
When updating a difference template with the recalculated date then the procedure is called with
make_company_='MODIFY_KEY_DATE'
Examples:
- A simple/standard Logical Unit: example7_1.apy
- A Logical Unit with date as a part of the key: example7_2.apy
In 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 usergrfi.apy in Accounting Rules.
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.
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.
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