Foundation1 / Development Guide / Ifs Applications Business Components / Posting Control Types / This page

Posting Types and Control Types

How Financial transactions should be posted is controlled by the Posting Control functionality within IFS Financials. Any component can register posting (event) types and control types in the Posting Control framework. Applicable posting and control types are sent to the Posting Control framework to retrieve the code string that defines the posting information of a transaction.

Use this page do learn more about how to register posting and control types for a component as well as how related translations are handled.

Contents

• Handling Basic Data for Posting Control
• Handling Translation Support for Posting Control Basic Data

Handling Basic Data for Posting Control

All component specific basic data related to Posting Control should be placed in a file named PctrlBasicData<Component>.ins. The file normally contains the following sections:

• Posting Types for the component
• Control Types for the component
• Allowed combinations of Posting Types and Control Types

Example files for posting control related basic data:

The following interfaces in package POSTING_CTRL_API can be used:

1. Registration of posting type

   PROCEDURE Insert_Posting_Type (
      posting_type_  IN VARCHAR2,
      description_   IN VARCHAR2,
      module_        IN VARCHAR2,
      ledg_flag_     IN VARCHAR2,
      tax_flag_      IN VARCHAR2 DEFAULT NULL,
      currev_flag_   IN VARCHAR2 DEFAULT NULL,
      logical_unit_  IN VARCHAR2 DEFAULT NULL,
      sort_order_    IN NUMBER   DEFAULT NULL );
   

   Parameter Name	Description
   posting_type_	Identity of the posting type
   description_	Posting type description
   module_	Module/component that owns the posting type
   ledg_flag_	If the posting type is used for account specific Posting Control then this parameter defines if the account must be a ledger account or not. Valid values are Y or N
   tax_flag_	If the posting type is used for account specific Posting Control then this parameter defines if the account must be a tax account or not. Valid values are Y or N. Default value is N
   currev_flag_	Specific parameter for currency revaluation in the General Ledger. If the posting type represents customer ledger events then the value should be AR.  If the posting type represents supplier ledger events then the value should be AP. Currently used only by INVOIC and PAYLED Components. Default value is NULL
   logical_unit_	Logical Unit name to be used as placeholder for basic data translation. Default value is NULL. See Handling Translation Support for Posting Control Basic Data for more information.
   sort_order_	Defines sort order of the posting type within a module/component in the Posting Control window. The sort order will be based on module, sort order, code part and valid from.

    

2. Allow posting type as part of combination control type definition

   PROCEDURE Set_Cct_Enabled (
      posting_type_ IN VARCHAR2 );

   Parameter Name	Description
   posting_type_	Identity of the posting type

    

3. Registration of control type

   PROCEDURE Insert_Control_Type (
      control_type_       IN VARCHAR2,
      module_             IN VARCHAR2,
      description_        IN VARCHAR2,
      ctrl_type_category_ IN VARCHAR2,
      view_name_          IN VARCHAR2,
      pkg_name_           IN VARCHAR2,
      logical_unit_       IN VARCHAR2 DEFAULT NULL );
   

   Parameter Name	Description
   control_type_	Identity of the control type
   module_	Module that owns the control type
   description_	Control type description
   ctrl_type_category_	Value Description FIXED This means that the control type must be set up so that the same code part value will always be returned from the rule. PREPOSTING This means that the user is expected to provide the code part value before the postings are created. ORDINARY All system-defined control types that are neither Fixed Value nor Pre Posting fall into this category. The resulting code part value will be determined by the detailed instructions in IFS Accounting/Accounting Rules. (Refer Posting Control under Topics in IFS Applications) COMBINATION This means that the control type is a user-defined combination of two other control types that belong to the Ordinary category.
   view_name_	View reference typically to support List of Values for the control type values. E.g. the value PAYMENT_TERM(COMPANY) means that the List of Values view name is PAYMENT_TERM and it has COMPANY as parent.
   pkg_name_	Name of package to be used to: Check existence of a control type value. This implies that the package has an Exist method. Get the description of a control type value. This implies that the package has a Get_Control_Type_Value_Desc method
   logical_unit_	Logical Unit name to be used as placeholder for basic data translation. Default value is NULL. See Handling Translation Support for Posting Control Basic Data for more information.

