Ce functional design workshop

445 views

Published on

Published in: Economy & Finance, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
445
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Each bank account is associated with a Bank and Bank Branch defined in Oracle’s common Trading Community Architecture (TCA). This centralization also extends to the creation and management of bank accounts. In Release 11 i , bank account management is separated. Cash Management, Payables, and Receivables access the Payables bank accounts, Payroll accesses the Payroll bank accounts, and Treasury accesses the Treasury bank accounts. The management of these accounts is separate, so the data must be replicated even if the banking information among these three bank account systems is the same. Now, in Release 12, all of the bank accounts are associated with the Legal Entity and retained in the Trading Community Architecture (TCA). This change improves data control and saves time in setup and maintenance (see Figure 2). Bank information is now maintained through one OA Framework form. The bank, bank branch, and bank account information is accessed via links where it can be created and maintained more efficiently. Users can also manage the payment documents for specific accounts from the bank account form.
  • New model provides a single access point for defining and managing internal bank accounts for AP, AR, Oracle Payroll, Oracle Cash Management and Oracle Treasury. The new centralized bank account model provides a single point for defining and managing internal bank accounts for Oracle Payables, Oracle Receivables, Oracle Payroll, Oracle Cash Management, and Oracle Treasury. A single legal entity is granted ownership of each internal bank account, and one or more organizations are granted usage rights. In addition, banks and branches are migrated to the Oracle Trading Community Architecture (TCA) and defined as parties.
  • TCA is a data model that allows you to manage complex information about the parties, or customers or suppliers or bank who belong to your commercial community, including organizations, locations, and the network of hierarchical relationships among them.
  • All internal banks and bank accounts that you had defined in Release 11 i are automatically migrated to the central Cash Management entities. The bank accounts and their payment documents are owned by a legal entity rather than by an operating unit. See Cash Management, page A-4 in this appendix for more information. Also, the banks and bank branches are centralized in Cash Management entities as described in the preceding paragraph. However, the bank accounts you had defined for your suppliers are migrated from the Payables entities to the central Payments entities. Payments centralizes and secures all payment instrument data
  • Bank Transaction Codes can be linked to multiple Sources (Previously has to be linked to songle source, such as AP) Now you can have mutliple sources with priority number for sequencing. Reconciliation Tolerances are defined at bank account level (Moved from system level to bank account) Available as separate tolerances for Manual and Auto reconciliation Broken down by source for Auto reconciliation (AP versus AR) Reconciliation can be done across operating units (Legal Entity)
  • Ce functional design workshop

    1. 1. R12 Upgrade Project R12.1.3 Cash Management analysis Functional Design Workshop: Cash Management (CE)
    2. 2. 2 Agenda • Introduction • Purpose of the workshop • Changed functionality overview Ο Banks Ο Other Setup Changes • Interactive discussion on requirements • Action Plan/Next Steps
    3. 3. 3 Introduction Alicia Wing Telephone: 780-508-4810 E-Mail: Alicia.Wing@atcoitek.com Upgrade applications: AP, IBY, CE, iExp Payables (AP) Payments (IBY) Cash Management (CE) Internet Expenses (iExp)
    4. 4. 4 Purpose of the Workshop • Interactive two way discovery session Ο Discuss changing functionality resulting from upgrade Ο Discuss related challenges Ο Gather information on: – Business requirements – Gaps
    5. 5. 5 Changing Functionality Upgrading 11i to R12 • Banks
    6. 6. 6 Internal Versus External Banks • Internal bank accounts are centralized in Cash Management Ο Legal entities own bank accounts – think Taxpayer ID Number • External bank accounts are centralized in Payments Ο Supplier and customer Ο Centralization gives a single point of control for encryption and masking
    7. 7. 7 New Bank Account Model • Single point of access for managing internal banks for AP, AR, Payroll, Cash Management and Treasury • Each Bank Account is associated with a Bank and Bank Branch defined in TCA • Is now an OA Framework/HTML form
    8. 8. 8 TCA Definition – Why do I care? • Trading Community Architecture (TCA) • New terminology • Data model • Manages suppliers, customers, banks Ο Any party with which you do business, except HR related entities, such as employees
    9. 9. 9 TCA and Banks • Bank, bank branch, account attributes,contact persons • Bank sites & locations • Change history & additional attributes • Contact details & methods • Contact titles • Contact purpose or role
    10. 10. 10 Bank Queries • Some 11i queries will need moderate attention • Data moved to TCA will require query rewrites
    11. 11. 11 CE Banks and Setup and Table Change • Setup in Cash Management (CE) Ο Bank, bank account setup Ο Shared with Payables, Receivables, Treasury, & Payroll Ο Banks & bank branches now represented as TCA parties • Three key CE tables Ο CE_BANK_ACCOUNTS for bank accounts Ο CE_BANK_ACCT_USES_ALL for account uses by Operating Units & Legal Entities Ο CE_GL_ACCOUNTS_CCID for bank account use accounting data
    12. 12. 12 Banks are Merged if: • Banks are merged during the upgrade if the following attributes are the same: Ο Bank number Ο Institution type Ο Country (w/default country setting for null) Ο Bank administrator’s email Ο Bank name Ο Alternative bank name Ο Taxpayer identifier Ο Tax reference Ο Description Ο Active date Ο End date
    13. 13. 13 Internal Bank Account Security • In Release 11i, bank accounts were used by a single operating unit Ο Operating unit security was used to control the maintenance of these accounts • In R12, bank accounts can be accessed by multiple operating units, but are owned by a single legal entity Ο The bank account maintenance security was moved to the legal entity level Ο Security Wizard grants each responsibility access to create and modify bank accounts owned by one or more legal entities
    14. 14. 14 Bank Account Security During Upgrade • During the upgrade: Ο Cash Management sets the Bank Account Maintenance security for each responsibility that had access to the bank account forms in Release 11i Ο For each of these responsibilities, a legal entity is derived from the organization that the responsibility had access to in Release 11i Ο The responsibility is then granted bank account maintenance security for this legal entity
    15. 15. 15 Other CE Setup Change • System Parameters Ο In order to provide more flexibility and control over the reconciliation process, many of the options that used to be defined as system parameters at the system level (operating unit) have been moved to the bank account level Ο By placing these controls at the bank account level, both the manual and automatic reconciliation processes can be configured depending on the bank account and its uses Ο In addition, the remaining system parameter options and controls from Release 11i are defined at the legal entity level in R12
    16. 16. 16 Transaction Codes and Tolerances • Bank Transaction Codes can be linked to multiple Sources • Reconciliation Tolerances are Ο Defined at bank account level Ο Available as separate tolerances for Manual and Auto reconciliation Ο Broken down by source for Auto reconciliation • Reconciliation can be done across operating units
    17. 17. 17 Requirements /GAPs • What are the requirements? • What are the GAPs?
    18. 18. 18 • Draft Functional design (RD.030) Ο Document requirements Ο Document GAPs (as identified) • Possible follow up requirements session • Review and Approval of RD.030 • Document tasks to be undertaken by POS Action Plan/Next Steps
    19. 19. 19 © 2012 ATCO Group of Companies. All Rights Reserved 19 Questions and Answers April 18, 2012

    ×