Skip to content

Functionality

This page describes the functionality of the IFS Financial Connector.

Send Voucher

Many components in IFS Cloud create data that cause changes in the account balances of a General Ledger application. All these activities within IFS Cloud cause the creation of a voucher. Some components that have activities which will be reflected in a voucher are Inventory, Costing and Human Resources. Vouchers can also be registered manually in the Accounting Rules component. All vouchers will end up in the Accounting Rules component. Send Voucher will send these vouchers to a General Ledger application in another ERP system.

Basic Data - Send Voucher

The process Send Voucher has the following basic data parameters that control the behavior of the process. These attributes are company specific and can be changed in a dedicated page.

Attribute Description
Include Zero Amount If this option is enabled, voucher rows with a zero amount are included in transfers
Store Confirmed Vouchers If this option is enabled, transferred vouchers for this company will be archived. This check box is applicable only when Voucher Source is Hold Table
Max Number in Transfer The maximum number of vouchers that should be included in one transfer message (xml file). If needed, several transfer messages are created.
Voucher Source Hold Table is default. If General Ledger is selected, only vouchers that are first updated to IFS General Ledger will be included in the transfer.
Message Format  specify the message format (XML or JSON) in which IFS Connect will send the messages .

If the attribute Include Voucher in Document in the basic data for Send Supplier Invoice or Send Customer Invoice is set to true, the vouchers connected to those invoice types should not be included.

Transfer - Send Voucher

The transfer is started in the Transfer Vouchers assistant where the Until Voucher Date should be entered, defaulted to current date. There is also a possibility to change the company or run the transfer in batch and to schedule it.

All vouchers complying with the basic data settings, the Until Voucher Date parameter and that does not have the field voucher updated set to Y will be selected for transfer.

The vouchers selected for transfer are marked as updated if voucher source is Hold Table or transferred if voucher source is General Ledger and recorded in the Voucher_In_Transfer_Tab table. This table consists of the keys of the vouchers and an additional column for Transfer_State. The Transfer_Stateis set to Under_Transfer for each voucher recorded

The voucher data is put together to a business object structure (see Data) and sent to the receiver by the use of IFS Moddle tier

Confirmation - Send Voucher

Confirmation of a transfer is made on the complete transfer message, which can include several vouchers. If one of the vouchers is erroneous then all the vouchers in the transfer message is treated as erroneous.

When a confirmation is received that a transfer was successful then the vouchers belonging to the transfer are removed from the Voucher_In_Transfer_Tab table. If voucher source is Hold Table the voucher is also removed from the Voucher table. If Store Confirmed Transferred Voucher is set to true then the voucher is entered into the voucher archive tables.

When a confirmation is received that a transfer was unsuccessful then the transfer state in Voucher_In_Transfer_Tab is set to Error and the error message is recorded in the error tables.

From the Vouchers In Transfer page there is a possibility to restore the erroneous vouchers for transfer again. The field voucher_updated is set to N and the voucher is removed from Voucher_In_Transfer_Tab and the error tables

Data - Send Voucher

The data that is sent in Send Voucher is put together to a business object structure. Below is the main business object structure for Send Voucher. For a complete listing of the content of the business objects please refer to Appendix A

Send Supplier Invoice

Supplier invoices can be registered manually in the Invoice component, created directly from a purchase order arrival or be imported via external interfaces. All invoices will end up in the invoice component. Send Supplier Invoice will send supplier invoices that have been authorized for payment to another ERP system’s payables application

Basic Data - Send Supplier Invoice

The process Send Supplier Invoice has the following basic data parameters that control the behavior of the process. These attributes are company specific and can be changed in a dedicated page.

