Oracle Cloud offers a broad portfolio of software as a service applications, platform as a service, and social capabilities, all on a subscription basis. Oracle Cloud delivers instant value and productivity for end users, administrators, and developers alike through functionally rich, integrated, secure, enterprise cloud services.
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

Subscribe to the OracleAppsHub to receive notifications when there are new posts:

 get RSS feed
 Oracle Fusion Applications (OFA) is a portfolio of next generation suite of software applications from Oracle Corporation. It is distributed across various product families; including financial management, human capital management, customer relationship management, supply chain management, procurement, governance, and project portfolio management
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

R12.2 :Modulus Check Validations for Bank Accounts

Posted on July 12th, 2014 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

The existing bank account number validations for domestic banks only check the length of the bank account number. These validations are performed during the entry and update of bank accounts.With R12.2 the account number validations for United Kingdom are enhanced to include a modulus check alongside the length checks.

  • Modulus checking is the process of validating bank account numbers in conjunction with the Banks Sort Code.
  • A new concurrent program "Load UK Domestic Account Validations Data" has been provided to load modulus validation data files.

Notes The feature can be disabled by using a Cash Management System Profile (CE: Disable Bank Validations).

If you compare , you can understand this way :

Existing validations:
The sort code should have 6 numeric digits
The bank account number should have 6 numeric digits

New Validation:
The combination of Sort Code and Account Number should pass a modulus check.

Modulus check methods are prescribed by VocaLink (BACS technology partner)
Modulus checking ensures sort code and account numbers are compatible before submitting BACS payment instructions.

dgreybarrow BANK ACCOUNT VALIDATION - THE BASICS

A modulus check is an arithmetic check that establishes whether there is a valid link between a given sort code and account number range.

Modulus checking is a vital process within bank account validation for Bacs submissions, ensuring that errors arising during the capturing of data are flagged for the payer's attention to enable them to correct them before they are submitted, thus avoiding costly returned transactions.

So far, There are 3 types of modulus checks that are performed on the UK bank accounts. These are:

  • Mod 10– Standard 10 modulus check
  • Mod 11– Standard 11 modulus check
  • DblAl– Double alternate modulus check.

This feature enhances the existing UK bank account validation model by introducing modulus check validation.

A modulus check will be performed during the creation and modification of the bank accounts and will also be applied on the importing of bank accounts through public APIs.

dgreybarrow HOW THIS WORKS

When the bank accounts are entered, the system will now invoke a new modulus check in addition to the existing length check (8 digits) for validating the UK bank accounts.

The modulus algorithm applied on the bank accounts depend on the bank sort codes and is part of the sort codes published by Vocalink.

dgreybarrowIMPLEMENTATION: UK BANK ACCOUNT VALIDATION

Implemenation Process can be best understood as below:

UK Validation Bank

In order to use the new validation model, customers need to upload the latest modulus weight table file and Sorting & Substitution data file published by Vocalink.

These concurrent programs allow customers to upload the latest version of these files. Vocalink publish updates to these regularly. Customers can register via Vocalink website to be alerted when a new version has been published.

This Consist of 4 steps process

1) Download 2 files from the VocaLink site:

a) Click on Modulus weight table data (.txt valid from 18/11/13)
Save the file : valacdos.txt [ This will be one the parameter ]

b) Click on Sorting code substitution data (.txt 1Kb valid from 13/06/05)
Save the file : scsubtab.txt [ This will be one the parameter ]

2) These two files must be Upload files to server

3) Then Import : From CM super user responsblity submit a program 'Load UK Domestic Account Validations Data’

4) Make sure System Profile Set - CE: Disable Bank Validations set to YES at site level

Posted in Cash Management | No Comments »

R12 :Country Specific Bank Account Validations

Posted on December 12th, 2012 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

R12 , the Bank Account model allows users to define and keep track of all bank accounts in the e-Business Suite in one place and explicitly grant account access to multiple operating units/functions and users. Bank accounts for internal use are consolidated in:

  • Payables
  • Receivables
  • Treasury
  • Global Financials
  • CRM

The Bank Account model reduces the number of access points to manage bank accounts by providing a centralized user interface where all internal bank accounts can be set up.

Bank account numbers are structured according to national and international standards.

In many countries, Rule are required to check that the bank account number is correct. If this number is not checked in the system and happens to be wrong, any payment orders to this account are rejected and bank fees are charged to the company.

R12 has VALIDATION RULES that were not present before.

Example: 11i would allow you to enter any length account number you wanted. Now, the account number length depends upon the country. This ensures that each country’s payment file requirements are met, by standardizing each country’s data input requirements.

arrow-up-3 VALIDATION RULES

Oracle R12 , added new feature called Country Specific Bank Account Validations

The following information is presented for certain countries:

  • Validation rules: The validation perform for the specific country
  • Unique Validation Rules: The unique validations perform for the specific country

The following countries have country specific validations:

When entering new bank accounts, different countries can have certain rules governing the format and content of the following related fields:

  • Bank Number
  • Branch Number
  • Account Number
  • Check Digit

