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_State
is 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 PostJournal. Post 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 LoadPayable. Load 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 LoadReceivable. Load 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 SyncSupplier. Sync 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 SyncExchngrate. Sync 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 SyncCOA. Sync 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. |