This page describes the functionality of the IFS Financial Connector.
Many components in IFS Applications create data that cause changes in the account balances of a General Ledger application. All these activities within IFS applications 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.
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 window.
Attribute | Description |
---|---|
Include Zero Amount | If this check box is selected, voucher rows with a zero amount are included in transfers |
Store Confirmed Vouchers | If this check box is selected, 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. |
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.
The transfer is started in the Send Vouchers dialog 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 Extended Server
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 Voucher In Transfer window 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
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
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
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 window.
Attribute | Description |
---|---|
Include Finally Posted Invoices | If this check box is selected, final posted supplier invoices will be included in transfers for this company. |
Include Preliminary Posted Invoices | If this check box is selected, preliminary posted supplier invoices will be included in transfers for this company. |
Include Voucher in Document | If this check box is selected, 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 check box is selected, 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 check box is selected, voucher rows with a zero amount are included in transfers. This check box is applicable only when the Include Voucher in Document check box is selected |
Remove IP5 Voucher Rows | If this check box is selected, voucher rows with posting type IP5 will be removed from the transfer for finally posted invoices. This check box is applicable only when the Include Voucher in Document check box 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. |
The transfer is started in the Send Supplier Invoices dialog 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 Extended Server
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 Invoice In Transfer window
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.
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.
The purpose of Send Customer Invoice is to send customer invoices that exist in the invoice component to another ERP system’s receivables application.
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 window.
Attribute | Description |
---|---|
Include Voucher in Document | If this check box is selected, 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 check box is selected, 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. |
The transfer is started in the Send Customer Invoices dialog 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 Extended Server.
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 Invoice In Transfer window
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.
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
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.
The ReceiveSupplierInfo Business API
receives a ReceiveSupplierInfo record and calls
the Receive_Supplier_Util_API
's for each Supplier in the record.
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 |
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.
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.
The ReceiveSupplierInfo Business API
receives a ReceiveCustomerInfo record and calls
the Receive_Customer_Util_API'
s for each Customer in the record.
The Receive_Customer_Util_API
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 |
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.
The purpose of Receive Currency Rate is to keep currency information synchronized that exists in separate systems.
The ReceiveCurrencyRate Business API
receives a ReceiveCurrencyRate record and calls
the Receive_Currency_Rate_Util_API
's for each Currency_Rate
in the record.
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 |
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__ . |
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.
The purpose of the Receive Account is to keep account information that exists in separate systems synchronized.
The ReceiveAccount Business API receives a
ReceiveAccount record and calls the
Receive_Code_Part_Util_API
's for each Account in the record.
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 |
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
The purpose of the Receive Code Part is to keep code part information that exists in separate systems synchronized¨.
The ReceiveCodePart Business API receives a
ReceiveCodePart record and calls the
Receive_Code_Part_Util_API
's for each CodePart
in the record.
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 |
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
The Open Applications Group (OAG) is a non-profit consortium focusing on best practices and process based XML content for eBusiness 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.
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 |
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. |