A new profile option, "CE: Disable Bank Validations" has been introduced. This profile can be set at the site, application, responsibility or user level. The profile is seeded with a default value of 'No' at the site level. The country-specific validations pertaining to the bank number, branch number, account number and check digit can be disabled by this profile option.

If the profile is set to 'Yes', these validations will not fire. If the profile is set to 'Yes' a tip is displayed on the Bank, Branch and Account setup pages. This indicates that the validations have been disabled. A similar tip is displayed in the Supplier (Oracle Payments) Bank Setup UI.

The checks for unique banks, branches, accounts and the mandatory requirement of bank account number are not affected by this profile.

Currently Bank validation is offered for Australia, Austria, Belgium, Brazil, Denmark, Colombia, Finland, France, Germany, Greece, Iceland, Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Spain, Sweden, Switzerland, United Kingdom, and United States.

If country does not have validation in above list, still have these default validation aka Unique Validation Rules

The unique key will be the combination of:

  • BANK
    • Bank Number, Country
    • Bank Name, Country
  • BRANCH
    • Bank ID, Branch Number
    • Bank ID, Branch Name
  • ACCOUNT
    • Bank Branch ID, Bank Account Number, Bank Account Name, Currency

Posted in Cash Management | No Comments »

What is Oracle Cash Management

Posted on October 16th, 2011 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Oracle Cash Management is an open integrated solution for managing your company/enterprise-wide cash cycle. In addition to seamlessly integrating with other modules from Oracle E-Business Suite, Oracle Cash Management's open interfaces allow company to easily integrate with external systems, giving timely access to global cash information . Companies those practicing and prepares cash forecast, they can project cash flows from Oracle General Ledger, Oracle Receivables, Oracle Payables, Oracle Payroll, Oracle Projects, and Oracle Purchasing. The Forecasting Open Interface allows you to also project cash flows from external systems. With the Forecasting Open Interface's distributed database support, you can generate a forecast that combines relevant transaction information from both local and remote databases which may be across region .

Oracle Cash Management lets you automatically or manually record and reconcile bank statements, matching against system transactions using rules and tolerance levels. You can review and correct any import validation or reconciliation errors online. Oracle Cash Management can automatically reconcile correcting statement lines against error statement lines and provide an audit trail for verifying correction of bank errors.

cashManagment

Fig 1: Cash Managment

Oracle Cash Management supports electronically downloading of bank statements from the bank. The Bank Statement Loader program supports standard formats such as BAI2 and SWIFT940, as well as user-defined formats. Bank statements are reconciled with payments in Oracle Payables and Oracle Payroll, receipts in Oracle Receivables, and journal entries in Oracle General Ledger. You can also reconcile with payments and receipts from other systems, including settlements from Oracle Treasury, using the Reconciliation Open Interface. The Reconciliation Open Interface is extensible, executing your custom logic when reconciling external transactions.

If you are implementing, you can refer these post that will be great help for you.

Posted in Cash Management | No Comments »

Difference between a standard bank charge and a negotiated bank charge

Posted on July 24th, 2011 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Bank charges are the fees that a bank charges you for transferring funds from your disbursement bank account to the bank accounts of your suppliers.

You negotiate with your supplier whether to deduct the bank charges from an invoice payment and you pay the bank at one of the following rates:

  • Standard
  • Negotiated

Difference between a standard bank charge and a negotiated bank charge

  • A standard bank charge is the typical rate that a bank charges you to transfer funds from a disbursement bank account to a supplier bank account.
  • A negotiated bank charge is a negotiated rate that you and your bank agree upon for the transfer of funds.

Posted in Oracle Payable, Oracle Treasury | No Comments »

Period Close Processing Checklist -> R12 Cash Management

Posted on June 13th, 2009 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

This is recap of previous post in brief for Close Checklist – Cash Management

  1. Load & Reconcile Bank Statements
    • Auto-Reconciliation Execution Report
  2. Resolve Exceptions
  3. Create Miscellaneous Transactions
  4. Resolve Unreconciled Lines
    • Bank Statement Detail Report
    • Transactions Available for Reconciliation Report
  5. Reconcile to GL
    • GL Reconciliation Report
    • Account Analysis Report for Cash Account

Posted in Cash Management | No Comments »

R12 : Cash Management Period Closure

Posted on March 13th, 2009 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Herewith providing the generic period close process for Cash managment for R12.

1.Make sure you have Loaded & reconciled all bank statements for month

  • You must verified Auto-Reconciliation Execution Report

2.If there any , resolve all exceptions

3.Create miscellaneous transactions

This step existed in Release 11i but the difference is that in Release 12 when you create the miscellaneous transactions in AR, the accounting is done by SLA.

4. Resolve unreconciled lines

  • Bank Statement Detail Report
  • Transactions available for Reconciliation Report

tip A Note on Transactions Available for Reconciliation Report

Take advantage of this report.This report shows all transactions available for reconciliation for a specific bank account. It lists detailed transaction information for your Available Receipts, AvailablePayments, and Available Journal Entries for reconciliation.

