Skip to content

Posting Types and Control Types

How Financial transactions should be posted is controlled by the Posting Control functionality within IFS Finance. 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.

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:

File Name Comment
PctrlBasicDataInvoic.ins Contains posting control specific data for the component/module INVOIC.
PctrlBasicDataWo.ins Contains posting control specific data for the component/module WO.

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 page. 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_ Control Type Categories that is possible to use:
    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 Cloud).
    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:
    1. Check existence of a control type value. This implies that the package has an Exist method.
    2. 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:
    * 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 file have to be created in this case:
      • <module>PostingCtrlTrans.utility One example is the Logical Unit EquipPostingCtrlTrans that is represented by the file:
      • EquipPostingCtrlTrans.utility
    • 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.