This page (revision-44) was last changed on 26-Nov-2021 10:22 by khiggs

This page was created on 26-Nov-2021 10:22 by JEscott

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
44 26-Nov-2021 10:22 13 KB khiggs to previous
43 26-Nov-2021 10:22 13 KB khiggs to previous | to last
42 26-Nov-2021 10:22 14 KB RForbes to previous | to last DERIVATION EXPRESSIONS ==> DERIVATION_EXPRESSION_USAGE
41 26-Nov-2021 10:22 14 KB JMyers to previous | to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 3 changed one line
Derivation expressions provide the ability to translate values or to retrieve information otherwise not accessible in an interface format in [IDIF]. Data from within the [{$applicationname}] database may need to be translated to match the requirements from a receiving third party system. Also, data within a source file may need to be translated to match the [{$applicationname}] specifications.
Derivation expressions provide the ability to translate values or to retrieve information otherwise not accessible in an interface format in [IDIF]. Data from within the Personality database may need to be translated to match the requirements from a receiving third party system. Also, data within a source file may need to be translated to match the Personality specifications.
At line 7 changed one line
Inbound interfaces provide the ability to load a source file into ePersonality; this is done by running [LMTD]. The [LMTD] allows you to apply derivation expressions to variables within the record that is being loaded.
Inbound interfaces provide the ability to load a source file into Personality; this is done by running [LMTD]. The [LMTD] allows you to apply derivation expressions to variables within the record that is being loaded.
At line 22 added one line
*[UPDISBV] - Disburse Vendor Payments (A/P File Interface)
At line 33 removed one line
\\
At line 36 added one line
At line 38 removed one line
\\
At line 40 added one line
At line 42 removed one line
\\
At line 44 added one line
At line 46 removed one line
\\
At line 48 added one line
At line 50 removed one line
\\
At line 52 added one line
At line 54 changed one line
\\
At line 58 removed one line
\\
At line 60 added one line
At line 62 removed one line
\\
At line 64 added one line
At line 66 removed one line
\\
At line 68 added one line
At line 71 changed one line
\\
At line 74 removed one line
\\
At line 76 added one line
At line 78 removed one line
\\
At line 80 added one line
At line 82 removed one line
\\
At line 84 added one line
At line 87 removed one line
\\
At line 89 added one line
At line 92 changed one line
\\
At line 96 changed one line
\\
At line 99 removed one line
\\
At line 101 added one line
At line 104 changed one line
\\
At line 108 changed one line
\\
At line 112 changed 2 lines
\\
;Translate an incoming value to a defined Time Code in the system using a translation lexicon. The lexicon is defined in [IMLN], the saved value is the value defined in the source file and the displayed value is the eP translation, in this example the time code.
;Translate an incoming value to a defined Time Code in the system using a translation lexicon. The lexicon is defined in [IMLN], the saved value is the value defined in the source file and the displayed value is the translation, in this example the time code.
At line 120 added one line
----
At line 117 changed one line
![IDIF] - Derivation Expression - Multiple Field Processing
! Multiple Field Processing
At line 126 changed 2 lines
*If the Pay Header Group user-defined field (UDF) 'PROJECT HOURS BY PERSON' is 'Y', this means that the employee is an 'ADMIN' employee and if the journal entry is reporting for 'Hours', then use the Identity eid.id on the Interface File field.
Otherwise, use the Unit dun.id on the field for all other situations.
*If the Pay Header Group user-defined field (UDF) 'PROJECT HOURS BY PERSON' is 'Y', this means that the employee is an 'ADMIN' employee and if the journal entry is reporting for 'Hours', then use the Identity eid.id on the Interface File field. Otherwise, use the Unit dun.id on the field for all other situations.
At line 129 changed 5 lines
*In the derivation expression, enter: decode(~,'Y',decode([[320803],'02',[[320009],[[350400]),[[350400])
where: \\[[320803] Journal Type (DGA), 01 - Financial Journal, 02 - Statistical Journal \\[[320009] Identity eid_id \\
[[350400] Unit dun_id (DUN)
* This derivation expression means decode the value of ~ from UDF. If the value is 'Y', then decode the value from [[320803] Journal Type. If the journal type is '02' Statistical Journal, then return [[320009] Identify eid.id. Otherwise, return [[350400]
Unit dun_id.
*In the derivation expression, enter:
;: decode(~,'Y',decode([[320803],'02',[[320009],[[350400]),[[350400])
;:where:
;:[[320803] Journal Type (DGA), 01 - Financial Journal, 02 - Statistical Journal
;:[[320009] Identity eid_id
;:[[350400] Unit dun_id (DUN)
* This derivation expression means decode the value of ~ from UDF. If the value is 'Y', then decode the value from [[320803] Journal Type. If the journal type is '02' Statistical Journal, then return [[320009] Identify eid.id. Otherwise, return [[350400] Unit dun_id.
Example: Record # 50, Field # 10 Requirement: Work Date or Pay Period
*If the Pay Header Group user-defined field (UDF) 'PROJECT HOURS BY PERSON' is 'Y', this means that the employee is an 'ADMIN' employee. In this case use the pay period on the interface file field, otherwise use the GL Effective date on the Interface File field.
*From above [IDIF] set up, you should specify the Variable Name using 'UDF (DGD)' and enter the UDF name in Constant Value field, then the value of UDF will be returned and represented as ~ in the derivation expression.
*In the derivation expression, enter: \\
;:decode(~,'Y',[320102],to_char(to_date([[320756]),'DD/MM/YYYY'))
;: where:
;:[[320102] Pay Period
;:[[320756] GL Eff Date (PJD)
*This derivation expression means decode the value of ~ from UDF. If the value is 'Y', then return the value from [[320102] pay period. Otherwise, return the value from [[320756] GL Effective date with the date format of 'DD/MM/YYYY'.
!Internal Functions
You have the ability to call some Personality internal functions in the derivation expression under the guidance of a consultant.
One example of doing this is for the [UPPHF] Payroll History interface. In this example, the Hours Comp Time Amount field is defined with the Variable Name 'Pay Header pph_id' and with a derivation Expression of:
;: P2K_PPAMTS.SPELPAY(~,P2K.PPAMTS.SPGETPEL('HOURS COMP TIME'))
The derivation expression will return the Element value of 'HOURS COMP TIME'.
The above example can also be achieved by setting up a variable name of 'Element pph
Value' with the element code specified in the Constant Value field.
!Internal Functions with Parameters
You have the ability to call some Personality internal functions in the derivation expression under the guidance of a consultant and pass the following internal parameters in order to perform some internal calculation:
;#PPH_ID#
;:This value must be in capital letters; this #PPH_ID# will be replaced by the current pay header's pph.id.
;#EEM_ID#
;:This value must be in capital letters; this #EEM_ID# will be replaced by the current employment's eem.id.
;#EID_ID#
;:This value must be in capital letters; this #EID_ID# will be replaced by the current identity's eid.id e.g. the Element PC value of 'HOURS O/T' will be retrieved first and is represented as ~ in derivation expression. The derivation expression will return the Element value of 'HOURS COMP TIME' for #PPH_ID# and add it to the value of ~.
;:Example:
;:The OT Hours field name is defined with the Variable Element PC Value with a Constant Value of HOURS O/T and has a derivation expression of:
;:P2K_PPAMTS.SPELPAY(#PPH_ID#,P2K_PPAMTS.SPGETPEL('HOURS COMP TIME')),~
;:You may perform some internal arithmetic calculation in the derivation expression to return some prorated amount.
;:Example:
;:The 'Prorate Element' Field Name is defined with the Varibale Name of elemnt PC Value with a Derivation Expression of:
;:~/P2K_PPAMTS.SPELPAY(#PPH_ID#,P2K-PPAMTS.SPGETPEL('HOURS O/T'))*P2K_PPAMTS.SPELPAY(#PPH_ID#,P2K_PPAMTS.SPGETPEL('HOURS COMPE TIME'))
!Call UserCalc Function
You can call the [UserCalc|USERCALC] function at each Record Number and each Field Number. You should set up the variable name to be 'User Calc', and specify the [UserCalc|USERCALC] name in the Constant Value field.
The field type must be defined with a Char, Number or Date type. The Return Value [UserCalc|USERCALC] function on [IMUC] screen must match the values (Char, Number or Date) with the [IMUC] RET command to return the corresponding Char, Number or Date.
The data base tables available for UserCalc are:
;:at company level: DEN / DLN / DDP / DDD / DUN / DGR / DGD / DGV
;:at employee level: EID / EPS / EEM / EAS / EASD / PPRU / PPRC
!BYPASS Capability
*On [IDIF] Derivation expression, you may decode the Variable Name using the ~ character and return the word 'BYPASS' to bypass the Detail record entry that is with certain criteria.
* The 'BYPASS' criteria can be set up for Record Type = 'Qualify Record', 'Detail Record', and should not be used for Header and Trailer records.
* If the return value of any [IDIF] Record Number/Field Number = 'BYPASS', then this Detail record will be bypassed and will not be written to the Interface file.
;:Example:
*to include only Departments start with 'P' on interface file: decode(rtrim(substr(~,1,1)),'P',~,'BYPASS')
* to include only Departments ends with 'C' on interface file: decode(substr(~,length(rtrim(~)),1),'C','BYPASS',~)
* to bypass Cost Centers that has '????' in second segments: decode(SUBSTR(~,5,4),'????','BYPASS',SUBSTR(~,5,4))
* to include Journal Entries with Account Numbers over 40000 in segment 5: decode(greatest('40000',substr(~,16,5)),'40000','BYPASS',substr(~,16,5))
! GOTO#nn#nnn
* when processing [IDIF] records of the same Record Type (e.g. Detail Record), you may want to skip some Record # Field # based on certain criteria and resume processing of the same Record Type at a later Record# Field# onward
* the following GOTO capabilities are available for all Record Types in Derivation Expression:
;:GOTO#nn#nnn where the 1st nn is the Record #, the 2nd nnn is the Field #
* since the [IDIF] entries are processed in chronological order, GOTO#nn#nnn must be for a Record# Field# that is after the current Record# Field#
* if an incorrect GOTO#nn#nnn is specified, or the #nn#nnn is NOT for the same Record Type, or if it is for a previous Rec# Field#, an exception message will be issued, the GOTO statement cannot be executed after skipping the records, you must verify the Interface File from this point onward
* multiple GOTO#nn#nnn can be used within the same Record Type
* if an Invalid GOTO is encountered in [IDIF] definition, the Trial mode parameter is set to 'Y' in order to prevent the Updating of the user-defined fields from the Record Type '92-Update Record'
* for XML File Format, the GOTO#nn#nnn can be used to skip certain XML Tags and carry on the processing
*for Fixed File Format, if the GOTO#nn#nnn is for the current Record#, it will GOTO the specified #nn#nnn, the current Record# information will be written
* for Fixed File Format, if the GOTO#nn#nnn is for a different Record#, it will GOTO the specified #nn#nnn of the different Record#, the current Record# information will NOT be written
* e.g. [UEEF] [IDIF] Record# 30 Field # 45, decode Plan_Code, if it equals to 'HL GROUP LIFE', GOTO#35#10
** this will skip the entire Record# 30 and carry on from Record# 35 Field#10 for the fixed file format
----
![Notes|Edit:Internal.DERIVATION+EXPRESSIONS]
[{InsertPage page='Internal.DERIVATION+EXPRESSIONS' default='Click to create a new notes page'}]