Detailed information includes the Customer, Supplier, Transaction Date, Payment Method, Transaction Number, Currency, and Amount. It also lists detailed information for statement lines that are available for reconciliation against other statement lines.

5.Reconcile to General Ledger

  • GL Reconciliation Report
  • Account Analysis Report for Cash Account

tip A Note on General Ledger Reconciliation Report

Use this report to reconcile the General Ledger cash account to a bank statement balance.

This report lists a balance and an adjusted balance for the bank statement. It also lists a separate adjustment amount for un-reconciled receipts, payments, and journal entries, as well as bank errors.

This Report will show

General Ledger Reconciliation Report

Hopefully these steps will be helpful for doing Closure for CE.

Posted in Cash Management, R12 | 2 Comments »

IBAN – Insights

Posted on August 18th, 2008 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

The European Committee establishes IBAN1 standards for Banking Standards (EBS) and the International Organization for Standardization (ISO).

IBAN provides an international standard account identifier for identifying an account held by a financial institution, in order to facilitate
automated processing of cross border transactions through:

  • Automatic processing of foreign bank account identifications
  • Uniform validation of foreign bank account identifications
  • Easy routing of transactions

The IBAN can be implemented without modification to domestic account numbers or account number formats. This is achieved by creating a standard prefix after which the domestic account number can sit unchanged.

Posted in Cash Management | No Comments »

R12 : Cash Management & SLA

Posted on May 22nd, 2008 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

dgreybarrow-2What two program responsible for creating events in R12 CM

They are

  • bank account transfers
  • bank statement cash flows

Once events created and the accounting program is run, the journal entry setup and the accounting configurations are referenced to produce journal entries. The journal entries are then transferred to GL which had visibility upto source transactions. This way CM user can drill down from the transaction level to the journal entry details.

SLA

dgreybarrow-2How it is differ from R11i

In 11i release Cash Management produced journal entries for bank statement activity based on simple rules and sent them to the GL interface

dgreybarrow-2A bit on Bank account transfers

For those who are new to R12, should note The bank account transfer functionality of R12 is one in which you can take action on the projected closing balances calculated by the system. This is integrated with the Payments application that allows you to send payment instructions to the bank in a variety of payment formats.

Posted in Cash Management, Release12 | 2 Comments »

R12 :Bank Statement Reconciliation

Posted on May 22nd, 2008 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

We already aware for changes for new Bank Account Model feature of R12.

Lets investigate how bank model drive some changes in Bank statement Reconciliation.

1....R12, Bank Transaction Codes is linked to multiple sources.

In 11i each bank transaction code had to be linked to a single source, such as Accounts Payable. This could create an issue if the bank was using the same transaction code to report back a payment that was initiated from an application other than Accounts Payable. With this enhanced changes link with bank transaction code to sources can easily manage and this way you can assign a priority number which can be used in the auto reconciliation for sequencing.

2..Another feature is Reconciliation tolerances.This R12 feature is moved from the system level to the bank account level. This moves simply means that each bank account can manage unique set or reconciliation tolerances. The options for setting tolerance is still distinct for at both manual and auto reconciliation. You should also note auto reconciliation tolerances is unique with sources, that mean each source like AP,.AR,CM, and Open Interface can have there own level.

3... Most important,now it is possible to use the same bank account, created in the centralized model, in multiple organizations, the bank statement reconciliation can also done across Operating Units.

dgreybarrow-2Underline Setup

Most of setup is now attached at Bank level which includes your Transaction codes. There is provision to manage and assign transaction code to multiple transaction sources.

Another changes you can see in R12 accounts Control in which you can easily manage reconciliation control parameters.

dgreybarrow-2

Post of your Intrest

Posted in Cash Management, Release12 | No Comments »

News: Citibank Japan and Oracle cash management solutions

Posted on May 21st, 2008 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

This is not Oracle acquisition news, rather yet another Big news this morning locally in Singapore for partnership with global bank Citibank Japan and Oracle for enhancing the Oracle Global Cash Management System,that provide a integrated solution for managing Cash Management for global manufacturing operations, retail, transportation, financial services sector of Japanese clients.

"Oracle Global Cash Management System" is SOA based product of Oracle Japan used for managing group corporate finance, fund management and financial risk management, financial transaction management function.

Some of the important Fund management features that product offers are : centralized group of companies in the financial management of pooling funds, payments to suppliers to pay a centralized agency, balances between group companies to make the difference between the settlement and netting capabilities.

"Oracle Global Cash Management System" available for local clients since October 1, 2007 with price tag 15 million yen for 4-user license,supported with most of available platforms(AIX, Solaris, HP-UX, RedHat Linux, Windows).

read this entire story

As need for banking Integration is greatly felt in corporate world, and Lets hope, this might bring some more banking functionality in next releases of Oracle EBS ..what you say...

Posted in Cash Management, News, Oracle Treasury | No Comments »

Page 1 of 212

« Previous Entries