Attribute Description
Include Finally Posted Invoices If this option is enabled, final posted supplier invoices will be included in transfers for this company.
Include Preliminary Posted Invoices If this option is enabled, preliminary posted supplier invoices will be included in transfers for this company.
Include Voucher in Document If this option is enabled, the accounting information is included in the transfer and the corresponding voucher will not be included in Send Voucher transfers.
Store Confirmed Vouchers If this option is enabled, transferred vouchers for this company will be archived. This check box is applicable only when Voucher Source is Hold Table.
Include Voucher Rows With Zero in Amount If this option is enabled, voucher rows with a zero amount are included in transfers. This option is applicable only when the Include Voucher in Document toggle is selected
Remove IP5 Voucher Rows If this option is enabled, voucher rows with posting type IP5 will be removed from the transfer for finally posted invoices. This option is applicable only when the Include Voucher in Document toggle is selected
Max Number in Transfer The maximum number of supplier invoices that should be included in one transfer message (xml file). If needed, several transfer messages are created.
Voucher Source Hold Table is default. If General Ledger is selected, only invoices where the voucher reference first is updated to IFS General Ledger will be included in the transfer.
Message Format specify the message format (XML or JSON) in which IFS Connect will send the messages .

Transfer - Send Supplier Invoice

The transfer is started in the Transfer Supplier Invoices assistant where the Until Invoice Date should be entered, defaulted to current date. There is also a possibility to change the company or run the transfer in batch and to schedule it.

All supplier invoices complying with the basic data settings, the Until Invoice Date parameter and that is not currently under transfer will be selected for transfer.

The supplier invoices selected for transfer are recorded in the Supp_Invoice_In_Transfer_Tab table. This table consists of the keys of the supplier invoices and an additional column for Transfer_State. The Transfer_State is set to Under_Transfer for each supplier invoice recorded. The Transfer_State in the invoice table is also updated to Under_Transfer for each supplier invoice.

The supplier invoice data is put together to a business object structure (see Data) and sent to the receiver by use of IFS Middle tier

Confirmation - Send Supplier Invoice

Confirmation of a transfer is made on the complete transfer message, which can include several supplier invoices. If one of the invoices is erroneous then all the invoices in the transfer message is treated as erroneous.

When a confirmation is received that a transfer was successful then the supplier invoices are removed from the Supp_Invoice_In_Transfer_Tab table and the Transfer_Status in the invoice table is updated to Transferred.

When a confirmation is received that a transfer was unsuccessful then the transfer state in Supp_Invoice_In_Transfer_Tab is set to Error and the error message is recorded in the error tables. The transfer status in the invoice table is also changed to Error.

From the Supplier Invoices In Transfer page there is a possibility to restore the erroneous supplier invoices for transfer again. The transfer status of the supplier invoices is reset and the supplier invoices are removed from Supp_Invoice_In_Transfer_Tab and the error tables.

Data - Send Supplier Invoice

The data that is sent in Send Supplier Invoice is put together to a business object structure. Below is the main business object structure for Send Supplier Invoice. For a complete listing of the content of the business objects see Appendix A.

Send Customer Invoice

The purpose of Send Customer Invoice is to send customer invoices that exist in the invoice component to another ERP system’s receivables application.

Basic Data - Send Customer Invoice

The process Send Customer Invoice has the following basic data parameters that control the behavior of the process. These attributes are company specific and can be changed in a dedicated page.

Attribute Description
Include Voucher in Document If this option is enabled, the accounting information is included in the transfer and the corresponding voucher will not be included in Send Voucher transfers.
Store Confirmed Vouchers If this option is enabled, transferred vouchers for this company will be archived. This check box is applicable only when Voucher Source is Hold Table.
Max Number in Transfer The maximum number of customer invoices that should be included in one transfer message (xml file). If needed, several transfer messages are created.
Voucher Source Hold Table is default. If General Ledger is selected, only invoices where the voucher reference first is updated to IFS General Ledger will be included in the transfer.
Message Format specify the message format (XML or JSON) in which IFS Connect will send the messages .

Transfer - Send Customer Invoice

The transfer is started in the Transfer Customer Invoices assistant where the Until Invoice Date should be entered, defaulted to current date. There is also a possibility to change the company or run the transfer in batch and to schedule it.

All customer invoices complying with the basic data settings, the Until Invoice Date parameter and that are not currently under transfer will be selected for transfer.

