@ronhu Check the country code mentioned in your Payment Institute office (connected to the cash account).
@SMcLees I have done this for a few of IFS customers using ISO20022 file format. It requires a few adjustments based on your bank. Please feel free to contact me via e.maldeniya@e-analytics.com
You can use the message functions in the external file template. For more information, please refer the IFS documentations
WIRE payments are generally handled via SWIFT clearing net work and generally use for cross boarder (forign) payments. You can use ISO20022 format to execute a WIRE payment under correct basic data setup. For an example, WIRE payments are sent as Urgent Payment. So you have to set the correct basis data setup in Supplier’s electronic pay address. This is a consulting task.
@ronhu You cannot use the value IBAN since there is no usage of IBAN in USA.
@ronhu to elaborate more on this..There are mainly two types of cash accounts, IBAN (International Bank Account Number) and BBAN (Basic Bank Account Number). If the inserted account number is not an IBAN (IBAN number starts with a valid two-digit country code followed by a valid number length), the system inserts the value BBAN to the selected cash account. There are some country-specific cash account types that you can enter via basis data, but this element cannot be omitted.
In IFS there are two flows in which you an upload the bank statements.AR/AP Reconciliation - Via External Payment flow Cash Book Reconciliation - Via Standard Bank ReconciliationsThe bank statements are uploaded with reference to the specific cash accounts. In the standard solution, you have to upload the statements one by one.
@ronhu I haven’t received this feedback before from any bank. It looks like you are dealing with the Bank of Nova Scotia. You can verify with them whether they expect any specific value or complete omission of the specified block. It is not possible to remove this element without doing a minor adjustment in the transformer level.
@Osthewha It seems like you're encountering an issue with how the XML transformer is handling the RECORD_TYPE_ID, where it's expecting it to be passed as "Record_Type_Id" and not recordtypeId. The discrepancy of "RECORD_TYPE_ID" and "RecordTypeId" might be causing problems (This might be a bit technical for you). Have you made any modifications to the Core XML file?
@Arend Simply put, the Payment_Block_number indicates the count of Payment information blocks (<PmtInf>) in the file. If you're processing payments on the same date, with the same payment type, cash account, and currency, there will be just one payment block in the file. However, there can be multiple supplier payments listed within this single payment block. It's important to note that the details of each supplier's payment are filled under the PmtInf block.
@Rasmus Raul The debtor agent’s bank account country (payment initiator's bank account country) should be defined in Payment Institute office window. You can define a new office code and define the country. After that connect this office code to the cash account which we are going to use to initiate the payment (Cash accounts window)
@Danny It's hard to determine the cause of this without looking at the actual setup. But with the information given it seems like the Tax code is taken from the sales part. If you want to implement the Sales Tax best option is to Define the Tax information in the Only Customer Delivery address and change the Tax Code Validation setup to the Transaction level in the Company Tax Control tab.
@Arend the usage of XML tags depends on the payment types. For example, if you are going to make SEPA payments, certain XML tags are required to be populated based on the EPC requirement. However, for foreign currency WIRE payments, the required XML tags are different. If you have specific requirements, please feel free to reach out to me via email (e.maldeniya@e-analytics.com). FYI: I was the former design owner of this functionality.
@Nancy Fink Thanks for the heads up. I just wanted to confirm that we have changed the accounting periods (although transactions were posted) via a data repair script in multiple cases. So, this is doable. but, always good to take corrective actions before going for a complex data repair.
@ronhu You can refer Payment File Trace information window to trace the Payment Order-related details after payment is created. Make sure that you have selected the Generate Trace information option for your payment method.
@ronhu You might have noticed that there are two options (Order ID and Payment Date) in the Acknowledged Supplier Payment window to view data. If you have acknowledged a payment order when the Payment Date view is used, the unacknowledgment also should be done in the same view. In you case, it looks like you have acknowledged the order with the payment date and now going to unacknowledge it via Order ID view. So, go back to the Payment Date view and unacknowledged the lines. The reason for this validation is there can be payment order lines with multiple payment dates within a single order. So, you might not required to acknowledge the whole order at once.
@Andreas_M I am not aware of a direct solution for your concern. As per the current design, the only option I can see is to decide the payment address when the supplier invoice is registered. It should be possible to do a configuration-based development to set the payment address ID based on the invoice currency. In this case, you must keep some indication in the Address ID to map the currency or use the Supplier’s Bank Account currency field to find the address ID.
@gumabs The check box is related to the structured address and not for the remittance details.In ISO 20022, offers rich remittance information through the use of the structured information element, however a payment can carry either unstructured (XML element called Ustrd) or structured (XML element called Strd) remittance information. In IFS solution, both options are available with some limitations.@karl.schneider82 I assume you are referring to using Structured Remittance Information (SRI) in ACH payments. SRI is the associated information for which the payment is being made. Within B2B payments this will often be purchase orders, invoices/credit notes or specific payment references. In IFS Core solution, SRI structure is limited to the requirement of SEPA (requirement of EU payment council). According to EPC rules, only one occurrence of ‘Structured’ is allowed and the tags and Rule(s) the data within the ‘Structured’ element (i.e. excluding <Strd> and </Strd>) should no
@Nagah.khaled Enter your IBAN number in this external site and see whether it is accepted.https://www.iban.com/iban-checkerIf this works, you have to register the IBAN country in IBAN Validation window.
@Nassim for According to European Payment Council (EPC) rules only the value “SLEV” (following Service Level, i.e., debtor and creditor pay their own bank fee) is allowed for SEPA payments. This is quite identical to the value SHAR, however when the file is transmitted for SEPA clearance, the value SLEV is only allowed. Hence, if you set the value SHAR, some banks will modify the value back to SLEV (otherwise rejected) when the file is transmitted. You can define this in the Charge Bearer column in the electronic payment address.
@Ramessh Kanna As far as I know almost every Telegraphic Transfers (TT) are currently handled via SWIFT network since telegraphic cable lines are not common now. In some countries, international Wire transfers via SWIFT network are also interpreted as outward TT payments. To answer your question, I would like to know your IFS customer’s country. If their bank supports ISO20022 format, you can do the outward SWIFT transfers via ISO20022 CT payment format.
@Nassim It depends on the payment method/format you are going to use. Most of the payment formats allow four values. If we consider the IS020022-based credit transfer payments, you have the following options.BEN (BENeficiary) – The Payee (recipient of the payment) will incur all of the payment transaction fees Typically, the recipient will receive the payment minus the transfer charges The Payer (sender of the payment) will not pay any payment fees OUR – The Payer (sender of the payment) will bear all of the payment transaction fees Normally you will be billed separately for the payment transfer The Payee (recipient of the payment) will not pay any payment fees, The beneficiary will receive the full amount of the payment SHA (SHAred) – The Payer (sender of the payment) will pay all fees charged by the sending bank You will be billed separately for the payment transfer The Payee (recipient of the payment) will pay all fees charged by the receiving bank The recipient wi
@Ramessh Kanna If I remember correctly, the core solution doesn’t support for combination of structured address and address lines. I believe, you have tried with the bank separately with Structured address and address lines. If this doesn’t work, you have to do a modification in XML transformer. We normally don’t recommend to modify the Core transformer when changing the XML structure, hence, it is recommended to introduce a new transformer file.
Hi @Abdessamad According to IFS Standard functionality, XML-based bank statements (CAMt.053 or CAMT.054) cannot be loaded to IFS standard Bank Reconciliation window. You can load them for external payment flow for AR/AP reconciliation purposes, but not for bank reconciliation purposes. If you want to use it for the bank reconciliation process, you have to do a configuration (quite bulky development). I can confirm that this is technically feasible since we have already done it.
@Ralph GerickeThis is a valid request and I think this request has been transferred to R&D. I have given following feedback in the post, Most of the banks now advise Corporates to migrate to the latest Common Global Implementation (CGI) ISO 20022 version (pain.001.001.09 or V9) in order to benefit from a harmonized cross-border payment experience and the latest value-add services. Although this version is based on the ISO20022 2019-2023 release, the bank adoption is very new and some global banks like Citi are going to support this version from 2023 onwards. Since IFS also follows the Common Global Implementation (CGI) releases, it is good to introduce pain.001.001.09 as a new XML transformer in IFS Core solution. However, pain.001.001.03 version should be continued until all the banks and clearing channels are completely moved to V9.There are not a lot of differences between V3 and V9 versions from IFS perspective other than some points highlighted below.Introduced additional attr
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