4. Registration of allowed combinations of posting type and control type

   PROCEDURE Insert_Allowed_Comb (
      posting_type_     IN VARCHAR2,
      control_type_     IN VARCHAR2,
      module_           IN VARCHAR2,
      code_part_        IN VARCHAR2 );

   Parameter Name	Description
   posting_type_	Identity of the posting type
   control_type_	Identity of the control type
   module_	Module that owns the specified control type
   code_part_	Code part that the combination is allowed for. Allowed values are: Value Description * Applies to all code parts A Applies to code part A (Account) B Applies to code part B C Applies to code part C D Applies to code part D E Applies to code part E F Applies to code part F G Applies to code part G H Applies to code part H I Applies to code part I J Applies to code part J

Handling Translation Support for Posting Control Basic Data

Descriptions of posting types and control types are supported by the Basic Data Translation framework according to the following:

• When a component registers new control and posting types, normally via the PctrlBasicData<module>.ins script, translatable attributes will be registered in the Basic Data Translation framework.

  The description will be defined as the PROG text.

• If the control or posting type already exists when the script is executed then the description for each type will update the installation text for the PROG entry. No specific language will be involved.
• The posting and control types will be defined as attribute keys in the translation framework.
• Each attribute must be associated with a module and a Logical Unit. The Logical Unit can be specified when performing the registration of each type, but can also be unspecified meaning that a default Logical Unit will be defined.

  The method in POSTING_CTRL_API to be used to register a posting type looks as follows:

  PROCEDURE Insert_Posting_Type (
     posting_type_  IN VARCHAR2,
     description_   IN VARCHAR2,
     module_        IN VARCHAR2,
     ledg_flag_     IN VARCHAR2,
     tax_flag_      IN VARCHAR2 DEFAULT NULL,
     currev_flag_   IN VARCHAR2 DEFAULT NULL,
     logical_unit_  IN VARCHAR2 DEFAULT NULL,
     sort_order_    IN NUMBER   DEFAULT NULL )
  

  The argument logical_unit_ in Insert_Posting_Type method,  can be used to specify a Logical Unit in module_ that should be used as parent for the translation key.

   

  The method in POSTING_CTRL_API to be used to register a control type looks as follows:

  PROCEDURE Insert_Control_Type (
     control_type_       IN VARCHAR2,
     module_             IN VARCHAR2,
     description_        IN VARCHAR2,
     ctrl_type_category_ IN VARCHAR2,
     view_name_          IN VARCHAR2,
     pkg_name_           IN VARCHAR2,
     logical_unit_       IN VARCHAR2 DEFAULT NULL )

  The argument logical_unit_ in Insert_Control_Type can be used to specify a Logical Unit in module_ that should be used as parent for the translation key.

   

  In both of the described cases the following happens if the parent Logical Unit is omitted:

• If the Logical Unit <module>PostingCtrl exists, then it will be used as the translation placeholder.
• Else if the Logical Unit <module>PostingCtrlTrans, e.g. EquipPostingCtrlTrans, exists then this Logical Unit will be used.

  The idea is to have a way to specify a Posting Control related Logical Unit to be used as a translation placeholder, if the component does not have a Logical Unit as <module>PostingCtrl. The following files have to be created in this case:

  • <module>PostingCtrlTrans.utility
  • <module>PostingCtrlTrans.plsql
  • <module>PostingCtrlTrans.views

  One example is the Logical Unit EquipPostingCtrlTrans that is represented by the files:

  • EquipPostingCtrlTrans.utility
  • EquipPostingCtrlTrans.plsql
  • EquipPostingCtrlTrans.views
• Else the Logical Unit PostingCtrlPostingType will be used for posting types and the Logical Unit PostingCtrlControlType will be used for control types.

  Note: This case is not the preferable one since the two Logical Units PostingCtrlPostingType and PostingCtrlControlType only exists for module_='ACCRUL', meaning that a combination like module_= 'EQUIP' and
Logical Unit_= 'PostingCtrlPostingType' cannot be found by the translation framework.
  Translations must in this case be handled manually.

• The translation framework can be used to build all translatable basic data related attributes and among these we will find the posting types and the control types.