The customer invoices selected for transfer are recorded in the Cust_Invoice_In_Transfer_Tab table. This table consists of the keys of the customer invoices and an additional column for Transfer_State. The Transfer_State is set to Under_Transfer for each customer invoice recorded. The Transfer_State in the invoice table is also updated to Under_Transfer for each customer invoice.

The customer invoice data is put together to a business object structure (see Data) and sent to the receiver by use of IFS Middle tier

Confirmation - Send Customer Invoice

Confirmation of a transfer is made on the complete transfer message, which can include several customer invoices. If one of the invoices is erroneous then all the invoices in the transfer message is treated as erroneous.

When a confirmation is received that a transfer was successful then the customer invoices are removed from the Cust_Invoice_In_Transfer_Tab table and the Transfer_Status in the invoice table is updated to Transferred.

When a confirmation is received that a transfer was unsuccessful then the transfer state in Cust_Invoice_In_Transfer_Tab is set to Error and the error message is recorded in the error tables. The transfer status in the invoice table is also changed to Error.

From the Customer Invoices In Transfer page there is a possibility to restore the erroneous customer invoices for transfer again. The transfer status of the customer invoices is then reset and the customer invoices are removed from Cust_Invoice_In_Transfer_Tab and the error tables.

Data - Send Customer Invoice

The data that is sent in Send Customer Invoice is put together to a business object structure. Below is the main business object structure for Send Customer Invoice. For a complete listing of the content of the business object see Appendix A

Note: For outbound services Send Voucher, Send Supplier Invoice, Send Customer Invoice users are allowed to determine the document format which it can be transferred between XML and JSON. This can be determined using the Message Format basic data entry for each service using as mentioned above.

In order this to work in desired format, users have to configure respective routing rules of services.

For example, if users wants to communicate Send Voucher service in XML format, message function should be equal to SEND_VOUCHER in the content based condition of routing rule (Default condition in given routing rule example). If it is JSON wanted by user, the message function should be equal to SEND_VOUCHER_JSON. Users can refer IFS Outbound Message Viewer to explore about functionalities and message formats of outbound services IFS provides.

Receive Supplier Info

The purpose of Receive Supplier Info is to facilitate keeping supplier information synchronized that exists in separate systems. Receive Supplier Info can add new suppliers and modify previously established suppliers.

Action - Receive Supplier Info

The ReceiveSupplierInfo action receives a ReceiveSupplierInfo structure and calls the Receive_Supplier_Util_API's for each Supplier in the structure.

Receive_Supplier_Util_API

The Receive_Supplier_Util_API holds the public interface for creating and modifying supplier information and contains the following methods,

Method Description
Exec_Supplier If the supplier exists in the database then SUPPLIER_INFO_API.Modify__ is called otherwise SUPPLIER_INFO_API.New__ is called.
Exec_Identity_Invoice_Info If the identity invoice info exists in the database then IDENTITY_INVOICE_INFO_API.Modify__ is called otherwise IDENTITY_INVOICE_INFO_API.New__ is called
Exec_Address If the address exists in the database then SUPPLIER_INFO_ADDRESS_API.Modify__ is called otherwise SUPPLIER_INFO_ADDRESS_API.New__ is called
Exec_Comm_Method If the communication method exists in the database then SUPPLIER_INFO_COMM_METHOD_API.Modify__ is called otherwise SUPPLIER_INFO_COMM_METHOD_API.New__ is called

Data - Receive Supplier Info

The data in Receive Supplier Info is received in a business object structure. Below is the main business object structure for Receive Supplier Info. For a complete listing of the content of the business objects see Appendix A.

Receive Customer Info

The purpose of Receive Customer Info is to facilitate keeping customer information synchronized that exists in separate systems. Receive Customer Info can add new customers and modify previously established customers.

Action - Receive Customer Info

The ReceiveSupplierInfo action receives a ReceiveCustomerInfo structure and calls the Receive_Customer_Util_API for each Customer in the structure.

Receive_Customer_Util_API

The Receive_Customer_Util_API's holds the public interface for creating and modifying customer information and contains the following methods,

Method Description
Exec_Customer If the customer exists in the database then CUSTOMER_INFO_API.Modify__ is called otherwise CUSTOMER_INFO_API.New__ is called.
Exec_Identity_Invoice_Info If the identity invoice info exists in the database then IDENTITY_INVOICE_INFO_API.Modify__ is called otherwise IDENTITY_INVOICE_INFO_API.New__ is called
Exec_Address If the address exists in the database then CUSTOMER_INFO_ADDRESS_API.Modify__ is called otherwise CUSTOMER_INFO_ADDRESS_API.New__ is called
Exec_Comm_Method If the communication method exists in the database then CUSTOMER_INFO_COMM_METHOD_API.Modify__ is called otherwise CUSTOMER_INFO_COMM_METHOD_API.New__ is called

Data - Receive Customer Info

The data in Receive Customer Info is received in a business object structure. Below is the main business object structure for Receive Customer Info. For a complete listing of the content of the business objects see Appendix A.

Receive Currency Rate

The purpose of Receive Currency Rate is to keep currency information synchronized that exists in separate systems.

Action - Receive Currency Rate

The ReceiveCurrencyRate action receives a ReceiveCurrencyRate structure and calls the Receive_Currency_Rate_Util_API's for each Currency_Rate in the structure.

Receive_Currency_Rate_Util_API

The Receive_Currency_Rate_Util_API holds the public interface for creating and modifying currency rates and contains the following methods,

Method Description
Exec_Currency_Rate If the ref_currency_code from the sender is not the same as the ref_currency_code in the database for the currency type then an error is raised.
The method CURRENCY_RATE_API.New__ is called
Exec_Currency_Code If the currency code exists in the currency_code_tab table in the database then CURRENCY_CODE_API.Modify__ is called otherwise the currency code is activated by calling ISO_CURRENCY_API.Activate_Code and then CURRENCY_CODE_API.New__.

Data - Receive Currency Rate

The data in Receive Currency Rate is received in a business object structure. Below is the main business object structure for Receive Currency Rate. For a complete listing of the content of the business objects see Appendix A.

Receive Account

The purpose of the Receive Account is to keep account information that exists in separate systems synchronized.

Action - Receive Account

The ReceiveAccount actions receives a ReceiveAccount structure and calls the Receive_Code_Part_Util_API's for each Account in the structure.

Receive_Code_Part_Util_API

The Receive_Code_Part_Util_API holds the public interface for creating and modifying accounts by using the following method,

Method Description
Exec_Account If the account exists in the database then ACCOUNT_API.MODIFY__ otherwise ACCOUNT_API.New__ is called

Data - Receive Account

The data in Receive Account is received in a business object structure. Below is the main business object structure for Receive Account. For a complete listing of the content of the business objects see Appendix A

Receive Code Part

The purpose of the Receive Code Part is to keep code part information that exists in separate systems synchronized¨.

Action- Receive Code Part

The ReceiveCodePart action receives a ReceiveCodePart structure and calls the Receive_Code_Part_Util_API's for each CodePart in the stucture.

Receive_Code_Part_Util_API

The Receive_Code_Part_Util_API holds the public interface for creating and modifying code part values by using the following method,

Method Description
Exec_Code_Partt If the code part value exists in the database then ACCOUNTING_CODE_PART_VALUE_API.MODIFY__otherwise ACCOUNTING_CODE_PART_VALUE_API.New__ is called

Data - Receive Code Part

The data in Receive Code Part is received in a business object structure. Below is the main business object structure for Receive Code Part. For a complete listing of the content of the business objects see Appendix A

OAG

The Open Applications Group (OAG) is a non-profit consortium focusing on best practices and process based XML content for e-Business and Application Integration. Open Applications Group, Inc. members have many years of extensive experience in building this industry consensus based framework for business software application interoperability and have developed a repeatable process for quickly developing high quality business content and XML representations of that content.

The Business Object Document is the architecture used to communicate messages or business documents between software applications or components. Each Business Object Document includes supporting details to enable the destination business application to accomplish the action.

The Financial Connector supports version 7.2 and 8.0 of the OAG standard.

OAG 7.2

The following detail information about the OAG 7.2 version is available,

Subject Reference Document Description
OAG 7.2 s1_001.pdf Description of the OAG 7.2 architecture
Post Journal s3_001_post_journal_006.pdf Description about business object PostJournalPost Journal corresponds to the Send Voucher functionality. For a detailed mapping of PostJournal see AppendixB
Load Payable s3_006_load_payable_006.pdf Description about business object LoadPayableLoad Payable corresponds to the Send Supplier Invoice functionality. For a detailed mapping of LoadPayable see AppendixB
Load Receivable s3_005_load_receivable_006.pdf Description about business object LoadReceivableLoad Receivable corresponds to the Send Customer Invoice functionality. For a detailed mapping of LoadReceivable see AppendixB
Sync Supplier s3_008_sync_supplier_005.pdf Description about business object SyncSupplierSync Supplier corresponds to the Receive Supplier Info functionality. For a detailed mapping of Sync Supplier see AppendixB
Sync Exchngrate s3_046_sync_exchngrate_003.pdf Description about business object SyncExchngrateSync Exchngrate corresponds to the Receive Currency Rate functionality. For a detailed mapping of Sync Exchngrate see AppendixB
Sync COA s3_045_sync_coa_003.pdf Description about business object SyncCOASync COA corresponds to the Receive Account functionality. For a detailed mapping of Sync COA see AppendixB
Confirm BOD s3_002_confirm_bod_004.pdf Description about business object ConfirmBOD.
Confirm BOD is the answer of a previously sent or received Business Service Request. If Confirm BOD is an answer to a sent Post Journal then the corresponding functionality is Confirm_Send_Voucher.

If it is an answer to a sent Load Payable then the corresponding functionality is Confirm_Send_Supplier_Invoice and if it is an answer to Load Receivable then the corresponding functionality is Confirm_Send_Customer_Invoice. If Confirm BOD is a response to a received Business Service Request then there is no corresponding functionality

OAG 8.0

For more information about OAG 8.0, please refer to AppendixDOagis8.0

Business Object Description
Post Journal Entry For a description of PostJournalEntry please read the document PostJournalEntry.html in AppendixDOagis8.0
PostJournalEntry corresponds to the SendVoucher functionality. For a detailed mapping of PostJournalEntry, please refer to  AppendixC
Load Payable For a description of LoadPayable please read the document LoadPayable.html in AppendixDOagis8.0
Load Payable corresponds to the Send Supplier Invoice functionality. For a detailed mapping of Load Payable, please refer to AppendixC
Load Receivable For a description of LoadReceivable please read the document LoadReceivable.html in AppendixDOagis8.0
Load Receivable corresponds to the Send Customer Invoice functionality. For a detailed mapping of Load Receivable please refer to AppendixC
Sync Party For a description of SyncParty please read the document SyncParty.html in AppendixDOagis8.0
Sync Party corresponds to the Receive Supplier Info and Receive Customer Info functionality. For a detailed mapping of SyncParty, please refer to AppendixC
Sync Exchange Rate For a description of SyncExchangeRate please read the document SyncExchangeRate.html in AppendixDOagis8.0
Sync Exchngrate corresponds to the Receive Currency Rate functionality. For a detailed mapping of Sync Exchngrate, please refer to AppendixC
Sync Chart Of Accounts For a description of SyncChartOfAccounts please read the document SyncChartOfAccounts.html in AppendixDOagis8.0.
Sync Chart Of Accounts corresponds to the Receive Account functionality. For a detailed mapping of Sync Chart Of Accounts, please refer to AppendixC
Confirm BOD For a description of ConfirmBOD please read the document ConfirmBOD.html in AppendixDOagis8.0.
Confirm BOD is the answer of a previously sent or received Business Service Request.

If Confirm BOD is an answer to a sent Post Journal Entry then the corresponding functionality is Confirm_Send_Voucher.

If it is an answer to a sent Load Payable then the corresponding functionality is Confirm_Send_Supplier_Invoice and if it is an answer to Load Receivable then the corresponding functionality is Confirm_Send_Customer_Invoice.

If Confirm BOD is a response to a received Business Service Request then there is no corresponding functionality.