Fin Implementation StudentGuide PDF

Fusion Applications:
Introduction to Financials
Implementation
Student Guide
D75544GC
Edition: 3.0
April 2013
D77370
Authors Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
Asara Alim, Tina Brand, Disclaimer

Gail D’Aliosio, Wally
Gardipe, Mary Kalway,
This document contains proprietary information and is protected by copyright and
Barbara Kostelec, Carol other intellectual property laws. You may copy and print this document solely for
Ann Lapeyrouse, Robert your own use in an Oracle training course. The document may not be modified or
MacIsaac, Essan Ni, altered in any way. Except where your use constitutes "fair use" under copyright law,
you may not use, share, download, upload, copy, print, display, perform, reproduce,
Sehkar Pappu, Barbara publish, license, post, transmit, or distribute this document in whole or in part without
Snyder, and Kathryn the express authorization of Oracle.
Wohnoutka
The information contained in this document is subject to change without notice. If
Technical Contributors you find any problems in the document, please report them in writing to: Oracle
University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This
and Reviewers document is not warranted to be error-free.
Ayse Aba, David
Barnacle, Vipin Restricted Rights Notice
Chengalpatu, Tina Cook,
Abhijit Dhakephalkar,
Giles Emberson, Ivy If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice
Farren, Wei Feng , is applicable:
Fernando Franco, David
Haimes, Bruce Ingram,
Imad Jabbour, Carolyn U.S. GOVERNMENT RIGHTS
Luk, Muhannad Obeidat, The U.S. Government’s rights to use, modify, reproduce, release, perform, display,
or disclose these training materials are restricted by the terms of the applicable
Jyoti Pandey, Bernardine Oracle license agreement and/or the applicable U.S. Government contract.
Rodgers, Greg Roth, Chris
Rudd, Johanna Rusly,
Aalok Shah, Mei Siauw, Trademark Notice
Matthew Skurdahl,
Mohana Suggula, Vincent Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other
Toh, Senthil names may be trademarks of their respective owners.
Vellakoilmuthusamy, Raj
Verma, Alison Wan, Xin
Wang, and Ian Yu.
CONTENTS
Lesson 1: Introduction to Oracle Fusion Financials .....................1
Lesson 1: Objectives .................................................................................. 1
Course Approach ........................................................................................ 2
Oracle Fusion Implementation Resources ...................................................... 3
Course Schedule ........................................................................................ 5
Introduction to Oracle Fusion Financials ...................................................... 6
Implementation Course Overview .......................................................... 23
Activity: Implementation Discussion ....................................................... 24
Introduction to Financials Offerings ........................................................ 25
Activity: Common Application Discussion ................................................ 29
Introduction to Common Applications Configuration ................................. 31
Introduction to Common Financials Configuration ......................................... 33
Lesson 1: Highlights ................................................................................. 35
Lesson 2: Overview of Oracle Fusion Functional Setup Manager36
Lesson 2: Objectives ................................................................................ 37
Getting Started in Oracle Fusion Applications ............................................... 38
User Interface ....................................................................................... 39
Dashboard ............................................................................................ 40
Work Areas ........................................................................................... 41
Recent Items ......................................................................................... 42
Overview of the Functional Setup Manager .................................................. 44
Implementation Overview ....................................................................... 45
Job Roles ............................................................................................ 46
Implementation Task Flow .................................................................... 47
Implementation Objects Overview ......................................................... 49
Implementation Project Overview .......................................................... 51
Implementation Project for Ongoing Maintenance .................................... 53
Offerings, Options and Features............................................................. 54
Implementation Objects Task Flow ......................................................... 56
Setup Data Export and Import Overview ................................................. 57
Export and Import Task Flow................................................................. 58
Browsing and Configuring Offerings .......................................................... 59
Gathering Implementation Requirements for Offerings ............................. 60
Using the Getting Started Page .............................................................. 61
Functional Setup Manager Reports Overview ........................................... 62
Functional Setup Manager Reports Features ............................................ 63
Selecting Feature Choices ..................................................................... 65
Lesson 2: Highlights ................................................................................. 67
Lesson 3: Overview of Common Applications Configuration ......68
Lesson 3: Objectives ................................................................................ 69
The InFusion Story ................................................................................... 70
Overview of InFusion Corporation ............................................................ 70
InFusion Corporation Analysis .................................................................. 71
Infusion Enterprise Structure Model.......................................................... 72
InFusion Corporation Structure Diagram ................................................... 73
InFusion Enterprise Structure Mapping ..................................................... 75
InFusion Chart of Accounts Summary ....................................................... 77
Define Enterprise Structures ...................................................................... 79
Define Geographies ................................................................................ 81
Available Options for Importing Geographies ........................................... 82
Running Maintain Geography Name Referencing ...................................... 83
Managing Geography Lookups ............................................................... 84
Zone Types and Zones ......................................................................... 85
Territory Zone Hierarchy ....................................................................... 86
i
Managing Geographies ........................................................................... 87
Geographies Overview .......................................................................... 88
Geography Structure ............................................................................ 89
Geography Hierarchy ........................................................................... 90
Geography Validations .......................................................................... 92
Address Cleansing................................................................................ 93
Configuring Enterprise Structures Overview ............................................... 94
Define Legal Jurisdictions and Authorities .................................................. 96
Legal Jurisdictions Overview .................................................................. 97
Legal Authorities Overview .................................................................... 98
Manage Legal Entities ............................................................................. 99
Legal Entities Overview ....................................................................... 100
Legal Entity Considerations .................................................................. 102
Legal Entity Decisions 1 ....................................................................... 103
Manage Legal Reporting Units................................................................. 114
Legal Reporting Units Overview ............................................................ 115
Define Reference Data Sharing ............................................................... 117
Reference Data Sharing Overview ......................................................... 118
Manage Reference Data Partitions ......................................................... 120
Determinant and Determinant Types ..................................................... 122
Reference Data Set Assignments .......................................................... 123
Reference Data Set Examples ............................................................... 126
Reference Group ................................................................................. 128
Knowledge Check: Reference Data Sets ................................................. 130
Knowledge Check: Reference Data Sets Answer ..................................... 131
Knowledge Check: Reference Data Sets with Business Units ..................... 132
Knowledge Check: Reference Data Sets with Business Units Answer ......... 133
Manage Business Units .......................................................................... 134
Business Units Overview ...................................................................... 136
Business Unit Definition Considerations ................................................. 137
Business Unit Hierarchy Example .......................................................... 138
Lesson 3: Highlights ................................................................................ 139
Lesson 4: Configuring Oracle Fusion General Ledger ..............140
Lesson 4: Objectives ............................................................................... 140
Chart of Accounts .................................................................................... 141
Sharing Ledger Components Across Oracle Applications ............................. 141
Accounting Configuration Prerequisites .................................................... 142
Creating Chart of Accounts ..................................................................... 143
Chart of Accounts Components ............................................................. 145
Define Value Sets ............................................................................... 147
Validation and Value Sets .................................................................... 149
Building the Chart of Accounts Structure ................................................ 151
Assigning Segment Labels.................................................................... 153
Knowledge Check: Chart of Accounts .................................................... 155
Knowledge Check: Chart of Accounts Answer ......................................... 156
Deploying the Chart of Accounts ........................................................... 157
Defining Segment Values ..................................................................... 159
Assigning Segment Attributes ............................................................... 161
Control Accounts Example.................................................................... 164
Defining Hierarchies .............................................................................. 167
ii
Account Hierarchy Purposes ................................................................. 169
Create Account Hierarchies .................................................................. 171
Published Account Hierarchy Example ................................................... 172
Enabling Account Combinations .............................................................. 174
Manage Segment Value Attributes ........................................................ 176
Defining Segment Value Security Rules ................................................. 178
Defining Cross-Validation Rules ............................................................ 179
Manage an Accounting Calendar ................................................................ 182
Accounting Calendar Considerations ........................................................ 183
Calendars with Different Period Frequencies ............................................. 185
Adding a Calendar Year.......................................................................... 186
Calendar Auditing ................................................................................. 187
Manage Currencies Overview .................................................................... 188
Currency Concepts ................................................................................ 189
Currency in Subledgers .......................................................................... 190
Knowledge Check: Manage Currencies ..................................................... 192
Knowledge Check: Manage Currencies Answer .......................................... 193
Define Currencies Overview ...................................................................... 194
Currencies Overview.............................................................................. 195
Conversion Rate Types Overview ............................................................ 197
Explain Cross Rate Rules ..................................................................... 198
Daily Rates Overview............................................................................. 200
Ledgers.................................................................................................. 202
Relevant Setup Tasks ............................................................................ 202
Ledgers and Accounting Configurations .................................................... 203
Define Ledger Components .................................................................... 206
Manage Primary Ledgers ........................................................................ 208
Specify Ledger Options .......................................................................... 210
Balancing Segment Value Assignments .................................................... 212
Manage Reporting Currencies ................................................................. 214
Reporting Currencies Conversion Levels ................................................. 216
Define Secondary Ledgers ...................................................................... 218
Secondary Ledgers Conversion Levels ................................................... 220
Secondary Ledgers Mapping ................................................................. 222
Review and Submit Accounting Configuration ........................................... 224
Balance Cubes Overview ...................................................................... 225
Balance Cube Dimensions .................................................................... 227
Manage Ledger Sets .............................................................................. 228
Defining Security .................................................................................. 229
Defining Segment Value Security Rules ................................................. 231
Segment Value Security Examples ........................................................ 232
Segment Value Security Operators........................................................ 234
Data Access Set Security ..................................................................... 235
Data Access Set Security Example ........................................................ 236
Knowledge Check: Data Access Set Security .......................................... 238
Knowledge Check: Data Access Set Security Answer ............................... 239
Function and Data Security .................................................................. 240
Job Roles ........................................................................................... 242
Assign Data Roles Overview ................................................................. 243
Secure Subledger Accounting ............................................................... 244
Period Close ........................................................................................... 246
Period Close Checklist ............................................................................ 247
Allocations Rule Sets and Components ..................................................... 248
Allocations Requirements ..................................................................... 251
Step Down Allocation Example ............................................................. 252
Using Actual and Allocated Amounts Example ......................................... 253
Allocations Concepts ........................................................................... 254
Allocations - Best Practices .................................................................. 255
Revaluation and Translation ................................................................... 257
iii
Revaluation and Translation Setup ........................................................ 258
Revaluation Overview ............................................................................ 259
Revaluation Example ........................................................................... 261
Translation Overview ............................................................................. 263
Historical Rates .................................................................................. 264
Consolidations .................................................................................... 265
Consolidation Methods ............................................................................. 266
Reporting Only Consolidation Method ...................................................... 267
Balance Transfer Consolidation Method .................................................... 269
Reporting Only Versus Balance Transfer ................................................... 271
Elimination Entries .................................................................................. 273
Consolidation Example ............................................................................. 275
Reporting Consolidation with Multiple Levels ............................................. 276
Elimination Level One Example ............................................................... 278
Elimination Level Two Example ............................................................... 282
Elimination Level Two Example Part II ..................................................... 286
Financial Management Integration Option................................................... 288
Mapping Segments to Financial Management Dimensions ........................... 290
Configure ERP Integrator ....................................................................... 292
Accounting Periods Overview .................................................................. 292
Accounting Period Statuses .................................................................. 294
Period Close with Oracle Fusion Financials .............................................. 295
Close Status Monitor ........................................................................... 296
Period Close Best Practices .................................................................. 297
Knowledge Check: Open and Close Periods ............................................ 298
Knowledge Check: Open and Close Periods Answer ................................. 299
Financial Reporting .................................................................................. 300
Financial Reporting Center Components ................................................... 302
Create Financial Reports ...................................................................... 303
Financial Reporting Studio Features ...................................................... 305
Account Monitor Features .................................................................... 306
Account Inspector Features .................................................................. 307
Smart View Features ........................................................................... 308
Configure Smart View.......................................................................... 309
Oracle Transactional Business Intelligence ............................................... 310
Budgeting and the Oracle Fusion Accounting Hub ...................................... 311
Lesson 5: Configuring Oracle Fusion Subledger Accounting ....313

Manage Subledger Accounting Overview .................................................... 315
Accounting Methods Overview .................................................................. 316
Create Accounting Process Overview ......................................................... 317
Manage Subledger Applications and Sources ............................................... 319
Accounting Event Model Example ............................................................ 320
Manage Subledger Accounting Rules .......................................................... 322
Manage Accounting Methods .................................................................. 324
Accounting Methods Best Practices........................................................ 326
Manage Subledger Journal Entry Rule Sets ............................................... 327
How the Different Types of Rules Fit Together ........................................ 328
Journal Header and Line Level Accounting Rules ..................................... 330
Subledger Journal Entry Rule Set Example ............................................. 331
Subledger Journal Entry Rule Sets Implementation Notes ........................ 332
Manage Journal Line Rules ..................................................................... 333
Journal Line Rules Implementation Notes ............................................... 335
Defining Conditions ............................................................................. 336
Manage Mapping Sets ............................................................................ 338
Mapping Sets Implementation Notes ..................................................... 339
Mapping Sets Best Practices ................................................................. 340
iv
Manage Account Rules ........................................................................... 341
Account Rules Implementation Notes .................................................... 343
Account Rules Best Practices ................................................................ 344
Defining Account Rule with Conditions Example ...................................... 345
Manage Description Rules ...................................................................... 348
Manage Description Rules Example ....................................................... 349
Description Rules Implementation Notes ................................................ 350
Manage Supporting References ............................................................... 351
Supporting References Implementation Notes ........................................ 353
Supporting References Best Practices .................................................... 354
Activate Subledger Journal Entry Rule Sets .............................................. 355
Define Accounting Methods Considerations ............................................... 356
Create and Process Subledger Journal Entries ............................................. 358
Creating Transactions ............................................................................ 360
Lesson 6: Configuring Intercompany Processing Rules ...........363
Relevant Setup Tasks .............................................................................. 365
Configuring Intercompany ........................................................................ 366
Intercompany Overview ........................................................................... 367
Intercompany General Ledger Integration ................................................ 368
Intercompany Receivables and Payables Integration.................................. 369
Intercompany Key Features.................................................................... 371
Manage Intercompany Transaction Processing ............................................ 372
Manage Intercompany System Options .................................................... 373
Intercompany System Options Key Decisions ......................................... 374
Manage Intercompany Transaction Types ................................................. 375
Manage Intercompany Period Status ....................................................... 376
Manage Intercompany Organizations ....................................................... 377
Intercompany Organizations Key Decisions ............................................ 378
Intercompany Organizations Implementation Notes ................................ 379
Intercompany Organizations Implementation Notes (cont'd) .................... 382
Define Invoice Options ........................................................................... 383
Manage Intercompany Customer and Supplier Assignments ..................... 384
Intercompany Customer and Supplier Assignments Implementation Notes . 385
Manage Intercompany Receivables Assignments ..................................... 386
Intercompany Receivables Assignments Implementation Notes ................ 387
Define Transaction Account Rules .............................................................. 388
Transaction Account Builder Components ................................................. 390
Intercompany Balancing ........................................................................... 392
Manage Intercompany Balancing Rules .................................................... 393
Precedence Order of Balancing Rules ..................................................... 394
Using Chart of Accounts Rules for Intercompany Balancing ...................... 396
Intercompany Balancing Key Decisions .................................................. 397
Intercompany Balancing Key Decisions (cont'd) ...................................... 398
Manage Ledger Balancing Options ........................................................... 400
Ledger Balancing Options Implementation Notes .................................... 401
Intercompany Challenges ....................................................................... 402
Intercompany Reconciliation ..................................................................... 403
Reconciliation Reports ........................................................................... 404
Lesson 7: Configuring Oracle Fusion Tax .................................407
Understanding Oracle Fusion Tax .............................................................. 408
Define Transaction Taxes Overview ......................................................... 410
Oracle Fusion Tax Architecture ............................................................... 413
Tax Requirements Organization .............................................................. 415
v
Setting Up Foundation Tax Configuration.................................................... 416
Foundation Tax Components .................................................................. 418
Configuration Owners and Options ........................................................ 419
Tax Regimes ...................................................................................... 420
Taxes ................................................................................................ 421
Tax Statuses ...................................................................................... 422
Tax Jurisdictions ................................................................................. 423
Tax Rates .......................................................................................... 424
Examples of Foundation Tax Setup .......................................................... 425
Knowledge Check: Minimum Tax Configuration ......................................... 426
Knowledge Check: Minimum Tax Configuration Answer .............................. 427
Setting Up Advanced Tax Configuration...................................................... 428
Key Building Blocks of Tax Rules ............................................................. 430
Tax Determination Process ..................................................................... 431
Determine Applicable Tax Regimes and Candidate Taxes ......................... 432
Determine Tax Applicability and Place of Supply and Tax Jurisdiction ........ 434
Determine Tax Registration .................................................................. 436
Determine Tax Status.......................................................................... 437
Determine Tax Rate ............................................................................ 438
Determine Taxable Basis ..................................................................... 439
Determine Tax Calculation ................................................................... 440
Determine Tax Recovery ...................................................................... 441
Knowledge Check: Tax Determining Factors ............................................. 443
Knowledge Check: Tax Determining Factors Answer .................................. 444
Setting Up Tax Reporting Configuration...................................................... 445
Verifying Tax Configuration ...................................................................... 446
Lesson 8: Configuring Oracle Fusion Payables ........................449
Key Concepts in Oracle Fusion Payables ..................................................... 450
Procure to Pay Flow ............................................................................... 450
Business Units in the Procure to Pay Flow ................................................ 451
Service Provider Model .......................................................................... 453
Service Provider Model Example ............................................................. 454
Knowledge Check: Business Units ........................................................... 455
Knowledge Check: Business Units Answers ............................................... 456
Supplier Model ...................................................................................... 457
Supplier Site Assignment Example .......................................................... 459
Knowledge Check: Suppliers................................................................... 461
Knowledge Check: Suppliers Answer ....................................................... 462
Invoice Entry Methods ........................................................................... 463
Implementation Considerations for Invoice Entry Methods.......................... 465
Function and Data Security .................................................................... 466
Job Roles and Duty Roles ....................................................................... 467
Data Security ....................................................................................... 468
Prerequisite Setups ............................................................................... 469
Defining Automated Invoice Processing Configuration .................................. 470
Automated Invoice Processing Flow ......................................................... 472
Defining Common Options for Payables and Procurement ............................. 474
Manage Payables Calendars ................................................................... 475
Manage Payment Terms ......................................................................... 477
Reference Data Sharing ....................................................................... 478
Predefined Payment Terms .................................................................. 480
Types of Payment Terms ..................................................................... 481
Payment Terms Example ..................................................................... 482
Manage Common Options for Payables and Procurement ........................... 483
Default Distributions ........................................................................... 484
Automatic Offsets ............................................................................... 486
vi
Currency Conversion ........................................................................... 489
Expense Accruals ................................................................................ 491
Self-Billed Invoices ............................................................................. 492
Legal Entity Information ...................................................................... 493
Knowledge Check: Common Options ..................................................... 494
Knowledge Check: Common Options Answers ........................................ 495
Defining General Payables Options ............................................................ 496
General Payables Options Terminology .................................................... 497
Manage Invoice Options ......................................................................... 499
Invoice Entry...................................................................................... 500
Matching............................................................................................ 502
Discount ............................................................................................ 503
Prepayment ....................................................................................... 504
Approval ............................................................................................ 505
Interest ............................................................................................. 506
Payment Request ................................................................................ 508
Self-Service Invoices ........................................................................... 510
Manage Payment Options ....................................................................... 512
Account for Payment ........................................................................... 513
Manage Tax Reporting and Withholding Tax Options .................................. 515
Income Tax Reporting ......................................................................... 516
Withholding Tax.................................................................................. 517
Knowledge Check: General Payables Options ............................................ 519
Knowledge Check: General Payables Options Answers ............................... 520
Defining Payables Configuration ................................................................ 521
Manage Payables Lookups ...................................................................... 522
Manage Payables Descriptive Flexfields .................................................... 523
Manage Payables Profile Options ............................................................. 524
Manage Payables Document Sequences ................................................... 526
Manage Distribution Sets ....................................................................... 528
Manage Invoice Tolerances .................................................................... 530
Manage Invoice Holds and Releases ........................................................ 532
Manage Aging Periods ........................................................................... 533
Defining Payables US 1099 Tax ................................................................. 534
Manage Tax Regions.............................................................................. 535
Manage Reporting Entities ...................................................................... 537
Defining Payment Options ........................................................................ 539
Manage Interest Rates ........................................................................... 539
Invoice Approval Rules ............................................................................. 540
Invoice Request Approval ....................................................................... 541
Invoice Approval ................................................................................... 542
Predefined Approval Task ....................................................................... 544
Defining Subledger Accounting Rules ......................................................... 546
Relevant Setup Tasks ............................................................................ 548
Payables Event Classes and Types........................................................... 549
Lesson 9: Configuring Oracle Fusion Payments - Payables ......551
Setups and the Disbursements Process ...................................................... 552
Overview of Disbursements for Oracle Fusion Payments ............................... 554
Key Decision and Best Practices for Payment Processing ............................ 556
Key Decision and Best Practices for Organizational Structure ...................... 557
Key Decision and Best Practices for Payment Selection Criteria ................... 559
Configuring Payment System Connectivity ............................................... 561
Prerequisites for Configuring Payment System Connectivity ..................... 562
Format Concepts ................................................................................ 564
Manage Formats ................................................................................. 566
Key Decision and Best Practices for Using Formats .................................. 569
vii
Transmission Configuration Concepts .................................................... 570
Manage Transmission Configurations ..................................................... 571
Key Decision and Best Practices for Using Transmission Configurations ...... 573
Key Decision and Best Practices for Using Transmission Protocols ............. 574
Payment System Concepts ................................................................... 575
Manage Payment Systems ................................................................... 577
Key Decision and Best Practices for Using Payment Systems .................... 580
Defining Disbursements ......................................................................... 581
Prerequisites for Defining Disbursements ............................................... 583
Payment Method Concepts ................................................................... 585
Manage Payment Methods ................................................................... 586
Creating Usage Rules for Payment Methods............................................ 588
Using Validations ................................................................................ 590
Creating or Assigning Validations to Payment Methods ............................ 592
Creating User Defined Validations ......................................................... 594
Choosing Predefined Validations ........................................................... 595
Key Decision and Best Practices for Validations ....................................... 596
Manage Payment Method Defaulting Rules ............................................. 598
Manage Payment Codes ....................................................................... 600
Prerequisites for Defining Payment Process Profiles ................................. 603
Payment Process Profile Concepts ......................................................... 606
Manage Payment Process Profiles ......................................................... 608
Creating Usage Rules for a Payment Process Profile ................................ 611
Specifying a Payment System for an Electronic Payment Process Profile .... 613
Specifying Document Behavior for a Payment Process Profile ................... 615
Specifying Payment Behavior for a Payment Process Profile ..................... 617
Specifying Report Generation for a Payment Process Profile ..................... 619
Manage Disbursement System Options .................................................. 621
Lesson 9: Highlights .............................................................................. 623
Lesson 10: Configuring Oracle Fusion Assets ...........................625
Lesson 10: Objectives .............................................................................. 625
Understanding Oracle Fusion Assets .......................................................... 626
Oracle Fusion Assets Lifecycle................................................................. 628
Implementing Oracle Fusion Assets ......................................................... 630
Planning Your Implementation ................................................................ 632
Inquiring About Your Company's History ................................................ 633
Obtaining Existing Asset Information ..................................................... 634
Determining the Conversion Period ....................................................... 635
Decide on Oracle Assets Setups ............................................................ 636
Prerequisite Setup ................................................................................. 637
Oracle Fusion Assets Implementation Steps ............................................. 638
Managing Assets Key Flexfields and Value Sets ........................................... 640
Managing System Controls ....................................................................... 642
Defining Your System Controls ............................................................... 643
System Controls Implementation Considerations ....................................... 645
Knowledge Check: System Controls......................................................... 646
Knowledge Check: System Controls Answer ............................................. 647
Managing Fiscal Years and Calendars ......................................................... 648
Defining Fiscal Years ............................................................................. 650
Fiscal Year Implementation Considerations ............................................... 652
Defining Asset Calendars ....................................................................... 653
Calendar Implementation Considerations ................................................. 655
Knowledge Check: Fiscal Years and Calendars .......................................... 657
Knowledge Check: Fiscal Years and Calendars Answer ............................... 658
Prorate Convention Concepts .................................................................. 659
Prorate Convention Implementation Considerations ................................... 661
Managing Asset Locations......................................................................... 663
Location Key Flexfield Implementation Considerations ............................... 664
viii
Defining Asset Locations ........................................................................ 665
Managing Asset Books ............................................................................. 666
Asset Books and Ledgers, Subledgers, and Business Units ......................... 668
Asset Book Implementation Considerations .............................................. 670
Defining Your Asset Book: Multiple Depreciation Requirements ................... 671
Defining Your Asset Book: Multiple Currency Representations ..................... 672
Defining Your Asset Book: Multiple Accounting Representations .................. 674
Implementation Questions ..................................................................... 675
Implementation Questions (continued) .................................................... 676
Knowledge Check: Managing Asset Books ................................................ 677
Knowledge Check: Managing Asset Books Answer ..................................... 678
Reference Data Sharing Across Asset Books ............................................. 679
Reference Data Sharing: US Company Example ........................................ 680
Reference Data Sharing: Multinational Company Example .......................... 681
Define Subledger Accounting Rules ............................................................ 682
Accounting Event Model ......................................................................... 684
Managing Asset Categories ....................................................................... 687
Defining Asset Categories ...................................................................... 688
Category Key Flexfield Implementation Considerations .............................. 690
Category Implementation Considerations ................................................. 692
Knowledge Check: Managing Asset Categories .......................................... 693
Knowledge Check: Managing Asset Categories Answer............................... 694
Optional Implementation Steps ................................................................. 695
Managing Distribution Sets ..................................................................... 696
Managing Profile Options........................................................................ 697
Profile Options Settings ....................................................................... 698
Profile Options Settings (continued) ...................................................... 699
Profile Options Settings (continued) ...................................................... 700
Managing Lookups ................................................................................ 701
Managing Descriptive Flexfields .............................................................. 703
Managing Descriptive Flexfields (continued) ........................................... 705
Managing Descriptive Flexfields (continued) ........................................... 706
Managing Asset Keys ............................................................................. 707
Asset Key Flexfield Implementation Considerations ................................. 708
Knowledge Check: Managing Asset Keys ................................................ 709
Knowledge Check: Managing Asset Keys Answer .................................... 710
Managing Depreciation Rules .................................................................. 711
Defining Depreciation Methods ............................................................. 712
Defining Depreciation Methods (continued) ............................................ 713
Defining Bonus Rules .......................................................................... 714
Defining Depreciation Ceilings .............................................................. 716
Knowledge Check: Depreciation Methods ............................................... 717
Knowledge Check: Depreciation Methods Answer .................................... 718
Lesson 11: Configuring Oracle Fusion Expenses .......................721

Overview of Oracle Fusion Expenses .......................................................... 722
Expense Reimbursement Flow ................................................................ 723
Knowledge Check: 1 .............................................................................. 725
Implementing Prerequisite Products ........................................................ 726
Setting Up Prerequisite Products ............................................................. 727
Setting Up Oracle Fusion Expenses .......................................................... 729
Configuring Expense Policies and Rules .................................................... 730
Define Expense Policies and Rules ......................................................... 731
Expense Template Concepts ................................................................. 732
Considerations for Defining Expense Templates ...................................... 734
Using Expense Templates .................................................................... 735
Defining Default Expense Templates ..................................................... 736
ix
Inactivating Expense Templates ........................................................... 739
Specifying a Receipt Required Policy ..................................................... 740
Conversion Rate Policy Concepts........................................................... 741
Specifying a Conversion Rate Policy ...................................................... 742
Knowledge Check: 2 ........................................................................... 745
Knowledge Check: 3 ........................................................................... 746
Knowledge Check: 4 ........................................................................... 747
Knowledge Check: 5 ........................................................................... 748
Expenses System Options Concepts ...................................................... 749
Manage Expenses System Options ........................................................ 750
Manage Expense Report Approval Rules................................................. 752
Approval Rules Overview ..................................................................... 754
Considerations for Configuring Approval Rules ........................................ 756
Configuring Approval Rules .................................................................. 758
Configuring Credit Card Data .................................................................. 760
Define Credit Card Data ....................................................................... 761
Overview of Corporate Card Transaction Processing ................................ 762
Manage Corporate Card Issuers ............................................................ 764
Configuring Corporate Card Issuers ....................................................... 767
Corporate Card Programs Concepts ....................................................... 768
Manage Corporate Card Programs ......................................................... 769
Configuring Corporate Card Programs ................................................... 770
Specifying a Corporate Card Usage Policy .............................................. 773
Lesson 12: Configuring Oracle Fusion Receivables ...................777

Key Concepts in Oracle Fusion Receivables ................................................. 778
Order to Cash ....................................................................................... 778
Receivables Process .............................................................................. 780
Prerequisite Setups for Oracle Fusion Receivables ....................................... 781
Review Implementation Project Tasks and Assign User Assignments............ 783
Knowledge Check: Implementation Project and User Assignments .............. 786
Knowledge Check: Implementation Project and User Assignments Answer ... 787
Define Users for Credit Memo Workflow ................................................... 788
Define Subledger Accounting Rules ......................................................... 789
Accounting Event Model ....................................................................... 791
Relevant Setup Tasks .......................................................................... 794
Simple Configuration for Oracle Fusion Receivables ..................................... 795
Set Billing and Revenue Receivables System Options ................................. 797
Set System Options for Salespersons .................................................... 798
Set System Options for Transactions and Accounting ................................. 799
Set Cash Processing Receivables System Options ...................................... 801
Set Cash Processing Receivables System Options for Accounting ................. 804
Define Receivables Activities .................................................................. 806
Receivables Activity Setup ..................................................................... 809
Receivables Activities Tax Rate Code Source Usage ................................... 811
Define AutoAccounting Rules .................................................................. 813
AutoAccounting Rules Table Names and Constant Values ........................... 815
Define Receipt Classes and Receipt Methods ............................................. 817
Defining Receipt Classes ........................................................................ 819
Defining Remittance Banks for Receipt Methods ........................................ 821
Define Remit-to Addresses ..................................................................... 822
Define Approval Limits ........................................................................... 824
Define Statement Cycles ........................................................................ 826
Knowledge Check: Simple Configuration to Operate Receivables ................. 828
Knowledge Check: Simple Configuration to Operate Receivables Answers .... 829
Implementation Considerations for Transactions ......................................... 830
Define Transaction Types ....................................................................... 831
x
Using Natural Application ....................................................................... 834
Define Payment Terms .......................................................................... 836
Define Transaction Sources .................................................................... 838
Set Up Document Sequences in Receivables ............................................. 841
Set Up Balance Forward Billing ............................................................... 843
Define Memo Lines ................................................................................ 845
Implement AutoInvoice.......................................................................... 847
Setting Up for AutoInvoice ..................................................................... 849
Implementation Considerations for Receipts ............................................... 852
Define AutoCash Rules ........................................................................... 853
Define Application Rules......................................................................... 855
Define AutoMatch Rules ......................................................................... 857
Define Receipt Application Exception Rules ............................................... 860
Implementation Considerations for Lockbox ............................................. 862
Best Practices for Automatic Receipts ...................................................... 865
Best Practices for Automatic Receipt Application ....................................... 867
Implementation Considerations for Revenue Management ............................ 868
Settings for Revenue Recognition ............................................................ 869
Revenue Scheduling Rules ..................................................................... 871
Define Revenue Policies ......................................................................... 873
Define Revenue Contingencies ................................................................ 875
Knowledge Check: Additional Implementation Considerations ..................... 877
Knowledge Check: Additional Implementation Considerations Answers ........ 878
Customers and Parties ............................................................................. 879
Manage Customers................................................................................ 881
Manage Customer Profile Classes ............................................................ 883
Lesson 13: Configuring Oracle Fusion Payments – Receivables 886
Setups and the Funds Capture Process....................................................... 887
Overview of Funds Capture for Oracle Fusion Payments ............................... 889
Defining Funds Capture ......................................................................... 891
Prerequisites for Defining Funds Capture ............................................... 893
Funds Capture Concepts ...................................................................... 898
Manage Funds Capture Payment Methods .............................................. 900
Key Decision and Best Practices for Funds Capture Payment Methods ........ 902
Manage Funds Capture Process Profiles ................................................. 904
Formatting Messages .......................................................................... 905
Building Settlements into a Settlement Batch ......................................... 907
Transmitting Messages to the Payment System ...................................... 908
Manage Internal Payees....................................................................... 910
Creating and Assigning Routing Rules to Internal Payees ......................... 912
Key Decision and Best Practices for Internal Payees ................................ 915
Defining Payments Security .................................................................... 916
Prerequisite for Defining Payments Security ........................................... 917
Security Options Concepts ................................................................... 919
Manage System Security Options .......................................................... 920
Key Decision and Best Practices for Security .......................................... 922
Key Decision and Best Practices for Encryption and Masking..................... 923
Encrypting Credit Card Data ................................................................. 924
Encrypting Bank Account Data .............................................................. 925
Rotating the System Key ..................................................................... 926
Masking Credit Card and Bank Account Numbers .................................... 928
Lesson 13: Highlights ............................................................................ 929
Lesson 14: Configuring Oracle Fusion Advanced Collections ....930
Oracle Fusion Advanced Collections ........................................................... 931
xi
Collections Overview and Process ............................................................ 932
Define Collections in Setup Manager ........................................................ 934
Related Fusion Applications Requirements ................................................ 936
Manage Aging Methods ............................................................................ 937
Manage Collectors ................................................................................... 939
Setting Up Collectors ............................................................................. 940
Manage Dunning Configurations ................................................................ 942
Seeded Dunning Configurations .............................................................. 944
Creating Dunning Configurations ............................................................. 948
Manage Collections Preferences ................................................................ 950
Configuring Collections Preferences ......................................................... 951
Optional Implementation Configurations..................................................... 953
Manage Collections Lookups ................................................................... 954
Manage Collections Note Types and Mapping ............................................ 956
Managing Note Descriptive Flexfields ....................................................... 957
Lesson 15: Configuring Oracle Fusion Cash Management .........960
Oracle Fusion Cash Management ............................................................... 961
Cash Management Overview................................................................... 962
Define Cash Management in Setup Manager ............................................. 964
Set Up Banks, Branches, and Accounts ...................................................... 966
Manage Banks ...................................................................................... 969
Manage Branches .................................................................................. 970
Manage Accounts .................................................................................. 971
Define Bank Statement Processing ............................................................ 976
Manage Bank Statement Transaction Codes ............................................. 977
Create and Edit Bank Statement Transaction Codes .................................. 978
Manage Parsing Rule Sets ...................................................................... 981
Create Parse Rules ................................................................................ 982
Payment Setups for Bank Statement Processing ....................................... 985
Define Bank Statement Reconciliation ........................................................ 986
Manage Cash Transaction Type Mapping .................................................. 987
Create Mapping .................................................................................... 989
Manage Bank Statement Reconciliation Tolerance Rules ............................. 991
Create Tolerance Rules .......................................................................... 993
Manage Bank Statement Reconciliation Matching Rules .............................. 996
Create Matching Rules ........................................................................... 997
Manage Bank Statement Reconciliation Rule Sets...................................... 999
Create Rule Sets ................................................................................. 1001
Manage Bank Statement Transaction Creation Rules ............................... 1003
Create, Edit, and View Transaction Creation Rules ................................... 1005
Define Subledger Accounting Rules for Cash Management .......................... 1008
Accounting Event Model ....................................................................... 1010
Relevant Setup Tasks .......................................................................... 1013
Lesson 15: Highlights ............................................................................ 1014
Lesson 16: Appendix .............................................................. 1016
Appendix Content .................................................................................. 1017
Common Applications Additional Topics .................................................... 1018
Getting Started with an Implementation ................................................ 1019
Getting Started Objectives ................................................................. 1020
Overview of Getting Started ............................................................... 1021
Prepare the Super User ..................................................................... 1024
Define Implementation Users ............................................................. 1027
Getting Started Highlights .................................................................. 1028
Getting Started Reference Resources .................................................. 1029
Define Application Toolkit Configuration ................................................. 1030
xii
Lesson Objectives ............................................................................. 1031
Reports and Analytics Pane ................................................................ 1032
Map Reports to Work Areas ................................................................ 1033
Watchlist ......................................................................................... 1034
Set Watchlist Options: Disabling Items and Categories .......................... 1036
Set Watchlist Options: Defining Refresh Intervals ................................. 1038
Rename Predefined Categories and Items ............................................ 1039
Reference Resources ......................................................................... 1040
Highlights ........................................................................................ 1041
Define Approval Management ............................................................... 1042
Approval Management Overview ......................................................... 1044
Key Concepts ................................................................................... 1046
Example .......................................................................................... 1048
Manage Task Configurations ............................................................... 1050
Data Driven Tab ............................................................................... 1052
Event Driven Tab .............................................................................. 1055
Manage Approval Groups ................................................................... 1057
Example: Setting Up Payables Invoice Approval.................................... 1059
Highlights ........................................................................................ 1067
Define Attachments ............................................................................. 1068
Key Concepts ................................................................................... 1069
Manage Attachment Categories .......................................................... 1071
Attachment Category Security ............................................................ 1072
Example .......................................................................................... 1073
Define Custom Enterprise Scheduler Jobs ............................................... 1074
Manage Job Definitions ...................................................................... 1076
Manage List of Values Sources............................................................ 1077
Highlights ........................................................................................ 1079
Define Help Configuration .................................................................... 1084
Set Help Options............................................................................... 1086
Assign Help Text Administration Duty .................................................. 1087
Manage Help Security Groups ............................................................. 1088
Highlights ........................................................................................ 1090
Define Flexfields ................................................................................. 1091
Flexfield Concepts ............................................................................. 1092
Value Sets ....................................................................................... 1096
Descriptive Flexfields......................................................................... 1098
Extensible Flexfields .......................................................................... 1099
Extensible Flexfield Example .............................................................. 1100
Key Flexfields ................................................................................... 1102
Tips for Managing Key Flexfields ......................................................... 1104
Flexfield Implementation Flow ............................................................ 1105
Flexfield Highlights ............................................................................ 1107
Flexfield Reference Resources ............................................................ 1108
Define Lookups ................................................................................... 1109
Key Concepts ................................................................................... 1110
Manage Lookups ............................................................................... 1113
Manage Menu Customizations ............................................................... 1115
Define Profile Options .......................................................................... 1116
Profile Options .................................................................................. 1117
Profile Option Categories ................................................................... 1118
Profile Option Levels and Values ......................................................... 1119
Profile Options for Common Set Up ..................................................... 1121
xiii
Define Security ................................................................................... 1122
Security Key Concepts ....................................................................... 1123
Role-Based Access Control ................................................................. 1124
Function and Data Security ................................................................ 1127
Access Provisioning and Identity Management ...................................... 1129
Security Reference Implementation..................................................... 1130
Defining Data Security....................................................................... 1131
Data Security Policies ........................................................................ 1132
Data Role Templates ......................................................................... 1135
Data Role and HCM Security Profiles ................................................... 1136
Defining Users Overview .................................................................... 1137
Creating Users and Importing Users .................................................... 1139
Provisioning Users with Roles ............................................................. 1140
Role Provisioning Events .................................................................... 1141
Define Security Highlights .................................................................. 1142
Security Reference Resources............................................................. 1143
Define Trees ....................................................................................... 1144
Trees .............................................................................................. 1145
Tree Structures ................................................................................ 1146
Tree Node ........................................................................................ 1147
Tree Label........................................................................................ 1148
Tree Versions ................................................................................... 1149
Manage Messages ............................................................................... 1150
Editing Message Text ........................................................................ 1151
xiv
Lesson 1: Introduction to Oracle Fusion Financials

Lesson 1: Objectives
After completing this course, you should be able to:
 Identify the key concepts of Oracle Fusion Financials Offering that

determine a successful implementation.
 Use Oracle Functional Setup Manager (FSM) to implement Oracle Fusion
Financials.
 Discuss the common applications configuration for Oracle Fusion
Financials.
 Describe configuration of enterprise structures and the related InFusion
Story.
 Define Oracle Fusion General Ledger.
 Define Oracle Fusion Subledger Accounting.
 Define Intercompany.
 Define Oracle Fusion Tax.
 Define Oracle Fusion Payables.
 Define Oracle Fusion Payments for Disbursements.
 Define Oracle Fusion Expenses.
 Define Oracle Fusion Assets.
 Define Oracle Fusion Receivables.
 Define Oracle Fusion Payments for Funds Capture.
 Define Oracle Fusion Advanced Collections.
 Define Oracle Fusion Cash Management.
Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 1

Course Approach
Each lesson in this course will begin with your instructor presenting important
concepts related to implementing the Oracle Fusion Financials. The lesson may
also include one or more of the following activities:
 Complete a portion of the case study in the Financial Setup Manager (FSM).
 Discuss key decisions and best practices.
 Complete a quiz or knowledge assessment task.
In this course the instructor:
 Presents introductory modules.

 Acts as a business analyst representing the case study customer.
 Imparts information to assist you with the Oracle Fusion Financial
implementation.
 Provides review sessions as needed.
2 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Oracle Fusion Implementation Resources
Classroom Resources:
 Oracle Fusion Financials: Introduction to Financials Implementation (this guide)

 Oracle Fusion Applications Help
 Your Instructor
 Other Students
Related Resources:
 Oracle Fusion Applications Financials Implementation Guide

 Getting Started with Oracle Fusion Applications: Common Implementation
 Getting Started with Oracle Fusion Applications: Enterprise Structures for
Financials
 Oracle Fusion Applications Asset Lifecycle Management, Assets Guide
 Oracle Fusion Applications Financial Control and Reporting, Accounting
Transactions, Tax Transactions, and Reporting Guide
 Oracle Fusion Applications Order Fulfillment, Receivables, Payments, Cash, and
Collections Guide
 Oracle Fusion Applications Procurement, Payables, Payments, and Cash Guide
 Oracle Fusion Applications Workforce Deployment, Expenses Guide.
 Oracle Fusion Accounting Hub Implementation Guide
 Oracle Essbase Database Administrator's Guide for Oracle Essbase

 Oracle Hyperion Financial Reporting Administrator's Guide for Oracle Hyperion

Financial Reporting
 Oracle Hyperion Financial Reporting Studio User's Guide for Oracle Hyperion
Financial Reporting Studio
 Oracle Fusion Transactional Business Intelligence Administrator’s Guide
 Oracle Fusion Applications Information Technology Management, Implement
Applications Guide
 Oracle Hyperion Enterprise Performance Management System Installation and
Configuration Guide, for Oracle Hyperion Enterprise
Performance Management, especially the Installing Smart View topic.
 Oracle Hyperion Smart View for Office, Fusion Edition User's Guide for Oracle
Hyperion Smart View
 Oracle Hyperion Financial Data Quality Management ERP Integrator Adapter for
Oracle Applications Administrator's Guide
Recommended Resources:
 Oracle Fusion Applications Administrator and Implementor Roadmap

 Oracle Fusion Technology Library on OTN
(http://www.oracle.com/technetwork/documentation/index.html#fusion_applicatio
ns)
 Getting Started with Oracle Fusion Applications: Common Implementation,

Article ID 1387777.1 on Oracle Support (http://oracle.support.com)
 Getting Started with Oracle Fusion Applications: Enterprises Structures for
Financials, Article ID 1387746.1 on Oracle Support (http://oracle.support.com)
 Oracle Fusion Middleware Report Designer's Guide for Oracle Business
Intelligence Publisher
(http://docs.oracle.com/cd/E25054_01/bi.1111/e13881/toc.htm)
 Working with Fusion Payments Formats: Article ID 1413989.1 on Oracle Support
(http://oracle.support.com).

Course Schedule
This course is designed to generally follow this agenda:
Day One:
 Oracle Fusion Financials Course Overview

 Introduction to Functional Setup Manager for Financials
 The InFusion Story
 Common Applications Configuration
 Oracle Fusion General Ledger
Day Two:
 Oracle Fusion General Ledger Continued

 Oracle Fusion Subledger Accounting
 Configure Intercompany
Day Three:
 Oracle Fusion Tax

 Oracle Fusion Payables
 Oracle Fusion Payments
Day Four:
 Oracle Fusion Assets

 Oracle Fusion Expense
 Oracle Fusion Receivables
Day Five:
 Oracle Fusion Receivables Continued

 Oracle Fusion Advanced Collections
 Oracle Fusion Cash Management

Introduction to Oracle Fusion Financials
This lesson covers the following topics:

 Overview
 Organizational Models in Oracle Fusion Financials
 Strategy and Planning of a Financial Implementation
 Introduction to the InFusion Corporation case study
 Introduction to Functional Setup Manager
 Introduction to Common Applications Configuration
 Introduction to implementing the Oracle Fusion Financial products
Overview
Oracle Fusion Applications are a complete set of business applications that sets the new standard for
innovation, work, and adoption. The Oracle Fusion Applications include applications for Customer
Relationship Management, Governance Risk and Compliance, Human Capital Management, Supply
Chain Management, Financial Management, Procurement and Project Portfolio Management . It sets the
new standard for innovation with its complete, standards-based platform and service-oriented architecture
that quickly adapts to changing business needs while lowering integration costs and other short and long-
term costs. Oracle Fusion Applications work the way end users do through role-based dashboards,
embedded business intelligence, and collaboration tools that dramatically increase productivity and
improve decision making. Oracle Fusion Applications allows companies to implement applications in a
modular fashion using delivery strategies that meet their enterprise IT strategy.

Oracle Fusion Financials is a complete and integrated financial management solution that sets the
foundation for good governance and consistent growth while helping today's fast-growing and dynamic
organizations make better decisions, increase efficiency, reduce costs, and continuously innovate. It is a
comprehensive solution that arms finance professionals with the right information at the right time,
increases productivity, and accelerates business performance.
Oracle Fusion Financials help companies meet their obligations in key areas such as:
• Compliance
• Financial Control
• Regulatory Reporting
• Cost Containment
• Risk Management
Oracle Fusion Financials consists of the following applications:

• General Ledger
• Accounts Payable
• Payments and Collections
• Accounts Receivable
• Cash & Expense Management
• Asset Management
• Common Modules
Organizational Models in Oracle Financials

Oracle Fusion Applications use a variety of organizational constructs to capture corporate structures that
exist in the real world. This course provides detailed information on the organizations you can set up in
Oracle Fusion Applications to represent your enterprise.
This course discusses how you might:

• Represent your registered companies and management organization in the system
• Report and analyze your business data
• Account for your businesses to management, investors, and authorities
• Share services across your world-wide operations
• Understand what other products do within Oracle Fusion Applications
• Control and ensure compliance across your organization
• Analyze and evaluate your enterprise performance

• Secure your information
Your Organization
Oracle Financials can be implemented in multiple ways to reflect your real-world organization. Groups
generally reflect a tension between their legal organization, management organization, and business
divisions.
The Legal Organization

Our ability to buy and sell, own, and employ comes from our charter in the legal system. Commercial
groups exist through corporate law. Units in the legal structure of a group are individual companies that
share common ownership and control. In a public group, a company is owned by the public through
shares sold on a stock market. In a private group, they are held by a privately held holding company. In
other organizations, the legal entities are partnerships, funds, or government agencies.
A legally recognized entity can own and trade assets and employ people; while an entity without legal
recognition cannot. When granted these privileges, legal entities are also assigned responsibilities to
account for themselves to the public (statutory reporting and external reporting), comply with legislation
and regulations, and pay income or profit and transaction taxes.
Most groups have many legal entities. They are created to facilitate legal compliance, segregate
operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the
laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance,
and taxation. The following diagram shows an archetypical group of companies operating various
businesses and a standard functional organization.
 A separate card represents each of a series of registered companies, that is, legal entities. The
list of cards is the "Legal Axis".
 Each company hosts parts or all of various subdivisions that management has made within its
businesses. These are shown as vertical columns on each card. For example, a Group might
have a separate company for each business in the United Kingdom, but have their Ireland
company host all businesses in that country.
 The subdivisions are linked across the cards so that a business can appear on some or all of the
cards. For example, the chemical business might be operated by the Ireland, United Kingdom,
and France companies. The list of business subdivisions is the "Business Axis".
 Each company's card is also horizontally striped by functional groups, such as the sales team
and the finance team. The functional list is the "Functional Axis".
The overall image suggests that information might, at a minimum, be tracked by company, business
subdivision, and function in a group environment.


Business Divisions
Successfully managing multiple businesses requires that you segregate them by the rewards and risks
involved in making them profitable. You divide your organization accordingly and assign management
personnel to each division.
Although related to your legal structure, the business organizational hierarchies do not need to be
reflected directly in the legal structure of the firm. The management entities and structure include
divisions and subdivisions, lines of business, and other strategic business units, and include their own
revenue and cost centers.
Functional Organizations
Straddling the legal and business organizations is an organization structured around people and their
competencies: sales force, operations, plants, researchers, finance people, human resource
management, information technologists, and management. The income statement often reflects their
efforts and expenses directly. Organizations must manage and report revenues, cost of sales, and
functional expenses such as Research and Development (R&D) and Selling, General, and Administrative
Expense (SG&A).
Other Organizational Structures

Oracle Fusion Financials formally recognizes several other organizational structures that will exist in your
enterprise, in the data schema. You will have processing structures along different business flows:
• Personnel reporting structures that may or may not correspond with the business hierarchy or legal or
external reporting dictates.
• Product driven structures in your production environment that may or may not correspond with your
market and delivery structures.
The Role of Your Legal Entities

Your legal entities, whether commercial registered companies or entities incorporated under laws other
than company laws, play a pivotal role in your processing systems.
Compliance and Disclosure Requirements

Legal entities are formally the entities that actually enter into transactions. Individual legal entities own the
assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses,
and make other transactions.
All legal entities exist in particular legal jurisdictions, both national and regulatory, and must comply with
the regulations of those jurisdictions. Legal entities have multiple compliance requirements placed on
them, many of which define the form of the transactions into which that legal entity enters.
Many company statutes require that legal entities created in compliance with them publish specific and
periodic disclosures. Annual or more frequent accounting reports, often referred to as "statutory accounts"
and "external reporting," are required. These must be reported to specified national and regulatory
authorities, for example the Securities and Exchange Commission (SEC) in the United States. Disclosure
requirements are diverse. Local entities file locally using local regulations and currency,
and through their holding company using parent Generally Accepted Accounting Principles (GAAP) and
currency.
A given legal entity may or may not represent all or part of a management framework in its domain. For
example, in a large country such as the United Kingdom or Germany, you might deploy individual
companies to represent each business division, and you might control many companies in that country. In
a smaller country, for example Austria, you might use a single legal entity to host all of your business
divisions. Legal entities have very specific relationships with shared service centers and with the

ownership of the goods and transactions managed by such centers.
Representing Your Organization in the System

Organization Structures
Oracle Fusion Financials has powerful schemas of organization units that support your legal,
management, and functional organization. They are designed to:
• Ease the management of your worldwide shared service organization and facilitate sourcing at the
optimal mix of employee cost, data flow, and management control.
• Provide access control and security, excluding those without authority, and facilitating access across
units for those who need it.
• Administer compliance and segregate transactions and administrative rules by jurisdiction.
• Provide attributes for reporting and identify business events according to the relevant business
dimensions.
Organizations and Transactions

Oracle Fusion Financials enables you to categorize and classify your transactions to the level of
granularity required to reflect each of these organizations. A single transaction can be categorized as
follows:
• On the Legal axis: By company or other legal entity, by groups of companies, and by legal reporting unit.
Legal Reporting unit reflects a legal entity in a jurisdiction for purposes such as payment of transaction
taxes.
• On the Management axis: Business classification by several management entities.
• On the Functional axis: By nature of the transaction (for example, detailed accounts involved such as
marketing or cost of sales). By people and cost centers involved.
• By Other attributes.
The core task of Oracle Fusion Financials applications is to track the appropriate business and
accounting attributes of a transaction. Business attributes are tracked in the product modules and include
such details as trading partner, subject matter, quantity, price, agent, employee, tax, addresses, dates,
and so on. Accounting attributes are generated from that data by our subledger accounting engine and
are recorded in detail in the subledger accounting tables and at your choice of summary level in General
Ledger.
Organizational Classifications in Fusion Financials

Two vehicles, system organization entities and the chart of accounts, are the cornerstones for securing
transactions and modeling an enterprise in Oracle Fusion Applications. The assembly of these building
blocks to model your enterprise will define the representation of your business and your process flows in
the applications suite.
In general, a system organization entity might represent any real organizational unit within a business.
Depending on their classification, system entities deliver specific features and controls, such as access
control and shared service administration, policy, legal or compliance administration, data storage, and
employee administration. Oracle Fusion Financials provides names that reflect that functionality. In
general, assigning a system entity to represent a real world entity with the same nomenclature is an
effective choice.
By contrast, a chart of accounts representation of a real world entity is an identifier for analysis and
accounting, with fewer features and control associated with it. Important entities, such as cost center and
legal entity, can be represented by both a system entity and as a value in a chart of accounts section.
Several system entities are so closely tied to accounting entities that we automatically correlate them;
others have looser associations so that you can tune the relationship to your actual organization.

System Entities
Oracle Fusion Applications include the following important system entities:
• Legal Entity
• Ledgers
• Business Unit
• Enterprise
• Inventory Organization
Legal Entity
"Legal entity" in the Oracle Fusion system corresponds closely to "legal entity" or "company" in the legal
world. You can store information about a registered company or other real world legal entity in the "legal
entity". For example, you can store the registered address and director or officer names.
The legal entity administers transaction level rules in compliance with national laws.
A real world legal entity is a discrete legal personality characterized by the legal environment in which it
operates.
In the real world, legal entities have the right to own property, the right to trade, and the responsibility to
comply with appropriate laws. They also often have the responsibility to account for themselves (balance
sheet, income statement, specified reports) to company regulators, taxation authorities, and owners
according to rules specified in the relevant legislation.
Oracle Fusion Applications reflect the real world for legal entities. The system legal entity is the first party
on business transactions and is the transaction tax filer and payer. We recognize that for many groups,
particularly in environments where the authorities allow you to treat many legal entities as one, you don't
need or want to segment data or account separately for each entity that you have incorporated.
Therefore, the system legal entity does not automatically account for itself.
Instead, we facilitate correlation of subledger activity with reporting legal structures by exploiting related
system entities for business units, ledgers, and company representation in the chart of accounts.
• You can account for any real world legal entity separately if you need to do so;
• You can account for a group of real world legal entities as if they were one when that fits your model;
• And you can account for a part of a real world legal entity as if it were completely standalone when
appropriate.
A system legal entity can account for its transactions in many ledgers, using different accounting
conventions, or using different currencies.
Legal Environment Considerations

There are two extremes to the legal environment that you might want to reflect in your setup.
1. In some jurisdictions, such as the United States, you might have many legal entities represented as
balancing segments in one ledger.
2. In other jurisdictions, each legal entity will be required to have a ledger of its own.
Around these extremes, several other arrangements are also supported.
If the Regulatory Situation of Your Subsidiaries Requires a Distinct Ledger

Certain authorities are focused on individual entities in the legal system and have drafted regulations that
require you to deal with each legal entity as a standalone entity. In this situation, you would assign a
legal entity one primary ledger. This is appropriate in the following situations:
• If the legal entity operates in a country with strict legislative demands. Legal or statutory rules may
require a separate ledger for the legal entity and require the entity to maintain its accounting data
separate from other legal entities.

• If the legal entity has unique primary ledger attributes. In other words, if a legal entity requires any one
of the 4 C's (or any of the ledger processing options) to be different from other legal entities, a different
primary ledger is required.
Note: The 4 C's is defined as Chart of Accounts, Calendar, Currency, and accounting Convention (also
known as accounting method).
Gapless Document Sequencing

Depending on the regulatory and accounting requirements of the countries in which you operate, it may
be necessary to set up document sequencing for applications. Some countries impose strict legal
requirements for maintaining a distinct and auditable number range for financial transactions.
In the subledgers, gapless document sequences are maintained at the business unit level. You cannot
create a single sequence that crosses business units in a subledger product.
This very often drives the creation of a businessunit; you will create business units in regulated countries
that correspond to the entities that need to sequence subledger documents.
In General Ledger, document sequences are generated for transactions at the ledger level, that is, all
business units and all legal entities associated with a given ledger will share available General Ledger
numbering sequences. In the rare situation that a local regulatory authority requires gapless General
Ledger document sequencing and gapless subledger document sequencing, it may be necessary to
maintain a one to one relationship between a legal entity, a ledger, and a business unit.
You can create secondary ledgers to represent the primary ledger's accounting data in a format that will
be consolidated with the parent. If you create ledgers for sequence management purposes, use a ledger
set so that you can treat them as one for accounting, adjustment, allocation, reporting, management, and
consolidation purposes.
If the Regulatory Situation of Your Subsidiaries Facilitates Using One Ledger in

Respect to Several Companies
Certain authorities focus on groups of legal entities in the legal system - where they "lift the veil of
incorporation" - and have drafted regulations that permit or require you to combine legal entities that you
control for compliance purposes in a given jurisdiction. This situation will allow multiple legal entities to be
associated with the same primary ledger, that is multiple legal entities can share the ledger attributes (4
C's) and ledger processing options of the primary ledger.
This accounting setup is appropriate when each of the legal entities assigned to the accounting setup
meets the following conditions:
• Operate in a country that allows multiple legal entities to share the same primary ledger, ledger
attributes, and accounting options.
• Do not need to use different ledger processing options (such as autonomous document sequencing) for
each legal entity.
• Do not have tax requirements that are specific to a legal entity.
Other Accounting Environment

It is also possible to use accounting setups that have no legal entities and do not establish any legal
relationship in respect to the primary ledger for that accounting setup. Use this setup to supplement
regular accounting arrangements. For example, you can maintain various ledgers for management
reporting or consolidation purposes.
Ledgers, Multiple Ledgers, Ledger Sets, Balancing Segments, and

Subledgers
Ledger
A fundamental concept in Oracle Fusion Applications is the "Ledger." The Ledger represents an
accounting representation for an organization that is accountable in a self-contained way.

A ledger owner might be a legal entity, a group of companies in a common legal environment, a
substantial operation within a legal entity but with legal entity attributes, or a foreign branch. Ledgers are
also used to consolidate and manage reporting. In a pure implementation, "a legal entity accounts for
itself in a ledger".
A ledger provides balanced ledger accounting for the accounting entity and serves as the repository of
financial information. Consequently, it is the principal source of information for the analytical applications
in Oracle Fusion Applications.
Ledger balances have meaning - they assert that the balance:

1. on an account
2. at a given date
3. has a specific value in a particular currency and
4. is properly calculated.
This implies a consistent application of what we sometimes call "the 4 Cs": Chart of Accounts (COA),
Calendar, Currency, and accounting Convention. The COA provides the account; Calendar the date;
Currency the amount; and Convention the calculation.
Multiple Accounting and Currency Representations
Companies often have to perform accounting for their business by more than one set of accounting rules
or accounting principles when it must report to multiple regulatory, industry, or legislative authorities. You
can achieve this by using multiple ledgers for an accounting entity.
When a company must provide both a corporate view and a local country view of its business results, and
possibly in different currencies, accounting policies, charts of accounts or calendars, Oracle Fusion
Financials provides primary ledgers, secondary ledgers, and reporting currency ledgers to meet these
needs. You choose the appropriate accounting configuration according to your needs. Following is the
recommended approach to configuring your ledgers, depending on the degree of difference between your
corporate and local country accounting policies.
The primary ledger should represent the local country’s accounting policy and local currency if:
1. the majority of transactions are denominated in the local currency, or
2. the transactions are subject to transaction taxes (GST, Sales tax, VAT, etc.) in the country where
they incurred, or
3. the local regulation requires it, or
4. there is a high level of conflict between the local country’s accounting policy and the corporate
accounting policy.
Our recommendation is to use local currency in the primary ledger to account for local businesses if it is
mostly denominated in local currency, and to use Reporting Currencies configured for either translation or
remeasurement as appropriate to get to the corporate position/currency. If you have a local operation
managed from overseas and need to see every transaction in the corporate currency, use a reporting
currency ledger at the subledger transaction level. If want to have a ledger populated (for analytic
purposes) with corporate valuations, use a reporting currency ledger at the journal level. For the
translation or remeasurement as described in FAS 52 or in IAS 21, use reporting currencies at the
balance level (GL Translation). A secondary ledger is used to represent the corporate accounting policy.
The primary ledger can represent the corporate accounting policy and local currency if there is a low or
medium level of conflict between the local country’s accounting policy and the corporate accounting
policy. In the case of low conflict, minor adjustment entries can be made within the primary ledger to
achieve the local country accounting policy. In the case of medium conflict, a secondary ledger can be

used to represent the local country accounting policy. Similarly, our recommendation is to use local
currency in the primary ledger to account for local businesses if it is mostly denominated in local currency,
and to use Reporting Currencies configured for either translation or remeasurement as appropriate to get
to the corporate position/currency. The following diagram provides a summary of your options.
Ledger Sets
Ledgers can be grouped into "Ledger Sets". A Ledger Set is a collection of ledgers that you wish to
manage as though they were one ledger. "Manage" includes reporting, opening and closing, running
allocation calculations, and entries. For example:
• You have 26 registered companies in Regmany. Regmany regulations require that each company
maintains a distinct book of accounts. You set up a Ledger for each company and group them into a
Ledger Set. Your finance staff can treat the collection as if they were one for all accounting activities,
while the data remains distinct for each company.
• You could create a Parent Currency and Parent GAAP ledger for each overseas operation. You can
group all of them into a Parent View Ledger Set. Your corporate finance staff can treat them as one
worldwide ledger for all accounting activities.
Primary Balancing Segment

Ledgers balance, that is, the sum of the debit and credit balances equal each other and you can prepare
an income statement and balance sheet from them. Oracle Fusion Financials checks that imported data,

subledger posting, and journal entries (adjustments) balance, in order to maintain this integrity. Ledgers in
a Ledger Set also balance and are also used for financial reporting.
Within a ledger, you can nominate a segment of your chart of accounts to be a "primary balancing
segment". The values (Primary balancing Segment Values or BSV) that you assign in that segment will
represent entities in your organization for which you want to measure both income and wealth, that is, to
prepare income statements and balance sheets, and to measure return on investment.
You might do this for divisions, plants, externally reportable segments, legal entities sharing a jurisdiction,
and for other reasons.
Customers frequently combine entities into BSVs and report on groups of them. For example, if you want
to track return on investment (ROI) on both "plants" and "divisions", you might create balancing segment
values as shown in the following table.
Division Plant Primary Balancing Segment Values

D01 P100 D01:P100
D01 P200 D01:P200
D02 P100 D02:P100
D03 P200 D03:P200
During setup, you can specify whether a system legal entity uses a whole Ledger or primary balancing
segment values.
Ledgers and Subledgers

Oracle Financials reflects the traditional segregation between the general ledger and associated
subledgers.
Detailed transaction information is captured in the subledgers and periodically posted (in summary or
detail form) to the ledger. You post from subledger to general ledger in real time, without any grouped
processing, or you can post on a schedule corresponding to your practice.
Business Units
Business Units
In the financial applications of Oracle Fusion Applications, a Business Unit (BU) is a system organization
that:
1. Performs business functions – assign business functions to business units and associate business
units with a ledger in order to process and partition your business transactions.
2. Partitions transactions – business transactions generated in a particular business unit is stored
separately from transactions processed in other business units.
3. Secures transactions – assign data roles associated with your business units to your users to secure
access to your business transactions.
4. Shares reference data – reference data objects can be shared across multiple business units, thus
significantly reducing setup efforts.
You can use BUs to store data on behalf of a Legal Entity. As compliance with transaction tax auditing
legislation is built into transaction types and transaction types are stored by a BU, this is an effective way
to manage transaction compliance. The real world legal entity's compliance obligations are administered
by:
• BU on subledger transactions and
• Ledger for balancing, closing, and reporting rules. Depending on the nature of the regulation with which
you must comply, various combinations of real world company and system legal entity, BU, and Ledger
are possible. In a worldwide deployment, one would expect to see all combinations in place
in different situations.

• One legal entity accounts for itself in one Ledger storing subledger data in one BU. This is a normal
setup for a country or region that closely regulates subledger data by legal entity.
• Several legal entities account for themselves in one Ledger storing subledger data in one BU, and use
the Chart of Accounts primary balancing segment to produce financial statements for each legal entity.
This is a normal setup for a country or region that regulates a group of companies as a whole.
• A legal entity or group of legal entities account for themselves in one Ledger storing subledger data in
several BUs. This is a normal setup for a group doing business in highly regulated industries in a given
country or region.
• A part of a legal entity accounts for itself in a ledger using one or several BUs. This is a normal situation
for a large corporation using several instances or Enterprise Resource Planning (ERP) systems.
System legal entities, Ledgers, and BUs are defined in relationship to one another. A legal entity accounts
for itself in the Primary Ledger and optionally in other ledgers, and stores its subledger data in one or
more BUs.
BUs are often identified with security. In Oracle Fusion Applications, users are given access to the data
they handle though "data roles". A data role is associated with a specific BU. A user can be granted
access to several BUs through the assignment of multiple data roles. By securing subledger data in this
way users can access and process transaction information only for the particular business unit or set of
business units to which they have been granted access. They view only what they need and have
authorization to view.
This is very fundamental security. Oracle Fusion Applications incorporate many other security models
specific to circumstances that match the usage and deployment requirement needs that you have for
those circumstances to provide comprehensive and appropriate security.
BUs can be used to model autonomous organizational units that create financial transactions. You create,
process, and report on subledger financial data within the context of a BU.
• Use a BU when you need to keep the data of one organization distinct - at arms length - from the data of
another organization. You might have the right to prevent a state's transaction tax auditor from viewing
the transactions of a neighboring state; consider storing each state's transactions in separate BUs. This
right often exists when the states are independent nations, but seldom when they are federated.
• Use a BU when you need to comply with transaction tax law that is substantially different (more than just
the tax rates) to similar laws in neighboring state. You can use product "transaction types" to create
similar transactions that follow different documentation and processing practices.
• Use a BU when you wish to keep data of an operation private from management of another operation.
For example, within a financial institution division, you may want to keep the transactions and data of the
lending operation separate from that of the brokerage operations.
BUs divide the subledger document data in Oracle Fusion Financials into distinct segments. Standard
reports and processes run within BUs; and 'special' reports and processes run across them. You can
deploy BUs to provide barriers that require special access, reporting, and processing to cross.
Subledger Accounting and Business Units

While subledger transaction rules are governed by BU, subledger accounting rules are not BU
dependent.
BUs store transaction types and rules that govern the transaction document such as invoices, and the
business rules (for example, credit terms) that you want applied to those documents.
Subledger accounting rules are not stored by BU. They are stored centrally, but can refer to any data
(including BU identifiers) associated with the transaction to derive the appropriate accounting.
Reference Data Sharing

Share your reference data (setup data) by grouping them into reference data sets and associating them
with one or more business units. Being able to share reference data across business units enables faster
and easier definition and maintenance of setup data, eliminates duplication, and ensures a single source
of truth for setups. For example, an organization has several business units and each business unit has

a set of payment terms that can be applied on a customer invoice. Instead of each business unit creating
and maintaining multiple sets of the same payment terms, you can define the payment terms reference
data at the organization level and stripe that data into partitions (create reference data sets) so that the
different payment terms can be assigned to each business unit.
If your enterprise has country specific requirements that affect your reference data, consider creating
separate reference data sets and business units to meet these local requirements.
Shared Services
The setup of business units provides a powerful security construct in the applications by creating a tight
relationship between the functions a user can perform and the data that a user can process. This security
model is appropriate in a business environment where local business units are solely responsible for
managing all aspects of the finance and administration functions.
In a worldwide deployment, this tight relationship provides an internal control on inappropriate processing.
For example, in traditional local operations, an invoice of one BU (a system representation of, perhaps, a
company in a country) cannot be paid by a payment from another (a system representation of, perhaps, a
different company in a different country). This would amount to tax fraud.
By contrast, in a Shared Service Center environment, processes that allow one company to perform
services for others, with appropriate intercompany accounting, require that users access the data of
different companies, each complying with different local requirements.
To accommodate shared services we use Role Based Access Control to expand the relationship between
functions and data. There are two types of relationships:
 Service/Provider Model - You can define relationships between business units to outline which
business unit provides services to the other business units. Your business units that have the
requisitioning business function can define relationships with business units that have the
procurement business function enabled. If you operate in this model, consider minimizing the
number of business units assigned to your primary ledgers because security considerations might
not be as prominent in the case of a shared service center.
 Non Service/Provider Model – Each business unit performs all business functions throughout
the transaction life cycle (business units do not provide services to other business units). A user
in the shared service center could manage more than one of these business units and is
assigned access to multiple business units for which he is responsible for transaction processing.
You can isolate your data by BU for security and local level compliance and also enable certain
users and processes to work across them. Consider an environment where the orders are taken
in several different BUs each representing different registered companies. These BUs segregate
the orders and data appropriately. However, all of these orders can be managed from a "shared
service" order desk in an outsourcing environment through a single job role.
Enterprise
Enterprise
The Enterprise is set up in Oracle Fusion Human Capital Management (HCM) and represents a company
or enterprise that consists of legal entities under common control and management. Each Enterprise has
one global version of all work structures and people. All customer specific data must exist within an
Enterprise. Data and processes cannot be shared across Enterprises.
Legislative Data Group

The Legislative Data Group is set up in HCM and is a country-specific data partition within an enterprise.
Legislative Data Groups support the configuration of objects with a strong legislative context, such as
payroll, absence types, elements, rates of pay. Legislative Data Groups do not span Enterprises.
Legal Entity

Legal Entities in HCM represent the legal employer and/or payroll statutory unit. A legal employer is a
legal entity that employs people. A payroll statutory unit is a legal entity responsible for the payment of its
workers and can be used to report tax and social insurance.
Departments
The Department is an organization in HCM to which you assign workers. You can create hierarchies of
departments to roll up your employees into the management structure.
Inventory Organizations
The Inventory Organization represents an organization for which you track inventory transactions and
balances. These organizations might be manufacturing or distribution centers. Several modules and
functions in the Oracle Fusion Manufacturing and Supply Chain Management suite secure information by
Inventory Organization.
Inventory Organizations are associated with BUs. Each Inventory Organization has a parent BU and can
serve other BUs.
Various functions in Oracle Fusion Applications use this organization classification. For example, to
activate the "Purchasing Receiving" function, your responsibility must have access to an organization that
is classified as an Inventory Organization.
Through its parent Business Unit, the Inventory Organization financially impacts the Ledger to which it
rolls up. For example, requisition transactions or replenishment of supplies are created against an
Inventory Organization, which then have a financial impact on the Ledger.
Chart of Accounts
For the most part, we have discussed system entities (for example, Legal Entity, BU, Ledger) and their
relationships with real world entities (for example, Company, Management Unit, Division) that you have in
your organization. System entities are created though special setup screens and stored in tables.
We have discussed the "Primary Balancing Segment" that is part of the chart of accounts rather than a
stored system entity. The chart of accounts, your listing of account numbers, includes other segments
that reflect your organization. You might have company codes, cost center codes, business organization
codes, and other organization related codes, as well as non-organization codes such as natural accounts,
product codes, or project codes.
The chart of accounts is a very flexible, almost free-form, combination of segments (as many as you like)
of different lengths. You use these segments to flag transactions so that they are summarized in a
meaningful way to your business. The chart is referred to as "flexfields", which is the underlying
technology. The acronym "CCID" (Code Combination Identifier) or the term "Accounting Flexfield" refers
to an individual combination of segment values, or a complete account number.
A specific chart of accounts (complete with values) is associated with each ledger and the same chart can
be associated with many ledgers.
We specify only three segments, Natural Account, Primary Balancing Segment, and Cost Center, as
mandatory.
Primary Balancing Segment

We previously discussed Primary Balancing Segment in the context of Ledgers and representations of
Legal Entities. A Primary Balancing Segment is a segment of the chart of account that forces balancing,
meaning that the Ledger will calculate a receivable and payable between primary balancing segments for
any entry that crosses them.
Example of 'Balancing'
My New York Division (01) ships to a California Division (03) customer. The entry as drafted is Credit 01-
Sales, Debit 03, Receivables from Customer. The entry is posted as:

• Credit 01, New York Sales

• Debit 01, New York Receivable from 03, California
• Credit 03, California Payable to 01, New York
• Debit 03, Receivable from Customer
This facilitates the preparation of full balance sheet and income statements for each Primary Balancing
Segment value and makes them an excellent representation for any business unit for which you need to
track balance sheets.
Our customers use primary balancing segments to identify registered companies that are accounted for
together in a single ledger, divisions for which they wish to measure balance sheet data and return on
investment, and externally reportable segments.
You can use a primary balancing segment value for each legal entity accounted for in a ledger:
Companies 01, 02, and 03. Other than balancing, no additional functionality is attached to the Primary
Balancing Segment, so using a Primary Balancing Segment Value alone is recommended only in a
federal environment that treats groups as one tax or statutory reporter or filer.
Cost Center
Cost Center is a focal point for a department's expenses. You might use the cost center to track "the
Finance Department". In cases where labor is the most important element of expense, cost centers in
your chart of accounts and the HR "Department" discussed earlier will refer to the same business unit in
the real world. Oracle Fusion Applications include the ability to keep them synchronized. There are some
important differences in the way you want them to behave.
When an employee leaves, you'd like HR to update the records immediately. But continuing expenses, if
any, should be accounted for in the same cost center. If the employee was a manager, the resulting
reorganization might not be reflected in the financial statements for some time.
Accordingly, the creation and maintenance of HR Departments and Ledger Cost Centers can be
synchronized. However, we facilitate different update paths. Approval and expenses associated with
employees are automatically associated with the cost center that relates to their HR department.
Many customers exploit naming conventions and ranges to facilitate the combination of individual cost
centers in local companies into a worldwide view of similar cost centers. Ledger security includes a
facility to control accounting access by ranges within chart of account segments that can be deployed
usefully in this context. Many customers also use cost centers, rather than natural accounts, to
aggregate functional expense types such as "Research and Development" or "Finance".
Natural Account
For many companies, natural account also has an organizational impact. Companies deploy the natural
account in different ways. Some start "at the top" with their external reporting lines (for example, cash,
revenue), expand the list to include their management reporting lines (different types of revenue), and
then expand further to the level of granularity they wish. Others start "at the bottom" with detailed
departmental expenditure types.
Companies that start with reporting lines often reach the point where "Finance Salaries", "Finance
Benefits", and so on are natural accounts, and a report on all Finance accounts delivers the Finance
expense. Those that start at the bottom often use "Salaries" and "Benefits" as the natural account and
establish a list of cost centers to be the total finance.
A Flexible Model
When you are finished, you will have modeled your organization in the system using ledgers, ledger sets,
and balancing segments to report your legal and management structure, and using different combinations
of each as appropriate for statutory compliance and management needs.
You will have selected BUs to store and secure your data, reflecting transaction tax audit and filing needs
that are mapped to your operating needs. You will also have selected accounting attributes through your

chart of accounts, using natural accounts and cost centers together with other segments, to help you cut
though the data to get to the heart of your operations.
In the earlier discussion for Your Organization, page XXX , a diagram shows cards representing
companies that are striped vertically by business subdivisions and horizontally by functional groups. The
following diagram shows how some system entities can be mapped, often in alternate ways, to your
organization. The system entities map to organizational characteristics as follows:
• Legal Entities correspond to the company cards and keep their financial accounting in Ledgers within
Ledger Sets.
• Balancing Segments can represent both legal entities and business subdivisions.
• Functional Groups map to Departments and Cost Centers in the system.
• Natural Accounts classify the functional groups' activities.
• Business Units most often hold companies' data and can hold the data of different businesses at arms
length from each other within a legal environment.
(need to change the diagram to ‘Business Units’ (instead of Operating Units) and ‘Primary Balancing
Segment Values’ (instead of Balancing Segment Values))
Using Oracle Fusion Human Capital Management with Oracle Fusion

Financials
Just as legal entity and ledger structures furnish a strong degree of transactional control within Oracle
Fusion Financials, structures in Oracle Fusion Human Capital Management provide significant internal
control in an enterprise.
In addition to direct relationships between headcount and spend rates, people and hierarchies are the
primary means of authorization and security in an organization. For example, spending controls can be

enforced by person and level in the hierarchy. Your internally controlled approval routing goes through a
process that you can default to the department hierarchy in Human Resources or to any other hierarchy
that you create. Consider the following examples:
1. Purchase Approval Hierarchy: Purchase orders entered in Oracle Fusion Procurement utilize workflow
to route the purchase order for approval.
2. Journals: Since journals can be unique in nature, their approval cannot be restricted to a hierarchy
within a particular department. You can create workflow routing rules to personnel in an enterprise for the
approval of journals in Oracle General Ledger.
3. Manual Invoices: Manual invoices use Oracle Approval Management Engine (AME) for approval. In
turn, AME uses the Human Resources departmental hierarchy and spending authority at every level in
the hierarchy to route the invoice.
4. Salary might be your primary expense. HCM breaks out salary by your departmental organizations.
Broadly speaking, your HCM departments will map to Oracle Fusion General Ledger cost centers.

Implementation Course Overview
Overview of the financial implementation course covers the following:
 Strategy and planning of a financial implementation.

 Introduction to Functional Setup Manager.
 Introduction to Common Applications Configuration.
 Introduction to Common Financial Configuration.
 Introduction to the InFusion Corporation case study.
 Introduction to implementing the Oracle Fusion Financial products.

Activity: Implementation Discussion
Background
Instructor led discussion about the implementation project.
Activity Scope
Topics to cover:
 Scope of the project.

 Schedule and agenda of the project.
 People involved in the project.
 Applications to be installed.
 Employees.
 Customers.
 Suppliers.

Introduction to Financials Offerings
Fusion Financials provides two task lists to set up Fusion Financials:

 Define Financials and Fusion Accounting Hub Configuration for Rapid
Implementation: This task list should be used for initial implementation projects
only to streamline your setup configuration to focus only on the critical setup
steps. The rapid implementation task lists minimize the time needed for you to
complete your key setups and enable the day-to-day use of Oracle Fusion
Financials and Oracle Fusion Accounting Hub. Spreadsheets are provided to
enter high volume data, such as legal entities, chart of accounts values and
hierarchies. However, there are also some limitations. For example, you will not
be able to upload more than one ledger that share a chart of accounts and you
can only define a monthly accounting calendar. For more complex
configurations, you should use the Financials task list.
 Financials: This task list shows the complete set of tasks that should be used for
ongoing maintenance and the set up of more advanced features and complex
setups.
The Define Financials and Fusion Accounting Hub Configuration for Rapid
Implementation task list contains the following task lists that each contain a subset of
tasks:
 Define Common Financials Configuration for Rapid Implementation
 Define Transaction Taxes for Rapid Implementation
 Define Fusion Accounting Hub Configuration for Rapid Implementation
 Define Invoicing and Payments Configuration for Rapid Implementation
 Define Expenses Configuration for Rapid Implementation
 Define Fixed Assets Configuration for Rapid Implementation
 Define Receivables Configuration for Rapid Implementation
 Define Financials Security Configuration for Rapid Implementation
Define Financials and Fusion Accounting Hub Configuration Project List

The Financials task list contains the following tasks::
 Define Common Applications Configuration for Financials.

 Define Common Financials Configuration.
 Define Invoicing and Payments Configuration.
 Define Expense Configuration.
 Define Fixed Assets Configuration.
 Define Receivables Configuration.
 Define Collections.
 Define Financials Define and Maintain Intercompany Processing Rules.
 Define Hyperion Financial Management Integration.
 Define Budget Configuration.
 Define Financial Reporting.
 Define Transactional Business Intelligence Configuration.
 Define Extensions for Financials.
Oracle Fusion Financials FSM Implementation Project List



Activity: Common Application Discussion
Background
Instructor led discussion on various aspects of the enterprise structure. This is a lead in
for lesson 3 where the set up of the enterprise structure is covered in greater detail.
Activity Scope
Enterprise Configuration
 What is the level of configuration needed to achieve the reporting and accounting
requirements?
 What components of your enterprise do you need to report on separately?
 Which components can be represented by building a hierarchy of values to
provide reporting at both detail and summary levels?
 Where are you on the spectrum of centralization versus decentralization?
Business Unit Management
 What reporting do you need by business unit?

 How will you structure your ledgers, legal entities and business unit roll-ups?
 How can you set up your departments or business unit accounts to achieve
departmental hierarchies that report accurately on your lines of business?
 What reporting do you need to support the managers of your business units, and
the executives who measure them?
 How often are business unit results aggregated?
 What level of reporting detail is required across business units?
Security Structure
 What level of security and access is allowed?

 Are business unit managers and the people that report to them secured to
transactions within their own business unit?

 Are the transactions for their business unit largely performed by a corporate
department or shared service center?
Compliance Requirements
 How do you comply with your corporate external reporting requirements and local
statutory reporting requirements?
 Do you tend to prefer a corporate first or an autonomous local approach?
 Where are you on a spectrum of centralization, very centralized or decentralized?

Introduction to Common Applications Configuration
The Define Common Applications Configuration task list contains implementation

and administration tasks that are common across multiple offerings. The tasks are
shown in this graphic.
Some of these tasks are performed the same way no matter the offering, for example
the Define Help Configuration. How you perform some other tasks depends on how the
corresponding feature is used in the product family. For example, the setup for Define
Approval Management depends on what documents are being approved.

Other task lists are also used in multiple offerings, including:
 Define Transactional Business Intelligence Configuration

 Define Extensions

Introduction to Common Financials Configuration
Use the Define Common Financials Configuration task list to create and maintain
transaction tax setup according to local and international tax requirements and to
apply tax data to the transaction line.
In the Define Transaction Taxes task list you can set up your entire transaction
tax configuration.
The Define Transaction Taxes task list is logically defined with prerequisite tasks,
core tax configuration tasks, optional setup tasks, and validation configuration
tasks. The task list categories include:
 Define Tax Geographies: Configure tax geographies to define geographical

regions that share the same tax requirement. These prerequisite tasks are
required for core tax configuration but they might not have been defined in the
previous steps of the Financials offering.
 Define Tax Regimes: Configure tax regimes for the taxes in each country and
geographic region where a separate tax applies. These tasks are most
commonly used by all the implementations. You should be able to calculate taxes
on the transactions based on this configuration.
 Define First Party Tax Profiles: Configure tax profile details that control the
transaction tax activities for your first party legal entities, legal reporting units,
and business units.

 Define Third Party Tax Profiles: Configure tax profile details that control the
transaction tax activities for your third party customer, customer sites, supplier,
and supplier sites.
 Define Occasional Tax Implementation Setups: Configure initial tax setup that
impacts tax calculation and reporting. These tasks are either predefined and you
do not have to configure them unless the predefined data needs to be extended
or are tasks required only for certain implementations.
 Verify Tax Configuration: Verify the transaction tax configuration by simulating
transaction data and reviewing tax calculation results.

Lesson 1: Highlights
In this lesson, you should have learned to:
 Explain the Oracle Fusion Financials Implementation Offering.

 Understand the concepts of the enterprise structure.
 Understand the Common Applications Configuration.
 Understand the Common Financial Application Configuration.
 Discuss your implementation strategy.

Lesson 2: Overview of Oracle Fusion Functional Setup Manager
Lesson 2: Overview of Oracle Fusion Functional

Setup Manager

After completing this lesson, you should be able to:
 Navigate Oracle Fusion Applications.

 Describe Oracle Fusion Functional Setup Manager.
 Browse and configure offerings.
 Review the Oracle Fusion Financials offering.
 Review the reports associated to the Oracle Fusion Account Hub offering.

Getting Started in Oracle Fusion Applications
Oracle Fusion Applications are:
 Designed from the ground up, using the latest technology advances and
incorporating best practices gathered from thousands of customers.
 Completely open, service-enabled enterprise applications.
 Designed with features for the best-in-class user-interface designs and
workflows that optimize usability and deliver business value.
All functionality revolves around the Oracle Fusion Applications Welcome page which
can be personalized.

User Interface
Each page can be divided up into components. This is an example of the main
components in the Oracle Fusion User Interface.
1. Global Area: Contains links to help you navigate user interfaces, personalized
links and tools, and the name of the user who is signed in.
2. Regional Area: Contains links to tasks and reports.
3. Local Area: Contains the transaction or form that requires creation, editing, or
review.
4. Contextual Area: Contains information that is linked to the transaction displayed
in the Local Area.

Dashboard
Oracle Fusion dashboards provide the following:
 Information summaries: View of the big picture as well as prioritization.

 Information monitoring: Quick action and further exploration.
The main dashboard within Oracle Fusion is the Welcome dashboard, or Oracle
Fusion Home, which is a collection of dashboards. In addition two other types of
dashboards are available:
 Role-based: Examples include Line Manager, HR Specialist.

 Business intelligence-driven: Examples include Balance Sheet and Sales
Pipeline.
General Accounting Dashboard

Work Areas
A work area is a grouping of similar tasks. For example, the Period Close work area
includes tasks for opening and closing accounting periods for the Oracle Fusion
General Ledger and subledgers.
Period Close Work Area

Recent Items
The Recent Items menu enables users to return to flows that have been recently
accessed, usually within, but not limited to, a single session.
Recent Menu from the Global Area

NOTE: Student activity Getting Started in Oracle Fusion Applications Activity.

Overview of the Functional Setup Manager
Oracle Fusion Functional Setup Manager provides for rapid and efficient
planning, configuration, implementation, deployment, and ongoing maintenance
of Oracle Fusion Applications through self-service administration. For clarity, this
lesson is divided into two major sections:
 Overview of the Functional Setup Manager

 Browsing and Configuring Offerings

Implementation Overview
Functional Setup Manager is a one-stop planning-to-deployment application that

enables a rapid start of Oracle Fusion applications implementation. Functional
Setup Manager provides:
 Single interface for all of the setup and maintenance phases across the
complete life cycle.
 Guided processes that make it easy to navigate through planning,
implementation, deployment, and ongoing maintenance.
 Configurability of the Oracle Fusion offerings to mold the offerings to fit the
business needs.
 Predefined, guided list of tasks for full end-to-end visibility to all setup
requirements enabling business users with the ability to implement quickly what
they need and when they need it.
 Export and import capability to let enterprises set up one instance and move
the setup and task lists to other instances.
 Set of comprehensive reports to give full visibility to setup at any time.

Job Roles
The following job roles are required to access information within Oracle Fusion
Functional Setup Manager:
 Application Implementation Manager

 Application Implementation Consultant
Users with these roles can:
 Gather Requirements for the Implementation: Perform this task outside of

Functional Setup Manager. There are no setup activities in the Functional Setup
Manager.
 Access the Getting Started Page: Review the implementation process flow and
the offerings available.
 Configure Offerings: Define the parameters of the implementation by selecting
the options and features to be implemented for each offering.
NOTE: Read only functionality to a limited number of tasks can be accessed even if
these roles are not assigned.

Implementation Task Flow
The Implement Applications process includes some activities that are manual and
executed outside of the Oracle Fusion Functional Setup Manager application.
 Plan is the process of gathering business requirements and comparing them to

the offerings available to determine what to implement.
 Install is not addressed directly with Oracle Fusion Functional Setup Manager.
The installation of the applications and instances is done prior to the functional
setup.
 Configure is the process of selecting the offerings, options and features to
implement. The selections made during the configure process determine the task
lists dynamically for implementation.
 Implement covers both the management and functional user aspects of
assigning tasks and due dates, as well as executing tasks and reporting status.
 Export provides the ability to export the configuration setup data from one
environment in order to import it into another environment.

 Transact is the process that is executed within the actual product application,
such as general ledger.
 Maintain is the process that provides the ability to search for tasks or tasks lists
to be executed from a single user interface. Maintenance activities are generally
performed after the applications are implemented.

Implementation Objects Overview
There are different types of implementation objects.
Setup Objects
 Encompass multiple setup entities including Business Objects, Tasks, Task Lists,
Processes, Features, Options, and Offerings.
 Consume all offerings applicable to your implementation.
 Exist for the Oracle Fusion Applications and cannot be modified.
 Create custom Setup Objects for use with third party or custom applications.
 Create new offerings, options, features, and task lists using setup objects
delivered with the system.
Business Objects

 Consist of collections of the logical entities that make up a complete business

document, transaction, or other high-level business concept.
 Used as the lowest level for data export and import.

Implementation Project Overview
The Setup and Maintenance work area in the Oracle Fusion Functional Setup
Manager is used to manage the configuration of your enterprise.
Implementation Projects
To begin creating your enterprise, your implementation consultant, or system

administrator must create an implementation project. An implementation project
defines the scope of the implementation. The implementation project can be
populated by adding one or more related offerings or task lists.
Progress reports on tasks can be seen on the Implementation Projects tab. Detailed
status can be seen by clicking on the numbers in the Assigned Tasks column, or by
drilling down into the Implementation Project detail graphical reports in the project
details region.
Assign Tasks
 Assign tasks to users using the Assign Tasks option within the implementation
project.
 You can either assign the same users and due dates to all tasks in a task list or
assign individual tasks to a specific user. Multiple tasks or task lists can be
selected if the same assignments apply.
 Notes can be assigned and are stored as attachments associated to the task list
or task.
 In the Assigned Users region, the users assigned to the implementation project
are displayed. Additional users can be added, or existing users can be deleted.
Offerings
There are two offerings predefined for financial implementations.
 Oracle Fusion Financials offering: Includes the Oracle Fusion General Ledger
and Oracle Fusion Subledger Accounting application features, as well as at least
one of the subledger financial applications.

 Oracle Fusion Accounting Hub offering: Includes the Oracle Fusion General
Ledger and Oracle Fusion Subledger Accounting application features integrated
with an existing enterprise resource planning (ERP) system or third party
application to enhance the current reporting and analysis.
The focus of this course is the Oracle Fusion Financials offering.
Navigate: Setup and Maintenance > Implementation Project tab.
Navigate: Setup and Maintenance > Tasks > Implementations > Manage
Implementation Projects > FAH V1GA Implementation > Expand to specific task
and select row header > Assign Tasks.

Implementation Project for Ongoing Maintenance
Maintenance activities are generally performed after the applications are

implemented. Consider defining an ongoing maintenance implementation project
that includes tasks such as Manage Daily Rates and Manage Calendars.
You can create a new ongoing maintenance implementation project:
 Do not select an offering. Add the required tasks lists or tasks to the
implementation project.
 Or, select an offering and delete the tasks lists or tasks that are not required.
Navigate: Setup and Maintenance > Tasks > Implementation > Manage
Implementation Projects.

Offerings, Options and Features
The decision tree for the implementation of specific business processes is represented
by selecting offerings, options and features. An offering contains all of the tasks
required to implement the top level business process. Within an offering, there may be
one or more options that represent optional business processes possible, within that
offering. Features are used to define the business rules for the implementation and how
the transactions of the corresponding business process work. Features can be available
for offerings, options, or even other features. For example:
As shown here:
 The offering is Oracle Fusion Financials.

 An option within that offering is General Ledger.
 A feature within the General Ledger option is Journal Approval.
By selecting the combination of offerings, options and features, the appropriate task list
is dynamically generated.
Scope, as used in Oracle Fusion Functional Setup Manager, refers to an object that
allows a task list to be executed repeatedly. An example of a scope value is Business

Unit, where you select a particular business unit, and proceed to perform all setup tasks
for that business unit.
To view Configure Offerings navigate: Setup and Maintenance > Implementations

task list > Configure Offerings

Implementation Objects Task Flow
Features, options and offerings are comprised of tasks and task lists. If a new custom
application is being introduced, all of these objects above need to be created to
integrate fully with Oracle Fusion Functional Setup Manager.
To create custom lists or types of implementations using the delivered Oracle Fusion
Applications functionality, various combinations of the above functionality might be
utilized. For example, if only a subset of setup tasks are required when setting up a
specific industry, new task lists, options and offerings might be created to streamline
that type of implementation.
The definition of setup objects can be done top-down to identify all the elements
required or bottom up to define and register the objects in Functional Setup Manager.
The following illustration shows bottom-up from defining business objects to defining the
offerings and publishing them in application stores.

Setup Data Export and Import Overview
The Export and Import Application Setup activity enables an Implementation

Manager to easily move the setup data between instances to reduce
implementation time between project phases and instances.
Export and Import:
Setup data can be exported from the source instance and imported into another
instance by creating a Configuration Package using Oracle Fusion Functional Setup
Manager.
A Configuration Package consists of the implementation project structure plus the setup
data. The package can be exported then imported into another instance using Oracle
Fusion Functional Setup Manager.
Customization and reporting options are available during the process to allow complete
flexibility and control of the process and tracking of the success of or errors in the
process.
As the project moves through multiple phases, such as test, quality, and production, the
data can automatically be exported from one instance to another.
Export and import help to ensure data consistency between instances.

Export and Import Task Flow

The Export and Import Application Setup activity is comprised of two tasks:
Manage Configuration Package
 Can be used for creating a configuration package and optionally selecting only
specific business objects or scope values to be exported.
 Can be used to move your configuration to another instance.
 You can either schedule this process or submit on demand.

 Configuration Package contents can be viewed in reports.
Manage Export and Import Process
 The task is the actual export and import of the setup. This task allows the status
and details of the process to be monitored.
You can run reports on the configuration package and the export and import
processes.
 On the Manage Configuration Packages page select the row header for a
configuration package. In the details region select the icon that to view or
download the setup data report.
 On the Manage Export and Import Processes page click the Download icon,
and select Download Setup Data Report.
Navigate: Setup and Maintenance > Tasks > Setup Data Export and Import >
Manage Configuration Packages.
Navigate: Setup and Maintenance > Tasks > Setup Data Export and Import >
Manage Export and Import Processes.

Browsing and Configuring Offerings
In this section, you will learn how to browse and configure offerings. The
following topics are included:
 Gathering implementation requirements for offerings.

 Viewing Functional Setup Manager provided reports and documents.
 Selecting options for an offering.
 Selecting feature choices.

Gathering Implementation Requirements for Offerings
Oracle Fusion Functional Setup Manager is used to perform the setup tasks required to
complete the implementation of Oracle Fusion applications. Before the implementation
even begins, there are several tasks that need to be performed. Some of these tasks
are manual tasks and utilize the software from a reference perspective. For example,
gathering functional requirements for the implementation and comparing those
requirements to the offerings available.
Task Flow
 Gather Requirements: Implementation requirements are manually gathered.

 Getting Started: Utilize the Oracle Fusion Functional Setup Manager Getting
Started page to review various reports that provide information about the multiple
Oracle Fusion Offerings. This allows the Implementation Manager to determine
which offerings are appropriate for this implementation.
 Configure Offerings: Use to select the offerings and options required to
implement the appropriate functionality satisfying the business requirements.

Using the Getting Started Page
The Getting Started page presents information about the offerings available for
implementation, allowing the implementor to compare the business requirements to the
available functionality of Oracle Fusion Applications.
Navigate: Setup and Maintenance > Tasks > Implementations > Getting Started.

Functional Setup Manager Reports Overview
Standard Reports
The various reports provide more detailed information about what type of transactions
and functionality are available within each of the offerings. Reports related to each
offering are available as HTML, PDF and Excel documents and include:
 Offering Content Guide

 Associated Features
 Setup Task Lists and Tasks
 Related Business Objects
 Related Enterprise Applications
Navigate: Setup and Maintenance work area > Tasks > Implementations > Getting
Started > Fusion Financials.
Demonstration: Review each report with the class. Specifically look at the Setup Tasks
List and Tasks in the HTML format. Filter the required versus the nonrequired setups.

Functional Setup Manager Reports Features
Offering Content Guide
 Describes the detailed contents of the offering for the current version of the
application.
 Provides a functional description of the components of the offering.
 Provides an understanding of what functionality the offering provides.
Associated Features Report
 Displays the options and features for the offering used for detailed application
configuration decisions.
 Displays a list of features available with the offering, including what level the
feature is associated with, as well as the choices available.
 Depicts the dependency between the offerings and their options and features.
Setup Task Lists and Tasks Report
 Lists the tasks and task lists for an offering, related to application configuration.
 Displays the setup tasks required to implement the functionality available in the
offering.
Related Enterprise Applications Report
 Lists the Enterprise Applications the offering requires for functional setup and
transactional tasks.
 Specifies the application required based on transaction type for special offerings.
Related Business Objects Report
 Lists the Business Objects that the Offering uses.

 Lists the applicable web service used for the export and import process.

NOTE: Instructor Demonstration Browsing Offerings. This demonstration can also be

played from the Help Portal.

Selecting Feature Choices
Configuring Offerings
 After reviewing all of the available offerings and printing or reviewing appropriate
reports, the next step for a new implementation is to progress to the Configure
Offerings page to select the offerings, options and features to be implemented.
 View the available options and select the offerings and options to implement. If
an offering is selected, but none of its options, only the basic tasks needed to
implement the base functionality for the offering are included in the Task List
generated for this offering. Only the offerings and options selected during this
process are available when an implementation project is later created by the
Implementation Manager. Configure Offerings can be updated at a later date,
particularly if offerings are implemented with a phased approach.
Selecting Feature Choices
Features are associated with some offerings or options. Each feature provides two or
more choices. The valid selection types for choices are:
 Yes or No: Indicates to include or to exclude functionality.

 Single Choice: Choices are mutually exclusive.
 Multiple Choices: More than one choice can be selected.
NOTE: Additional features may appear if any dependency has been defined and the
corresponding feature choice has been selected.
NOTE: Instructor Demonstrations. These demonstrations can also be played from the
Oracle Fusion Help Portal.

 Browsing Offerings
 Configuring Offerings.
NOTE: Student hands-on activity Create an Implementation Project.

 Navigate Oracle Fusion Applications.

 Describe Oracle Fusion Functional Setup Manager.
 Browse and configure offerings.

 Review the Oracle Fusion Financials offering.
 Review the reports associated to the Oracle Fusion Account Hub offering.

Lesson 3: Overview of Common Applications Configuration
Lesson 3: Overview of Common Applications

Configuration

 Discuss the InFusion Story and implementation considerations.

 Explain legal jurisdictions and authorities.
 Describe legal entities.
 Understand legal reporting units.
 Discuss reference data sharing.
 Understand business units.

The InFusion Story

Overview of InFusion Corporation
The Oracle Fusion Financials Implementation course is based on a fictional yet

realistic enterprise that combines many of the common aspects of your
enterprise structure. This is the enterprise that you will be exploring and
implementing during this class.
Scenario:
 Your company, InFusion Corporation, is a multinational conglomerate that

operates in the United States (US) and the United Kingdom (UK). In the future
you are expanding to other countries in Europe and around the world.
 InFusion has purchased an Oracle Fusion solution including Oracle Fusion
General Ledger and all of the Oracle Fusion subledgers.
 InFusion Corporation has 400 plus employees and revenue of $120 million.
 Your product line includes high technology products, health care, and financial
services.
 You have two distribution centers and four warehouses that share a common
item master in the US and the UK.
 Your financial services organization in the UK provides financing to your
customers.
 You are leading the Enterprise Structure team for your implementation project
and are designing the model for your global enterprise structure including both
your US and UK operations.

InFusion Corporation Analysis
The following are elements you need to consider in creating your model for your
global enterprise structure.
 Your company is required to report using US Generally Accepted Accounting

Practices and UK Statements of Standard Accounting Practice and Financial
Reporting Standards.
 Your managers need reports that show profit and loss (revenue and expenses)
for their lines of business.
 Your corporate management requires reports showing total organizational
performance with drill down capability to the supporting details.
 Your company has all administrative, account payables, procurement, accounts
receivable, billing, and human resources functions performed at your corporate
headquarters.
Questions and decisions that need to be addressed before implementation starts:
 How many ledgers do you need to achieve proper statutory reporting?

 Do you use business units and balancing segments to represent your divisions
and businesses?
 Do you secure data by two segments in your chart of accounts which represents
each department and legal entity or one segment that represents both to enable
production of useful, but confidential management reports?
 Do you need multiple balancing segment hierarchies to achieve proper rollup of
balances for reporting requirements?
 Do you need one or more business units in which to perform all these functions?
 Do you have a procurement shared service center to process requisitions and
negotiate supplier terms for your other business units across your enterprise?

Infusion Enterprise Structure Model
The following figure and table summarize the model that your team has designed
and uses numerical values to provide a sample representation of your structure.
The model includes the following recommendations:
 Create three separate ledgers representing your separate legal entities.

InFusion North America Inc.
InFusion Health Care Inc.
InFusion UK Financial Services Ltd.
 Consolidate results for high technology and health care products and your
financial services business across the enterprise in a corporate consolidation
ledger.
 Process all UK general and administrative costs processed at the UK
headquarters.
 Process all North America general and administrative costs at the US Corporate
headquarters.
 Maintain USA Health Care with its own payables and receivables departments.

InFusion Corporation Structure Diagram
This diagram illustrates the InFusion Corporation enterprise.
NOTE: This diagram was created to illustrate the InFusion Corporation Enterprise
Structure in the Oracle Demonstration Solution Services with the following limitations:
 Due to space, only some of the InFusion entities are shown. For example, only
three legal entities and four warehouses.

 Version one of the demo environment does not include a shared service center.
The one shown here is for discussion purposes.
 Version one of the demo environment only has data loaded for US1 LE1 and BU
USA1. The diagram was expanded to include future data for discussion
purposes.

InFusion Enterprise Structure Mapping
The following chart illustrates the mapping of real world entities to our InFusion
Corporation entities.
The following statements expand on the data in the chart.
 The enterprise is required because it serves as an umbrella for the entire

implementation. All organizations are created within an enterprise.
 Legal entities are required. They can be optionally mapped to balancing
segment values or represented by ledgers. Mapping balancing segment values
to legal entities is required if you plan to use the intercompany functionality.
 At least one ledger is required in an implementation in which you record your
accounting transactions.

 Business units are also required because financial and other transactions are
processed and secured by business units.
 A shared service center to perform the Procurement business function,
including processing requisitions and negotiating supplier terms, is optional. If
used, the shared service center must be a business unit.
 Divisions are optional and can be represented with a hierarchy of cost centers
or by a second balancing segment value.
 Departments are required because they track your employees.
 Optionally, add an item master organization and inventory organizations if
you are tracking your inventory transactions in Oracle Fusion Applications.

InFusion Chart of Accounts Summary
The following is the chart of accounts structure with the names of the segments
and the default values that your team is proposing for the InFusion Corporation's
three primary ledgers.
Sample Accounts
InFusion US: 101.10.12190.000.000.000

InFusion Health: 01.20.11300.0000.00.0000.000
InFusion Fin Svcs: 110.20.1104.0000.000.000.000


Define Enterprise Structures
An enterprise consists of legal entities under common control and management.
In this section we will discuss:
 Geographies.
 Legal jurisdictions and authorities.
 Legal entities.

 Legal reporting units.

 Reference data sets.
 Business units.

Define Geographies
Use the Define Geographies task list to create and manage geographies and
zones used for real-time address validation and tax calculation. Examples include
tax and shipping zones.
Navigation: Setup and Maintenance work area > Manage Implementation Projects link
> XX Implementation Project row > Financials task list > Define Common Applications
Configuration for Financials task list > Define Enterprise Structures for Financials task
list > Define Geographies task list.

Available Options for Importing Geographies
You can create new geographies by importing data through interface tables.
There are two options for populating the interface tables:
 File-based import option: You can use the file-based import process, if you
plan to provide geographic data details in a source file. The process reads the
data in the source file, populates the interface tables, and imports the data into
the application destination tables.
 Geography loader process option: You can use the geography loader process,
if you plan to populate the interface tables directly. The first step is to use a tool
of your choice to manually load geography data into interface tables. Interface
table data is always based on a batch and all rows will have a batch ID. Next, run
the geography loader process to import data from the interface table to the
destination tables. The geography loader is an Enterprise Scheduler Service
process which you can submit immediately or schedule to run at a later point.
You need to provide the Country Structure Batch ID or Geography Batch ID to
run this process.

Running Maintain Geography Name Referencing
Geography Name Referencing is the process of validating and mapping address

elements of existing location information against master reference geographies. This
process establishes a cross reference between location information columns and
geography data. For example, for a specific address record, the CA value in the STATE
column of the HZ_LOCATIONS table is mapped to the master reference geography of
CA.
Run Geography Name Referencing only if you make changes to the geography data
that impact addresses, or to troubleshoot issues. Take note of the following before
running the Geography Name Referencing process:
 Use the new or all value of run type to indicate which addresses should be
referenced.
 You can use dates and IDs to filter.
 Usage can be GEOGRAPHY or TAX.
 Location table can be HZ_LOCATIONS or PER_ADDRESSES_F.
The application runs this process whenever you create a new address or edit an
existing address in the application. Additionally, you can run this process at scheduled
intervals to maintain address data quality.

Managing Geography Lookups
Geography lookup types provide choices related to geographies, such as address

validation methods. There are two extensible geography lookups that you can
customize. You can rename the values or codes for these lookup types. You can also
add new extensible codes to these lookups types. These lookups are:
 HZ_GEO_DATA_PROVIDER: Specifies the source of geography data such as

user entered or from third party providers such as TAXWARE.
 HZ_GEO_IDENTIFIER_SUBTYPE: Identifier sub type for geography, for
example, primary and alternate names and codes for each geography.

Zone Types and Zones
Zone types and Zones define a geographical boundary, based on master geography
hierarchy data, that can be used to create tax or shipping zones. Zone types categorize
and group related zones together. For example, you can create a United States Tax
zone type, to include various tax zones in the country.
You must create a zone type before you can define a zone for the geographical
boundary. A zone type can include geographies from anywhere in the world, or can be
restricted to contain geographies from within a specified country. When you create a
zone type that is restricted to a country, you can define the geography types or
geographies that can be used to create a zone.
Zones are geographical boundaries for a zone type. When you are creating a zone you
will need to either create the zone under an existing zone type, or you will need to
create a new zone type and then create the zone.

Territory Zone Hierarchy
Based on your business needs, you can use master reference geographies, zones, and
zone types to create territory zone hierarchies. Territory zone hierarchies enable you to
create and manage zone hierarchies which contain master geographies and custom
zones. You can customize a zone hierarchy at any level, but need to ensure that the
country’s geographical structure is not changed.
Zone types categorize and group zones for specific purposes. For example, you can
create an Americas zone type and use it to create a Southeast Sales Region zone. You
can then add various geographies or zones to the Southeast Sales Region zone, and
add the Southeast Sales Region zone to a larger North America zone to create a
territory zone hierarchy.
NOTE: Although you can create zones without including master geographies, for the
zones to be selected by the Assignment Manager, the zones must include master
geographies at the lowest level.
You can create a hierarchy using geographies from the master reference geography
data hierarchy, and you can also add geographies to hierarchies created from zones.
When you are adding a geography to a hierarchy you have the option of either adding
just the geography, or you can add the geography and selected child geographies.

Managing Geographies
This section covers:
 Geography structures, hierarchies, and validations.

 Address cleansing.
 Managing geographies.

Geographies Overview
Geographical information is a critical asset that helps you define and monitor
where and how you do business. This is why you need to structure and create
geographical information associated with your business when you first set up
Oracle Fusion. You can then use this information to facilitate business processes
that rely on geographical data.
For instance, you need geographical information to validate addresses, calculate

taxes, or create sales territories. All your geographical information is centrally
located and shared with other application offerings within your company.
Oracle Fusion comes with predefined country names. You need to define the geography
structure and hierarchy of each country associated with your business before working
on any process that requires geographical data. You can do this by either importing
geography data or by setting it up manually.

Geography Structure
A prerequisite to understanding the concept of geography structure is an understanding

of the concepts of geography and geography type.
 Geography: A geography is a boundary such as a country, state, province, or

city.
 Geography Type: A geography type is a divisional grouping of geographies,
either geopolitical (for example, City, Province, and District) or physical (for
example, Island and Mountain).
A geography structure is a hierarchical grouping of the geography types for a
country. It specifies the geography types required for a country and how they are
organized. For example, the required geography types for the US are State, County,
and City arranged in the order listed.
A country's geography structure determines the component geography types that can
be defined and the hierarchical relationship between them. A set of predefined
geography types are available for inclusion in a country's geography structure.
Additionally, you can create a geography type to add it to the country structure. Each
geography type is added below the current lowest level. You cannot delete a geography
type that has related geography data. It is recommended that you plan the geography
structure before creating it. Also, if you want to delete a geography type that is not at the
lowest level in the country structure, then you have to delete the geography type level
and all the levels below it.
For example, the geography structure for the United States comprises the State,
Country, City, and Zip Code geography types. In the United States geography structure,
the State geography type is the highest level within the country geography structure,
followed by the County as the second level, City as the third level, and Postal Code as
the lowest level within the country structure.
There are two ways of defining a geography structure:
 Creating the geography structure using the Manage Geographies pages.

 Importing the geography structure from a source file or using interface tables.

Geography Hierarchy
The geography hierarchy establishes a conceptual parent-child relationship between

geographies.
For example, in the US geography hierarchy the state of California is defined as the
parent of San Mateo County, which is the parent of Redwood City, which is the parent
of the zip code 94065. Based on these hierarchical relationships, Oracle Fusion
Applications can infer information. For example, if you enter just 94065 in a zip code of
the application, the application determines that the postal code is in California, or that
the corresponding city is Redwood City.
Because the top level of any geography hierarchy is Country, a geography hierarchy
contains countries and their child geographies such as state, county, and city.
A geography hierarchy can be a Master Reference Geography Hierarchy or a User

Defined Geography Hierarchy:

 Master Reference Geography Hierarchy: The Master Reference Geography

Hierarchy is the source of truth for geography data. It consists of master
reference geography types and geographies. For example, Country is a
universally recognized geography type, and United States is considered a master
geography. Master Reference Geography Hierarchy data is used as the source
for validating addresses, and for creating user-defined geography hierarchies.
 User Defined Geography Hierarchy: The User Defined Geography Hierarchy is
a classification of geographical data, containing entities with arbitrary boundaries,
such as tax zones that encompass various US states in each zone. A user-
defined geography hierarchy comprises geographical data, either created from
the master reference data or entered manually.

Geography Validations
Geography validation determines the geography mapping, validation for a country's

address styles, and overall geography validation control for a country. You can define
multiple address style formats for a country, and then define geography mapping and
validation for each of the address style formats. The No Styles Format address style
format is the default address style format for a country, and can be used to define
mapping and validation for any address in the country.
You can map the address attributes, for each of the address style formats, to a
geography type. For example, you can map the State geography type to the County
address attribute for the United Kingdom. For each address component, you can enable
the following:
 List of values: Specifies whether the geography type will appear in a list of
values during address entry in user interfaces. You must enable a list of a list of
values only if you have sufficient geography data. This ensures address data
quality while creating new addresses, by displaying a list of values from the
geography data during address entry.
 Tax validation: Specifies whether the geography type will be included in tax
validation. This ensures that the addresses are valid, based on the geography
hierarchy data, for tax calculation.
 Geography validation: Specifies whether the geography type will be included in
geography validation. This ensures that a new address will have correct
geographic data, based on the geography hierarchy data.
You can define Geography Validation Control at the country level. The geography
validation control determines if an address that did not pass geography validation during
address entry can be saved or not. If the validation control is set to Error, then an
address that has failed validation cannot be saved and the errors are saved in the
status. If the validation control is set to No Validation, all addresses are saved including
incomplete and invalid addresses.

Address Cleansing
Address cleansing validates, corrects, and standardizes addresses that you enter in a
user interface. While geography validation validates the geography attributes of an
address, address cleansing validates both geography attributes and the address line
attributes. Address line attributes are defined in the Address Style format, which
specifies the layout of an address. Real-time address cleansing ensures consistency in
address representation by checking whether address data entered conforms to a
particular format.
Real-time address cleansing for a country has the following levels:
 None: Specifies that the country does not have real-time address cleansing.
 Optional: Specifies that you can optionally cleanse address data during address
entry. You can select the option to perform real-time address cleansing, and
receive a corrected, standardized address. This displays a Verify Address
option at the address data entry level. During data entry, you can click on the
Verify Address option to check if the address entered conforms to the address
format, in order to have consistent representation of addresses. If the address
does not conform to the format, Oracle Fusion either presents alternative
addresses or lets you optionally add the address you entered to the registry.

Configuring Enterprise Structures Overview
Begin configuring the enterprise structure from the Setup and Maintenance work
area.
 The list of tasks to complete are arranged in the order they should be completed.
Define Legal Jurisdictions and Authorities for Financials
Setup and Maintenance > XXImplementation Project > Financials > Define Common
Applications Configuration for Financials > Define Enterprise Structures for Financials
Define Legal Entities for Fusion Accounting Hub and Define Legal Reporting
Units for Financials
Setup and Maintenance > XXImplementation Project > Financials > Define Common
Applications Configuration for Financials > Define Enterprise Structures for Financials

Define Business Units
Setup and Maintenance > Financials > Define Common Applications Configuration for
Financials

Define Legal Jurisdictions and Authorities
Legal Jurisdictions and Authorities
Requirements:
 Register your legal entities with legal authorities in the jurisdictions where you
conduct business.
 Register your legal entities as required by local business requirements or other
relevant laws.
Additional Considerations:
 Define jurisdictions and related legal authorities to support multiple legal entity
registrations.
 When you create a legal entity, Oracle Fusion Legal Entity Configurator
automatically creates a registration for the new legal entity as well as creating a
main legal reporting unit along with its registration.
NOTE: Legal Jurisdictions and Authorities are likely only relevant to your Oracle Fusion
Financials implementation if you are also using Oracle Fusion Payables and Oracle
Fusion Receivables. If you are not using those applications, and have no need for tax
calculations, this feature will not be relevant for your Oracle Fusion Financials
implementation.

Legal Jurisdictions Overview
Legal jurisdiction is where a particular piece of legislation applies, perhaps group

of countries, country, state, county, or parish. French Labor Law, Singapore
Transactions Tax Law, and US Income Tax Laws are examples of particular
legislation that apply to legal entities operating in different countries'
jurisdictions.
Types of jurisdictions are:
 Identifying Jurisdiction
 Income Tax Jurisdiction
 Transaction Tax Jurisdiction
Identifying Jurisdiction
An identifying jurisdiction is the first jurisdiction you must register with to be

allowed to do business in a country. For each legal entity, select an identifying
jurisdiction. If there is more than one jurisdiction that a legal entity needs to register with
to commence business, select one as the identifying jurisdiction. Typically, the
identifying jurisdiction is the one you use to uniquely identify your legal entity.
Income tax jurisdictions and transaction tax jurisdictions are not represented by the
same jurisdiction. Although in some countries, the two jurisdictions are defined at the
same geopolitical level, such as a country, and share the same legal authority, they are
two distinct jurisdictions.
Income Tax Jurisdiction
Income tax jurisdictions impose taxes on your financial income generated by all
your entities within their jurisdiction. Create income tax jurisdictions to properly
report and remit income taxes to the legal authority.

Legal Authorities Overview
A legal authority is a government or legal body that is charged with powers to

make laws, levy and collect fees and taxes, and remit financial appropriations for
a given jurisdiction.
For example, the Internal Revenue Service is the legal authority responsible for
collecting taxes and the interpretation and enforcement of the Internal Revenue Code of
the United States.
 Legal authority information is printed on your tax reports to meet some countries’,
such as India and Brazil, requirements.
 Legal authorities are defined in the Oracle Fusion Legal Entity Configurator.
 Tax authorities are a subset of legal authorities and are defined using the same
setup flow.
NOTE: Instructor Demonstration Creating Legal Jurisdictions, Addresses and
Authorities.

Manage Legal Entities
 A legal entity is a recognized party with rights and responsibilities given by

legislation.
 A legal entity has the right to own property, the right to trade, the
responsibility to repay debt, and the responsibility to account for
themselves to regulators, taxation authorities, and owners according to
rules specified in the relevant legislation.
 A legal entity's rights and responsibilities may be enforced through the
judicial system.

Legal Entities Overview
Define a legal entity for each registered company or other entity recognized in law
for which you want to record assets, liabilities, expenses and income, pay
transaction taxes, or perform intercompany trading.
A legal entity has a separate legal identity and therefore conducts aspects of your
business for the following reasons:
 Facilitating local compliance.

 Complying with corporate taxation within local jurisdictions.
 Preparing for acquisitions or disposals of parts of the enterprise.
 Isolating one area of the business from risks in another area. For example, your
enterprise develops and leases properties. You can create separate legal entities
for development and leasing. This would minimize cross-line of business risk.
The Role of your Legal Entity
The contracting party on any transaction is always the legal entity.
Individual legal entities:
 Own the assets of the enterprise.

 Record sales and pay taxes on those sales.
 Make purchases and incur expenses.
 Perform other transactions.
A legal entity must comply with the regulations of jurisdictions in which they register. To
support local reporting requirements, legal reporting units are created and registered.
Legal Entity Considerations
Oracle Fusion Applications support the modeling of your legal entities. If you
make purchases and sell to and from companies under your control, define these
companies (or other legal entity types) in your customer and supplier registers,
which are part of the Oracle Fusion Trading Community Model.
Transactions between legal entities require accounting. Accounting for transactions

between legal entities under common control (your legal entities) is called intercompany
accounting.
Legal entities can be identified as legal employers. In Oracle Fusion Financials, the
employees employed by the legal employer can be assigned as users.
There are several decisions that need to be considered in creating your legal
entities. Some of these are outlined on the following Decision pages.
Legal Entity Decisions 1
Importance of a Legal Entity in Transactions
Assets and liabilities of the enterprise are owned by individual legal entities.
Enter legal entities on transactions that represent a movement in value or
obligation.
For example, the creation of a sales order:
Creates an obligation for the legal entity that books the order to deliver the goods on the
acknowledged date, and an obligation of the purchaser to receive and pay for those
goods.
Provides, under contract law in most countries, that damages can be sought:
 For actual losses, putting the injured party in the same state as if they had not
entered into the contract
 For loss of bargain, meaning the profit that could have been made on a
transaction
Legal Entity and its Relationship to Business Units
A business unit that serves your enterprise as a shared service center can
process transactions on behalf of many legal entities.
In most cases, the legal entity is explicit on your transactions. For example, a
transaction to record a loan origination may include an explicit legal entity field.
In some cases, the transaction legal entity is inferred from other reference entities that
are themselves linked to a single legal entity. For example, your business unit A agrees
on terms for the transfer of inventory to your business unit B.
Legal Entity and its Relationship to Divisions
 The division is an area of management responsibility that can correspond to a

collection of legal entities or to part of a single or of several legal entities.
 Aggregate financial results for divisions by legal entity or by combining parts of
multiple legal entities.
 Define date-effective hierarchies for the segment that represents the
management entity in the chart of accounts to facilitate the aggregation and
reporting by division.
Legal Entity and its Relationship to Ledgers
 Use the Oracle Fusion General Ledger Accounting Configuration Manager

to specify which ledger a legal entity uses to perform accounting.
 When several legal entities share a ledger, specify which balancing segment
values they use.
There are special considerations when assigning journal and document
sequences to ledgers.
If the deploying enterprise has operations in countries with strict legal entity document
and journal entry sequencing requirements, then consider implementing one legal entity
per ledger. This limitation does not apply to operations in other countries.
NOTE: For more information on Document Sequencing see the Define Document
Sequences lesson.
Legal Entity and its Relationship to Balancing Segments
 Accounting for your operations means you must produce a trial balance and
balance sheet by legal entity.
 Oracle Fusion General Ledger supports the use of up to three balancing
segments. Best practice is to use the primary balancing segment to hold values
that represent legal entities.
 If more than one legal entity is represented in the ledger, best practice is to use
at least one balancing segment to represent legal entity to facilitate financial
reporting to regulatory agencies, tax authorities, and investors.
 If you would like to subdivide legal entities into lower levels for reporting, you can
use one or two additional balancing segments in your chart of accounts.
If you account for each legal entity in a separate ledger, there is no requirement
to identify the legal entity with a balancing segment value within that ledger.
However, this is not considered best practice.
If you would like to create consolidated management reporting across legal entities, you
can use a single ledger to represent multiple legal entities. This is possible when the
legal entities are governed by the same legislative requirements, such as operating in
the same country.
 For example, multiple legal entities that operate in the United States can be
accounted in the same ledger.
However, if the legal entities are not governed by the same legislative requirements,
you may need to store them in separate ledgers.
 For example, a legal entity that operates in France should not be accounted in
the same ledger as a legal entity that is operating in Ireland.
If you account for many legal entities in a single ledger, you must:
 Decide which balancing segment values correspond to each legal entity and
assign them in Oracle Fusion General Ledger Accounting Configuration
Manager. This is completed as part of the configuration of Oracle Fusion
Financials, since you are in the context of Oracle Fusion Financials for your
 Assign balancing segment values. If you use a balancing segment to represent
legal entities, you should represent all of your legal entities with that same
balancing segment. This recommended best practice facilitates reporting on
assets, liabilities, and profit and loss by legal entity.
 You must use separate balancing segment values to represent each legal entity.
Transactions that cross legal entities are intercompany.
NOTE:
 If you use multiple balancing segments, the total debits and credits must balance,
per balancing segment, per journal entry. If needed, balancing lines, using
general ledger accounts as specified in the intercompany balancing options, are
automatically added by Oracle Fusion Financials to ensure this balancing.
 Carefully consider whether to use multiple balancing segments before using a
ledger. Once a ledger has been used, historical balances are not automatically
converted based upon the selection of additional balancing segments. You
cannot change to multiple balancing segments easily after you have begun to
use the ledger because your historical data is not balanced by the new multiple
balancing segments.
NOTE: For additional information see the lesson on Creating Chart of Accounts.
Legal Entity and its Relationship to Consolidation Rules
 When you have specified which balancing segments are used by which
companies or other types of legal entities, then define consolidation rules using
your balancing segments.
 Defining consolidation rules creates a relationship between the definition of your
legal entities and their role in your consolidation.
NOTE: For additional information see the Configuring Oracle Fusion General Ledger
lesson.
Legal Entity and its Relationship to Intercompany Transactions
Once you have created transactions for your companies or other types of legal
entities, and assigned values in the appropriate balancing segment to them,
intercompany accounting will maintain balances in synch between them.
There are two feature areas available:
 You can have Oracle Fusion Financials generate balancing lines as it creates
accounting to record due to or from legal entity receivables and or payables.
 You can manually create intercompany transactions or use automatic
intercompany balancing journal creation, booking changes to intercompany
activity by legal entity, to balance and clear intercompany accounts.
Use Oracle Fusion Intercompany functionality to automatically create
intercompany entries across your balancing segments.
 Intercompany transactions processing updates accounting balances using

balancing segment values.
 You can post intercompany transactions directly to the general ledger. Subledger
invoicing is not required. Instead, these transactions get directly transferred and
posted to general ledger. If you want this business flow for Oracle Fusion
Financials, you must set up the processing options.
 Define processing options and select the intercompany account combinations

that will be used to create intercompany transactions.
 Account combinations for intercompany transactions are derived automatically
based upon intercompany setup.
 Setup intercompany organizations for your legal entities to limit the number of
trading parties.
Intercompany organizations within the same legal entity are also supported. For
example, you can track assets and liabilities that move between your departments
within your legal entities by creating departmental level intercompany organizations.
NOTE: For additional information see the lesson on Configuring Intercompany

Processing Rules.
Legal Entity and its Relationship to Worker Assignments and Legal Employer
A legal employer is a legal entity that employs workers. You define a legal entity as a
legal employer in the Oracle Fusion Legal Entity Configurator. This includes
employees who are Oracle Fusion Financials users.
Legal Entity and its Relationship to Legal Reporting Units
To support local reporting requirements, legal reporting units are created and
registered.
When you first create a legal entity, the Oracle Fusion Legal Entity Configurator
automatically creates one legal reporting unit for that legal entity with a registration.
NOTE: See the Manage Legal Reporting Units topic for additional information.
NOTE: Instructor Demonstration Create a Legal Entity.
Manage Legal Reporting Units
Each of your legal entities must have at least one legal reporting unit. When a
legal entity is created, a legal reporting unit with the same name as that of the
entity is also automatically created. You can define both domestic and foreign
establishments.
Legal Reporting Units Overview
Create a legal reporting unit in respect of each part of the legal structure you
have registered with a jurisdiction. If you have registered a group of workers for
the purpose of tax or social insurance reporting, use a legal reporting unit for that
registration. If you have specific statutory or tax reporting obligations, use legal
reporting units for each registration.
Define legal reporting units by:
 A physical location, such as:

- Sales office.
 A logical unit, such as:

- Groups of employees subject to different reporting requirements.
- Human Capital Management (HCM) system where you use your legal
reporting units to model your tax reporting units. A tax reporting unit can be used
to group workers for the purpose of tax reporting.
Plan and define your legal reporting units at both the local and national levels if
you operate within the administrative boundaries of a jurisdiction that is more
granular than country.
For example:
 If the legal entity establishes operations requirements for each local area in a
country that requires reporting of employment and sales taxes locally as well as
nationally.
 If you need more than one legally registered location to meet this legal entity's
reporting requirements in each local area.
NOTE: There can be multiple registrations associated with a legal reporting unit.
However, there can be only one identifying registration, defined by the legal authority
used for the legal entity or legal reporting unit, associated with the legal reporting unit.
NOTE: Instructor Demonstration Create a Legal Reporting Unit.
Define Reference Data Sharing
After completing this section, you should be able to:
 Define reference data sharing.

 Manage reference data partitions.
 Describe determinant and determinant types.
 Manage reference data set assignments.
 Explain reference group.
Reference Data Sharing Overview
Reference data sharing helps organizations share common transactional data

without unnecessary duplication.
For example, an organization has several business units and each business unit uses
different payment terms on a customer invoice. Instead of each business unit creating
and maintaining individual payment terms, you can define the payment terms reference
data at the organization level and stripe that data into partitions (create reference data
sets) so that the different payment terms can be assigned to each business unit.
Reference data sharing enables you to:
 Create reference sets across tables or lookup types.

 Share information and data processing options among the determinant types,
such as business unit or asset book.
 Create separate sets and subsets for each business unit depending upon its
business requirement.
 Create common sets or subsets to enable sharing reference data between
several business units, without the need for duplicating the reference data.
Define Reference Data Sharing
 Manage Reference Data Sets: Use this page to create the Set Code, Set
Name, and Description that can then be assigned to reference data.
 Manage Set Assignments for Set Determinant Type: Assign the reference
data sets to reference objects. For multiple assignments, you can classify
different types of reference data sets into groups and assign them to reference
entity objects. The assignment takes into consideration the determinant type,
determinant, and reference group, if any.
Manage Reference Data Partitions
Define reference data and divide the data into partitions called reference data
sets. Assign the reference data sets based on your business needs across your
organizational entities.
Oracle Fusion Applications contain two predefined sets: Common and Enterprise.
You can create more reference data sets based on your business and data sharing
requirements.
The following figure illustrates the partition of the Receivables Payment Terms
reference data into three sets. In this
example, if you are entering an invoice for USA 2 Business Unit, you have the following
payment terms display in the invoice's list of values: Net 15, Net 20, Net 30 and Net 60.
For this example, define reference data sets of the following types:
 Common: Used globally across the organization as a common set. Add the
Common Set to the global Receivables Payment Terms, Net 30 or Net 60, to
be used in all business units.
 Shared: Used by a few business units, US: Health and USA 2, that work with
similar data and therefore share the sets. Add the Shared Set to Receivables
Payment Terms, Net 15 or Net 20, that are defined by country or region where
a few business units belonging to that country or region use it.
 Enterprise specific: Unique to that business unit and not shared by any other
business unit within that organization. Add the Enterprise Set to the Receivables
Payment Term, Prepayment, defined by line of business and used only by that
line of business irrespective of the country or region where it operates.
Determinant and Determinant Types
Determinant Type
You can share the partitioned reference data based on a business context setting called
the determinant type. It is the point of reference used in the data assignment process.
The available determinant types used in the reference data assignment are:
 Asset Book: A book that records information about assets including their
acquisition, depreciation, and retirement. An Asset Book is tied to a ledger.
 Business Unit: A department or organization within an enterprise.
 Cost Organization: An organization used for cost accounting and reporting on
various inventory and cost centers within an enterprise.
 Project Unit: A logical organization within an enterprise that is responsible for
enforcing consistent project management practices.
Determinant
A determinant is the value that qualifies the selected determinant type. For example,
when managing set assignments for the set determinant type, if you select Business
Unit as the determinant type, you would provide the name of the Business Unit as the
corresponding determinant.
Reference Data Set Assignments
You can assign reference data to the relevant reference data sets depending
upon the required level of sharing the data. If you want to share it across the
organization, you can assign it to the predefined Common set.
Other types of reference data may be specific to certain business units. Therefore, you
would want to restrict the use of that data to those business units. In that case, you can
create sets specifically for this type of data, and assign the sets to the business units.
For multiple assignments, you can classify different types of reference data sets into
groups and assign reference data to those groups. The assignment takes into
consideration the determinant type, determinant, and the reference group.
Assignments to one set only, with common values:
 Most commonly used method.

 Allows defining reference data object instance across all sets.
 Method used for Receivables Payment Terms in example on the Manage
Reference Data page.
For example, Receivables Transaction Types are assigned to a:
 Common set that is available to all the business units. With the common set, you
do not have to explicitly assign transaction types to each business unit.
 Business unit specific set of transaction types.
At transaction entry, the list of values for transaction types includes transaction types
from the set assigned to the business unit, as well as transaction types assigned to the
common set that is shared across all business units.
Assignments to one set only, with no common values:
 Simplest form.
 Allows assigning a reference data object instance to one and only one set.
For example, Asset Prorate Conventions are defined and:
 Assigned to only one reference data set.

 Shared across multiple asset books, but all the values are contained only in this
one set.
Assignments to multiple sets, no common values:
Allows a reference data object instance to be assigned to multiple sets.
For example, Payables Payment Terms use this method. Each payment term can be
assigned to one or more than one set.
 Assign the payment term Net 30 to several sets.

 Assign payment term Net 15, Net 20, Net 60, Immediate, and Prepayment to only
one of your reference data sets.
The assignment type of With assignments to multiple sets, no common values
provides payment terms to an invoice from only one reference data set, the set
assigned to the invoice’s business unit. As this example shows, invoices created for
USA 2 Business Unit have the following payment terms available: Net 10, Net 20, and
Net 30.
Reference Data Set Examples
The following list contains some of the reference data objects for the Oracle Fusion
Financial Applications that can be shared across business units and the method in
which the reference data for each is shared.
The following list contains some the reference data objects for Oracle Fusion Assets
that can be shared across asset books and the method in which the reference data for
each is shared.
Reference Group
Reference data sets that share common business policies and legal rules are treated in
the same way and are classified into reference groups. Grouping is done on the basis of
functional area and the partitioning requirements that the reference data has in
common.
For example, all tables and views that define Asset details might be part of the same
reference group.
In Oracle Fusion, the reference groups are predefined in the reference groups table and
are available for selection and assignment to reference data sets.
In this example, a Reference Group of Receivables Payment Terms has been created
to combine the Reference Data Sets for USA1 BU, USA2 BU, and the Common Set.
Navigate > Define Common Applications Configuration > Define Enterprise

Structures > Define Reference Data Sharing >
Manage Set Assignments for Set Determinant Type
Knowledge Check: Reference Data Sets
Reference data sets are:
1. Data models
2. Mapped tables
3. Partitioned reference data
4. Assignments
Knowledge Check: Reference Data Sets Answer
Reference data sets are
1. Data models
2. Mapped tables
3. Partitioned reference data
4. Assignments
You can define reference data, and then depending upon the business context,
decide how to divide the data into partitions (reference data sets) appropriate to
the organizational entities that will use the data.
Knowledge Check: Reference Data Sets with Business Units
Common reference data set is specific to a business unit.
1. True
2. False
Knowledge Check: Reference Data Sets with Business Units

Answer
Common reference data set is specific to a business unit.
1. True
2. False
You can assign reference data to the relevant reference data sets depending
upon the required level of sharing the data. If you want to share it across the
organization, you can assign it to the predefined Common set. Other types of
reference data may be specific to certain business units.
Manage Business Units
 A business unit represents a unit of an enterprise that performs one or

many business functions, and can be consolidated in both a managerial
and legal hierarchy.
 A business unit can process procurement transactions on behalf of many
legal entities.
 A business unit is used to partition your subledgers.
 A business unit is similar to the Operating Unit in prior versions of Oracle,
with additional functionality.
Oracle Fusion Financials facilitates independent balance sheet rollups for legal
and management reporting by providing the ability to use up to three balancing
segments.
Hierarchies created using the management segment can provide the divisional
results.
For example, it is possible to define management segment values to correspond to

business units, and arrange them in a hierarchy where the higher nodes correspond to
divisions and subdivisions, as in the Infusion US Division example above.
Business Units Overview
Use business units in the following ways:
 Management reporting
 Processing of transactions
 Security of transactional data
 Reference data definition and sharing
Business Unit Definition Considerations

 How will you structure your ledgers, legal entities and business unit roll-
ups?
 Are there financial reports that need to be generated by business unit?
 How can you set up your departments or business unit accounts to achieve
departmental hierarchies that report accurately on your lines of business?
 What reporting do you need to support the managers of your business
units, and the executives who measure them?
 How often are business unit results aggregated?
 What level of reporting detail is required across business units?
Business Unit Hierarchy Example
As an example, this InFusion America Company provides:
 Air quality monitoring systems through your division InFusion Air Systems.
 Customer financing through your division InFusion Financial Services.
The InFusion Air Systems division further segments your business into the
System Components and Installation Services subdivisions.
Your subdivisions are divided by business units:
 System Components by products: Air Compressors and Air Transmission

 Installation Services by services: Electrical and Mechanical
NOTE: Student hands-on activity Create a Business Unit.
 Discuss the InFusion Story and implementation considerations.

 Explain legal jurisdictions and authorities.
 Describe legal entities.
 Understand legal reporting units.
 Discuss reference data sharing.

 Understand business units.
Lesson 4: Configuring Oracle Fusion General Ledger

 Manage value sets.

 Define chart of accounts components.
 Manage and publish account hierarchies.
 Maintain segment values
 Manage cross-validation rules.
 Create account combinations.
 Manage chart of accounts mappings.
 Define calendars.
 Manage currencies.
 Define ledgers.
 Consolidate financial results.
 Open and close periods.
 Perform financial analysis and reporting.
Chart of Accounts
Sharing Ledger Components Across Oracle
Applications
Many elements of an accounting configuration are shared with other Oracle

Fusion Applications.
The chart of accounts, calendar, and currencies are called the three C's as they are the
three main components required to create a ledger. An accounting method is also
required, but seeded accounting methods are available, such as Standard Accrual and
Standard Cash.
NOTE: Instructor Demonstration Shared Components.
Accounting Configuration Prerequisites
Before you configure your ledgers, complete the required steps to define the
components that make up the ledgers.
 Define a chart of accounts.

 Define an accounting calendar.
 Enable a currency.
Creating Chart of Accounts
List from the Setup and Maintenance work area
To create a chart of accounts:
1. Define value sets.

2. Define a chart of accounts structure and instance.
3. Define valid segment values.
4. Define account hierarchies.
Other steps are optional and are determined by your implementation

requirements.
 Optionally, create cross-validation rules.

 Optionally, create account combinations.
 Optionally, define security rules.
The task list from the Setup and Maintenance work area and the numbered list vary
slightly.
 You must create value sets first and then add the sets to your structure and
instance even though the Manage Chart of Accounts Values Sets appears
second in the Setup and Maintenance work area list. Do not create your values
before assigning the value sets to your structure and instance because the
value attributes, such as Allow Posting or Account Type, are not available
for data entry.
 After creating the structure and instance, create values for the value sets.
Chart of Accounts Components
There are several important components in a chart of accounts in Oracle Fusion

Applications:
 Chart of Accounts Structure: Defines the key attributes for your chart of
accounts, such as the number of segments, the segment sequences, the
segment names, segment prompts, default values sets, and segment labels,
such as, Natural Account and Primary Balancing.
 Chart of Accounts Structure Instance: Inherits by default all the attributes of
the chart of accounts structure, meaning that all instances of the same structure
share a common shape and have the same segments in the same order.
However, at the chart of accounts instance level, you can override the default
value set assignments for your segments and assign a unique account hierarchy
that determines the parent and child relationships between the value set values.
 Value Sets: Attached to each segment to provide formatting and validation of the
set of values used with that segment. You can think of a value set as a container
for your values.
 Segments: Combines with other segments to create the account combination.
Each segment has a value set attached to it to provide formatting and validation
of the set of values used with that segment.
 Segment Labels: Identifies certain segments in your chart of accounts and
assigns special functionality to those segments. NOTE: The Management
segment label is descoped in V1.
 Deploy: Generates or refreshes components that activate the flexfield in a user
interface. To use a flexfield, it must have been deployed.
 Values: Set of valid values that you assign to a flexfield segment.
 Security Rules: Applied at the value set level to secure the data. If a value set is
secured, all chart of accounts segment that refers to that value set are affected
by the value set's defined security rules.
 Cross-Validation Rules: Determines which account combinations are created
dynamically as your users enter transactions or journal entries.
 Account Combinations: Contains a completed code of segment values that
uniquely identifies an account in the chart of accounts.
Define Value Sets
Use value sets to control the characteristics and format of the chart of accounts
segments.
What is a Value Set?
 Defines the boundaries for the attributes that you assign to a key or descriptive
flexfield segment. Value sets control what types of values can be used as chart
of accounts segment values.
 Determine the attributes of your segments such as length, zero-fill, right-justify,
alphanumeric, and value security.
 Control how validation is performed. For example, a list of values must be
created and used.
Assigning Value Sets to Segments
 Assign one value set to each chart of accounts segment.

 Share the same value sets across multiple charts of accounts to facilitate
consolidation if the values are the same and have the same meaning.
 Use the same value set more than once within the same chart of accounts
structure, as noted in the diagram above, where the same values set is used for
the balancing and intercompany segments.
Caution: If security rules are applied to the shared value set used for both the company
and intercompany segments, you can experience problems with intercompany values
used to record transactions with balancing segment values outside the values that are
use for the legal entities in your ledger.
NOTE: Changing the attributes of a value set affects all charts of accounts segments
using that value set.
The maximumum length of the value set should be carefully considered. By specifying 2
characters, then it is assumed that you will only have 99 company values. If you think
you will have hundreds of companies, then the maximum length should be set to 3.
Validation and Value Sets
When you define value sets, you also need to determine how you want to validate
your values. The validation type of an existing value set cannot be changed.
Independent Validation
 List of values are independently displayed when filling out the segment in the
account combination.
 Best practices recommend using Validation Type of Independent
validation, the Value Data Type of Character, and the Value Subtype of Text
for your chart of accounts. This structure enables you to build a
hierarchical tree structure from the values and report on each segment
independently.
Note: It is strongly recommended that you choose the Value Data Type of
Character and Value Subtype of Text. These can never be changed. If you only
want to use numbers, just define only numeric values for that value set. If you
choose the Value Subtype of Numeric digits only, then you will be stuck with your
decision and you will never be able to use characters or letters for your values in
the future.
Table Validation
 List of values is determined by a column in an application or external table to

facilitate maintenance and sharing of values. The list of values may be limited by
a WHERE clause.
 Caution: If you choose Table Validated, you cannot define Trees or Segment
Value Security for the segment.
 If your value set is validating against a nonOracle database table, have your
System Administrator register the table in the Oracle Fusion Applications.
Enable Security:
If flexfield data security rules are to be applied to the value set assigned to your chart of
accounts, the Enable Security check box must be checked for the assigned value
set. In addition, assign a data security resource name to enable creation of a data
security object automatically for the value set. The data security object is used in the
definition of flexfield data security rules. If you select security, you must define security
rules and data roles to use value sets.
NOTE: In Oracle E-Business Suite, access was granted to all users until restricted by
security rules. In Oracle Fusion, if security is enabled, access is denied to all users until
rules are defined and assigned granting access. Security is defined on value sets, which
can cause problems when you are sharing value sets across charts of accounts.
NOTE: The other validation types that are available and used with different types of
flexfields, such as descriptive flexfields or the Asset Category key flexfield, but not with
the Accounting key flexfield, are:
 Format only: Where end users enter data rather than selecting values from a
list.
 Dependent: List of values where a valid value is determined by the independent
value of another segment. (Not in scope for V1 for the Accounting key flexfield.)
 Subset: List of values which is a subset of the values in an existing independent
value set.
NOTE:
 Instructor Demonstration Create Values Sets.

 Student Activity Create Value Sets.
Building the Chart of Accounts Structure
Sample Chart of Accounts Structure
The chart of accounts structure defines the key attributes for your chart of
accounts:
 Number of segments.
 Segment sequences.
 Segment names and prompts.
 Segment labels, for example natural account and balancing.
 Default value sets.
Other considerations:
 Create up to 30 segments with a maximum of 25 characters per segment. Best

practices recommend 5 to 9 segments.
 Limit maximum length of all segments plus the segment separator. The
maximum allowed is 240 characters.
 Define each segment name and the order in which it appear beginning with the
number one.
 Use a default value set which can be changed at the instances level.
Chart of account instance:
 Displays in the user interfaces and processes.

 By default, inherits all the attributes of the chart of accounts structure, meaning
that all structure instances of the same structure share a common shape and
have the same segments in the same order.
 Permits overriding the default value set assignments for your segments.
Optionally, assign unique hierarchies to create relationships between the value
set values for each segment in the instance by the assignment of a tree code to
the value set associated with the chart of accounts instance segment.
 Determines if allow dynamic insertion is enabled to generate new account
combinations dynamically instead of creating them manually.
The decisions you make when designing your chart of accounts are very
important. Making changes in the future to the structure and instances of your
chart of accounts is difficult and not recommended.
 Plan carefully to create an account structure that meets the current needs of your
organization and anticipates future requirements.
 Tailor your account structure for your industry and reporting requirements.
 Choose the number of segments, as well as the length, name, and order of each
segment carefully.
Define multiple chart of accounts structure instances when different value sets
and values are required to meet local and statutory reporting requirements.
At the chart of accounts structure instance level:
 Optionally, override the value sets defaulting from the chart of accounts structure.
 Assign a value set with the same segment type and length to each segment.
 Create hierarchies for each segment to meet financial reporting requirements.
 Assign a tree code to each instance segment to indicate the source of the
hierarchy information for the associated value set.
 Optionally, assign the same value set multiple times within the same or across
different chart of accounts structure instances within the same structure or in
different structures. Caution: Remember security is enabled at the value set
level and applies to all segments that use that value set.
Assigning Segment Labels
Segment labels indicate that a segment is used in a particular manner. For

example, assign a segment label of Primary Balancing to a Company segment to
indicate that journals must balance by Company. Assign segment labels as part of
the configuration of your chart of accounts structure in the Manage Key Flexfield
Structures page which you access using the Manage Structures button on the
Manage Chart of Accounts page.
Balancing Segment Labels
 Ensures that all journals balance by balancing segment value, or by a

combination of balancing segment values if multiple balancing segment values
are used.
 Allows you to create balance sheets and trial balances by balancing segment.
 Allows you to define data access security across additional levels.
There are three balancing segment labels: primary, second, and third balancing.
 The primary balancing segment label is required.
 The second and third balancing segment labels are optional, and may not be
necessary unless, for example, you need to balance at more than the legal entity
level.
Cost Center Segment Labels
 Facilitates grouping of natural accounts by functional cost types, accommodating

tracking of specific business expenses across natural accounts.
 Enables combining expenses and head count data into cost centers that are
useful for detailed analysis and reporting.
 Optional, but required if you are using Oracle Fusion Assets or if you want to
store expense approval limits in expense management. Add cost center if you
plan to add these modules in the future, as the chart of accounts cannot be
modified without a new install.
Natural Account Segment Labels
 Determines the account type (asset, liability, expense, revenue, or equity) and
other information specific to the segment value.
 Facilities processes in the general ledger application, such as retained earnings
posting, therefore is required.
Intercompany: Optionally assigns the segment to be used in intercompany balancing
functionality.
Management: (Not supported in Oracle Fusion V1.) Optionally denotes the segment
that has management responsibility, such as the department, cost center, or line of
business. Also, can be attached to the same segment as one of the balancing segments
to make legal entity reporting more granular.
NOTE: Segment labels were referred to as qualifiers in Oracle E-Business Suite.
NOTE:
 Instructor Demonstration Create a Chart of Accounts.

 Student Activity Create a Chart of Accounts Structure Activity.
 Student Activity Create a Chart of Accounts Instance Activity.
Knowledge Check: Chart of Accounts
A chart of accounts structure sets the following:
1. Number of segments, segment sequences, default value sets, and dynamic

insertion allowed.
2. Segment sequences, default value sets, dynamic insertion allowed, and segment
prompts.
3. Segment name, segment sequences, default value sets, and number of
segments.
4. None of the above.
Knowledge Check: Chart of Accounts Answer
A chart of accounts structure sets the following:
1. Number of segments, segment sequences, default value sets, and dynamic

insertion allowed.
2. Segment sequences, default value sets, dynamic insertion allowed, and segment
prompts.
3. Segment name, segment sequences, default value sets, and number of
segments.
4. None of the above.
Chart of accounts structure defines the key attributes for your chart of accounts:
 Number of segments.
 Segment sequences.
 Segment names and prompts.
 Segment labels, for example natural account and primary balancing.
 Default value sets.
Deploying the Chart of Accounts
To use a chart of accounts, first deploy the Accounting key flexfield.
After configuring your chart of accounts, navigate to the Manage Chart of Accounts
page from the Setup and Maintenance work area and click the Deploy Flexfield
button.
.
To verify the Deployment Status has completed, navigate to the Manage Key
Flexfields page from the Setup and Maintenance work area.
Deployment Status
1. Edited: The flexfield definition has not been deployed or changes have been
made to the structure, structure instances, or value sets.
2. Patched: The flexfield definition has been modified through a patch, but the
flexfield has not yet been deployed so the patched definition is not reflected.
3. Deployed to Sandbox: The flexfield is deployed and available in a flexfield-
enabled sandbox.
4. Deployed: The flexfield definition is deployed and available to end users.

5. Error: The deployment attempt failed.
NOTE: Changing a value set definition, which should be a rare occurrence, changes the
deployment status of a flexfield to Edited. If the change results from a patch, the
deployment status of the flexfield changes to Patched.
The process deploys all chart of accounts key flexfields. It stops when it encounters an
error. You must fix the errors and run the process again until successful.
Defining Segment Values
Enter valid values for each segment after adding them to the chart of accounts
structure and structure instance.
Defining Segment Values
Navigate from the Setup and Maintenance work area to the Manage Chart of
Accounts Value Sets page. Click the Manage Values button to enter values for each
segment. These are the values that you use when building your account combinations.
Each value is defined with a name, description, and optionally a start date, and end
date. To use a segment value, it must be enabled. The period of usage must fall within
the start and end dates if entered on the value.
NOTE: Sort Order is not used with the Accounting key flexfield.
Caution:
 When creating a new chart of accounts with new value sets, create the value
sets definition first and leave the values creation until after the creation of the
instance and structure.
 Creating values before assigning the value set to the account structure prevents
the ability to define the required attributes on the values and make them
unusable for the chart of accounts.
Assigning Segment Attributes
Assign attribute options for your segment values. Attributes display based on the
segment label options assigned to the segments during chart of accounts
creation and vary by segment.
You can define the following segment attributes:
NOTE: If you select Yes for Summary (Parent), the application does not post to the
accounts created using that value even if Allow Posting is set to Yes. Account Type,
Third Party Control Account, Reconcile, and Financial Category attributes are only
available on the Natural Account segment values. The Financial Category is a seeded
list and you can add additional values.
Allow Posting: Enter Yes to enable posting to the account. If set to No, you cannot
post to the account. If you are defining a parent segment value, you must enter No
because you cannot not post to parent accounts.
Allow Budgeting: Enter Yes to perform budgeting for accounts with this segment
value. If you are defining a parent segment value, you must enter No. (Descoped for
V1.)
Account Type:
 Define an account type for each natural account segment value.

 Enter the type of proprietary account, Asset, Liability, Owners' Equity, Revenue,
or Expense. (Type of budget account, Budgetary Debit or Budgetary Credit is not
supported in Oracle Fusion V1.)
 Enter either Asset or Expense for statistical accounts. If you choose Asset, the
balance in the account carries forward year to year. If you choose Expense, your
statistical balance zeros-out at the end of the fiscal year.
 Do not change the Account Type for a value that has been used or has a balance
without first consulting Oracle Fusion Support.
Third Party Control Account:
 Enter Customer, Supplier, or Yes for the Third Party Control Account to
designate the account as a Control Account.
 Access to this account will be restricted to Oracle Payables, Receivables, and
Inventory, for which Subledger Accounting automatically creates detailed
balances.
 Do not specify the account as a control account if you want to use the account for
all Oracle Fusion Applications.
 Restrict Manual Journal option prevents using the account in manual GL journal
entries, but allows the account in manual SLA journal entries.
Reconcile: Enter Yes for Reconcile to allow reconciliation for natural accounts that
should balance to zero. (Not Supported in Oracle Fusion V1.)
Financial Category: Used with Oracle Transaction Business Intelligence reporting to

further identify groups of accounts.
Control Accounts Example
Control accounts are Oracle Fusion General Ledger accounts accessed from Oracle
Fusion Payables, Receivables, and Inventory, for which Oracle Fusion Subledger
Accounting automatically creates detailed balances.
Control accounts ensure only specific data is posted from an approved journal source.
Control Accounts prevent users from entering data from unauthorized sources. Manual
data entry to control accounts can be prevented.
Benefits
 Improved data integrity: Only allow approved sources to post to an account.

 Streamlined reconciliation: Enforce consistency between the source system
and the general ledger account balance.
Control Accounts Setup and Process
When defining your natural account segment values, you can designate an account as
a control account using the attributes in the Manage Values page from the Setup and
Maintenance work area. Select one of the following options:
 Customer: Only journals from subledger accounting for receivables are

permitted.
 Supplier: Only journals from subledger accounting for payables are permitted.
 Restrict Manual Journals: No GL manual journals are permitted to use this
account.
 Yes: No manual journals from GL or SLA are permitted against this account.
 No: Not a control account.
NOTE: Student Activity Enter Values.
Defining Hierarchies
Oracle Fusion General Ledger Account Hierarchies functionality leverages the

common date-effective tree model employed throughout Oracle Fusion
Applications. Hierarchies are used in Oracle Fusion General Ledger to facilitate the
setup of chart of accounts mappings, revaluations, data access sets, cross validation
rules, and segment value set rules. Account hierarchies are also highly leveraged in
Financial Reporting, Smart View queries, and allocations.
A given segment in the chart of accounts can have multiple hierarchies, and each
hierarchy can have multiple versions. Analyze financial results from any
accounting period using any version of any account hierarchy.
In summary, use Oracle Fusion Accounting Hub to:
 Create account hierarchies (trees) to identify managerial, legal or geographical

relationships between your value set values.
 Define date-effective tree versions to reflect organizational changes within
each hierarchy over time.
 Publish multiple hierarchies to balances cubes to allow for financial reporting
and analysis of past, present or future data.
NOTE: Oracle Fusion Applications offers out-of-the-box integration with Oracle
Hyperion Data Relationship Management (DRM) for management of chart of accounts
reference data including segment values, business rules, cross validation of values, and
hierarchies. If you decide to implement DRM with the integration with Oracle Fusion
Applications, chart of accounts values and account hierarchies (trees) are maintained in
DRM rather than in Oracle Fusion Applications.
Account Hierarchy Purposes
Create multiple hierarchies for different purposes. For example, define three
different hierarchies to be used for each chart of accounts segment that has rollups,
each for a particular purpose:
Hierarchies for financial reporting: Must be published to Essbase cubes. Child values
in these hierarchies cannot roll up to different parents within a hierarchy as this
functionality is not support when publishing such hierarchies to Essbase.
Hierarchies for allocations: Must be published to Essbase cubes. Used with

Calculation Manager in creating allocation rules.
Hierarchies for cross validation rules, revaluation, and chart of accounts

mapping:
 Created within the same hierarchy and must be associated with a chart of
accounts instance.
 Only associate one hierarchy with a chart of accounts instance, per segment.
 Such hierarchies can have the same child to roll up to different parents.
 Do not publish to the Essbase cube since multiple child assignments are not
supported in the Essbase cube.
NOTE: these hierarchies will not be available for reporting and allocations.
NOTE: In the rare cases where you can utilize the same hierarchical account
relationships for financial reporting, allocations, cross validation rules, revaluations, and
chart of accounts mapping definition, you can just define one hierarchy. However, if you
need multiple hierarchies, we recommend that you define them using multiple trees.
Create Account Hierarchies
Use the Manage Account Hierarchies page to search, create, and edit account
hierarchies.
Following are the general steps to create a hierarchy in the Manage Account
Hierarchies page:
1. Create Tree icon to open the definition of the Tree.

2. Enter the Name, Code, Tree Structure, and Description for the tree.
3. Enter the Data Source Parameters to designate the value set and whether
parent or detail values are used in the hierarchy.
4. Search for the Tree you just created to add a Tree Version.
5. Enter the Name, Description, and Effective Start Date for the tree version.
6. Select the Data Source values (parent or child nodes) to use.
7. Use the Audit Results region to start the Audit process to verify the correctness
of the tree.
8. Use the Actions menu > Flatten menu > Column Flattening and Row
Flattening. Row and Column Flattening optimize parent-child. Information for
run-time performance by storing an additional column in a table for all parents of
a child.
9. Actions menu > Set Status > Active to activate the hierarchy.
Published Account Hierarchy Example
Each combination of a tree plus tree version is published as a different account

hierarchy to balances cube.
To uniquely identify values in trees, each chart of accounts value in the hierarchy is
assigned a Fully Qualified Member Name Path in the cube to guide in select values
during general ledger processes.
When a chart of accounts detailed or parent value is assigned to multiple tree versions,
the fully qualified member name path includes the tree version name.
For example:
 Cost Center 500 is associated with two Tree Versions: V1 and V2.
 When selecting the value 500, the cube has logic to uniquely identify the
member. One example is:
[All IF Cost Centers-V1].[999].[500] where IF is InFusion.
[All IF Cost Centers-V2].[999].[500] where IF is InFusion.
 NOTE: The fully qualified member path may also be shortened by the cube logic.
An example is: [All IF Cost Centers-V1].[999].[500] reads as [All InFusion
Cost_Centers for Version 1] @ [Cost Center Level 999] @ [Value 500].
The following points are important:
 The fully qualified member name path for a member may change if you originally
published a single hierarchy to a cube and later published another hierarchy that
includes the same chart of accounts value.
 If the fully qualified member name path changes, you will need to update existing
financial reports, allocation rules, and Smart View template that refer to that
member. Otherwise, such processes will have errors.
Example of Name Path:
Only a single tree version V1 existed when a financial report is defined.
 The tree version includes the chart of accounts value 500 for a cost center.
 The path will not include a tree version name, since there is only one tree version
in the cube.
 The fully qualified name path will be: 500.
A new tree version V2 is published.
 The fully qualified member name path will change since there are now two
versions.
[All VF Cost Centers-V1].[999].[500]
[All VF Cost Centers-V2].[999].[500]
 Any configurations in financial reports, allocations, and Smart View queries that
referenced the original fully qualified name path 500, must be updated to use
the new name of either: [All VF Cost Centers-V1].[999].[500] or [All VF Cost
Centers-V2].[999].[500].
NOTE: Instructor Demonstration Create an Accounting Hierarchy.
Enabling Account Combinations
 New account combinations are always enabled.

 An account combination cannot be deleted.
 To discontinue using an account combination, simply deselect the Enabled
check box for the account combination.
 Or use the To Date to end date the account combination.
 The From Date is used to enable an account combination as of a particular date.
For example, if you have a new department as of January 1, 2012, you can create an
account combination with a From Date of 01-JAN-2012 and the account combination
becomes enabled on that date. This functionality provides the flexibility to create the
account combinations in advance.
To create an account combination, navigate from the Setup and Maintenance work
area to the Manage Account Combinations page. Additionally, you can set the
following attributes from the Manage Account Combinations page:
 Preserve Attributes: To prevent changed segment values from overriding

values defined at the account combination level when running the Inherit
Segment Value Attributes process.
 Type: To identify the type of account - Asset, Liability, Revenue, Expense, and
Owner's Equity.
 From and To Dates: To enable or disable the account combination on a specific

date.
 Allow Posting: To use the account combination in journals.
 Alternative Account: To use an alternative account combination when this one
is disabled.
NOTE: Student Activity Create an Account Combination.
Manage Segment Value Attributes
Oracle Fusion General Ledger eases chart of accounts maintenance by

automatically replicating changes to segment value attributes of the account
combinations that contain that segment value.
For Example
If you enable a particular cost center segment value that had been disabled previously,
you can navigate from the Setup and Maintenance work area to the Maintain
Segment Value Attributes task to run the Inherit Segment Value Attributes process
and re-enable all account combinations containing that cost center automatically. You
can also prevent selected account combinations from being affected by segment value
attribute changes by selecting the Preserve Attribute check box in the Manage
Account Combinations page.
 Use the Segment Value Inheritance Exception Report to view the account
combinations that have been changed.
 Individual segment value attributes override account combination attributes.
 An account combination is composed of several segment values. If these
segment values have conflicting settings for Enabled, Allow Posting, From
Date, or To Date, the most restrictive of the settings for any of the individual
segment values applies to the account combination when the program is run. If
you disable a segment value, the combinations that contain that value is no
longer able to be used, even if the Preserve Attributes check box is selected.
NOTE: You can also disable an account combination in the Manage Account
Combination page. However, you must select or deselect the Enabled check box for
each account combination individually. This applies to other attributes such as Allow
Posting as well.
Defining Segment Value Security Rules
Set up segment value security rules against your value sets to control access to
parent or detail segment values.
 Securing a value set denies access to all values by default. Create conditions
and assign them to specific data roles to control access to your segment values.
 Restrict data entry, online inquiry, and reporting to specific values by using
segment value security rules. For example, create a segment value security rule
that grants a user access only your own department.
General Points About Value Set Security:
 Used in conjunction with flexfield segments.

 Specifies that data security be applied to the values in the segments that use the
value set. Based on the roles provisioned to users, data security policies
determine which values of the segment end users can view or modify.
 Applies at the value set level. If a value set is secured, every usage of the value
set in a segment is secured.
 Applies to independent or table-validated value sets.
 Applies mainly when data is being created or updated, and to account
combination tables for query purposes.
Defining Cross-Validation Rules
 Prevent the creation of invalid account combinations by setting up cross-

validation rules.
 Define cross-validation rules before entering a chart of accounts.
 Use cross-validation rules in combination with dynamic insertion.
Defining Cross-Validation Rules
 Controls the combinations of values you can create when you are setting up
account combinations.
 Defines whether a value of a particular segment can be combined with specific
values of other segments.
 Differs from segment validation, which controls the values you can enter for a
particular segment.
 Used to prevent the creation of combinations that should never exist, such as
combinations with values that should not coexist in the same combination. For
example, you can assign rules to prevent the combination of a product with
administrative departments.
Defining and Revising Cross-Validation Rules
 Because cross-validation rules validate only new accounts, you should define
and enable them prior to entering accounts.
 Revise cross-validation rules at any time, but remember that they only prevent
the creation of new invalid account combinations.
Combinations of Segment Values
 New accounts must pass every enabled cross-validation rule to be valid.
 Cross-validation rules do not affect existing accounts.

Using Cross-Validation with Dynamic Insertion
 Enable dynamic insertion in the Manage Structure Instances page to allow

users to define new account combinations of segment values.
 If dynamic insertion is not enabled, you can only enter new account combinations
of segment values using the Manage Account Combinations page.
 Cross validation rules are important even if dynamic insertion is not enabled to
prevent creating invalid combinations accidentally.
Filters and Conditions
Use Filters to narrow down the search the application has to do before performing
validation. For example, if you enter company Equals 102 as a filter, the application
only validates new account combinations with 102 as the company value.
Use Conditions to determine if an account combination is created or not. For example,

enter company 102 and cost center 139 with Does not equal operators to prevent any
account combinations from being created with those two values, regardless of the other
values used in the account combination.
The following operators are available for both the Filters and the Conditions:
NOTE: Instructor Demonstration Define Cross-Validation Rules.
Manage an Accounting Calendar
Create a calendar to define an accounting year and the periods that it contains.
 Specify common calendar options that the application uses to automatically

generate a calendar with its periods.
 Define your calendar with at least one year before the period in which you start
entering transactions.
 Make choices carefully when specifying the options, because it is difficult to
change your accounting calendar after a period status is set to open or future
enterable.
 Optionally, define multiple calendars and assign a different calendar to each
ledger.
Account Calendar Considerations
 Foreign currency translations cannot be performed in the initial period opened for
your ledger.
 Select the earliest period carefully. After you open the first accounting period,
prior periods cannot be opened.
 When the next accounting period is opened, Oracle Fusion Applications rolls
account balances forward to the new period. Do not change the name of the
period once used.
Accounting Calendar Considerations
Start Date
 Specify a calendar start date that is a full year before the start date of the
year of the first translation period for your ledger.
 Remember translation cannot be run in the first period of a calendar. Translation
requires that the first period that is ever translated for the ledger must be at least
the second defined period in the ledger's calendar because it derives an opening
balance based on the prior period's ending balance.
 Consider how many years of history to load from your previous system.
Period Frequency: Use period frequency to set the interval for each subsequent period
to occur, for example, monthly, quarterly, yearly, 4-4-5, 5-4-4, or 4-5-4.
Adjusting Period Frequency
 Use the adjusting period frequency to control when the application creates
adjusting periods.
 The default is None which adds no adjusting periods.
Period Name Format Region: User Defined Prefix
 Optionally, enter your own prefix.

 For example, define a weekly calendar and then enter a prefix of Week, - as the
separator, and the period name format of Period numberYY fiscal year. The
application creates the names of Week1-11, Week2-11, through Week52-11.
Period Name Format Region: Format
 Calendar Period: Select a calendar period format to append the period's

start date's year (matches the calendar on the wall year) to the prefix. For
the period covering September 1, 2011 to December 31, 2011, 2011 or 11 is
appended to each period's name depending on the period format selected. For
the remaining periods covering January 1, 2012 to August 31, 2012, 2012 or 12,
is appended to each period's name.
 Fiscal Period: Select a fiscal period format to always append the period's
year assignment (year of the last period in year) to the prefix. If the
accounting periods in the set of twelve are all assigned the year of 2012, 2012 or
12 is appended to the period name of all 12 periods depending on the period
format selected.
NOTE: The list of values is filtered based on the selected separator and only displays
the options that match the selected separator.
Calendars with Different Period Frequencies
When you are using the period frequency of Other, you must manually enter the
calendar.
 Select the period frequency of Other.

 Enter the number of periods for alternative frequencies.
 Enter the start and end dates manually.
The application generates the period names, year, and quarter number.
 For example, select the period frequency of Other and enter 52 as the number of
periods when you want to define a weekly calendar.
 The period format region is hidden.
 The application generates a temporary period name using a fixed format of
Period numberYY.
 You can override this format with your own customized period names.
Adding a Calendar Year
For manually entered calendars, when you click the Add Year button on the Edit
Calendar page, the application populates the next year or creates a blank year,
depending on your period frequency. If a blank year is created, manually enter the
periods for the new year.
NOTE: For an accounting calendar that is associated with a ledger, changing period
names or adding a year updates the accounting period dimension in the balances
cubes.
NOTE: Student Activity Create a Calendar.
Calendar Auditing
Calendar validation is automatic and prevents serious problems when you begin
using the calendar. Once you set a calendar period status to open or future
enterable, you cannot edit the period. The calendar validation runs automatically
when you save the calendar.
Calendar Auditing:
 Audits your accounting calendars to check for common setup errors. This feature
strengthens controls during implementation and prevents potential processing
problems related to invalid calendar definitions.
 Performs online checking of errors such as the wrong number of days assigned
to a period or nonadjusting periods that have overlapping days.
 Provides online feedback in the form or error message as the process checks for
validation errors such as date omissions, overlapping nonadjusting periods, and
nonsequential periods.
Manage Currencies Overview
Oracle Fusion Applications provides full cross currency functionality to meet the
needs of global companies. Currency functionality is designed in accordance
with the United States Statement of Financial Accounting Standards 52 (SFAS
#52) and International Accounting Standards 21 (IAS 21) requirements.
Use cross currency functionality to:
 Record transactions, journal entries, and report in any currency.

 Enter daily rates online or automatically.
 Perform currency conversion online and in real time.
 Comply with Generally Accepted Accounting Principles (GAAP).
Currency Concepts
The following are the three currency processes performed in Oracle Fusion
Applications:
 Conversion: Refers to cross currency transactions that are converted during the
accounting transformation to the currency of the ledger in which the transaction
takes place.
 Revaluation: Adjusts asset or liability accounts that may be materially

understated or overstated at the end of a period due to a fluctuation in the
conversion rate between the time the transaction was entered and the end of the
period.
 Translation: Restates an entire ledger or a set of balances for a company from

the ledger currency to a reporting currency.
Currency in Subledgers
 Many foreign-denominated transactions are originally entered and then settled in

feeder systems such as Oracle Fusion Payables and Oracle Fusion Receivables.
 Oracle Fusion subledgers share the same Oracle Fusion General Ledger rate
table.
 Different conversion rate types provide each subledger the opportunity to convert
transactions at different rates daily.
 Corporate procedures can assist in entering and maintaining conversion rates

and avoiding inconsistencies.
Knowledge Check: Manage Currencies
The three currency concepts are:
1. Allocation, revaluation, conversion

2. Conversion, revaluation, translation
3. Reporting currency, allocation, translation
4. Translation, accounting transformation, conversion
Knowledge Check: Manage Currencies Answer
The three currency concepts are:
1. Allocation, revaluation, conversion

2. Conversion, revaluation, translation
3. Reporting currency, allocation, translation
4. Translation, accounting transformation, conversion
Define Currencies Overview
In the Setup and Maintenance work area locate the Define Currencies task list and
navigate to the tasks needed to successfully implement your currencies.
 Use the predefined International Standards Organization (ISO) currencies or

create new ones.
 Enable currencies to use them for your financial transactions and processes.
 Enable the STAT currency, which is predefined, to record statistical data, such as
employee head count, labor hours, or units sold. For example, statistical data is
used in allocation journal calculations to spread related costs over different cost
centers. For example, in a manufacturing operation, use labor hours to allocate
the costs of a product to the different cost centers that performed the work.
The Define Currencies task list consists of the following tasks:
 Manage Currencies: Enable and create currencies to use when recording cross-
currency transactions and running accounting processes.
 Manage Conversion Rate Types: Create and manage conversion rate types to
categorize the relationships between your currencies and daily rates.
 Manage Daily Rates: Enter and manage daily, periodic, and historical rates
used to record transactions or in processes involving multiple currencies.
NOTE: The Manage Conversion Rate Types and the Manage Daily Rates tasks open
the Currency Rates Manager page.
Currencies Overview
Create currencies to use, for example for reporting purposes or in cases of newly
created countries or currencies.
Enable currencies other than USD, which comes enabled, to:
 Display monetary amounts in other currencies.

 Assign them to ledgers.
 Enter cross currency transactions and journal entries.
 Record balances.
When creating or editing currencies, consider these points:
 Currency Codes: After a currency is enabled, the currency code cannot be

changed, even if you later disable that currency.
 Date Ranges: Currency codes can only be selected for the dates within the date
range defined. If you do not enter a start date, then the currency is valid
immediately. If you do not enter an end date, then the currency is valid
indefinitely.
 Symbols: Some applications use currency symbols, others, such as Oracle
Fusion General Ledger, do not, even if the currency is defined with a symbol.
 Euro Currency Derivation: Derivation Type, Derivation Factor, and Derivation

Effective Date fields are used to define the relationship between the official
currency (euro) of the European Monetary Union (EMU) and the national
currencies of new EMU member states during their transition period.
NOTE: If you need to use a different currency code than EUR for the euro currency, you
can disable the predefined EUR currency code and create the new one.
NOTE:
 Instructor Demonstration Create Currencies.

 Student Activity Create Currencies.
Conversion Rate Types Overview
Conversion rate types are assigned to currency rates to convert cross currency
amounts to ledger currency equivalents. Define conversion rate types in the
Currency Rates Manager page access from the Manage Daily Rates task in the
Setup and Maintenance work area.
Oracle Fusion General Ledger predefined conversion rate types are:
 Spot: Represents rates for a specific date. Usually entered daily.

 Corporate: Represents standard rates determined by senior financial
management and used over a period of time throughout your enterprise. Usually
used with stable currencies which have minor fluctuations over time.
 User: Represents rates entered by users during cross currency journal entry
creation for infrequently used currencies or currencies that fluctuate over time.
 EMU Fixed: Represents rates used by countries joining the European Union
during the transition period to the euro currency from their national currency.
NOTE: Define additional rate types to use with rates for special needs.
Explain Cross Rate Rules
Cross rates facilitate the creation of daily rates by automatically deriving the rates
from the relationship between contra currencies and a pivot currency. The
automatic creation of rates is particularly beneficial for intercompany transactions with
multiple currencies because it ensures consistency among the rates, thereby minimizing
the effect of conversion rate differences during the intercompany elimination process.
 Pivot Currency: A currency linked to the two contra currencies to enable the
automatic creation of the daily rates between the contra currencies. Select a
pivot currency that is commonly used in your currency conversions and is
enabled, effective, and not a statistical currency.
 Contra Currency: A currency other than your pivot currency that is enabled,
effective, and not a statistical currency,
For example, you set up a daily rate between the US dollar (USD) and the euro
currency (EUR) and another between the USD and the Canadian dollar (CAD).
USD is the pivot currency used by the application to create a daily rate between
EUR and CAD automatically. EUR and CAD are the contra currencies.
NOTE: If the Enable Cross Rates check box is changed to unchecked after entering
contra currencies, the application stops calculating cross rates going forward for that
particular rate type. All the earlier calculated cross rates for that rate type remain in the
database unless you manually delete them.
NOTE:
 Instructor Demonstration Create Conversion Rate Types.

 Student Activity Create Conversion Rate Types.
Daily Rates Overview
After you define your conversion rate types, you can enter daily rates through the
Currency Rates Manager page access from the Manage Daily Rates task in the
Setup and Maintenance work area.
 Daily rates define the conversion rate relationship between two currencies, using
a specific conversion rate type on a particular date.
 Daily conversion rates are between any two currencies that you have enabled in
your applications instance, regardless of your ledger currency.
Sharing Daily Rates:
 Daily conversion rates are shared across all ledgers within an applications
instance and are available when entering cross-currency transactions in your
Oracle Fusion subledgers.
 Subledger applications share the same daily rates with the general ledger, but
different rate types provide each subledger the ability to convert transactions at
different rates.
Entering Daily Rates:
 Enter inverse rates independently or have the application calculate the inverse
rate from the entered rate.
 Use the provided spreadsheet template to load daily rates or you can map the
rates directly to the GL_DAILY_RATES_INTERFACE table to automatically
insert, update, or delete daily rates in the GL_DAILY_RATES table. The
application validates the rows in the interface table before making changes in the
GL_DAILY_RATES table.
 Warning: Always use the interface table to load your daily rates either through
the spreadsheet template or by using other file loading tools. Do not load rates
directly into the GL_DAILY_RATES table. This can corrupt your daily rates data.
NOTE: Use conversion rate service companies to provide you with rates that can be
loaded into the GL_DAILY_RATES_INTERFACE table automatically.
Ledgers
Relevant Setup Tasks
Use your implementation project or the Setup and Maintenance work area to
locate the Define Accounting Configurations task list and navigate to the tasks
needed to successfully complete your accounting configuration.
Ledgers and Accounting Configurations
The process of designing the enterprise structure, including the accounting

configuration:
 Starts an implementation.
 Includes determining financial, legal, and management reporting requirements.
 Requires setting up primary and secondary ledgers.
 Entails making currency choices.
 Involves examining consolidation considerations.
 Serves as a framework for how financial records are maintained for an
organization.
This figure shows the enterprise structure components and their relationships to each
other.
Oracle Fusion Applications reflect the traditional segregation between the general
ledger and associated subledgers.
 Detailed transactional information is captured in the subledgers.

 Transactions are periodically sent to Subledger Accounting for creation of journal
entries.
 Transactions are Imported and posted in summary or detail to the ledger using
Subledger Accounting.
Subledger Accounting is an application that is used to create and capture
transactions, which contains accounting rules that are used to create detailed journal
entries.
A ledger determines the currency, chart of accounts, accounting calendar, ledger

processing options, and accounting method for its associated subledgers.
 Each accounting setup requires a primary ledger and optionally, can include
one or more secondary ledgers and reporting currencies.
 Reporting currencies are additional currency representations of primary ledgers
or secondary ledgers.
 The number of ledgers and subledgers is unlimited and determined by your
business structure and reporting requirements.
Companies account for themselves in primary ledgers, and, if necessary,
secondary ledgers and reporting currencies.
 Your transactions from your subledgers are posted to your primary ledgers and
possibly, secondary ledgers or reporting currencies.
 Local and corporate compliance can be achieved through an optional secondary
ledger, providing an alternate accounting method, or in some cases, a different
chart of accounts.
 Your subsidiary's primary and secondary ledgers can both be maintained in your
local currency, and you can convert your local currency to your parent's ledger
currency to report your consolidated financial results using reporting currencies
or translation.
Define Ledger Components
There are 3 types of ledgers defined in Oracle Fusion General Ledger using the
four components that are already defined: Chart of accounts, calendar, currency,
and accounting method.
 Primary Ledger: Main record keeping ledger and a required component in your
configuration. Every accounting configuration is uniquely identified by its primary
ledger. The primary ledger is closely associated with the subledger transactions
and provides context and accounting for them.
 Secondary Ledger: Optional ledger linked to a primary ledger for the purpose of
tracking alternative accounting. A secondary ledger can differ from its primary
ledger in its chart of accounts, accounting calendar, currency, accounting

method, or processing options.
 Reporting Currency: Optional, additional currency representation of a primary
or secondary ledger. A reporting currency can differ from its source ledger in its
currency and some processing options, but shares the same chart of accounts,
accounting calendar, and accounting method with its related ledger.
Manage Primary Ledgers
The Primary Ledger:
 Performs as the main record keeping ledger.

 Records transactional balances by using a chart of accounts with a consistent
calendar and currency, and accounting rules implemented in an accounting
method.
 Is used to book journals to record the impact of subledger transactions.
To determine the number of primary ledgers:
 Begin with your financial, legal, and management reporting requirements.

 Consider corporate year end and local government regulations and taxation.
For example, if your company has separate subsidiaries in several countries
worldwide, enable reporting for each country's legal authorities by creating multiple
primary ledgers representing each country with the local currency, chart of accounts,
calendar, and accounting method. Use reporting currencies linked to your country
specific primary ledgers to report to your parent company in their ledger currency from
your foreign subsidiaries.
NOTE:
 Instructor Demonstration Create a Primary Ledger.

 Student Activity Create a Primary Ledger.
Specify Ledger Options
After configuring your primary ledger, the next step is to specify your ledger
options. These options:
 Control many of the accounting processes and defaults that are used in both the
general ledger as well as the subledgers.
 Are required if marked with an asterisk *.
 Require the account combinations to be created in advance or dynamic inserts to
be turned on at the chart of accounts instance level to enter the Retained
Earnings and other accounts. Note: Dynamic inserts can be toggled off and on, if
you desired it to be turned off after setting up the ledger options page.
 Affect balances and journals.
Processes that affect balances are:
 Year End Closing: When you open the first period of a new year, the application
updates the Retained Earnings accounts and moves the total balances in your
revenue and expense accounts to the Retained Earnings accounts by balancing

segment.
 Translation process: When you translate your ledger currency to another
currency, the application updates the Cumulative Translation Adjustment
account.
Processes that affect journals are:
 Journal Posting: Updating balances by completing the journal process.

 Revaluation: Calculating unrealized gains or losses on foreign currency
transactions due to currency fluctuations.
 Suspense: Posting of amounts to the Suspense and other accounts, such as
Rounding and Entered Currency Balancing to balance a standard, reversal,
and intercompany journal entries.
NOTE:
 Instructor Demonstration Ledger Options.

 Instructor Demonstration Journal Processing Ledger Options.
 Student Activity Specify Ledger Options.
Balancing Segment Value Assignments
Assignment of primary balancing segment values to legal entities and ledgers is

performed within the context of a single accounting setup. If implementing the
Fusion Intercompany module, then it is mandatory to assign BSVs to legal
entities. Assignment to legal entities is best practice and is used more often than
assigning balancing segment values to ledgers.
If assign balancing segment values, you limit your ledger transactions to just
those values you assigned. If you do not assign balancing segment values, then
all balancing segment values are available for journal and transaction processing.
For example, if one ledger is recording transactions for three legal entities and another
is recording transactions for two legal entities, assigning balancing segment values to
your legal entities and ledgers simplifies the list of values on journal entries and
transactions.
Balancing Segment Value Assignments to Legal Entities
 Assign values to legal entities before assigning them to the ledgers.

 Use the values to identify legal entities during transaction processing and
reporting.
 Use the values to ease accounting for your operations to regulatory agencies and
tax authorities.
Demonstration
Within your implementation project and with scope set to your ledger, navigate to the
Define Ledgers > Define Accounting Configurations > Assign Balancing Segment
Values to Legal Entities page from the Define Accounting Configurations task list in
the Setup and Maintenance work area. Click the Create icon. Select the balancing
segment value and optionally add start and end dates.
Balancing Segment Values Assignments to Ledgers
 Assign specific primary balancing segment values to the primary and secondary
ledgers to represent non-legal entity related transactions such as adjustments or
top-side entries.
 Assign each balancing segment value to a legal entity only once.
 Assign the same primary balancing segment values to more than one ledger.
Demonstration
Within your implementation project and with scope set to your ledger, navigate to the
Define Ledgers > Define Accounting Configurations > Assign Balancing Segment
Values to Ledger page from the Define Accounting Configurations task list in the
Setup and Maintenance work area. Click the Add icon. Select the balancing segment
value and optionally add start and end dates.
Balancing Segment Value Assignments Report
 Shows all primary balancing segment values assigned to legal entities and
ledgers across accounting setups.
 Ensures the completeness of your accounting configuration and the accuracy of

your assignments. Allows you to quickly identify these errors and view any
unassigned values.
Manage Reporting Currencies
Reporting currencies maintain and report subledger and general ledger journal
entries in additional currencies. Each primary and secondary ledger is defined
with a ledger currency. Reporting Currencies:
 Record your business transactions and accounting data for that ledger.
 Maintain the ledger in the currency in which the majority of its transactions are
denominated. For example, create, record, and close a transaction in the same
currency to save processing and reconciliation time.
 Meet local requirements, for example paying transaction taxes, is easier using a
local currency.
NOTE: Many countries require that one of your ledgers be kept in their national
currency. With Reporting Currencies, you are able to produce financial statements using
the national currency or alternate currencies.
Business Reasons to Use Reporting Currencies
 Useful for consolidation reporting and analysis.

 No need to physically move balances to create views of consolidation data.
 Beneficial for parent consolidation entities that share the same chart of accounts
and calendar with their subsidiaries.
Reporting Currencies Conversion Levels
A reporting currency is linked to a primary or secondary ledger, and can be maintained

at one of three data conversion levels.
 Balance level: Only general ledger balances are maintained in the reporting
currency through the Translation process.
 Journal level: General Ledger Posting process transfers the journal entries to
the reporting currency.
 Subledger level: Subledger Accounting creates the subledger journals to the

reporting currency. General Ledger converts the remaining journal entries to the
reporting currency during the Posting process.
A full accounting representation of your primary ledger is maintained at the subledger
level reporting currency. Secondary ledgers cannot use subledger level reporting
currencies.
 Balance data conversion level is typically the least expensive, requiring

duplication of only the balance level information.
 Journal and subledger data conversion levels require more storage and
processing since most general ledger and subledger journals, plus general
ledger balances are replicated.
 Do not use journal or subledger level reporting currencies if your organization
has only a need to translate your financial statements to your parent company's
currency for consolidation purposes. Standard translation functionality meets this
need.
NOTE: Instructor Demonstration Reporting Currencies.
Define Secondary Ledgers
A secondary ledger is an additional ledger linked to a primary ledger for the

purpose of tracking alternative accounting.
 Differs from its primary ledger by using a different accounting method, chart of
accounts, accounting calendar, currency, or processing options.
 Receives all or some of the journal entries processed in the primary ledger by
transfer, based on your configuration options.
Below are scenarios and required action for different components in primary and
secondary ledgers.
 If the primary and secondary ledgers use different charts of accounts, the
chart of accounts mapping is required to instruct the system how to propagate
journals from the source chart of accounts to the target chart of accounts.
 If the primary and secondary ledgers use different accounting calendars, the
accounting date is used to determine the corresponding nonadjusting period in
the secondary ledger. The date mapping table also provides the correlation
between dates and non-adjusting periods for each accounting calendar.
 If the primary ledger and secondary ledger use different ledger currencies,
currency conversion rules are required to instruct the system on how to
convert the transactions, journals, or balances from the source representation to
the secondary ledger.
NOTE: Journal conversion rules, based on the journal source and category, are
required to provide instructions on how to propagate journals and types of journals from
the source ledger to the secondary ledger.
Secondary Ledgers Conversion Levels
Secondary Ledgers use one of the four conversion levels:
 Balance Level: Transfer Balances to Secondary Ledger process transfers only

balances to the secondary ledger.
 Journal Level: General Ledger Posting process transfers the journal entries to
the secondary ledger.
 Subledger Level: Oracle Fusion Subledger Accounting creates the subledger

journals to both the primary and secondary ledger. The Posting process transfers
the remaining journal entries to the secondary ledger.
 Adjustment Only: This adjustments only secondary ledger is an incomplete
accounting representation that only holds manual or automatic adjustment
journal entries from General Ledger or Oracle Fusion Subledger Accounting. This
conversion level requires that the secondary ledgers share the same chart of
accounts, accounting calendar, and currency with its primary ledger. A complete
accounting representation is achieved by creating a report that includes both the
primary and secondary ledger data together.
NOTE: The journal and subledger data conversion levels require more processing
resources as they duplicate of most general ledger and subledger journal entries, as
well as general ledger balances.
Example
 You maintain a secondary ledger for your International Financial Reporting

Standards (IFRS) accounting requirements.
 Your primary ledger uses US Generally Accepted Accounting Principles (GAAP).
 You decided to select the subledger level for your IFRS secondary ledger.
Conclusion
 Since most of the accounting is identical between US GAAP and IFRS, a more
powerful solution is to use the adjustment only level for your secondary ledger.
Then you don't need to perform a difference comparison as all your entries are in
the adjustment ledger.
 With the adjustment only level, your secondary ledger contains only the
adjustment journal entries and balances necessary to convert your US GAAP
accounting to the IFRS accounting, which uses a fraction of the resources that
are required by full subledger level secondary ledger.
 A subledger level secondary ledger would provide more functionality than you
need in this example.
Secondary Ledgers Mapping
Navigate to the Define Secondary Ledgers page from the Define Accounting
Configurations task list in the Setup and Maintenance work area.
Creating Secondary Ledgers follows the same steps as Primary Ledger. On the
Create Secondary Ledger page select the additional option for secondary ledgers,
Data Conversion Level.
Chart of Accounts Mapping Feature
 Supports the ability to correlate a source chart of accounts to a target chart of

accounts to allow for creating journals to book general ledger entries using an
alternative chart of accounts.
 Accomplished by either using segment rules, account rules, or a combination of
both.
 Used by the posting program in propagating general ledger entries from the
primary ledger to the chart of accounts used by the secondary ledger, providing
the means to map the primary ledger chart of accounts to that of the secondary
ledger.
 Used by both balance transfer programs for balance level secondary ledgers as
well as cross ledger transfers, whereby balances from one ledger are copied to
another ledger.
Segment rules serve to map each segment of the target chart of accounts to an
account value or segment in the source account.
Three different mapping actions are available:
 Assign a constant value for a segment in the target chart of accounts.

 Copy the value from the source segment to the corresponding target segment.
 Use hierarchical roll up rules when a specific parent source value and all of its
child segment values are mapped to a given detail target segment value. This
provides the ability to process groups of source segment values in one single roll
up rule.
 Define parent source values in roll up rules with date effective versions of a
hierarchy. Then use the accounting date from the journal entries to reference the
chart of accounts mapping that falls within the date effectivity of the hierarchy.
This gives the additional benefit of self maintaining mappings since the
hierarchies referenced change with time and the applicable child values are
processed automatically.
You can also define account rules as part of a chart of accounts mapping. Account
rules map a complete target account combination against one or more source account
code combinations. The source account code combinations can be defined segment by
segment using:
 Single detail account values.

 Detail account value ranges.
 Parent values for each segment.
Review and Submit Accounting Configuration
Navigate to the Review and Submit Accounting Configuration page from the Define
Accounting Configurations task list in the Setup and Maintenance work area.
 Select your ledgers and click the Submit button.

 A green check mark in the Status column shows that your configuration is
completed and confirmed.
Balance Cubes Overview
A new standard balances cube is created when an accounting configuration is

submitted for a primary or secondary ledger that uses to a new unique
combination of chart of accounts and calendar. This occurs automatically when an
accounting configuration is submitted or secondary ledger is created after accounting
configuration was completed.
A new balances cube is also created when a secondary ledger is added to an existing
accounting configuration and uses a new unique combination of chart of accounts and
calendar. The balances cubes are named after the chart of accounts they contain.
A balances cube:
 Stores your financial balances in a multidimensional model to enable high-speed,

interactive financial reporting and analysis.
 Pre-aggregates your balances at every possible point of summarization, thus
ensuring immediate access to financial data and eliminating the need for an
external data warehouse for financial reporting.
 Is uniquely identified by the combination of a chart of accounts and an
accounting calendar. Average balances are tracked in a separate balances cube.
 Is automatically updated by the following general ledger processes: posting,
open period, and translation.
 Consists of a set of defining business entities called dimensions.
Example
 The chart of accounts InFusion Corporation has a related balances cube also
entitled, InFusion Corporation.
 If a chart of accounts is used by multiple ledgers with different calendars, the
balances cube names will be distinguished by appending a number to their
names.
 If the InFusion Corporation chart of accounts is used by two different ledgers,
each of which uses a different accounting calendar, two balances cubes are
created with the names InFusion Corporation Chart of Accounts 1 and InFusion
Corporation Chart of Accounts 2.
Balance Cube Dimensions
A balances cube consists of a set of defining business entities called

dimensions. This table details the dimensions that are available for creating financial
reports using multi-dimensional cubes.
The General Ledger Posting process updates your balances and stores these
balances in a balances cube for efficient multidimensional analysis. This provides for
efficient reporting.
NOTE: Dimensions are seeded and new ones cannot be added.
Manage Ledger Sets
Ledger Sets enable you to group multiple ledgers that share the same chart of
accounts and calendar combination to increase the efficiency of your period
close, security administration, and reporting. Essentially, Ledger Sets allow you to
treat multiple ledgers as one.
For example, you can open and close periods for multiple ledgers in a ledger set in a
single submission by submitting the new Open and Close Periods programs from the
Submit Request form.
NOTE: Instructor Demonstration Create a Ledger Set.
Defining Security
Data Access Set Security: Grants access to a ledger, ledger set, or specific primary
balancing segment values associated with a ledger. Create and edit data access set
security on the Manage Data Access Sets page from the Setup and Maintenance
work area or from your implementation project.
Segment Value Security: Controls access to value set values associated with any
segment in your chart of accounts. Create and edit segment value security on the
Define Chart of Accounts page from the Setup and Maintenance work area or your
Function and Data Security: Secures features and data with privileges that are
mapped to roles.
 Access through the Define Security from the Setup and Maintenance work
area or your implementation project.
 Use Oracle Identity Manager (OIM) to manage user and user-role assignments.
 Use Authorization Policy Manager (APM) to manage data roles and duty roles.
Defining Segment Value Security Rules
Set up segment value security rules against your value sets to control access to
parent or detail segment values.
 Securing a value set denies access to all values by default. Create conditions
and assign them to specific data roles to control access to your value set values.
 Restrict data entry, online inquiry, and reporting to specific values by using
segment value security rules.
General Points About Segment Value Security:
 Used in conjunction with flexfield segments.

 Specifies that data security be applied to segment values that use the value set.
Based on the roles provisioned to users, data security policies determine which
values of the segment end users can view or modify.
 Applies at the value set level. If a value set is secured, every usage of the value
set in the chart of accounts structure is secured. For example, if the same value
set is used for the legal entity and intercompany segments of the chart of
accounts, the same security will apply to both segments.
 Applies only to independent value sets.
 Applies mainly when data is being created or updated, and to account
combination tables for query purposes.
 Controls access to parent or detail segment values.
NOTE: A distinction between setup and transactions user interfaces is that segment
value security prevents you from seeing certain account values in setup user interfaces
but you can still see account combinations with the values. If you try to update the field,
you won't be able to use those values. For transaction, balance, and activity query user
interface, the segment value security prevents both the viewing and using of the
secured values. Segment value security control is both for Read and Write access
control.
Segment Value Security Examples
Segment value security is enforced in Oracle Fusion Applications where ever the
chart of accounts values are used.
Examples:
 When entering a journal for a ledger with a secured chart of accounts, you can
only use account values for which the access is granted using segment security
conditions and data access roles.
 When running reports against a ledger with a secured chart of accounts, you can
only view balances for accounts for which the access is granted using segment
security conditions and data access roles.
 When viewing ledger options in an accounting configuration, if the accounts
specified include references to an account with values you have not been
granted access to, you can see the account but not be able to modify the
secured values.
Create conditions and assign them to specific data roles to control access to
your segment values. For example:
 Enable security on both the cost center and account value sets that are
associated with your chart of accounts.
 Assign the General Accountant – InFusion USA data role will have access to
cost center Accounting and account US Revenue.
 Deny all other users access to all cost center and account value set values.
Segment Value Security Operators
Use any of the following operators in your conditions to secure your segment
values:
NOTE: For Is descendent of and Is last descendent of:
 Specify an account hierarchy (tree) and a tree version to use this operator.
 Notice that the security rule applies across all the tree versions of the specified
hierarchy, as well as all hierarchies associated with the value set.
Data Access Set Security
Secures access to ledgers, ledger sets, and portions of ledgers using primary
balancing segment values. If you have primary balancing segment values assigned to
a legal entity, then you can use this feature to secure access to specific legal entities
 Secures parent or detail primary balancing segment values.

 Secures the specified parent value as well as all its descendents, including mid-
level parents and detail values.
 Requires all ledgers assigned to the data access set to share the same chart of
accounts and accounting calendar.
Full Ledger Access: Access to the entire ledger or ledger sets. For example, this could
be read only access to the entire ledger or both read and write access.
Primary Balancing Segment Value: Access one or more primary balancing segment
values for that ledger. You can specify read only, read and write access, or a
combination of the two for different primary balancing segment values for different
ledgers and ledger sets.
NOTE: Security by Management segment is not available in V1.
Data Access Set Security Example
This example shows a data access set that secures access by using primary
balancing segment values which correspond to legal entities.
Scenario
 The ledger, InFusion USA Primary Ledger, is assigned to this Data Access Set.
 Read only access has been assigned to balancing segment value 131 that
represents the InFusion USA Heath LE 3.
 Read and write access has been assigned to the other two primary balancing
segment values for legal entities, InFusion USA LE 1 and 2.
In summary, you can:
 Create a Journal Batch: In ledgers or with primary balancing segment values if

you have write access.
 Modify a Journal Batch: If you have write access to all ledgers or primary
balancing segment values that are used in the batch.
 View a Journal Batch: If you have read only or write access to the ledger or
primary balancing segment values.
NOTE:
 Instructor Demonstration Data Access Set Security.

 Student Activity Data Access Set Security.
Knowledge Check: Data Access Set Security
When modifying a journal batch, you must have write access to all ledgers or
primary balancing segment values that are used in that batch.
1. True
2. False
Knowledge Check: Data Access Set Security Answer
When modifying a journal batch, you must have write access to all ledgers or
primary balancing segment values that are used in that batch.
1. True
2. False
Modify a Journal Batch: If you have write access to all ledgers or primary balancing
segment values that are used in the batch.
Function and Data Security
Functions and data are inaccessible to users unless they are provisioned with the roles
necessary to gain access.
Function Security: Consists of privileges unconditionally granted to a role and used to

control access to:
 Page or a specific widget.

 Functionality within a page, including services, regions, and flows.
Data Security: Consists of privileges conditionally granted as data security policies
carried by roles, or granted as Human Capital Management (HCM) security profiles, and
used to control access to data:
 Within a business object such as a business unit.

 Based on user profiles.
 Based on privacy policies.
For example: A job role might give view access to the functions needed to access
invoices, but a data role that inherits the job role gives limited view access to the invoice
data within a business unit, such as the data role Accounts Payable Manager - US
which inherits the job role Accounts Payable Manager for performing accounts payable
duties for the US business unit only.
Job Roles
Job Roles can be configured to:
 Access to the typical system functions assigned to the role.

 Group related and necessary actions required to manage discrete functional
areas in duty roles.
 Create roles for the organization and assign the desired duty roles.
 Create custom duty roles to fine tune access to actions within discrete functional
areas.
 Simplify setup and maintenance by building hierarchy of duty roles and job roles
NOTE: Application Implementation Consultant carries access to the general ledger

functional and technical administration features.
Assign Data Roles Overview
 Assign to your user the data role that contains the data access set your
user needs with the job role that provides the required functional access
level.
 Optionally, assign Segment Value Security Rules to data roles.
 Assigned multiple data roles to a user, if needed.
NOTE: See the Security topic in the Appendix for more information.
Secure Subledger Accounting
Oracle Fusion Subledger Accounting requires both function and data security
privileges.
Oracle Fusion Financials security for Subledger Accounting include:
Setup Task Security
 Security to integrate Oracle Fusion applications with Subledger Accounting.

 Security to determine which users can configure accounting rules.
Transactional task security
 Security to determine which users can create subledger journal entries, manual
subledger journal entries or those generated by the Create Accounting process.
 Security to determine which users can review and generate reports of subledger
journal entry headers and lines.
Subledger Journal Entry Security
In the Oracle Fusion Financials offering, use the task Define Subledger Application
and Sources from the Setup and Maintenance work area to integrate your subledger
applications with Oracle Fusion Financials.
To register subledger applications, and configure accounting rules, the setup user
needs to be provisioned with a role that includes the Oracle Fusion Financials
Administration Duty role.
 In the security reference implementation, the Financial Application Administrator

job role hierarchy includes the Oracle Fusion Financials Administration Duty role,
which provides the access to integrate your source systems with accounting
transformations.
 For more information on available setup job roles, duty roles and privileges, see
the Oracle Fusion Financials Security Reference Manual.
Security to Perform Transactional Tasks
To create and view subledger journal entries, you must have the access necessary to
perform the tasks. These tasks can be accessed from the Oracle Fusion General
Ledger, Journals work area, therefore you must have access to the work area, and the
ledgers (primary, secondary and reporting currency) in which the journal entry is posted.
You can also access the create and view subledger journal entries tasks from the
individual subledgers transaction work areas.
The following are defined in the security reference implementation:
 The General Accounting Manager job role hierarchy includes duty roles that
provide entitlement to manage your general accounting functions. This
entitlement provides access to General Ledger Journals work area.
 The General Accounting Manager data role hierarchy includes data security
policies that provide entitlement to access ledger and subledger journal entries.
Ledger access is provided through Data Access Sets.
The following duty roles need to be assigned directly to the General Accounting
Manager job role to provide access to create and view subledger journal entries:
 Subledger Accounting Duty

 Subledger Accounting Reporting Duty
Alternatively, you can assign the Subledger Accounting Duty and Subledger Accounting
Reporting Duty roles to any of the following General Ledger job roles:
 Chief Financial Officer

 Controller
 Financial Analyst
 General Accountant
Period Close
While implementing your accounting configuration, optionally define and

maintain the period close components to customize your accounting
configurations setup.
Period close components include allocations, revaluation, and historical rates. If

you use allocations, revaluation, or translation, configure the following tasks under the
Define Period Close Components parent task in your implementation project:
 Manage Allocations and Periodic Entries

 Manage Revaluations
 Manage Historical Rates
Period Close Checklist
Best practice is for each enterprise to develop a comprehensive period close

check list that includes Oracle Fusion Applications tasks and other enterprise tasks
outside Oracle Fusion Applications. The following is a sample period close checklist.
 Transfer and import data from all subledgers.

 Perform reconciliation of subsidiary ledgers.
 Close the period for each subledger.
 Perform allocations
 Revalue foreign currency balances.
 Verify all journals are posted.
 Reconcile account balances.
 Translate balances to parent's currency using period end and historical rates.
The period end rates for balance sheet and period average for the income
statement are both used.
 Consolidate subsidiary ledgers.
 Run Trial Balance and other reports.
 Close the period and open the next period.
Fusion Calculation Manager
The Hyperion Calculation Manager is used to create allocation and other formulaic
journal templates for generating periodic journal entries automatically. Allocations are
defined and generated on top of the pre-aggregated multidimensional balances in the
Balances cubes and provide the following benefits:
 Immediate real-time access to financial balances for allocations
 Accelerated performance with highly scalable allocations
 Physical allocation journal entries for auditing and posting to Fusion GL
Allocation components include: Run-Time Variables, Rules, Formulas, and Rule Sets.
These components are stored in Oracle Essbase.
The Calculation Manager provides the following features:

 Distribution of revenues or costs with recursive allocation rules
 Complex formula rules using formula component
 A graphical wizard to define allocation rules
 Real-time check of rule definitions to validate correctness of rules
 Reusable components to minimize setup and maintenance
 Simplified allocation generation mechanism via integration with Enterprise
Scheduler
 Grouping of rules in Rule Sets to cascade allocations for processing efficiencies
 Primary, statistical, or foreign currency allocation and formula rules
Allocations Rule Sets and Components
Calculation Manager provides an automated solution to flexibly distribute

revenues and costs across the enterprise or to record formulaic recurring
adjustments.
 Define rules to generate formula-based journals.

 Leverage references to pre-aggregated multidimensional balances to maximize
efficiency in executing complex calculations.
Allocation Rule Sets Structure and Components
Run-Time Prompt Variable (RTP)

Before defining a rule, the user will usually define a run-time prompt (RTP) variable. A
RTP variable is an optional component of a rule. When the user generates an
allocation based on a rule with an RTP variable, the user is prompted at run-time to
specify a dimension member for which an RTP has been defined to use in the allocation
calculation. An example of an RTP variable is Accounting_Period that prompts the user
to specify what period to use in the allocation calculation. An RTP variable can be
created once and shared across multiple rules.
Point of View
A Point of View is used to define dimension values that remain fixed throughout the
entire allocation rule. For example, assume a chart of accounts includes a segment for
future use. The Point of View fixes the value to be the default value so that the
dimension value does not have to be selected while defining the source, basis, target,
offset or allocation range.
Allocations Wizard
The Allocations wizard is a guided process to define each element of the Allocation
definition. The Source amount to be allocated can be from the balances cube or can be
a fixed amount entered in the Rule. Allocations can be distributed based on the Basis
or can be spread evenly.
Formula
Formulas can be used to define simple to complex calculations.
Rule Set
Rule Sets can be created by combining two or more related rules so that they are
launched sequentially.
Generate Allocations
To Generate the Allocation(s), you will select the Rule or Rule Set, and specify the
value(s) for any Run Time Prompt(s). The Generate Allocations process will submit four
processes consecutively (three if Post Allocations is not selected) that will calculate the
allocation, write back the results to the GL_INTERFACE table, import, and post the
batches/journals to Fusion General Ledger.
What is the equivalent Fusion Calculation Manager functionalities compared to

Release 12 E-Business Suite features?
Allocations Requirements
Complex formula definitions
 Optimally design formulas in a graphical environment with Allocation Wizard.

 Real time check of rule definitions to validate rules.
 Minimize setup and maintenance time with reusable formula components.
 Use combinations of available mathematical operators to achieve complex
calculations.
 Combine formula components to build complex allocations
Enhanced allocation formula scope and longevity
 Use the same allocation rules for similar allocations for different accounting
periods or with other determinable variants with run time prompts for accounting
period, balancing segment values, ledgers, and user-defined variables.
 Leverage hierarchy versioning with parent account values in formulas.
Optimal generation of allocations
 Leverage preaggregated multidimensional balances to maximize efficiency in

executing complex calculations.
 Integration of allocation generation mechanism with enterprise scheduler with
flexibility of generating immediately or in the future.
 Seamless process from generation to posting to reversal of allocation.
 Creation of rule sets to achieve multi-step cascading allocations.
 Audit trail for allocated amounts with well documented rules.
Step Down Allocation Example
Use Only Allocated Amounts
In this example, you allocate only the $100 that was allocated to 1A ($70) and 1B ($30),
not the actual amounts in each: 1A ($700) and 1B ($60).
Using Actual and Allocated Amounts Example
Using Actual and Allocated Amounts:
In this example, you allocate not only the $100 that was allocated to 1A ($70) and 1B
($30), but also the actual amounts in each: 1A ($700) and 1B ($60) for a total of:
 $770 for 1A
 2Aa $550
 2Ab $220
 $90 for 1B
 2Ba $75
 2B1 $15
Allocations Concepts
Allocations - Best Practices
NOTE: The following are limitations in Oracle Fusion Calculation Manager.
 Allocation rules cannot be shared across cubes in Calculation Manager.

 Within a rule or rule set, the same target or offset cannot be written to by multiple
rule components.
 An error occurs when generating allocation rules with Run Time Prompts other
than the User Point of View in an allocation rule component. Therefore, select
values for Run Time Prompts from the list of values, do not type them in.
NOTE:
 Student Activity Create An Allocation Rule.

 Student Activity Generate an Allocation
Revaluation and Translation
Revaluation: Process of adjusting the accounted value of foreign currency

denominated balances according to current conversion rates.
 Revaluation adjustments represent the difference in the value of the balance due
to changes in conversion rates between the date of the original journal entry and
the revaluation date.
 These adjustments are posted through journal entries to the underlying account
with the offset posted to an unrealized gain or loss account.
 All debit adjustments are offset against the unrealized gain account and all credit
adjustments are offset against the unrealized loss account. If the same account
is specified in the Unrealized Gain Account and Unrealized Loss Account fields,
the net of the adjustments is derived and posted.
Translation: Process of converting accounted balances from one currency to
another reporting currency.
 Run translation after you have completed all journal activity for an accounting
period.
 If you post additional journal entries or change your translation rates after running
translation for a period, you must retranslate.
Revaluation and Translation Setup
Navigate to the Manage Daily Rates task under Define Currencies and the Manage
Revaluations and Manage Historical Rates tasks under Define Period Close
Components to perform your revaluation and translation configuration.
Run Revalue Balances and Translate Balances from the Period Close work area's
task panel.
NOTE: For more information on Manage Daily Rates see the Daily Rates Overview
topic in the Financial Reporting Structures lesson.
Revaluation Overview
Prerequisites
 Define an unrealized gain/loss account.

 Define a period end rate type and create a period end rate for each currency if
required.
Running Revaluation
 Revaluation is run at the end of each accounting period as part of the close
process to revalue balance sheet accounts that are denominated in a foreign
currency in accordance with SFAS 52 (US).
 The journal is then reversed at the beginning of the next period.
 The process is repeated until the transactions are settled.
 The Realized Gain/Loss is recorded in the appropriate subledger and transferred
to the Oracle Fusion General Ledger at the time the obligation is settled.
Currencies
 Revaluation can be run for a single foreign currency or for all currencies.
 When you run revaluation, General Ledger creates a revaluation batch
containing a separate journal entry for each revalued foreign currency.
NOTE: General Ledger creates the revaluation adjustments in your ledger currency.
General Ledger will automatically define the reversal period for your Revaluation
Journals if the Category has been set to automatically reverse.
Average Balance Ledgers
 When you revalue balances in an average balance ledger, General Ledger only
revalues standard balances.
 When you post the revaluation journal entries to update your standard balances,
the system recalculates your average balances automatically.
Reporting Currencies: Under the SFAS 52 remeasurement, the temporal method

translation, it is necessary to remeasure foreign currency gains or losses recorded in
your primary ledger currency and recorded them in the reporting ledger currency.
Revaluation Example
At the end of the accounting period, the revaluation process creates an unposted
journal to record the change in the converted balances to the Unrealized Gain/Loss
Account. The journal is posted, and then reversed at the beginning of the next reporting
period. In this example:
 The original journal entry in Euro remains the same.

 At period end, the exchange rate has changed to 1.2885
 The receivable is still 10,000 Euro, but is now $12,885 US Dollars.
 The offset of $100 is recorded in the Unrealized Gain account.
Translation Overview
Running Translation
 Restates your ledger currency account balances into a reporting currency.

 Translates actual balances from ledger currency to foreign currencies for online
inquiries, reports, and consolidations.
 Supports multiple balancing segments for the Retained Earnings and Cumulative
Translation Adjustment accounts.
 Is done after you have completed all journal activity for an accounting period.
NOTE: If you post additional journal entries or change your translation rates after
running translation for a period, you must retranslate.
Historical Rates
 Weighted average rate for transactions that occur at different times.

 Used to report journal entry line amounts in the units of money that were
current when the transactions took place.
Historical rates are:
 More precise than period end rates with respect to equity accounts.
 Defined before running translation to avoid having to retranslate your
balances.
 Can stabilize the translated balances by defining fixed historical rates for long-
term accounts.
 Used with highly inflationary currencies to remeasure specific historical account
balances in accordance with United States Financial Accounting Standards
Board 8.
Consolidations
Consolidation Methods
Select the best Oracle Fusion General Ledger consolidation solution for your
enterprise:
Reporting Only Consolidations: If your subsidiaries and your corporate ledger share
the same chart of accounts and calendar.
Balance Transfer Consolidations: If your subsidiaries and your corporate ledger have
either or both different charts of accounts and different calendars.
Financial Management Consolidations: If there are complex factors in your financial

consolidation requirements such as:
 Complex company structures such as joint ventures, minority interest holdings,

partially or fully owned subsidiaries.
 Multiple heterogeneous systems including non general ledger data sources that
are required to support non-financial or industry specific metrics, disclosures, and
footnote schedules.
Reporting Only Consolidation Method
Use the Reporting Only Consolidation method and the reporting solutions listed
in the graphic with the following scenario.
 All subsidiaries and your corporate ledger share the same calendar.
 One of your subsidiaries has a local chart of accounts and local currency. This
subsidiary uses a secondary ledger to record balances in the corporate chart of
accounts and the corporate currency.
 One subsidiary has a local currency and uses reporting currency functionality to
record balances in the corporate currency.
With the Reporting Only Consolidation method, perform the following tasks:
 Group the ledgers in a ledger set. This assumes the ledgers share the same
chart of accounts and calendar.
 Translate balances to the corporate currency for ledgers not in the corporate
currency.
 Create eliminating entries.
 Report using the ledger set and the corporate currency as parameters to view the
consolidated balances.
If each entity’s ledger has a different chart of accounts or calendar from the corporate
chart of accounts and calendar, a secondary ledger would need to be maintained that
conforms to the common chart of accounts and calendar so that this could be included
in the consolidation ledger set.
Balance Transfer Consolidation Method
If multiple subsidiaries and the corporate ledger do not share the same chart of
accounts and calendar, use the Balance Transfer Consolidation method and the
reporting solutions listed in the graphic.
 Translate balances to the corporate currency for ledgers not in the corporate
currency.
 Create a chart of accounts mapping to map subsidiaries account values to the
corporate chart of accounts.
 Transfer balances from the subsidiaries to the corporate consolidation ledger
using. Run the Balance Transfer process using the cross ledger version which
transfers between any source and target ledger pair or the Balance Transfer
process for Balance Level secondary ledgers.
 Create eliminating entries using journal entries or the Calculation Manager in
the corporate consolidation ledger.
 Generate a report on the consolidated balances net of eliminations in the
corporate consolidation ledger.
Reporting Only Versus Balance Transfer
Here are pros and cons comparing the Reporting Only Consolidation method
versus the Balance Transfer Consolidation method.
Reporting Only Consolidation Pros:
 No need to run additional processes to consolidate unless ledgers have a

different currency than the consolidation currency.
 View the consolidated balances anytime. This cannot be done in the Balance
Transfer Consolidation method because that method requires a balance transfer
be done to achieve consolidation.
 Faster close.
When reviewing balances that use either consolidation method, verify that the
translation to the consolidation currency is current.
Reporting Only Consolidation Cons: Requires a standardized chart of accounts

and calendar for the subsidiaries and corporate ledgers in order to group ledgers
into ledger sets.
Balance Transfer Consolidation Pros: Do not require a standardized chart of

accounts and calendar.
Balance Transfer Conduction Cons:
 May require an additional consolidation ledger to maintain balances or the

current parent ledger can serve as the consolidation ledger. You can use your
parent ledger and just transfer the subsidiary balances directly into that ledger.
 Need to run balance translation process if the currency is different from the
consolidation currency .Then run the transfer processes to view the consolidated
balances.
 Maintain charts of accounts mappings, which can be a labor intensive.
 Outdated balance transfers have to be reversed and posted, then new balance
transfer ran every time the source ledger's balance changes. Also requires
translation to be run again if ledger currency is different than consolidation
currency.
Elimination Entries
Example: The formula to enter a fully reciprocating elimination entry for intercompany
receivables and payables accounts for all subsidiaries of parent company (All Company
Values) to company 95 (Elimination Company) is represented in the following table.
 Select PTD (period to date) balances as the period activity for intercompany
income statement accounts, such as intercompany sales and cost of goods sold.
 If the eliminating intercompany balance sheet accounts such as intercompany
receivables and payables, reverse prior eliminations and use YTD (year to date)
balances as the period activity.
This example shows eliminating balances from the source across all balancing
segments, in this case company values 0 to 90, into a single target balancing
segment with a company value of 95. The offset is to an intercompany clearing
account.
With Oracle Fusion General Ledger functionality, you can:
 Perform other types of eliminations that are not based on fully reciprocal
eliminating accounts.
 Apply formulas using math operators and variables, such as percentages, to
calculate the elimination amounts as needed.
 Write elimination entries using the Calculation Manager.
Consolidation Example
Your company, InFusion Corporation needs to consolidate across its entities

worldwide using the Reporting Only Consolidation Method. InFusion Corporation
has four entities:
 InFusion USA
 InFusion Canada
 InFusion UK
 InFusion Germany
The four entities have different charts of accounts, calendars and currencies.
InFusion Corporation uses secondary ledgers and reporting currencies to align all
ledgers to the corporate chart of accounts, calendar, and currency. The InFusion
Corporate ledger is an elimination ledger to hold the elimination entries. Financial
Reporting functionally is used to create the consolidation reports.
Reporting Consolidation with Multiple Levels
The InFusion Corporation consolidation happens at two levels.
Level One
InFusion North America elimination ledger is used to record elimination entries

between InFusion USA and InFusion Canada. A ledger set has been created for the
three ledgers to enable creation of consolidation reports in Financial Reporting.
InFusion EMEA elimination ledger is used to record elimination entries between

InFusion UK and InFusion Germany. A ledger set has been created for the three
ledgers to enable creation of consolidation reports in Financial Reporting.
Level Two
InFusion Corporate elimination ledger is used to record elimination entries between all
four entities. A ledger set has been created for the five ledgers to enable creation of
consolidation reports in Financial Reporting.
Elimination Level One Example

 The arrows represent the business transactions occurring between the entities.
 The balances need to be eliminated in the consolidation are between entities
within each ledger set.
 The eliminations are accomplished using the Calculation Manager by creating
allocation rules.
 The elimination adjustments are recorded in an elimination ledger.
Transaction: InFusion USA pays InFusion Canada 10,000 USD for copper wiring.
InFusion North America Elimination Entry
Transaction: InFusion UK pays InFusion Germany 5,000 EUR for manufactured

technical components.
InFusion EMEA Elimination Entry
Elimination Level Two Example
The following are transactions recorded in the InFusion entities ledgers that
require elimination entries in the InFusion Corporate elimination ledger during
consolidation.
Transaction one InFusion USA pays InFusion Canada 10,000 USD for office rental
expense.
Transaction two InFusion UK pays InFusion Germany 5,000 EUR for

manufactured technical components.
Transaction three InFusion Germany pays InFusion USA 20,000 USD for high
technical products.
Transaction four InFusion Canada pays InFusion UK 15,000 USD for copper rolls.
Elimination Level Two Example Part II

The elimination entries below are based on the previous page of cross ledger
transactions. At different levels of the consolidation, certain intercompany payables
and receivables balances have not been eliminated yet Eliminations are only required in
the context of a consolidation where the trading parties are both included in a given
consolidation.
 The arrows represent the business transactions occurring between the entities.
 The balances need to be eliminated in the consolidation.
 The eliminations are accomplished using the Calculation Manager by creating
allocation rules.
 The elimination adjustments are written into an elimination ledger.
InFusion Corporation Elimination Entries
*(5,000 EUR 1.577 conversion rate to USD)
Consolidation Report
Financial Management Integration Option

The Oracle Fusion General Ledger includes integration to Oracle Hyperion
Financial Management, Fusion Edition through the Enterprise Resource Planning
(ERP) Integrator.
For complex consolidation requirements: Use the integration to bring general ledger
balances from the Oracle Fusion General Ledger to Oracle Hyperion Financial
Management, Fusion Edition and perform advanced consolidation in Oracle Hyperion
Financial Management, Fusion Edition.
Functionality includes drill through from Oracle Hyperion Financial Management,

Fusion Edition to the Oracle Fusion General Ledger balances.
Perform the following tasks to implement this option:
 Map chart of account values and hierarchies from the Oracle Fusion General
Ledger to the Oracle Hyperion Financial Management, Fusion Edition
dimensions.
 Load data from the general ledger balances table to Oracle Fusion Financial
Management, Fusion Edition after performing the Oracle Fusion Account Hub
chart of accounts to Oracle Hyperion Financial Management chart of accounts
transformations.
 Perform advanced consolidation in Oracle Hyperion Financial Management,
Fusion Edition.
 Drill through from Oracle Hyperion Financial Management, Fusion Edition to the
Oracle Fusion General Ledger balances stored in the general ledger balances
table.
Mapping Segments to Financial Management

Dimensions
When integrating with Oracle Hyperion Financial Management, Fusion Edition,
you can use the following dimensions for consolidation. Map one to one or
concatenate segments into a single Oracle Hyperion Financial Management, Fusion
Edition dimension.
Data will be summarized across segments that are not mapped to Oracle Hyperion
Financial Management, Fusion Edition dimensions.
In this example:
 Company is mapped to Entity.

 Department and Location are concatenated and mapped to Department
 Account and Sub-Account are concatenated and mapped to account

 Product is mapped to Product.
 Program is not mapped and its data will be summarized.
Configure ERP Integrator
The following are the implementation steps that need to be performed to use the Oracle
Hyperion Financial Data Quality Management ERP Integration Adapter.
Refer to Oracle Hyperion Financial Data Quality Management ERP Integration

Adapter for Oracle Applications Administrator’s Guide for more details on how to
set up the ERP Integrator to integrate with Hyperion Financial Management.
Accounting Periods Overview
For all ledgers, primary, secondary, and journal and subledger level reporting
currencies, open the first period of the ledger when you are ready to transact.
1. To open the first period of your ledgers, navigate to the Open First Period task
in the Define Ledger task list from the Setup and Maintenance work area or your
2. On the submission page, select the ledger and the period to open.
3. Click the Submit button to launch the open period process.
There are other ways to open the first period or subsequent periods without going into
the Setup and Maintenance work area. You can maintain the ledgers' period statuses
from the:
 Close Status region in the General Accounting dashboard. The Close Status
region provides real time visibility into the period close process from your
subledgers to your General Ledger across the entire enterprise.
 Manage Accounting Periods task in the Period Close work area.
 Process Monitoring work area, which provides a framework for launching,
monitoring, and maintaining processes across Oracle Fusion Financials.
NOTE: For more information on calendars, see the Manage an Accounting Calendar
topic earlier in this lesson.
Accounting Period Statuses
Accounting Period Statuses:
 Open: Open period to enter and post journals. An unlimited number of periods
can be open, but doing so may slow the posting process and can confuse users
entering journals.
 Closed: Close periods after finishing your month-end processing. Reopen closed
periods before you can post journals.
 Permanently Closed: Permanently close periods before archiving and purging
data. Permanently closed periods cannot be reopened.
 Future Enterable: Set to Future Enterable status to enter and import journals
before opening the next periods. Journal cannot be post in a Future Enterable
period. Specify a numerical value in the Specify Ledger Options to permit
entering journals but not posting them in future periods. You can change the
number of Future Enterable periods at any time.
 Never Opened: The application sets all new periods to Never Opened until you
change the status.
Period Close with Oracle Fusion Financials
Manage period close better with monitors to gauge various aspects of the period
close:
Close Status Monitor
Navigator > Period Close
Single Ledger View
 Focus on a single ledgers’ period status by Oracle Fusion General Ledger and
subledger for the period.
 Details for partially closed subledger periods.
 Review subledger business units and asset books for the ledger.
 Drill to period status details of that ledger for all periods.
 Convenient navigation to submit open and close period processes after status
review for General Ledger and subledgers.
Ledger Set View
 Summary view of period status across multiple ledgers in a ledger set.

 Matrix of General Ledger and subledger period status for each ledger.
Period Close Best Practices
Knowledge Check: Open and Close Periods
You cannot open and close periods for multiple ledgers in a ledger set in a single
submission.
 True
 False
Knowledge Check: Open and Close Periods Answer
You cannot open and close periods for multiple ledgers in a ledger set in a single
submission.
 True
 False
The correct answer is you can open and close periods for multiple ledgers in a ledger
set in a single submission by selecting the Open or Close button on the Manage
Accounting Periods from the Period Close work area.
Financial Reporting
Oracle Fusion Financials
 Offers state of the art reporting and analytics capabilities.

 Includes embedded multi-dimensional cubes. Multi-dimensional balances are
seamlessly embedded within Oracle Fusion General Ledger.
 Performs multi-dimensional analysis and pivot with drill down to general
ledgers and Oracle subledger transactions from Financial Reporting, Smart
View, Account Monitor, and Account Inspector.
 Maintains balances in a multi-dimensional data model with a single posting
process for consistent, timely, and accurate information for all users.
 Integrates with various reporting tools, such as Oracle Hyperion Financial

Reporting Studio, Fusion Edition, Oracle Business Transactional Business
Intelligence, and Oracle Business Intelligence Publisher, all working off the same
source of truth so your users are on the same page. You can drill down from any
of the live reports to the underlying journal and transaction detail.
 Provides secure and self-service access to reports using real-time accounting
information.
Financial Reporting Center Components
The Financial Reporting Center provides:
 Single point of entry for all financial reporting functions.

 Tools to create and format financial reporting including Financial Reporting
Studio and Workspace.
 Live and interactive Financial Reporting with multiple output options including
HTML, PDF, Excel, or Excel in Query Ready mode using Smart View Enabled
format.
 Self-service reporting and analytics against real-time data and the ability to
expand parent values to view the next level in the hierarchy within the reports
using Oracle Fusion Financials preaggregated balances.
 Drill down to underlying journals and subledger transactions with the Account
Inspector.
 Multiple reporting methods for ad-hoc analysis, efficient monitoring, and tracking
of key account balances in real-time with the Account Monitor.
NOTE: Student Activity View a Financial Report in HTML.
Create Financial Reports
You can design traditional financial report formats such as balance sheets, profit
and loss statements, and cash flow reports. You can also design nontraditional
reports for financial or analytic data that include text and graphics.
Use Financial Reporting Studio which is a client based application and is

launched from your desktop to create your reports.
The information used to create financial reports is stored in Oracle Essbase. in

Oracle Fusion General Ledger balances cubes. This table details the dimensions
that are available for creating financial reports using multi-dimensional balances cubes.
Financial Reporting Studio Features
Financial Reporting Studio enables report authors to use an object-oriented

graphical report layout with report objects, such as text boxes, grids, images, and
charts, to design reports.
Financial Reporting Studio supports the following functionality:
 Client based report definition tool.

 Object based reporting. Objects are reusable across multiple reports.
 Drag and drop report grids.
 Insert additional report objects such as text boxes, images, and charts.
 Drag and drop dimension to the report grid. Each dimension can only be in one
location on report: Row, column, page, or Point of View (POV).
 Insert rows and columns including data, formula, and text.
 Select dimension member using member selection or functions.
 Add calculations or mathematical functions.
Account Monitor Features
Financial analysts monitor and track key account balances in real time at every
level of your dimensions and hierarchies. The Account Monitor provides the
following capabilities:
 Proactive monitoring of your critical balances.

 User-configurable rules and thresholds.
 Alerts you to account balances that exceed thresholds.
 Supports year over year, quarter to quarter, and period to period actual versus
budget comparisons.
 Embedded intelligence built-in to assess the change such as favorable versus
unfavorable variances.
 Drill from Account Monitor to view break down of balances for each child value
that rolls up to the parent value.
Account Inspector Features
The Account Inspector works off the same multidimensional analytic cube which
has preaggregated balances at every level so queries are in real time. The live,
preaggregated data allows you to change your query criteria and instantly refresh
your results.
The Account Inspector does the following:
 Perform ad hoc balance queries using the Account Inspector.

 Perform multi-dimensional analysis, slicing and dicing of information, and pivoting
within a web page.
 Specify your query criteria, such as your ledger and chart of accounts
dimensions, and then expand on any parent value to get a breakdown by each
child value that rolls up to the parent value.
 Drag and drop the page level dimensions to further slice and dice results for
further analysis.
 Move dimensions from page to row or column to obtain different views of your
data.
NOTE: Student Activity Configure an Account Group.
Smart View Features
Smart View is a multi-dimensional pivot analysis tool combined with full Excel
functionality. Smart View enables you to interactively analyze your balances and
define report using a familiar spreadsheet environment.
Smart View supports the following functionality:
 Drag and drop dimensions to row, column or page.

 Perform multi-dimensional analysis, pivoting, and drill down.
 Drill from any parent to the next parent level within Excel.
 From detail account level, user can drill to detail balances, journal lines, and
subledger transactions.
 Utilize Excel’s built in features including calculations and graphs.
 Save reports and queries offline, then reconnect to live data by accessing the
spreadsheet.
 E-mail the spreadsheet to distribute reports.
Configure Smart View
Smart View is an Excel add-in that must be loaded to each client. Users need to
download the installation files in Workspace from Navigator > Tools > Download
Desktop Integrator Installer and select to install Smart View.
NOTE: Since Smart View is an add-in to Microsoft Office products, you can install
Smart View only on Windows operating system. Once Smart View is installed, it must
be configured to connect to Oracle Fusion Applications. Obtain the Smart View Shared
Connections URL information from your system administrator and enter it in Microsoft
Excel using the following navigation path: Smart View -> Options -> Advanced ->
Shared Connections URL.
For more information on configuring Smart View client for users, see the following:
 Oracle Hyperion Enterprise Performance Management System Installation

and Configuration Guide, for Oracle Hyperion Enterprise Performance
Management, especially the Installing Smart View topic.
 Oracle Hyperion Smart View for Office, Fusion Edition User's Guide for
Oracle Hyperion Smart View.
Oracle Transactional Business Intelligence
With Oracle Transaction Business Intelligence, you can:
 Perform ad hoc queries on operational data without technical support's

assistance.
 Define your own queries by modifying predefined reports and using predefined
business views.
 Drill down to supporting journals and transactions for increased visibility to
information.
 Reconcile accounts. For example, reconcile receivables and liability accounts in
the entire ledger at once by running the reports for a ledger, or reconcile by
individual primary balancing segment values within the ledger. NOTE: This
assumes your primary balancing segment values are mapped to your business
units.
Budgeting and the Oracle Fusion Accounting Hub
Budgeting preparation can be done with:
 Oracle Hyperion Planning, Fusion Edition

 Third party budgeting system
 Spreadsheet entry
Oracle Fusion Accounting Hub provides budget reporting capabilities through its
reporting tools.
 Manage value sets.

 Define chart of accounts components.
 Manage and publish account hierarchies.
 Maintain segment values
 Manage cross-validation rules.
 Create account combinations.
 Manage chart of accounts mappings.
 Define calendars.
 Manage currencies.
 Define ledgers.
 Consolidate financial results.
 Open and close periods.
 Perform financial analysis and reporting.
Lesson 5: Configuring Oracle Fusion Subledger Accounting
Lesson 5: Configuring Oracle Fusion Subledger

Accounting
Manage Oracle Fusion Subledger Accounting Configuration, which includes:
 Define subledger accounting rules.

 Generate accounting event and subledger transactions.
 Review subledger transactions.
Manage Subledger Accounting Overview
In the Oracle Fusion Subledger Accounting offering, you can generate journal
entries for Oracle Fusion subledger transactions, create adjustment entries, and
review accounting results using a standard set of features.
You can:
 Create accounting entries online for a specific transaction from a transaction

view.
 Create accounting for a batch of transactions by submitting an offline process.
 Create manual adjustment entries.
 Review generated journal entries and projected balances on views and reports.
Accounting Methods Overview
Accounting methods group subledger journal entry rule sets together to define a
consistent accounting treatment across all accounting event classes and
accounting event types for all source systems.
NOTE: Additional information on Subledger Accounting Rules is provided in this

lesson.
Create Accounting Process Overview
The Create Accounting process uses the accounting method definition with active
journal entry rule set assignments to create subledger journal entries. The accounting
method must be completed, by activating its journal entry rule set assignments, so that
it can be used to create accounting.
The following figure illustrates the process used to create subledger journal entries.
NOTE: Additional information on the Create Accounting process is provided in this

lesson.
Manage Subledger Applications and Sources
The Define Subledger Application and Sources task list is primarily utilized during
development to define the Oracle Fusion subledgers, and complete the required setups.
You can also utilize this task list if your implementation requires integration with
additional nonOracle source systems.
There are predefined rules that will be sufficient to create subledger accounting entries.
If you require additional subledger accounting entries you can create additional rules,
such as special entry descriptions, containing certain attributes, or complex account
rules that do not use the distribution accounts on transactions.
Accounting Event Model Example
The accounting event model is predefined for Oracle Fusion subledgers.
The following is an example of an accounting event model for a nonOracle loan

application:
Process Category
A process category consists of specific event classes and the event types within those
classes. To restrict the events selected for accounting, users can select a process
category when they submit the Create Accounting process. This may be useful for
segmenting events due to processing volumes.
Accounting Event Classes
An accounting event class categorizes transaction types and groups event types for
accounting rules.
Accounting Event Type
An accounting event type represents a business operation that may have an accounting
impact.
For accounting event types, specify whether their accounting events have accounting
impact. When the Create Accounting process is submitted, it only accounts business
events that are enabled for accounting.
NOTE: Reference the individual subledger lesson for a list of subledger specific event
classes.
Manage Subledger Accounting Rules
Begin configuring the Oracle Financials offering from the Setup and Maintenance
work area.
Define Subledger Accounting Rules Task List:
Navigation: Home page > Navigator > Tools > Setup and Maintenance > Manage
Implementation Projects > XXImplementation Project.
Expand your specific product task list to access the Define Subledger Accounting
Rules task list.
This graphic displays the tasks to complete to set up Oracle Fusion Subledger
Accounting for your product.
During implementation, when defining Configure Offerings, you can determine the task
lists and tasks that are included. You can include either the Manage Subledger
Accounting Method task list or the Maintain Subledger Application and Accounting
Method task list in your offering.
NOTE: See the Configuring Oracle Fusion Subledger Accounting lesson for
additional information on the Define Subledger Accounting Methods task.
NOTE: See the Oracle Fusion Financials Implementation guide for additional
information on Maintain Subledger Application and Accounting Method.
Manage Accounting Methods
Accounting methods group subledger journal entry rule sets together to define a
consistent accounting treatment across all accounting event classes and
accounting event types for all subledger applications.
Each ledger that is fed by subledger accounting is assigned an accounting method.
By assigning different accounting methods to related primary and secondary ledgers,

you can generate multiple alternate accounting representations for a single set of
subledger transactions. This method may use more system resources, as a large
amount of data will be generated. The chart of account or balances level would be
preferable.
Accounting rules can be defined with either a top down, or a bottom up approach.
 When defining subledger accounting rules from the top down, you will initially
define the accounting method followed by components of each rule, which will
need to be assigned to it.
 When defining subledger accounting rules from the bottom up, you will initially
define components for each rule and then assign them as required.
The Create Accounting process uses the accounting method definition with active
journal entry rule set assignments to create subledger journal entries. The accounting
method must be completed, by activating its journal entry rule set assignments, so that
it can be used to create accounting.
Assignment of Accounting Methods to Ledgers
 If the accounting method has a chart of accounts, it may only be used by ledgers
that use the same chart of accounts.
 If the accounting method does not have a chart of accounts, the accounting
method can be assigned to any ledger.
Accounting Methods Best Practices
You can maintain a history of journal entry rule set assignments in an accounting
method, as well as make rule changes that can date effectively scheduled.
Over time, as the accounting rules change, instead of deleting assignments and
replacing new ones, you can end date the existing assignments and add new ones with
effective start dates.
For example, if there is a change of accounting policies which is effective as of 01-Jan-

12, then the rule administrator can create and test accounting rules which reflect the
new policy in 31-Dec-11, and schedule them to come into effect on the 01-Jan-12.
Transactions with an event date of December, 2011 will be accounted using the original
accounting rules, transactions with an event date in January, 2012 or later will be
accounted using the new accounting rules. This will occur even if transactions with an
event date in December, 2011 are processed at the beginning of January, 2012.
Manage Subledger Journal Entry Rule Sets
A subledger journal entry rule set is a collection of rules that will generate a
complete journal entry for an accounting event. Select the option to define the
subledger journal entry rule set for a particular accounting event class or
accounting event type.
Subledger accounting methods are assigned to ledgers. If you are using multiple
accounting representations to meet divergent accounting requirements, you will assign
different accounting methods to the primary and secondary ledgers defined in a single
accounting configuration.
The following are the components of a subledger journal entry rule set:
 Description rules
 Journal line rules
 Account rules
 Supporting references
How the Different Types of Rules Fit Together
After the accounting rules are all defined, you assign them to a particular event class or
type to determine how a balanced journal entry will be generated for that event class or
type.
This construct is called a journal entry rule set, which determines:
 The debit and credit lines to be generated.

 The accounts to be used.
 How to determine the accounting date
 The descriptions to stamp on the entries.
 The supporting references to capture on the entries.
Journal line rules and corresponding account rules are mandatory to be able to
generate an entry.
You can define multiple subledger journal entry rule sets for an accounting event class
or accounting event type. A single journal entry is generated per accounting event per
ledger using the line assignments from the journal entry rule set assigned to the
accounting event class or accounting event type.
Journal Header and Line Level Accounting Rules
Header assignments define subledger journal header information and subledger

journal line assignments define journal line accounting treatment.
Subledger journal header level attributes:
 Accounting date (required).

 Accrual reversal accounting date (optional).
 Description rule (optional).
 Supporting references (optional).
Subledger journal line level attributes:
The following can be assigned to a subledger journal entry line:
 Journal header description rule (optional).

 Journal line rule (required).
 Account rule (required).
 Journal line description rule (optional).
 Supporting references (optional).
Subledger Journal Entry Rule Set Example
This is an example of a journal entry for a sample mortgage loan application.
A journal entry rule set is a collection of rules. As a whole, these rules are used to
create balanced journal entries for a given event type.
Each rule creates a part of the entry.
 Journal line rules determine that the Loan Receivable Debit and Cash Credit
journal lines are generated by the Create Accounting process.
 One or more account rules determine that the Loan Receivable journal line
uses the 01.9100010.100 account combination, and the Cash journal line uses
the 01.7000010.000 account.
 One or more description rules determines the journal header Description and
the journal line Description values
Subledger Journal Entry Rule Sets Implementation Notes
Rules can be used in a specific journal entry rule set when there is:
Compatibility in source assignment to event class
If the rules, with the exception of supporting references, are defined with sources, all
sources must have been assigned to the same event class that is associated to the
journal entry rule set. A supporting reference can only be used on a journal entry rule
set if it is defined with a source from the event class of that journal entry rule set.
Supporting references or description rules defined with line level sources can only be
used on journal lines. Supporting references and description rules that are assigned
with source assignments at the header level can be assigned to journal entry header or
journal lines.
Compatibility in Chart of Accounts
If the journal entry rule set is defined with a chart of accounts, then any account rule to
be used in the journal entry rule set must be for the same chart of accounts or be chart
of accounts independent.
Manage Journal Line Rules
The journal line rule determines how each debit and credit entry will be created. It
defines:
 Accounting class.
 Side as debit, credit or gain or loss.
 Sources that will drive the values on the entry, such as amount. Accounting
attributes link sources to specific journal entry line values such as the accounted
amount.
 Advanced set up features, such as business flows and summarization options.
Characteristics of journal line rules are as follows:
 Are defined within the context of accounting event classes.

 Can be used in a subledger journal entry rule sets that have the same event
class.
 Can contain conditions that determine when they will be used to create a line.
 Are assigned to journal entry rule sets.
To create a journal line rule, select values for options such as:
Side (Debit, Credit, Gain or Loss)
For example, to create a journal line rule to capture the collection of cash, you could
create a Debit line.
Merge Matching Lines
To summarize subledger journal entry lines within each subledger entry. Lines are only
merged if they share the same account combination, description, supporting reference
values, and accounting class.
Accounting Class
To classify journal entry lines. For example, a line used to record the collection of cash
would typically have an accounting class of Asset.
Conditions
Conditions are used to restrict the use of a journal line rule by controlling when a
particular journal line rule is used by the Create Accounting process. For example,
generate a freight expense line if there are freight charges. Or generate a tax line if
there is tax associated with a transaction. The journal line is only created if the
conditions evaluate to true.
Accounting Attributes
When creating a journal line rule, accounting attribute assignments are automatically
established based on the default accounting attribute assignments for that journal line
rule's accounting event class. You can override this default mapping of standard
sources to accounting attributes. The list of values for the source override includes all
sources assigned to the accounting attribute for the event class associated with the
journal line rule.
NOTE: Refer to the Oracle Fusion Applications Financials Implementation Guide

for more information on Journal Line Rule advanced options.
Journal Line Rules Implementation Notes
Defining Conditions
You may set conditions to specify whether the journal line rule will be used to
create a subledger journal entry line. If the conditions are true, the line rule is
used to create a subledger journal entry line. You can use sources to create these
conditions.
For example, you can set up a condition that will create a journal line to record tax, only
if there is tax for an invoice. The line type and account class mentioned here are
examples of sources.
The condition for an invoice tax journal line rule could be:
 Where Amount Type = Tax

 When this condition is true, there is tax for an invoice line. A journal entry line is
created to record the accounting impact of the tax.
Another example is a condition that creates a journal line for freight when there are
freight charges on an invoice.
Journal line rule conditions determine whether a journal line rule and its associated
account rules and description rules, are used to create the subledger journal entry line.
NOTE: Constant values that are used in any Conditions region must not contain the
following characters:
 "
 ,
 &
 |
 (
 )
 '
For example, in the condition "Project Type" = ABC (123), the constant value following
the equal sign, ABC (123), contains restricted characters ( ) that enclose 123 and is
invalid.
The conditions region is available for:
 Journal Line Rules

 Account Rules
 Description Rules
Manage Mapping Sets
Mapping sets are used to map input source values to specific output values.
A mapping set can have a segment, account, or a value set as the output. The output
values of a mapping set are used by account rules to derive account combinations or
segment values. For example, a mapping set can be created that determines the cost
center based upon the salesperson associated with each order.
Mapping sets allow the mapping of input source values, or transaction attribute values,
to account combinations or segment values.
Using mapping sets can simplify the data entry process when creating account rules
because you don't have to specify conditional logic. You are simply determining a
source value and then mapping it to a chart of accounts combination or value. Use
conditions on account rule policies when there is a need to specify multiple clauses or
steps to determine an account. A condition is ideal when you need to determine
whether a source has a value, and whether that value is greater or less than another
value.
For example, instead of defining an account rule with multiple priorities, each for a
different account combination based on a transaction attribute, you can use a mapping
set. In the mapping set you map each transaction attribute value to an account
combination, and use this mapping set in a single priority based, simple account rule.
The mapping set maintenance will be simpler than that of the account rule, as you can
use a mapping set in account rules that are each defined for a different chart of
accounts. Within the same mapping set, you can define the transaction attribute
mappings for accounts across different charts maintenance costs.
Mapping Sets Implementation Notes
You can define a mapping set when you have a matrix of input values that produce
distinct output values.
A mapping set definition includes the sources that will supply the input values, and the
mappings of the input values to output values.
The mappings section displays how input values are mapped to output values.
A mapping set can be defined to derive a value for an account combination, a particular
segment value, or a value from a value set.
A mapping set can be defined to return values based upon a value set rather than
directly to a chart of accounts. When this is done, the mapping set can be reused
across any chart of accounts that uses that value set.
Mapping Sets Best Practices
Use mapping sets when the conditions are simple, but they are all based upon
the same logic.
Simple condition example:
 If salesperson = Joe use 100.

 If salesperson = Linda use 200.
This is a simple condition, but it can go on and on.
Complex condition conceptual example (not in condition format):
 If salesperson is Joe AND the transaction date is after 01-Jan OR the transaction
amount <100.
This is an example of a complex condition, where mapping sets are not appropriate.
Manage Account Rules
Account rules are used to determine the accounts for subledger journal entry
lines. You can define account rules for an account, segment, or value set.
You can specify the conditions under which these rules apply. Using these capabilities,
you can develop complex rules for defining accounts under different circumstances to
meet your specific requirements.
Account Rules by Account
Define account rules by account to determine the entire account combination.
Account Rules by Segment
Define segment rules to derive a specific segment of the general ledger account. A
single account combination can be derived from a combination of segment and account
based rules.
Segment specific rules are used, where they are defined, and take the remaining values
from an account based rule. For example, you can select an account rule which is for all
segments and also separately select a rule which is for one particular segment.
Segment specific rules take precedence over the account rule by account.
If the segment rule has conditions associated with the priorities and none of the
conditions are met, no override occurs and therefore, the segment value is derived from
the account rule.
NOTE:
 If the returned account is end dated with a date that is the same or before the
subledger journal entry accounting date and an alternate account is defined in
Oracle Fusion General Ledger, an alternate account is used. The original
account is stored on the journal line for audit purposes.
 If the alternate account is invalid, and the Post Invalid Accounts to Suspense
Account option is selected in the Create Accounting process, then a suspense
account is used. An error message is displayed if a valid suspense account is not
available.
Account Rules by Value Sets
If desired, you may define account rules based upon value sets rather than chart of
accounts. This enables you to share the same rule between more than one chart of
accounts if the segments in these charts of accounts share the same value set.
Account Rules and Mapping Sets
Mapping sets can be used to associate specific source values with segment values.
You can use mapping sets in account rules to build the account.
Account Rules Conditions
In the account rule you may specify conditions for each rule detail line. Priorities
determine the order in which account rule conditions are examined. When the condition
is met, the rule associated with that priority is used. Depending on which of the defined
conditions is met, a different account rule detail is employed to create the account. The
Create Accounting process evaluates conditions based on the priority of the rule
detail. When the condition is met, the rule detail is applied.
Account Rules Implementation Notes
You can create account rules that directly specify chart of accounts values rather than
taking the values from a transaction object.
You can define an account combination by using several different account rules to
determine each segment value. Each of those segment based rules could use different
transaction and reference information to determine the segment value.
For example:
 The cost center could be derived from the salesperson's line of business.
 The company value could be based upon the legal entity of the operations.
 The subaccount could be based upon the product sold plus the discount terms.
 Any number of variations of these examples is possible.
 As more transaction and reference information is made available from the source
applications, account rule logic becomes more robust.
Account Rules Best Practices
Defining Account Rule with Conditions Example
The following examples illustrate defining an account rule with a condition.
Example 1: Custom Real Estate Application Account Rule Condition Example
This is an example to define an account rule for assignment for a loan journal line. The
account rule has two priorities, a mapping set and a constant.
The first priority will create an output for an account based on the mapping set rule
definition.
A condition is created on the first priority rule. This rule will only be used if the condition
below is met.
 The condition is Credit Status must not be null.

 The accounts derived from the mapping set rule will be used if the Credit Status
has a valid value. Otherwise, the accounts derived from the entered constants
value from the second priority will be
used.
The following describes the setup of the condition on the first priority:
("Credit Status" is not null)
The second priority will create an output from a constant value

(101.10.15150.000.000.000). There is no condition associated with the second priority.
When no condition is present, the priority is automatically used.
Example 2: Capital Purchase Account Rule Condition Example
This is an example of a rule for a capital purchase that could be booked from a system
used to record assets. The rule is to be applied only if the Asset Location is the same as
the Liability Account Cost Center and the Asset Tracking option is Yes.
This condition can be expressed as:
Where Asset Location = Liability Cost Center and Asset Tracking option = Yes
The following describes the setup of the condition:
Condition:
("Distribution Account"."Cost Center"="Liability Account."Cost

Center")'AND'("Asset Flag"=Yes)
Condition content field definitions:
Source = Asset Location

Segment = Cost Center
Value = Liability Account
Segment = Cost Center
Source = Asset Flag
Value = Yes
The following two rows of data are used in the accounting event, to which the account
rule and condition applies.
Account Rule Condition Example: Accounting Event Data
In the example above, assume the cost center segment is the second segment. When
the account rule with this condition is used to derive the account for the transaction, the
account rule is applied to derive the account of Invoice 1 only. For Invoice 2, even
though the assets tracking option is set to Yes, the cost center for the Distribution
account and Liability account are not the same. Both conditions must be met in order for
the rule to apply.
NOTE: When an account source is selected or entered, you must also select or enter a
specific segment. If an entire account is required to be used in the condition instead of a
specific segment, then select or enter All as the segment for the account.
Manage Description Rules
Use descriptions rules to define the elements of a description that appears on the
subledger journal entry at the header and/or the line. The definition determines
both the content and sequence in which the elements of the description appear.
You can assign conditions to a description rule to determine that the description is
selected for display if the condition is satisfied. The conditions are associated with
priorities like account rules.
A description rule can be defined with combinations of source and literal values. If
sources are used in the rule, the accounting event class associated with the sources
determines in which subledger journal entry rule set the description rule can be selected
and used.
Build descriptions using the available sources for the application.
For example, the following are description details that have been entered, using a
literal and a source:
 Complete Description: Loan Origination Date = Origination Date

 Which consists of a literal: "Loan Origination Date = "
 And a source: Origination Date
Assuming that the source value of the origination date is "01-Nov-2015", then a journal
entry that has the above description rule attached will have the description, "Loan
Origination Date 01-Nov-2015".
Manage Description Rules Example
Define description rules for static information stored on journal entries and entry
lines.
In this example one of the lines has a description showing the rate for the loan:
Description Rules Implementation Notes
Manage Supporting References
Supporting references are used to store additional source information about a

subledger journal entry either at the header or line level. Each supporting
reference is composed of one to five segments.
Sources are assigned to supporting reference segments to indicate which

transaction or reference values should be captured on subledger journal entries.
The segments are grouped into one supporting reference.
Supporting references that have the option for maintain balances set to Yes, establish
subledger balances for a particular source and account for a particular combination of
segment values plus the account combination.
For example, if a supporting reference to hold customer information with two segments
Customer Type and Customer Name is assigned to a journal line, balances will be
created for each combination of: account combination plus customer name and
customer type.
You may want to use reference balances to:
 Reconcile detailed accounting to subledger applications.

 Reporting using dimensions not captured in the chart of accounts.
 Enrich Oracle Fusion Business Intelligence Applications reporting on
subledger journals.
Define supporting references to hold additional supporting information for
detailed account balance maintenance or reconciliation/ reporting requirements.
This example shows ‘Location’, ‘Contract’, and ‘Channel’ of the loan origination as the
supporting information available on the journal entry line. Optionally, you may choose to
maintain account balances for any of these attributes.
Supporting References Implementation Notes
Supporting references is a powerful tool to allow capture of journal entries with

transaction attributes.
You can use these tags to report on entries, reconcile entries back to subledger
applications or even maintain balances at the attribute level.
Supporting References Best Practices
You can assign one source per event class to each supporting reference segment.
Oracle Fusion Subledger Accounting uses the segment name to store the source
values. This standardizes supporting reference information, even if it comes from
disparate subledger applications.
If there is no balance to be maintained for a supporting reference, and no slicing and

dicing is needed for reports on supporting references, consider using a journal entry
header or line description instead of the supporting reference feature.
This is recommended for accounting engine performance considerations. Using

supporting references instead of descriptions will impact the performance.
Activate Subledger Journal Entry Rule Sets
You can activate the subledger journal entry rule set assignments from the
Accounting Method window.
You can also submit the Activate Subledger Journal Entry Rule Set Assignments
task or process to validate and activate your accounting setups.
NOTE: Instructor Demonstration:
 Create Invoice and Credit Memo.
NOTE: Student hands-on activities:
 Create Account Rule.

 Duplicate Journal Entry Rule Set.
Define Accounting Methods Considerations
Define accounting methods in the following sequence:
1. Define accounting method.

2. Assign a subledger journal entry rule set to each event class and/or type
for each subledger application.
3. Select an accounting method for each ledger.
 If assigning multiple journal entry rule assignments to an event class or type, use
non overlapping assignment dates. This can be used to accommodate changes
in accounting treatment due to new regulations or corporate policies.
 If the accounting method is associated with a chart of accounts, the assigned
journal entry rule sets must have the same chart of accounts or have no
assigned chart of accounts.
 When assigning an accounting method to a ledger, you can select an accounting
method that uses the same chart of accounts, or an accounting method that does
not have an assigned chart of accounts.
 The assignment status must be Active for the rule to be used by the Create
Accounting process. Activate a journal entry rule set directly from the Manage
Journal Entry Rule Sets window, or by running the Activate Subledger

Journal Entry Rule Set Assignments process.
 The journal entry rule set assignments in accounting methods are used by the
Create Accounting process to create journal entries for the specified event class
and event type.
NOTE: For Oracle Fusion Payables transactions, the invoice date on the header of the
invoice is used as the accounting date.
NOTE: Instructor Demonstration Edit Subledger Accounting Method.
Create and Process Subledger Journal Entries
The Create Accounting process uses the transaction and reference objects data, plus
the accounting rules, to create subledger journal entries. For example, if a subledger
journal entry rule set specifies that the customer name should appear in the description
of a subledger journal entry line, then the customer name value is taken from the
customer name source data provided by the transaction objects.
The following figure illustrates the process used to create subledger journal entries.
How Subledger Journal Entries Are Created and Processed
1. On a periodic basis, transaction and reference information from subledger

applications that require accounting is transferred to Oracle Financials. The
determination of what information should be sent to the Oracle Fusion Subledger
Accounting is part of the implementation. There is no prescribed approach for
how this should be done. Any ETL (extract, transform, and load) tool can be
used.
2. The Create Accounting process identifies all accounting events eligible to be
processed. For each of these events, the transaction objects provide the Create
Accounting process with the transaction objects data (source information). This
is the contextual data of the transaction, such as amounts and accounting dates.
3. When the Create Accounting process is run accounting transformation rules, as
assigned to the subledger accounting method for the ledger, and transaction
objects data are applied to the transaction object data to create subledger journal
entries.
4. These entries are summarized and transferred to Oracle Fusion General Ledger.
Creating Transactions
Subledger Transactions
The transactions created in the subledgers will trigger accounting events to be created,
which will then be used to create subeldger journal entries.
Manual Transactions
You can enter manual subledger entry adjustments by using the Create Subledger
Journal Entry window. This task is available in the transaction task list within your
Oracle Fusion subledger application.
These subledger journal entries can be created in Incomplete or Final completion

status, and then can be posted to the Oracle Fusion General Ledger.
NOTE: Instructor Demonstrations:
 Submit the Create Accounting Process.

 Review Subledger Journal Entries.
Manage Oracle Fusion Subledger Accounting Configuration, which includes:
 Manage accounting attributes.

 Define subledger accounting rules.
 Generate accounting event and subledger transactions.
 Review subledger transactions.
Lesson 6: Configuring Intercompany Processing Rules
Lesson 6: Configuring Intercompany Processing

Rules
 Manage Intercompany Balancing Rules.

 Manage Intercompany Transaction Processing Options.
 Create an intercompany batch.
 Run intercompany reconciliation.
Initial Setups
 In the Setup and Maintenance work area create an implementation project for
the Financials offering.
 When performing the Define Ledgers task, use the Specify Ledger Options
task and select the Enable Intercompany Accounting. This must be done for
each ledger for which you want to use intercompany.
 Access the Define and Maintain Intercompany Processing Rules task list to
complete the required setup tasks.
Configuring Intercompany
Begin configuring the Intercompany from the Setup and Maintenance work area.
 Reference the Relevant Setup Tasks section for the navigation.

 The lists of tasks to complete the implementation are arranged in the order they
should be completed.
Define and Maintain Intercompany Processing Rules Configuration Task List
Intercompany Overview
Oracle Fusion Financials Common Module, Intercompany supports the internal

business activity between two or more related legal entities within the same
enterprise.
 An Intercompany segment label can define a segment in a chart of accounts

structure. A segment with this label means that the Oracle Fusion Subledger
Accounting will populate a value in this segment to identify the trading partner for
the intercompany transaction or the contra primary segment value, whenever it
generates intercompany receivable or payable lines using the Intercompany
Balancing Rules.
 Automatic intercompany balancing journal creation in the Oracle Fusion
Financials ensure proper recording of journals across legal entities.
 Intercompany balancing rules are defined for pairs of primary balancing

segment values, pairs of legal entities, pairs of ledgers, or for a chart of accounts
structure. These accounts are used to build the accounts for intercompany
balancing lines.
 Account combinations for intercompany balancing lines are automatically
created based on combinations of source, category, and balancing segment
values of the line to be balanced.
 Intercompany transaction account definition rules are used to build the
default distribution accounts for intercompany transactions for a specific ledger.
Intercompany General Ledger Integration
Intercompany offers two options to complete processing of intercompany transactions

into Oracle Fusion General Ledger.
General Ledger Integration
 Transfer intercompany transactions directly to the general ledger if you do not

need intercompany invoices.
 The general ledger transfer process allows you to automatically transfer to
multiple ledgers with a single submission request.
 Once you have posted transactions in general ledger, you will be able to inquire
on account balances or journal lines, and drill down to the source intercompany
transaction.
Intercompany Receivables and Payables Integration
Oracle Fusion Receivables and Oracle Fusion Payables integration
NOTE: This is only applicable if you require invoices to be generated for intercompany
transactions. The invoices will be created in Oracle Fusion Receivables and recorded
in Oracle Fusion Payables.
You can enter transactions using the user interface, Oracle Fusion Desktop
Integrator, or import them from an external source.
You may need to generate intercompany invoices if legislation requires you to do so.
Intercompany uses Receivables and Payables to generate the invoices.
 Create receivables invoices for the appropriate intercompany customers by

running the Transfer to Receivables process with auto invoice import. Then
record the invoice in payables by running the Transfer to Payables. The
invoices generated in the receivables system will be recorded in the payables
system against the intercompany suppliers, with the same amount and
accounting date; saving you time and ensuring both the receivables and
payables intercompany activity match up.
 Once invoices have been generated and recorded, you can book the accounting
impact by running the Create Accounting process in receivables and payables,
and transfer accounting entries to general ledger with the option to automatically
run journal import and posting.
 You can drill down from general balances or journal lines to general ledger
journal entries, then to the subledger journal entry, and finally to the source
receivables or payables transaction.
Intercompany Key Features
Manual Intercompany Transaction Processing
 Create manual intercompany transactions using the Create Transaction task,

Single Batch Spreadsheet Entry task, or using a custom program to transfer
transaction data from an external system into interface tables.
 Allows you to create, edit, and optionally submit intercompany transactions for
approval.
 Transfer and post transactions to the general ledger. Transfer to Oracle Fusion
Receivables and Payables where invoices are generated and recorded.
 Dashboard is available to review incomplete transactions and any import errors,
and to drill down to edit or view transaction details.
Intercompany Balancing
Adding Due To or Due From lines to journal entries to ensure debits equal credits for
each legal entity or management entity that requires balance sheet reporting.
There is the ability to balance by up to 3 balancing segments:
 Primary balancing segment

 Second balancing segment
 Third balancing segment
Balancing is performed when subledger journal entries are created and also when
Oracle Fusion General Ledger journals are created.
Manage Intercompany Transaction Processing
In order to maintain consistency throughout an enterprise, intercompany

transaction processing rules are defined at the enterprise level. By standardizing
these rules, an enterprise can minimize disputes, decrease processing time, and
cut administrative costs.
Manage Intercompany System Options
Define intercompany system options to set up intercompany processing rules at

the enterprise level, based on your specific business needs.
Intercompany system options can be used to complete the following:
 Enforce an enterprise-wide currency or allow intercompany transactions in local

currencies.
 Allow receivers to reject intercompany transactions.
 Determine the minimum transaction amount that will be processed.
NOTE: Changing and saving a system option will have no effect on intercompany
transactions already in progress. Intercompany system options will only affect new
intercompany transactions, and are not retroactive to any transactions previously
entered.
Intercompany System Options Key Decisions
Manage Intercompany Transaction Types
You can define intercompany transaction types to drive how your transactions
get processed. You can determine if invoicing in receivables and payables is
required, and if manual approval is required.
 Use transaction types to control entry of intercompany transactions by opening

and closing periods by transaction type.
 Define separate balancing rules with different accounts by intercompany
transaction types.
Identify transaction types and the following options:
Manual Approval
Select the Manual Approval option to require receivers to manually approve

transactions.
Invoicing
The Invoicing option determines if transactions will be routed to payables or

receivables for invoice generation and recording respectively.
This option can be overridden by the Manage Legal Jurisdiction, legal function which
contains the Generate intercompany invoice option. If the invoicing option for the
transaction type is not enabled, but either the provider legal entity or receiver legal entity
has the legal function Generate intercompany invoice assigned, invoices will be
generated.
NOTE: The Invoicing functionality is only used if you require invoices to be generated
for your Intercompany transactions using Oracle Fusion Payables or Oracle Fusion
Receivables; otherwise it is not relevant to Oracle Fusion Financials. Also note that
you can have Receivables and Payables installed, but not use intercompany invoices.
Manage Intercompany Period Status
Identify the calendar to be used for intercompany by selecting the calendar in the
Manage Intercompany System Options task. You can select the predefined
general ledger calendar that you want to utilize for intercompany periods.
The opening and closing of these intercompany periods by transaction type will control
whether users can enter transactions for a specific intercompany period and
intercompany transaction type.
The calendar selected can be changed if the intercompany period status is either Never
Opened or Closed.
You can open and close periods as well as initiate the Sweep Transactions process to
move open transactions from one period to a future period.
Use the Manage Intercompany System Options task to select an intercompany

calendar.
Manage Intercompany Organizations
The Manage Intercompany Organizations task allows you to create intercompany

organizations and assign legal entities to them. Intercompany organizations can
act either as a provider or a receiver in intercompany transactions.
Optionally, assign a receivables and payables business unit to the organization if you
require invoice generation.
You can initiate an intercompany transaction only for those organizations that you can
access. When new organizations are added, access must be granted to users as
required.
You can disable intercompany organizations that have no open transactions.
When creating an organization, the following attributes should be considered:
 Legal Entity
 Receivables Business Unit
 Payables Business Unit
 Default Organization Contact
NOTE: This functionality is only used if you are creating intercompany transactions;
otherwise it is not relevant to Oracle Fusion Financials.
Intercompany Organizations Key Decisions
Intercompany Organizations Implementation Notes
For example, map a legal entity to one or multiple intercompany organizations.
In the Legal Entity scenario there is a one to one mapping between legal entities
and intercompany organizations:
In the Management Entity scenario there are multiple management entities per
legal entity. This is an example of a possible InFusion setup:
Intercompany Organizations Implementation Notes (cont'd)
Define Invoice Options
Use the Define Invoice Options task list to define the rules for generating
intercompany invoices.
This is required if you are using Oracle subledgers, such as Oracle Fusion Payables,
and Oracle Fusion Receivables. If you have no future plans to implement Oracle Fusion
subledgers in this version or future versions of Oracle Fusion, then you can skip this
topic.
Manage Intercompany Customer and Supplier Assignments
The intercompany customer and supplier assignments are used to identify which
customer and supplier represent a legal entity. They will be used for generating
and recording invoices for intercompany transactions.
In order for Oracle Fusion Receivable and Payables invoices to be generated for the
Intercompany transaction type, you must associate a customer and a supplier with the
legal entities of the provider and receiver of the intercompany transaction. You can
associate a legal entity with either a customer account or supplier, or both.
Customer Account
Assign a unique customer account to the legal entity of the organization that receives
and approves intercompany transactions. The customer must have an active site, and it
must not be an external customer.
Supplier
Assign a unique supplier to the legal entity of the organization that initiates
intercompany transactions. The supplier must have an active primary pay site.
Additional Considerations
A customer or a supplier can be associated with only one legal entity. Once a customer
or a supplier is associated with a legal entity, it cannot be associated with another legal
entity.
The customer account and supplier assigned to the legal entity can be modified at any
time, regardless of the existing transaction status.
Intercompany Customer and Supplier Assignments

Implementation Notes
Manage Intercompany Receivables Assignments
Set up your Oracle Fusion Receivables assignments by mapping an

intercompany transaction type and a receivables business unit to the Receivables
transaction type and Receivables memo line.
The Receivables transaction type and the Receivables memo line are used to process
intercompany transactions transferred to the Receivables application.
You can configure specific Receivables transaction types, and Receivables memo lines
that you use for each intercompany transaction type for a Receivables business unit.
Invoices can then be transferred and recorded.
Intercompany provides a default Receivables transaction type of Intercompany and a

default Receivables memo line of Global Intercompany. These defaults are used when
there are no other assignments. However, you can choose to set up individual
assignments for each Receivables business unit and intercompany transaction type to
override the default values.
First, select a business unit and intercompany transaction type, and then select the
Receivables transaction type and Receivables memo line. The Receivables transaction
type values available are derived from the reference data set for the Receivables
transaction type assigned to the business unit. The Receivables memo line values are
derived from the reference data set for Receivables memo line assigned to the business
unit.
Intercompany Receivables Assignments Implementation

Notes
Define Transaction Account Rules
Define transaction account rule assignments to default the revenue account and
expense account for provider and receiver distributions.
Setup includes:
Manage Transaction Account Definitions
Define transaction account rules to derive the revenue accounts and expense
accounts for provider and receiver transaction distributions. Transaction account
definitions are assigned at the ledger and subledger levels. Transaction attributes are
used in account rules, which are used in transaction account definitions.
Transaction account types are predefined by the Oracle Fusion subledger

applications, and categorize different accounts generated for transactions. Sources are
assigned to transaction account types.
The transaction account types are:
 Intercompany Provider Distribution Account

 Intercompany Receiver Distribution Account
Transaction account types are assigned to transaction account definitions. Assign
account combination or segment rules to each transaction account type assignment in a
transaction account definition. Assigned sources in each transaction account type are
available for use in account rules to derive accounts for a transaction account type.
Accounts that require consistent derivation throughout the application should share the
same transaction account type.
Transaction Account Builder Components
Transaction Account Builder Components
1. Transaction Account Types: Predefined.

2. Account Rules: Users and Predefined.
3. Sources: Predefined.
NOTE: Refer to the Configuring Oracle Fusion Subledger Accounting, Define

Subledger Accounting Methods topics for additional information on the other Define
Transaction Accounts tasks.
Intercompany Balancing
If balancing segment values are assigned to legal entities, you can use
intercompany accounting to balance journals and subledger accounting entries
between legal entities, and within a legal entity.
Manage Intercompany Balancing Rules
Intercompany balancing rules are used to generate the accounts needed to

balance journals that are out of balance by legal entity or primary balancing
segment values.
You specify the intercompany receivables and intercompany payables accounts you
want to use. The intercompany balancing feature then uses these rules to generate the
accounts of the balancing lines it creates.
You can define intercompany balancing rules at the following levels:
1. Primary balancing segment.

2. Legal entity.
3. Ledger.
4. Chart of accounts.
The rules are evaluated in the order shown above. For example, you can define a
Primary Balancing Segment rule and a Legal Entity level rule. If both rules can be used
to balance a particular journal, the Primary Balancing Segment rule is used, as it has a
higher precedence.
Precedence Order of Balancing Rules
Precedence Order of Balancing Rules
Examples of rules include:
Simple Rule
Create a simple rule to be used for all intercompany balancing for all ledgers that use
the same chart of accounts.
Granular Rule
Create a different rule for each legal entity and one chart of accounts rule to cover any
gaps in your rule definitions.
Combination of Rules
Gain even more granularity by defining rules for specific journal and category
combinations or intercompany transaction types.
Using Chart of Accounts Rules for Intercompany Balancing
Intercompany balancing rules that are based upon a chart of accounts can be
used by all ledgers that use that chart of accounts.
To create a chart of accounts rule, specify the chart of accounts, intercompany

receivables and payables accounts, source, and category. It is recommended that the
intercompany receivables general ledger account be an asset type account, and the
intercompany payables general ledger account be a liability type account.
You can define rules that are applied to a specific source and category, such as
payables and invoices, or a specific intercompany transaction type, such as
intercompany sales. Alternatively, you can choose to create rules for all sources and
categories by selecting the source of Other and the category of Other.
You can have a more complex structure and define multiple rules between pairs of
ledgers, legal entities, or primary balancing segment values. If you choose to have rules
at various levels, then intercompany balancing evaluates the rules in the following order.
1. Primary balancing segment rules.

2. Legal entity level rules.
3. Ledger level rules.
4. Chart of accounts rules.
It is therefore recommended that you set up a chart of accounts rule for every chart of
accounts structure. This will ensure that intercompany balancing will always find a rule
to generate general ledger accounts for balancing lines.
Intercompany Balancing will then evaluate the journal source and journal category
combination in determining which rule to use for balancing. The order of precedence is
as follows.
 Specific journal source and journal category.

 Specific journal source and journal category of Other.
 Journal source of Other and specific journal category.
 Journal source of Other and journal category of Other.
Intercompany Balancing Key Decisions
How many balancing segments are required?
Determine your balance sheet reporting requirements; analyzing whether the level of
balancing require more than one segment. For example, if balance sheets are required
at a brand level, and brand is a subdivision of product, then two balancing segments
may be required.
Having more balancing segments may result in a higher number of lines generated for
balancing journals. Hence, there may be an impact on performance in journal posting
and subledger accounting.
How should the segment values for primary balancing segment and
intercompany segment be defined?
It is recommended that you assign the same values to both the primary balancing and
intercompany value sets to enable clear visibility of the Due To and Due From
relationships inherent in intercompany accounting across the entire organization.
What are the advantages of having an intercompany segment?
You can implement an intercompany segment in your chart of accounts by enabling the
Intercompany Flexfield label for a segment, to track the trading partner for each
intercompany transaction. You would use the same values for the primary balancing
segment and intercompany segment, or ensure the values in each value set are the
same, so that the trading partners can be tracked.
The advantage is that it will remove the need to have a preelimination in a clearing
house or otherwise before doing the eliminations, which is a labor intensive task. It also
identifies intercompany differences.
Intercompany Balancing Key Decisions (cont'd)
How is it populated?
With the intercompany segment, you can set up a single natural account value, per
chart of accounts, for the intercompany payables account, and a single natural account
value for the intercompany receivables account, and use the intercompany segment
value to identify the trading partner, or the contra primary segment value, whenever it
generates intercompany receivable/payable lines . Intercompany Balancing
automatically populates the intercompany segment value when it generates Due To or
Due From journal lines to balance a journal.
Can I use the same value set for balancing segment and intercompany segment?
Instead of sharing the same value set, it is recommended to use a different value set for
primary balancing segment and intercompany segment, where both value sets have the
same values. If the primary balancing segment and intercompany segment shares the
same value set, then when segment value security is enabled, it will also affect the
intercompany segment. Securing a value set denies access to all values by default.
Does the company have more than one chart of accounts and do transactions
span more than one chart of accounts?
You would use the same values for the primary balancing segment for all charts of
accounts in your enterprise for accurate identification of trading partners.
I am upgrading, and my current chart of accounts does not have an Intercompany

Segment, do I need to add one in Fusion?
No, you can still use all Intercompany features. However, we strongly recommend an
Intercompany segment for new implementations, due to the reasons discussed earlier.
Do I need to setup one rule for each of the balancing rules, for example, one for
Primary Balancing Segment Rule, Legal Entity Rule, etc?
If the same natural account can be used for each legal entity and balancing segment
value, and only using the Intercompany segment to track the trading partners, then you
do not need to set up a rule each. This will substantially reduce the setup needed.
Manage Ledger Balancing Options
Ledger balancing options are defined for the ledger to balance the second
balancing segment and the third balancing segment, when a journal entry has
unequal debits and credits by segment value for one or both of these segments.
This is only used when the primary balancing segment is balanced, but the
second balancing segment or the second and third balancing segments are not.
Ledger balancing options include the following settings:
 Receivables and payables accounts used for ledger balancing.

 Summarization options.
 Clearing company options.
If your chart of accounts has the second balancing segment or the third balancing
segment enabled, you can choose to specify the receivables and payables accounts to
be used. These accounts are used for the balancing lines generated when a journal is
balanced by its primary balancing segment values but is not balanced by its second
balancing segment or third balancing segment.
Summarization Options
You can choose to summarize balancing lines generated for a primary balancing
segment, where the total debits and credits for a balancing segment value do not
balance, if all the primary balancing segment values are assigned to the same legal
entity, by specifying the Summarization option of Summary Net or Detail.
You can choose to summarize balancing lines by primary balancing segment value or
alternatively have individual balancing lines (that have not been summarized)
generated. Note that summarization always applies to balancing lines generated in a
cross legal entity scenario.
Clearing Company Options
You can choose to set clearing company options to balance a journal with different
primary balancing segment values that all belong to a single legal entity
Ledger Balancing Options Implementation Notes
Intercompany Challenges
Recommendations:
 All intercompany trading must net to zero when accounting is consolidated or you
have artificially increased the numbers of the Group.
 All transactions must hit each subsidiary ledger in the same period or they won't
net to zero.
 The same currency conversion rates should be used on each side or when
converted to the corporate currency they will not net to zero.
NOTE: Instructor Demonstration View Intercompany Balancing Rules.
Intercompany Reconciliation
The intercompany reconciliation process starts with running the Extract Intercompany
Reconciliation Data process. Choose from a variety of parameters to determine what
data will appear on your reports. For example, choose the provider legal entity and
receiver legal entity for which you want to run reconciliation.
Once the Extract Intercompany Reconciliation Data process has completed

successfully, choose your request from the Oracle Business Intelligence Publisher (BI
Publisher), BI Publishing Options list of values and view the Reconciliation Period
Summary report. This report displays the intercompany receivables and intercompany
payables balances in summary for a period, and any differences between them. Drill
down on the hyperlinks to view the balances by source and then by journal lines. You
have full drill down capabilities to the general ledger journal, subledger journal entry and
source receivables or payables transaction.
Reconciliation Reports
Intercompany reconciliation provides you with reports to assist you with

reconciling your intercompany receivables and intercompany payables accounts,
and to identify any differences.
The main goal of the reports is to make it easy for you to identify either the receiver or
provider side of an intercompany transaction that has not been posted to the
intercompany receivables or intercompany payables accounts.
The reports show the following intercompany lines:
 Intercompany receivables and intercompany payables lines generated by the

intercompany balancing feature.
 Intercompany receivables and intercompany payables lines generated for the
provider and receiver of each intercompany transaction
Intercompany reconciliation reports will not include:
 Clearing company balancing lines.

 Ledger balancing lines generated when the primary balancing segment value is
in balance but either the second balancing segment or the third balancing
segment values are out of balance.
The reconciliation reports show the Entered or Transaction amounts of the journal
entries booked to the intercompany receivables and payables accounts for a pair of
provider and receiver legal entities. Since the accounted amounts may be different if the
conversion rates used for the intercompany receivables and intercompany payables are
different, you can choose to run the reports using an additional currency and conversion
rate that will convert all amounts into a common currency for comparison.
NOTE: Instructor Demonstration: Submit and Review Reconciliation Reports.
 Manage Intercompany Balancing Rules.

 Manage Intercompany Transaction Processing Options.
 Create an Intercompany Batch and Review Intercompany Reconciliation
Report.
Lesson 7: Configuring Oracle Fusion Tax

 Understand Oracle Fusion Tax as a centralized transaction tax solution.

 Understand how tax is calculated on transactions.
 Understand foundation tax configuration.
 Understand advanced tax configuration.
 Understand tax reporting configuration.
 Test and validate your tax configuration.
Understanding Oracle Fusion Tax
Oracle Fusion Tax provides a single-point solution for managing your

transaction-based tax requirements. In the Define Transaction Taxes task list in
the Setup and Maintenance work area, set up your entire tax configuration.
Oracle Fusion Tax:
 Provides a single solution for global transaction tax needs.

 Uniformly delivers transaction tax services to all Oracle Fusion application
business flows through one application interface.
 Provides a single source of truth for tax configuration and reporting.
 Provides a single integration point for third-party transaction tax products and
services.
You can model your taxes according to the needs of the following local and
international tax requirements:
 Both simple and complex country-specific tax legislation.

 Cross-border transactions, including exports and Intra-European Community
transactions.
 Intercompany transactions.
 Local compliance requirements for recording and reporting.
 Continual changes to tax legislation, such as new taxes, local law changes,
special tax rates, and special exceptions for products and customers.
You can manage the entire configuration and maintenance of tax content from the one
Oracle Fusion Tax application. Using one application ensures a uniform tax setup
across applications, with a centrally managed system of automated tax services and
control over manual intervention and update.
NOTE: Instructor Demonstration Viewing Calculated Tax on a Receivables

Transaction.
Define Transaction Taxes Overview
In the Define Transaction Taxes task list you can set up your entire transaction
tax configuration.
Navigation: Setup and Maintenance work area > Manage Implementation Projects link
> XX Implementation Project row > Financials task list > Define Common Financials
Configuration task list > Define Transaction Taxes task list.
The Define Transaction Taxes task list is logically defined with:
 Prerequisite tasks.
 Core tax configuration tasks.
 Optional setup tasks.
 Validation configuration tasks.
The task list categories include:
 Define Tax Geographies: Configure tax geographies to define geographical

regions that share the same tax requirement. These prerequisite tasks are
required for core tax configuration but they might not have been defined in the
previous steps of the Financials offering.
Navigation: Define Transaction Taxes task list > Define Tax Geographies task list.
 Define Tax Regimes: Configure tax regimes for the taxes in each country and
geographic region where a separate tax applies. These tasks are most
commonly used by all the implementations. You should be able to calculate taxes
on the transactions based on this configuration.
Navigation: Define Transaction Taxes task list > Define Tax Regimes task list.
 Define First Party Tax Profiles: Configure tax profile details that control the
transaction tax activities for your first party legal entities, legal reporting units,
and business units.
Navigation: Define Transaction Taxes task list > Define First Party Tax Profiles task
list.
 Define Third Party Tax Profiles: Configure tax profile details that control the
transaction tax activities for your third party customer, customer sites, supplier,
and supplier sites.
Navigation: Define Transaction Taxes task list > Define Third Party Tax Profiles task
list.
 Define Occasional Tax Implementation Setups: Configure or upload initial tax

setup that impacts tax calculation and reporting. These tasks are predefined, and
you can configure your own setups if needed.
Navigation: Define Transaction Taxes task list > Define Occasional Tax
Implementation Setups task list.
 Verify Tax Configuration: Verify the transaction tax configuration by simulating

transaction data and reviewing tax calculation results.
Navigation: Define Transaction Taxes task list > Verify Tax Configuration task list.
Oracle Fusion Tax Architecture
Oracle Fusion Tax architecture has a centralized data model which provides a
single source of truth for transaction tax information. It consists of five tiers:
1. Tax Configuration - Foundation: This tier represents the tax data that you set
up for each tax regime and tax that your company is subject to. A tax authority
administers the taxes of a tax regime. Each tax within a tax regime is comprised
of a certain number of elements, including tax statuses, tax jurisdictions, tax
rates, and if applicable, tax recovery rates.
2. Tax Determining Factors: This tier identifies the factors that participate in
determining the tax on an individual transaction. Tax determining factors can be
classified into the parties involved in a transaction, the products transacted, the
places involved in a transaction, and the process or kind of transaction that
takes place. Tax determining factors are the building blocks for tax rules.
3. Tax Configuration - Advanced: This tier consists of the defaults and tax rules
used to determine and calculate tax on a transaction. Create tax rules by
translating the tax regulations of a tax authority into determining factors and tax
conditions. For each transaction line, the tax determination process uses the
defaults or tax rules to determine the applicable tax regimes and taxes, place
of supply, tax registration, tax rate and taxable basis to use in tax calculation,
and any tax recovery to the extent applicable.
4. Services: This tier consists of calculating tax amounts, determining
appropriate tax recovery amounts, exporting and importing designated tax
setups, and integrating with third-party vendor products for transaction tax
data upload, calculation, and reporting considerations where elected.
5. Tax Management: This tier maintains all of the tax information pertaining to each
transaction for use in tax reporting.
The configuration repository contains all of your tax setup that you can share across
multiple legal entities and multiple business units with the global configuration owner.
The tax record repository stores the transaction tax events and attributes for your
country-specific reporting requirements.
These tiers are discussed in further details throughout this lesson.
Tax Requirements Organization
In order to determine how to set up your tax configuration, you must first analyze
your transaction tax requirements. You must make key decisions when you
analyze your transaction tax requirements and use Oracle Fusion Tax and other
Oracle Fusion applications to implement a solution.
Setting Up Foundation Tax Configuration
Use Oracle Fusion Tax to set up and maintain your transaction tax requirements
in all geographic locations where you do business. Foundation tax configuration
refers to a set of tax setup components that you use to satisfy your transaction
tax requirements. It is the minimum configuration to calculate tax. At transaction
time, Oracle Fusion Tax uses your tax configuration to determine the taxes that
apply to each transaction and to calculate the tax amounts.
Foundation tax configuration components consist of:
Use the Define Tax Regimes, Define Taxes, Define Tax Statuses, Define Tax Rates,
Define First Party Tax Profiles and Third Party Tax Profiles task lists to set up your
foundation transaction tax configuration.
Foundation Tax Components
Complete the setup tasks to create a basic tax configuration for each of your tax
regimes. Throughout Oracle Fusion Tax, care is taken to minimize your effort in
creating setup. One way of achieving this objective is the extensive use of defaulting
so that you can enter your data once and use the defaults that appear on the
subordinate or child records where applicable. For example, many values you enter on
the tax regime appear as defaults on each tax that is associated to that tax regime.
Generally, you can override the data where necessary if the defaulted value is not
correct.
Also, to ensure maximum flexibility, as well as to ensure that the accuracy and integrity
of the data and transactions are maintained, Oracle Fusion Use Tax makes extensive
use of data-driven controls that enable and control how tax functionality works. For
example, you have the requirement to set up tax recovery for value-added tax (VAT)
processing. Enable the Allow tax recovery option on the tax record so you can set up
tax recovery rates for this type of tax.
Set up the following tax components as part of your foundation tax configuration:
 Tax Configuration Owners and Options

 Tax Regimes
 Taxes
 Tax Statuses
 Tax Jurisdictions
 Tax Rates
Configuration Owners and Options
Set up configuration owner tax options for a combination of configuration owner

and application event class. The types of owners are the:
 Tax configuration owner: A business unit, legal entity, or the global

configuration owner that owns the data.
 Global configuration owner: An abstract owner which is used to define the
owner of content that can be shared by any business units and first party legal
entities.
Configuration owner tax options let a configuration owner update default tax options on
transactions that belong to a specific application event class. At transaction time, Oracle
Fusion Tax uses the tax option settings of the configuration owner and application event
class instead of the default settings.
This is the appropriate level to:
 Define a business unit or legal entity as a configuration owner.

 Subscribe to a global configuration option.
 Turn tax calculation on or off.
 Define the regime determination method.
 Define tolerances.
 Enforce controls.
Tax Regimes
Set up tax regimes in each country and geographical region where you do
business and where a separate tax applies. A tax regime associates a common
set of:
 Default information.
 Regulations.
 Fiscal classifications.
 Registrations, to one or more taxes (optionally).
For example, in the US create a US Sales and Use Tax regime to group taxes levied
at the state, county, and district levels. For the UK create a tax regime for GB VAT.
 Share tax content among legal entities and business units.

 Enable partner integration.
 Define reporting tax authority and collecting tax authority.
 Define features to influence setup task list.
NOTE: Student Activity Creating a Minimum Tax Configuration: Defining a Tax
Regime.
Taxes
Set up details for the taxes of a tax regime. Each separate tax in a tax regime
includes records for the:
 Tax statuses.
 Tax rates.
 Tax rules that are used to calculate and report on the tax.
Oracle Fusion Tax applies as defaults tax information from the tax regime to each
tax that you create under a tax regime. You can modify this information at the tax
level according to your needs, as well as add additional defaults and overrides.
For tax rule defaults, specify values that apply to the majority of your
transactions. Use tax rules to configure exceptions to the tax rule defaults.
For example, for US Sales and Use Tax define a tax for each state, county, and city.
For the UK, set up a tax for GB VAT.
You can enable a tax for simulation or for transactions only after you have
completed all of the required setup. Minimum setup for a country-level standard
tax with no recovery and always applicable includes:
 Entering the required fields in the Create Tax or Edit Tax pages.
 Entering direct tax rule defaults. Direct tax rule defaults are the default values
for the direct tax rule types, which include place of supply, tax applicability, tax
registration, tax calculation formula and taxable basis formula.
 Entering indirect tax rule defaults. The indirect tax rule defaults are the default
values for the indirect tax rule types, which include tax jurisdiction, tax status, tax
recovery rate and tax rate.
 Entering tax accounts.
 Enable controls to influence tax behavior.

 Specify defaults that are commonly applicable.
 Define default tax applicability.
 Specify party registration defaults.
Tax Statuses
Set up the tax statuses that you need for each tax that you create for a
combination of:
 Tax regime.
 Tax.
 Configuration owner.
A tax status is the taxable nature of a product in the context of a transaction and
specific tax on the transaction. You define a tax status to group one or more tax
rates that are the same or similar in nature.
For example, for US Sales and Use Tax create a tax status for standard and exempt.
For the UK set up separate tax statuses for standard, zero, exempt, and reduced
rates.
 Group common tax rates.

 Drive reporting needs.
 Allow manual override to tax rates.
Tax Jurisdictions
Set up tax jurisdictions where a specific tax authority levies a tax for:
 Geographic regions.
 Tax zones.
A tax jurisdiction specifies the association between a tax and a geographic
location. At transaction time, Oracle Fusion Tax derives the jurisdiction or
jurisdictions that apply to a transaction line based on the place of supply. You
must set up at least one tax jurisdiction for a tax before you can make the tax
available on transactions.
For example, for US Sales and Use Tax create a county jurisdiction for every county in
the parent geography type of State and in the parent geography name of
California. For the UK, create a tax jurisdiction for the country of United Kingdom.
 Define location based tax rates.

 Define tax accounts and tax reporting codes as appropriate.
Tax Rates
Set up tax rates for your:
 Tax statuses.
 Tax jurisdictions.
For tax statuses, set up a tax rate record for each applicable tax rate that a tax
status identifies. For tax jurisdictions, set up tax rate records to identify the tax
rate variations for a specific tax within different tax jurisdictions.
For example, for US Sales and Use Tax create a tax rate for each tax jurisdiction
(jurisdiction-based rates). For the UK, set up separate tax rates for standard, zero,
exempt, and reduced.
 Define tax rates by effective periods.

 Specify tax account variations as appropriate.
 Assign default tax recovery rates.
If you have tax recovery, set up tax recovery rate codes for the recovery types
identified on the taxes within a tax regime. A tax recovery rate code identifies the
percentage of recovery designated by the tax authority for a specific transaction.
For example, organizations that produce VAT-applicable goods and services are
allowed to recover 100% of the VAT they pay on typical purchases. They would use a
default 100% recovery rate. Organizations, such as financial institutions, who provide
services that are exempt from VAT are not able to recover VAT on their normal
purchases. They would use a default 0% recovery rate.
NOTE: Student Activity Creating a Minimum Tax Configuration: Defining a Tax,

Defining a Tax Jurisdiction, Defining a Tax Status, Defining a Tax Rate, and
Enabling a Tax for Simulation.
Examples of Foundation Tax Setup
NOTE: The above data examples are introduced to illustrate the foundation transaction
tax configuration and may not represent the complete tax setup for the country. How
you define your configuration depends on your transaction tax requirements.
Knowledge Check: Minimum Tax Configuration
You must set up tax rules before you can enable your tax for simulation or
transactions:
1. True
2. False
Knowledge Check: Minimum Tax Configuration

Answer
You must set up tax rules before you can enable your tax for simulation or
transactions:
1. True
2. False
You do not have to set up tax rules to enable your tax for simulation or transactions.
However, you must define the direct and indirect tax rule defaults for the tax before you
can enable the tax for simulation or transactions. Oracle Fusion Tax provides
predefined data to select from for the direct tax rule defaults.
Setting Up Advanced Tax Configuration
Create a simple tax model using tax rule defaults that you define in setting up
your foundation tax configuration. You can also create tax rules for your complex
tax requirements that consider each tax requirement related to a transaction
before making the final tax calculation.
When running the tax determination process, Oracle Fusion Tax evaluates, in order of
priority, the tax rules that you have defined against the foundation tax configuration
setup and the details on the transactions. If a tax rule is:
 Successfully evaluated, the result associated with the rule is used.

 Not successfully evaluated, the next rule is evaluated until either a successful
evaluation or a default value is found.
In summary, it is important to note that tax rules take precedence over default
values in the tax determination process.
Advanced tax configuration consists of tax rules to define exceptions to the

default results.
Key Building Blocks of Tax Rules
Determining factors are the key building blocks of the tax rules. The determining
factors represent the tax-decision criteria that are passed at transaction time
derived from information on the transaction or associated with the transaction.
They are used within tax rules logic to determine the conditions under which
specific tax rules are applicable to a specific transaction.
Conceptually they fall into four groups:
Tax Determination Process
The tax rules that are part of the tax determination process are organized into rule
types. The rule types and related processes are used for tax line determination
and tax calculation.
You must either provide a default value for each rule type or set up a tax rule for
each rule type to determine and calculate taxes. Each rule type identifies a
particular step in the determination and calculation of taxes on transactions.
The tax determination process evaluates, in order of priority, the tax rules that are
defined against the tax configuration setup and the details on the transaction. The
application processes tax rules in order of evaluation until one evaluates successfully,
then the process stops. If none of the rules defined evaluate successfully, the
associated default value is used.
The tax line determination process uses transaction header, transaction line, and any
additional information derived by transaction attributes such as party fiscal classification
to determine the tax lines. The evaluation process is subdivided into the following
processes:
 Determine Applicable Tax Regimes and Candidate Taxes

 Determine Place of Supply and Tax Jurisdiction
 Determine Tax Applicability
 Determine Tax Registration
 Determine Tax Status
 Determine Tax Rate
 Determine Taxable Basis
 Determine Tax Calculation
 Determine Tax Recovery
Determine Applicable Tax Regimes and Candidate Taxes
Tax regimes are considered based on geography and subscription. Either a

country or zone associated to the tax regime definition must be the same as the
country or zone identified via the location that evaluates to true on the regime
determination set of the first party of the transaction. In addition, the tax regime
must have a subscription to the applicable configuration owner.
Once the tax determination process identifies the appropriate tax regime or
regimes, the list of candidate taxes can be evaluated based on the configuration
option setting of the first party in the tax regime subscription definition:
 Common Configuration: Consider all taxes with the configuration owner of

global configuration owner.
 Party Specific Configuration: Consider all taxes with the first party or business
unit as configuration owner.
 Common Configuration with Party Overrides: Consider all taxes with the first
party or business unit and the global configuration owner as configuration owner.
If a tax is defined by both the first party or business unit and the global
configuration owner, then the application only uses the tax defined by the first
party or business unit.
 Parent First Party Configuration with Party Overrides: Consider all taxes with
the first party and the parent first party as configuration owner. If a tax is defined
by the first party and the parent first party, then the application only uses the tax
defined by the first party.
Determine Tax Applicability and Place of Supply and Tax

Jurisdiction
This process determines the tax applicability of each candidate tax based on:
 Direct rate determination.

 Place of supply.
 Tax applicability.
 Tax jurisdiction.
The first step in tax applicability is to process any direct rate rules defined for a
tax regime, configuration owner, and candidate taxes.
 If a direct rate rule evaluates to true, then place of supply is processed for this
transaction tax. In addition the tax is applicable and the tax status and tax rate
defined for the direct rate rule are used in the tax calculation.
 If a direct rate rule does not evaluate to true for this tax regime, configuration
owner, and tax, then the tax applicability rules are processed next. After a tax is
found applicable based on an applicability rule or a default value, the process
verifies the place of supply and associated tax jurisdiction. This is required
except in the cases of migrated taxes.
The place of supply process identifies the applicable location type and
associated tax jurisdiction where the supply of goods or services is deemed to
have taken place for a specific tax. If the tax determination process cannot find a
tax jurisdiction for the location that corresponds to the place of supply location type,
then the tax does not apply and it is removed as a candidate tax for the transaction.
For example, the place of supply for UK value-added tax (VAT) on goods is generally
the ship-from country. Thus, the place of supply of a sale or purchase within the UK is
the UK itself. However, if a UK legal entity supplies goods from its French warehouse to
a German customer, then the place of supply will not find a jurisdiction for UK VAT in
France, and therefore UK VAT does not apply.
Determine Tax Registration
This process determines the party whose tax registration is used for each tax on
the transaction, and, if available, derives the tax registration number. Tax
registration is also important for triggering the application of self-assessed taxes.
Determine Tax Status
This process determines the tax status of each applicable tax on the transaction.
If no default value was defined earlier and the process cannot find a tax status for
an applicable tax, then Oracle Fusion Tax raises an error.
Determine Tax Rate
This process determines the tax rate code for each tax and tax status derived
from the previous process. First, Oracle Fusion Tax looks for a tax rate based on
a rate code and tax jurisdiction. If these elements are not found, then Oracle
Fusion Tax looks for a tax rate without any tax jurisdiction. If applicable, the tax
rate is then modified by any exception rate or tax exemption that applies. The
result of this process is a tax rate code and tax rate for each applicable tax.
Determine Taxable Basis
This process determines the taxable basis for each tax rate code. Depending on
the tax rate type, the taxable basis is amount based or quantity based. The tax
determination process typically determines the tax by applying the tax rate to the
taxable basis amount. In some cases, the taxable basis either can include another
tax or is based on the tax amount of another tax. Define taxable basis formulas to
manage these requirements.
Determine Tax Calculation
This process calculates the tax amount on the transaction. In most cases, the tax
amount is computed by applying the derived tax rate to the derived taxable basis.
In some exceptional cases, the tax amount is altered by adding or subtracting
another tax. Define tax calculation formulas to manage these requirements.
Determine Tax Recovery
This process determines the recovery rate to use on procure-to-pay transactions

when the tax allows for full or partial recovery of the tax amount. The recovery
type is defined on the tax and identifies whether there are one or two recovery
types: primary and secondary. For each tax and recovery type, the application
determines the recovery rate based on a tax rule or default value defined on the
tax.
The recovery process impacts the purchase invoice distributions level, tax
amounts, inclusiveness of taxes, and the tax accounting within Oracle Fusion
Payables. The resulting distribution amounts are adjusted as a result of the recovery
process.
Examples of recovery rates include:
 For UK manufacturing companies, VAT on normal purchases used for company

business is 100% recoverable.
 For a financial institution which only makes VAT exempt on sales, you are not
allowed to recover any taxes and your recovery rate is zero percent on all
purchases.
Knowledge Check: Tax Determining Factors
What are the determining factors that contribute to the outcome of a tax:
1. Tax regime, tax, tax status, and tax rate

2. Party, product, place, and process
3. Tax registration, fiscal classification, tax exception, and tax exemption
Knowledge Check: Tax Determining Factors Answer
What are the determining factors that contribute to the outcome of a tax:
1. Tax regime, tax, tax status, and tax rate

2. Party, product, place, and process
3. Tax registration, fiscal classification, tax exception, and tax exemption
By understanding the requirements of how transaction taxes should be determined in

accordance with applicable tax laws and industry conventions, the party, product, place,
and process elements can meaningfully provide a method of accommodating complex
business requirements through specific configuration.
Setting Up Tax Reporting Configuration
The global tax reporting feature provides a reporting solution to:
 Capture and report data for country-specific tax reporting requirements.

 Organize tax report data according to the requirements of your company and
any applicable tax authorities.
Oracle Fusion Tax provides you with legal, business, and reconciliation reports for tax
activity associated with buying and selling goods and services through Oracle Fusion
Payables and Oracle Fusion Receivables.
You can:
 Produce reports and returns to meet tax reporting requirements for specific
countries and those required for reconciliation and audit of tax calculated on
transactions.
 Generate registers with comprehensive information of transactions with tax
impact, which can be used as a basis for creating tax reports required by tax
authorities and meeting the internal reporting needs of the organization.
To set up global tax reporting, you can:
Verifying Tax Configuration
The Tax Simulator is a tool for simulating the tax determination process using
your tax setup. The Tax Simulator lets you preview the workings of your tax
configuration before you perform tax calculations on transactions in a subledger
application. The Tax Simulator also allows you to test new tax configuration in
conjunction with existing tax configuration to preview the resulting tax
calculation. The Tax Simulator is a useful tool to identify the root cause when tax
calculation or other tax processing is not what is expected on active data.
Run taxes from all applicable tax regimes against a sample transaction to verify that
your tax configuration and tax rules were created and applied according to your
requirements. You can either create a sample transaction within Tax Simulator or copy
an existing transaction. The simulated tax calculations do not affect active data.
Use the Verify Tax Configuration task list to access the Tax Simulator.
NOTE: Student Activity Using the Tax Simulator to Test a Receivables Transaction.
In this lesson, you should have learned:
 How Oracle Fusion Tax is a centralized transaction tax solution.

 How tax is calculated on transactions.
 How to set up foundation tax configuration.
 When you would use advanced tax configuration.
 How to set up your tax reporting configuration.
 How to test and validate your tax configuration.
Lesson 8: Configuring Oracle Fusion Payables

 Explain key concepts in Oracle Fusion Payables.

 Explain automated invoice processing.
 Define common options for Payables and Procurement.
 Define general Payables options.
 Define Payables configuration.
 Define Payables US 1099 tax.
 Define payment options.
 Explain invoice approval rules.
 Define Subledger Accounting rules.
Key Concepts in Oracle Fusion Payables

Procure to Pay Flow
The procure to pay flow includes the following steps:
 Request: Request materials and services and get authorization for requests.
 Source: Source products and services. Negotiate terms and agreements.
Manage contracts, agreements, and suppliers. Create purchase orders.
 Receive: Confirm delivery and receipt of products and services.
 Invoice: Process invoices.
 Pay: Disburse payments and settle supplier liabilities.
Use Oracle Fusion Payables to manage invoices and payments.
NOTE: Instructor Demonstration Creating an Invoice from a Scanned Image.
Business Units in the Procure to Pay Flow
Configure business units for the following procure to pay transactions.
Procurement Business Unit
 A business unit with the Procurement business function.

 Establishes a relationship with a supplier through the creation of a site, which
maintains internal controls for how procure to pay transactions are executed with
the supplier.
 Manages, owns, and is responsible for purchasing transactions.
Requisitioning Business Unit
 A business unit with the Requisitioning business function.

 Manages and owns requisitioning transactions.
Sold-to Business Unit
 A business unit with the Payables Invoicing business function.

 Responsible for invoicing transactions.
 Assumes the liability for the purchases made on behalf of a client business unit.
Setup and Maintenance work area > Define Business Units > Assign Business Unit
Business Function
Example
The figure provides an example of business function assignment. The Business Unit
USA1 Business Unit performs the requisitioning, procurement, and invoicing business
functions. USA1 Business Unit is a procurement business unit, a requisitioning
business unit, and a sold-to business unit.
Service Provider Model
Shared service centers are supported in two ways.
 Service provider model: Allows a business unit to act as a service provider to

client business units, so that the personnel in a shared service center can
process transactions on behalf of client business units.
 Business unit security: Allows shared service center personnel to process
transactions for other business units.
Service Provider Model
Use the service provider model to centralize the procurement business function. Define
business units with Requisitioning and Payables Invoicing business functions as
clients of a business unit with the Procurement business function.
The following figure illustrates a scenario where business unit BU 1 provides

procurement services for business unit BU 2. BU 2 performs Requisitioning and
Payables Invoicing business functions. The service provider relationship is defined
with BU 1 as a service provider for BU 2.
Service Provider Model Example
The following figure depicts an example of service provider setup where business unit
USA1 Business Unit is its own procurement service provider.
Setup and Maintenance work area > Define Business Units > Manage Service
Provider Relationships
Knowledge Check: Business Units
A client business unit is serviced by one or more requisitioning business units.
1. True
2. False
The business unit that establishes a relationship with a supplier through the
creation of a supplier site is the:
1. Procurement business unit

2. Requisitioning business unit
3. Sold-to business unit
4. Client business unit
Knowledge Check: Business Units Answers
A client business unit is serviced by one or more requisitioning business units.
2. False. A client business unit is serviced by one or more procurement business units.
The business unit that establishes a relationship with a supplier through the
creation of a supplier site is the:
a. Procurement business unit
Supplier Model
Suppliers are modeled as a global entity and are not created within a business unit or
within any other organizational context.
Supplier Sites:
 Are associated with a procurement business unit.

 Represent the relationship between a procurement business unit and a
supplier.
 Set terms, controls, and policies which govern how procure to pay transactions
are executed between its client business units and the supplier.
Example
The following figure provides an example of a supplier site setup. The supplier
Advanced Corp has a site called AC USA1, which is associated with the procurement
BU USA1 Business Unit.
Suppliers work area > Search for Supplier > Site tab
Supplier Site Assignments:
 Control which client business units can transact with the site.
 Define the sold-to business unit associated with the client business unit.
Supplier Site Assignment Example
The following figure provides an example of a supplier site assignment.
The client business unit USA1 Business Unit, which is also the sold-to business unit, is
assigned to the site AC USA1. Therefore, the business unit USA1 Business Unit can
create requisitions and process invoices for this site.
Suppliers work area > Search for Supplier > Site tab > Site link > Site Assignments
tab
In most cases, the client business unit and sold-to business unit are the same. In
certain instances, due to tax or legal reasons, the client business unit may only perform
requisitioning, and another business unit acts as the sold-to business unit and assumes
liability for purchases.
 When a different sold-to business unit acts as an agent for the client business
unit, you must create an additional assignment for the sold-to business unit to
process invoices. The list of sold-to business units that you can select for a given
client business unit is determined by the Intercompany Transaction Flow
setup.
 When the client business unit and sold-to business unit are different, you must
accrue purchase orders on receipt.
NOTE: Instructor Demonstration Supplier Model.
Knowledge Check: Suppliers
Suppliers are associated with a procurement business unit.
1. True
2. False
Knowledge Check: Suppliers Answer
Suppliers are associated with a procurement business unit.
2. False. Suppliers are modeled as global entities and are not associated with a
business unit. Supplier sites are associated with a procurement business unit.
Invoice Entry Methods
Oracle Fusion Payables supports a variety of invoice entry methods.
Manual
Use Oracle Fusion Automated Invoice Processing to support scanning of invoices
for paperless processing and routing. Enter complex invoices with sophisticated
defaulting and matching logic to match to purchase orders or receipts. View invoice
information, such as invoice status, installments, holds, payments, and applied
prepayments. Drill down to the original purchase order or receipt. For high volume
invoice entry that does not require extensive online validation, use spreadsheet invoice
entry.
Supplier Portal
Oracle Fusion Supplier Portal allows suppliers to enter their own invoices. Invoices
that are not matched to purchase orders are routed through workflow approval rules that
you can configure.
Automated
To alleviate the workload of your payables staff, there are many ways in which invoices
can be created automatically. Use the Evaluated Receipt Settlement (ERS) process to
automatically create an invoice in Payables upon receipt, and use the Return to
Supplier (RTS) feature to automatically create debit memos when you return goods to
your supplier. Payables automatically creates invoices from expense reports entered by
employees in Oracle Fusion Expenses.
Electronic
Payables supports B2B XML invoice web service and provides an open interface to
import invoices from another system.
Regardless of the invoice entry method that you use, Payables supports foreign
currency conversion, automatic tax calculation including withholding tax, invoice
approval, online accounting, and multiple accounting representations.
Implementation Considerations for Invoice Entry

Methods
Function Security
The predefined Oracle Fusion Payables job roles are configured to maintain
segregation of duties for managing suppliers, creating invoices, force approving
invoices, and creating payments.
This table lists the predefined Payables job roles.
Job Roles and Duty Roles
This table lists some of the Payables duty roles and shows how duties are segregated
across job roles.
For example, the Accounts Payable Specialist has the Payables Invoice Creation
Duty and can create invoices, but does not have the Payables Payment Creation
Duty, so cannot pay them.
Data Security
Generate data roles for business units and reference data sets using predefined data
role templates. The following table summarizes the data roles required for Payables
and the security access that the data roles grant.
Prerequisite Setups
Before you perform the tasks in the Define Payables task list, configure the following
common tasks for Oracle Fusion Payables:
 Manage reference data sets.

 Verify data role generation.
 Provision roles to implementation users for sets.
 Manage business unit set assignments.
 Assign the business unit business function Payables Invoicing.
Creating suppliers is part of Procurement. To define suppliers, perform additional tasks,

such as:
 Create a supplier with a type of Tax Authority for withholding tax.

 Manage Inventory Organizations.
 Manage Procurement Agents to identify the users who will create supplier sites.
 Assign the Procurement Business Unit Business Function.
 Manage Service Provider Relationships to specify the business units that provide
the procurement service.
 Configure the Procurement Business Function.
Defining Automated Invoice Processing Configuration
Defining Automated Invoice Processing is a manual task. Automated invoice

processing is a fully integrated invoice imaging solution that supports the entire invoice
life cycle from scanning, recognition, and routing, to invoice entry, approval, and
payment.
If you have Oracle Fusion Automated Invoice Processing, you must set up Oracle
Document Capture, Oracle Forms Recognition, and Oracle Imaging and Process
Management.
Document Capture
 Digitizes paper invoices to images to support the automation necessary for

streamlining invoice processing.
 Is designed for high volume, centralized image capture, where batches of
invoices can be scanned at a time.
 Supports implementation scenarios where companies can centrally scan all
invoices by having suppliers send invoices to one location, or they can scan
documents in field offices using multiple Document Capture instances.
Forms Recognition
 Offers intelligent recognition capabilities for extracting key invoice header data
from scanned images. The extracted data is later prepopulated directly into the
invoice entry user interface.
 Intelligently locates data within the invoice, regardless of its location on the image
and whether or not it has processed invoices from that supplier before, unlike
other solutions that use supplier-specific templates to extract information. As new
suppliers are added, or an existing supplier changes its invoice layout, Forms
Recognition can extract data from these new invoice layouts without additional
configuration.
Imaging and Process Management
 Stores and routes invoice images to accounts payable specialists. For the rest of
the invoice life cycle, any reference to the invoice image points to the Imaging
and Process Management repository so documents are never replicated.
NOTE: For more information, see the Oracle Fusion Applications Post-Installation
Guide.
Automated Invoice Processing Flow
The invoice imaging process begins with invoices arriving in the mail room.
 Imaging specialists prepare and sort invoices based on parameters, such as

geography, invoice amount, and due date, and then scan the invoices using
Document Capture.
 Images are then sent over a network file share to a central Forms Recognition
server for intelligent data recognition and extraction. Any invoices that fail data
extraction or validation are sent to the Forms Recognition Verifier for manual
resolution.
 Once data recognition is complete, the invoice images are sent to Oracle
Imaging and Process Management for storage and routing to accounts payable
specialists using Oracle BPEL Process Manager workflows.
 Payables specialists view the list of scanned images for invoice entry in the
Scanned Invoices region of the Invoices work area, and proceed with invoice
entry using dual monitors where the invoice entry page is displayed on one
monitor, and the image is displayed on the other. During invoice entry, key
invoice header attributes are already prepopulated with the data extracted by
Forms Recognition, reducing entry time and data entry errors.
Defining Common Options for Payables and

Procurement
The Define Common Options for Payables and Procurement task list consists of the
following tasks:
 Manage Payables Calendars

 Manage Payment Terms
 Manage Common Options for Payables and Procurement
Manage Payables Calendars
Define Payables calendars for:
 Payment terms.
 Automatic withholding.
 Key indicator reporting.
When you create a calendar or add years to an existing calendar, the following
attributes control how periods are generated:
 Period Frequency: Determines the number of periods per year and period name
format options. If you select a Period Frequency of Other, you must define
calendar periods manually.
 Periods per Year: Identifies the number of periods per year based on the period
frequency selected.
 Start Date: Represents the first date for the calendar and is the start date for the
first period.
 Period Name Format: Determines the period name.
The following figure shows an example of a monthly calendar.
Setup and Maintenance work area > Implementation Projects > XXImplementation
Project > Financials > Define Invoicing and Payments Configuration > Define
Payables > Define Payables Configuration > Manage Payables Calendars
Manage Payment Terms
Payment terms:
 Contain information used to determine invoice due dates and amounts.

 Consist of one or more installments, each of which can have up to three
discounts.
 Can be shared across business units through reference data set assignment.
Reference Data Sharing
Payment terms are enabled for reference data sharing using the method of assignment
to multiple sets, no common values allowed. The predefined reference group is
called Payables Payment Terms and the determinant type is business unit. Assign
payment terms to one or more reference data sets and share them across business
units. A payment term must be assigned a set before the payment term can be used.
Assigning Sets to Business Units
When you define a business unit, you assign the business unit a default set. The default
set becomes the set for the reference group Payables Payment Terms. Use the
Manage Business Unit Set Assignment task to change the default set.
In this example, for business unit USA1 Business Unit, the reference data set name
USA1 BU Set is assigned to the reference data object Payables Payment Terms.
Setup and Maintenance work area > Manage Implementation Projects >
XXImplementation Project > Define Business Units > Manage Business Unit Set
Assignment
Assigning Sets to Payment Terms
Assign sets to payment terms as part of the Manage Payment Terms task. To assign a
set, you must first generate and provision the set data role to the implementor. Data
roles for reference data sets are generated using the predefined data role template
Financials Common Module Template for SetID. The set data role is required only for
payment terms setup.
Assigning the Common Set to Payment Terms
You can assign the predefined Common set to a payment term.
Unlike the reference data sharing method of assignment to one set only, with
common values, payment terms that you assign to the Common set are not always
available regardless of the business unit on a transaction. Instead, the Common set
works like any other set. You must assign the Common set to the reference data object
Payables Payment Terms, and also assign the Common set to every payment term that
you intend to use.
NOTE: You must complete payment terms setup before performing the Manage
Common Options for Payables and Procurement task.
Predefined Payment Terms
The following payment terms are predefined and assigned to the Common set.
 Immediate: Scheduled for payment immediately.

 2/10 Net 30: Two percent discount deducted if paid within 10 days, remainder
paid 30 days from invoice terms date.
 Net 30: Payment due in 30 days.
 Net Monthly Account: Payment due on last day of the month following the one
in which the invoice is dated.
 End Current Month: Pay by end of current month.
Important
The first time that you configure common options and save the Manage Common
Options for Payables and Procurement page for a business unit, a default record for
the Manage Invoice Options task is automatically created at the same time. The
Payment Terms field on the Manage Invoice Options page is a required field and the
invoice options record is saved using the predefined payment term Immediate.
Before you proceed with the Manage Common Options for Payables and
Procurement task, you must:
 Generate the data role for the reference data set that is assigned to the business
unit.
 Provision the data role for the reference data set to the implementor.
 Assign the reference data set for the business unit to the payment term
Immediate.
Types of Payment Terms
You can define different types of payment terms. This table describes each type of
payment term.
Payment Terms Example
This table shows how the attributes on a Day of month payment term affect the
calculated invoice due date.
NOTE: Student Activities Provision a Data Role and Create a Payment Term.
Manage Common Options for Payables and

Procurement
Define the common controls and default values for each business unit with the
Payables Invoicing and Procurement business functions.
Common options are grouping into the following categories:
 Default Distributions
 Automatic Offsets
 Currency Conversion
 Expense Accruals
 Self-Billed Invoices
 Legal Entity Information
Default Distributions
Default distributions provide default accounts for payables transaction processing.

You can specify some default distributions on a supplier site assignment, in which case
the supplier provides the default distributions on an invoice.
Setup and Maintenance work area > Implementation Project > XXImplementation
Project > Define Invoicing and Payments Configuration > Define Payables >
Define Common Options for Payables and Procurement >Set business unit scope >
Manage Common Options for Payables and Procurement
Liability
Default liability distribution for an invoice, unless a supplier site assignment has a
different value.
Prepayment
Default distribution for a prepayment invoice, unless a supplier site assignment has a
different value.
Bill Payable
Default bill payable distribution, unless a supplier site assignment has a different value.
Conversion Rate Variance Gain and Conversion Rate Variance Loss: Conversion
rate variance gains or losses for inventory items or expense items that were accrued on
receipt. Variance is calculated between the invoice and either the purchase order or the
receipt, depending on how you matched the invoice. These distributions do not record
variances for expense items that were not accrued on receipt.
Discount Taken: Discounts taken on payments if you allocate discounts to a single

distribution.
Miscellaneous
Distribution for invoice lines with a type of Miscellaneous. If you do not enter a value,
miscellaneous charges are prorated across invoice item lines.
Freight
Freight for an invoice. You can override this distribution during invoice entry. If you do
not enter a freight distribution, freight charges are prorated across invoice item lines.
Prepayment Tax Difference

Tax amount difference between a prepayment and the invoices that it is applied to.
These differences are usually due to changes in tax rates between prepayment and
invoice creation times. This distribution is used only if the Applied Amount Handling
option on the tax record is set to Recalculate.
Automatic Offsets
Automatic offsets are a method for balancing invoice and payment journal entries that
cross primary balancing segment values.
Automatic Offset by Primary Balancing Segment
For this method, Payables uses the invoice liability distribution and overrides the
primary balancing segment with the one from the charge distribution to build the liability
entry line account. The resulting journal entry is balanced by the primary balancing
segment. The invoice distribution combination provides the primary balancing segment
value and the liability distribution on the invoice header provides the remaining segment
values.
Receiving uses the receiving inspection distribution for the destination organization, and
overrides the primary balancing segment with the one from the PO charge distribution to
build the receiving inspection entry line account.
Automatic Offset by All Segments, Except Natural Account
For this method, Payables uses the charge distribution combination from the invoice
distribution and overrides the natural account segment with the one from the invoice
liability distribution to build the liability entry line account. The resulting journal entry is
balanced by all segments, except the natural account segment.
Receiving uses the charge distribution and overrides the natural account segment with
the one from the receiving inspection distribution for the destination organization to build
the receiving inspection entry line account.
Implementation Consideration
Consider this option carefully before setting it. Changing automatic offsets after creating
accounting entries can result in accounting inconsistencies or slow performance.
Currency Conversion
Currency conversion options provide default settings for converting foreign currency
invoices to the ledger currency.
Require conversion rate entry
Require a conversion rate whenever you enter an invoice or a payment in a currency

other than the ledger currency. If you maintain daily rates, the rate is automatically
populated based on the date and the rate type that you enter. If daily rates do not exist
for the date and rate type, and if this option is enabled, you cannot enter or save the
transaction.
If the conversion rate type is User, then you must always enter a conversion rate. You
cannot create accounting entries or pay foreign currency invoices without conversion
rates.
If you do not enable this option, after you have entered invoices or created payments,
you can enter conversion rates manually or by running the Apply Missing Conversion
Rates program.
Conversion rate type
Specify the default conversion rate type when you enter invoices or create payments.
You can change the conversion rate type at invoice entry or payment creation time.
Realized gain and loss distributions
Specify the realized gain and loss accounts for payments. If a conversion rate changes
between the time the invoice is entered and the time of payment, the realized gain or
loss is calculated and recorded to these accounts.
Expense Accruals
Specify when to accrue for expense items.
 Period end: During period close, accrual entries are created for all receipts that
do not have invoices. Accrual entries are reversed when the next period is
opened.
 Receipt: During receiving, accrual entries are created. You can override this
setting on the purchase order schedule for expense destination types.
Specify a default expense accrual distribution for use in purchase orders.
Self-Billed Invoices
Self-billed invoices are:
 Evaluated Receipt Settlement (ERS) invoices that are automatically created by

the Pay on Receipt process in Oracle Fusion Receiving.
 Debit memos that are automatically created from a return to a supplier
transaction in Receiving.
Set automatic invoice numbering options for self-billed invoices.
 Gapless invoice numbering: Enable gapless invoice number generation.

 Buying Company Identifier: Enter an identifier to use as part of the
automatically generated invoice number.
Legal Entity Information
Define a legal entity for each registered company or other entity recognized in law for
which you want to record assets, liabilities, and income, pay transaction taxes, or
perform intercompany trading.
Subledger applications, like Oracle Fusion Payables, use the legal entity model to
identify the legal entity that owns an invoice. Legal entity information is used for tax
calculations, legal reporting, and to classify whether an invoice between two entities is
an intercompany transaction.
Specify values for:
 VAT Registration Member State and VAT Registration Number: If business

operations are carried out in a member state of the European Union. These
values are used in Value Added Tax (VAT) reporting.
 Bill-to Location: The default bill-to location for purchase orders if a bill-to
location is not already specified on a supplier site assignment.
NOTE: Student Activity Manage Common Options for Payables and Procurement.
Knowledge Check: Common Options
The default distributions for conversion rate variance gain and loss record
variances for expense items that are accrued on receipt.
1. True
2. False
You can override the default freight distribution during invoice entry.
1. True
2. False
The method of automatic offset by primary balancing segment builds the liability
entry line account using the invoice liability distribution and overriding the
primary balancing segment with the one from the charge distribution.
1. True
2. False
Knowledge Check: Common Options Answers
The default distributions for conversion rate variance gain and loss record
variances for expense items that are accrued on receipt.
1. True
You can override the default freight distribution during invoice entry.
1. True
The method of automatic offset by primary balancing segment builds the liability
entry line account using the invoice liability distribution and overriding the
primary balancing segment with the one from the charge distribution.
1. True
Defining General Payables Options
The Define General Payables Options task list consists of the following tasks:
 Manage Invoice Options

 Manage Payment Options
 Manage Tax Reporting and Withholding Tax Options
For each business unit with the Payables Invoicing business function, define the
controls and default values to use throughout Oracle Fusion Payables.
Defaulting Flow
Unlike Oracle E-Business Suite, in Oracle Fusion Payables default values do not flow
from Payables options to a supplier site because:
 The business unit for a supplier site has the Procurement business function,
which could be different from the business unit for Payables.
 A supplier site can have more than one business unit assigned to it using
supplier site assignment.
You can set some of these options directly on a supplier, in which case the supplier
setup determines the default value for an invoice.
General Payables Options Terminology
The following terms are applicable to the General Payables Options tasks:
Invoice Distribution
The accounting information for an invoice line, such as accounting date, amount, and
account combination.
Invoice Group
A collection of invoices that is used as:
 A parameter in reports.
 A parameter in the invoice validation process.
 Selection criteria for pay run processing.
Invoice Request
An invoice created through Oracle Fusion Supplier Portal that is not associated to a
purchase order and that is pending approval by the requester.
Matching
The process of associating an invoice with a purchase order or receipt. Used to ensure
that you pay only for goods and services that were ordered or received.
Final Matching
A process that changes the status of a purchase order schedule to final close and
prevents further invoicing.
Pay Group
A method for categorizing suppliers for payment processing.
Payment Process Request

A grouping of installments that are processed for payment in a batch. For each request,
you specify selection criteria, payment attributes, and processing options.
Payment Request
A request from Oracle Fusion Receivables or Oracle Fusion Expenses to disburse
funds to a payee who is not defined as a supplier. Recorded in Oracle Fusion
Payables with an invoice type of Payment request.
Self-Service Invoice
An invoice that a supplier enters through Oracle Fusion Supplier Portal.
Tolerance
The allowed variance between invoice, purchase order, and receipt information. The
invoice validation process places matching holds on invoices that exceed the allowed
variance.
Withholding Tax Group

A collection of one or more withholding tax codes. Used to associate more than one
withholding tax code to an invoice.
Manage Invoice Options
Invoice options control how Oracle Fusion Payables processes invoices and are
grouped into the following categories:
 Invoice Entry
 Matching
 Approval
 Discount
 Payment Request
 Prepayment
 Self-Service Invoices
Invoice Entry
Project > Define General Payables Options > Set business unit scope > Manage
Invoice Options
The following options are set at a business unit level only:
 Require invoice grouping: Enable this option to require the name of a group
during invoice entry.
 Allow document category override: Enable this option to override the
document category that is assigned to an invoice. Document category usage is
based upon the value of the profile Sequential Numbering Enforced.
 Allow adjustments to paid invoices: Enable this option to cancel or add lines
to paid invoices such that paid amount remains the same. You can also unmatch
an invoice from a purchase order that is not final matched, and then rematch the
invoice to a different purchase order.
 Recalculate invoice installments: Enable this option to recalculate installment
information during the invoice validation process.
 Receipt acceptance days: Enter the number of days to accept receipts. Receipt
acceptance days are added to the Goods Received Date when recalculating
installments.
 Accounting date basis: Select the basis for the default accounting date.
- Goods received or invoice date: If the invoice does not have a date for goods
received, the invoice date is used.
- Goods received or system date: If the invoice does not have a date for goods
received, the system date is used.
- Invoice date: The date on the invoice.

- System date: The system date when the invoice is created.
The following options can be set for a business unit and for a supplier site. If a value is
not specified for a supplier site, the invoice options value is used.
 Currency: Select the default currency.

 Pay group: Select the default pay group.
 Payment priority: Select the default payment priority.
 Payment terms: Select the default payment terms.
 Terms date basis: Select the basis for determining the terms date.
- Goods received date: The date the goods are received.
- Invoice date: The date on the invoice.
- Invoice received date: The date the invoice is received.
- System date: The date the invoice is entered.
 Pay date basis: Specify the basis for determining whether an installment is
selected for payment and whether a discount is taken.
- Discount date.
- Due date.
Matching
Invoice Options
The following options are set at the business unit level only:
 Allow final matching: Enable this option to perform a final match when
matching to a purchase order or when adjusting a matched invoice distribution.
Once you final match to a purchase order, any subsequent matching of that
purchase order to invoices results in the invoices being placed on hold.
 Allow matching distribution override: Enable this option to override the
invoice distribution that was created from matching an invoice to a purchase
order.
 Transfer PO distribution additional information: Enable this option to transfer
descriptive flexfield information from the purchase order distribution to the invoice
distribution when you match an invoice to a purchase order.
The following options can be set for a business unit and for a supplier site. If a value is
not specified at a supplier site, the invoice options value is used.
 Quantity tolerances: Select a quantity-based tolerance set.

 Amount tolerances: Select an amount-based tolerance set.
NOTE: If you define tolerances after this task, you can edit the Manage Invoice
Options page to include them later.
Discount
Invoice Options
The discount options are:
 Exclude tax from calculation: Enable this option to exclude tax from an invoice
when calculating the discountable amount for an installment.
 Exclude freight from calculation: Enable this option to exclude freight from an
invoice when calculating the discountable amount for an installment.
 Discount allocation method: Specify how to distribute discounts: All invoice
lines, Tax lines and single distribution, or Single distribution.
 Always take discount: Enable this option to take the available discount,
regardless of when you pay the invoice.
You can set each of the following options on a supplier site to Yes, No, or Default from
Payables Options. The supplier site setting determines how the option is used.
 Exclude tax from calculation.

 Exclude freight from calculation.
 Always take discount.
Prepayment
Invoice Options
The prepayment options are as follows:
 Payment terms: Specify the default payment terms for a prepayment. For
example, you may want to have Immediate payment terms for all prepayments.
 Settlement days: Enter the number of days to add to the system date to
calculate a default settlement date for a prepayment. You cannot apply a
prepayment to an invoice until on or after the settlement date.
 Use distribution from purchase order: Enable this option to build the invoice
distribution by taking the purchase order distribution and overriding the natural
account segment with the natural account segment from the supplier site
prepayment distribution or, if not defined, from the common options prepayment
distribution.
 Show available prepayments during invoice entry: Enable this option to
display the number and amount of available prepayments when you enter an
invoice.
Approval
Approval options control the automated invoice approval process.
Oracle Fusion Payables provides configurable predefined invoice approval rules as well
as the ability to add rules using the Approval Management extensions (AMX) of the
Oracle SOA Suite and Oracle Human Workflow. The invoice approval process
determines if an invoice requires approval, and if so, automatically routes the invoice to
the applicable approvers who then approve or reject the invoice.
Invoice Options
The approval options are as follows:
 Enable invoice approval: Enable this option to automate the invoice approval
process using the invoice approval workflow.
 Allow force approval: Enable this option to allow a user with the Accounts
Payable Manager job role to override the automated invoice approval process
and approve invoices manually.
 Require validation before approval: Enable this option for the invoice approval
workflow to select invoices for processing only when they are validated. Self-
service invoices that are not matched to purchase orders always require approval
before validation, regardless of the option setting.
 Require accounting before approval: Enable this option for the invoice
approval workflow to select invoices for processing only when they are
accounted.
Interest
Interest invoices are invoices that Oracle Fusion Payables creates automatically for
overdue invoices. An interest invoice is created and paid while you are paying an
overdue invoice.
The interest options are as follows:
Invoice Options
 Create interest invoices: Enable this option to calculate interest on overdue

invoices and create interest invoices. To use automatic interest rate calculation,
you must also define interest rates. You can set this option on a supplier site to
Yes, No, or Default from Payables Options.
 Minimum interest amount: Enter the minimum amount of calculated interest
below which an interest invoice is not created.
 Interest allocation method: Select the method for allocating interest expense.
- Single distribution: Use the interest expense distribution.
- All invoice lines: Use the natural account segment from the interest expense
distribution.
 Interest expense distribution: Enter the distribution combination for interest
expense if the option Interest allocation method is set to Single distribution.
Payment Request
Oracle Fusion Receivables can submit requests for customer refunds and Oracle
Fusion Expenses can submit requests for expense reports. Create payments to
disburse funds using the payment functionality in Payables.
The payment request options are as follows:
Invoice Options
 Payment terms.
 Pay group.
 Payment priority.
Implementation Considerations
Manage payment requests separately from other payments using the following setups in
Oracle Fusion Payments:
 Payment method controls.

 Payment method defaulting rules.
 Payment file and report formats.
 Payment attribute validations.
NOTE: In Oracle Fusion Payables, employees are no longer modeled as suppliers

unlike Oracle E-Business Suite.
Self-Service Invoices
Oracle Fusion Supplier Portal lets registered suppliers create invoices, view invoices,
and view payments. When a supplier creates an invoice that is not matched to a
purchase order, the invoice is initially recorded in Payables as an Invoice request.
Once an Invoice request is approved by the requester, the request becomes an
invoice.
The self-service invoice options are as follows:
Invoice Options
 Limit invoice to single purchase order: Enable this option to limit an invoice to
purchase order schedules that belong to a single purchase order.
 Allow invoice backdating: Enable this option to allow a supplier to enter an
invoice for a date in the past.
 Allow unit price change for quantity-based matches: Enable this option to
allow a supplier to enter a unit price on an invoice that is different from the unit
price on the purchase order. Select from among the following values: No, Price
decrease only, Price increase only, and Price increase or decrease.
NOTE: Student Activity Manage Invoice Options.
Manage Payment Options
Payment Options
The payment options are:
 Allow payment date before the system date.

 Allow override of the supplier site bank account.
 Account for payment.
Account for Payment
Specify when to create payment accounting entries by setting the Account for
Payment option.
At payment issue
Debit the liability account and credit the cash account. For a bills payable, debit the
liability account and credit the bills payable account. Then, at payment maturity, debit
the bills payable account and credit the cash account. Realized gain or loss is
calculated at payment creation and, for bills payable, at payment maturity.
At payment clearing
Debit the liability account and credit the cash account when the payment clears.
Realized gain or loss is calculated only at payment clearing for both regular payments
and bills payables.
NOTE: You should enable this option only if Oracle Fusion Cash Management is
implemented. Otherwise, payments will never be accounted.
At payment issue and clearing

Payables accounts for each payment at:
 Issue time: Debit the liability account and credit the cash clearing account. For
bills payable, debit the liability account and credit the bills payable account. Then,
at payment maturity, debit the bills payable account and credit the cash clearing
account.
 Clearing time: Debit the cash clearing account and credit the cash account. This
accounting is created only if Cash Management is implemented.
Realized gain or loss is calculated at all points where accounting is created.
Implementation Consideration
After you set the Account for Payment option, the only change you can make is from
account At payment issue to account At payment issue and clearing.
NOTE: Student Activity Manage Payment Options.
Manage Tax Reporting and Withholding Tax Options
Tax reporting and withholding tax options control United States (US) 1099 tax
reporting and withholding tax calculations.
Income Tax Reporting
In the United States, the Internal Revenue Service (IRS) requires that you report certain
types of payments that you make to US 1099 reportable suppliers.
Withholding Tax
You may be required to withhold tax from invoices and pay it to a tax authority on behalf
of the supplier.
Income Tax Reporting
Project > Define General Payables Options > Set business unit scope > Manage Tax
Reporting and Withholding Tax Options
Income tax reporting options control combined federal and state US 1099 filing.
 Use combined filing program: Enable to produce state records for all tax
regions participating in the Combined Filing program that have qualifying
payments.
 Use supplier tax region: Enable to use the income tax region on a US 1099
supplier as the default tax region on invoice distributions.
 Income tax region: Enter the default income tax region for invoice distributions
of US 1099 suppliers if you enable the Use combined filing program option and
do not enable the Use supplier tax region option.
Withholding Tax
Project > Define General Payables Options > Set business unit scope > Manage Tax
Reporting and Withholding Tax Options
The withholding tax options are as follows:
 Use withholding tax: Enable withholding.

 Allow manual withholding: Enable this option to create and adjust manual
withholding tax lines.
 Include withholding distributions in income tax reports: Enable this option to
include federal tax withheld for US 1099 suppliers on US 1099 reports.
 Tax group: Select the default withholding tax group for invoices.
 Apply withholding tax: Select when to withhold.
- Never: Payables will not automatically withhold taxes. You must create
withholding tax lines manually.
- At invoice validation: Taxes are automatically withheld at invoice validation. If
you select this option, Payables calculates withholding only once. If you adjust an
invoice after it was validated, you must adjust the withholding tax manually and
the option Allow manual withholding must be enabled.
- At payment: Taxes are automatically withheld when you create payments in a
payment process request or with a Quick payment.
 Create withholding tax: Enable to automatically create withholding tax invoices
to remit withheld taxes.
- Never: Payables will not automatically create withholding tax invoices. You
must create withholding tax lines manually, run the withholding tax reports to
determine the amounts to remit to your tax authorities, and create the withholding
tax invoices.
- At invoice validation: A withholding invoice is automatically created when an
invoice subject to withholding tax is validated. You can enable this option only if
withholding is applied at invoice validation time.
- At payment: A withholding invoice is automatically created when an invoice
subject to withholding tax is paid. You can enable this option if withholding is
applied either at invoice validation or at payment.
 Withholding amount basis: Specify whether to include discount and tax
amounts when calculating withholding tax.
Withholding Tax Options on a Supplier
Supplier site assignment includes the following options which, if specified, provide the
default value for an invoice.
 Use withholding tax.

 Withholding tax group.
Knowledge Check: General Payables Options
You must define general Payables options for all of your business units.
1. True
2. False
The values for general Payables options flow to supplier site setup.
1. True
2. False
When you account for payment at payment issue, the liability account is debited
and the cash account is credited when you create a payment.
1. True
2. False
An invoice request becomes an invoice when the invoice request is:
1. Validated
2. Approved
3. Paid
4. Canceled
Knowledge Check: General Payables Options

Answers
You must define General Payables Options for all of your business units.
2. False. Define General Payables Options for business units with the
Payables Invoicing business function.
The values for general Payables options flow to supplier site setup.
2. False. General Payables options do not flow to supplier sites because a supplier site
can have more than one invoicing business unit assigned to it through site assignments.
When you account for payment at payment issue, the liability account is debited
and the cash account is credited when you create a payment.
1. True.
An invoice request becomes an invoice when the invoice request is:
2. Approved.
Defining Payables Configuration
The Define Payables Configuration task list includes the following tasks:
 Manage Payables Lookups

 Manage Payables Descriptive Flexfields
 Manage Payables Profile Options
 Manage Payables Document Sequences
 Manage Distribution Sets
 Manage Invoice Tolerances
 Manage Invoice Holds and Releases
 Manage Aging Periods
Manage Payables Lookups
Lookups are containers for the list items that appear in an application. Users select one
of the items from such lists to enter a value on the application user interface.
Payables has several predefined lookups. Some lookups, such as Invoice Type, have
a customization level of System and are locked for editing. Other lookups, such as Do
Not Pay Reason and Source have a customization level of Extension, which allows
you to add lookup codes.
The following figure shows the predefined lookup type Valid Pay Groups, which has a
customization level of User. You can edit this lookup type and its codes.
Payables > Define Payables Configuration > Manage Payables Lookups
NOTE: For more information, see the Define Lookups topic in the Appendix.
Manage Payables Descriptive Flexfields
There are several Payables descriptive flexfields that you can deploy for use, such as
Invoices and Invoice Lines.
The following figure shows general information for the descriptive flexfields Invoices
and Invoice Lines.
Payables > Define Payables Configuration > Manage Payables Descriptive
Flexfields
NOTE: For more information, see the Descriptive Flexfields topic in the Appendix.
Manage Payables Profile Options
Profile options are global configuration settings that users can modify to change the way
an application works. For example, settings such as user preferences and application
configuration parameters can be modified as per the user's requirements.
Define Payables Configuration > Manage Payables Profile Option
Oracle Fusion Payables has one profile option. The Reconciliation Data Purge
Frequency profile option specifies the number of days to keep Payables to Oracle
Fusion General Ledger reconciliation extract data.
Every time you run the Extract Reconciliation Data from Payables to General
Ledger program, the program refers to the Reconciliation Data Purge Frequency
profile option. Extraction requests that are older than the number of days specified in
the profile option are purged.
Set the interval in such a way that it does not interfere with the reconciliation time line.
The number of days should be long enough so as not to lose prior extracts that may be
needed for comparison purposes.
Example
If you set the Reconciliation Data Purge Frequency profile option to 30 and run the
extraction program on:
NOTE: For more information, see the Define Profile Options topic in the Appendix.
Manage Payables Document Sequences
Assign a unique voucher number to each invoice and payment document to have a
unique identifier for each document.
Define Payables Configuration > Manage Payables Document Sequences
Example
You may get two invoices with identical invoice numbers from two different suppliers. If
you assign a voucher number to each invoice, you can locate each invoice based on its
unique voucher number. Voucher numbers provide proof of completeness. If you use
sequential voucher numbers, you can confirm that no document was lost.
Document Sequences
When defining a new sequence, you must enter the name of the table that stores
sequence audit information. For document sequences used by Oracle Fusion Payables,
the audit table name is AP_DOC_SEQUENCE_AUDIT.
Document Categories
Set up document sequencing for different types of documents or document sequence

categories. For example, you may decide to assign a sequence of numbers to the
document category Credit Memo Invoices. Each credit memo that you create will have
a unique voucher number.
Predefined Document Categories
There are several predefined document categories that you can use in document
sequencing, such as the following:
 Standard Invoices
 Credit Memo Invoices
 Debit Memo Invoices
 Interest Invoices
 Electronic Payments
 Check Payments
 Clearing Payments
NOTE: For more information, see the Define Document Sequences topic in the
Appendix.
Manage Distribution Sets
Distribution sets automatically create distributions for invoices that are not matched to
purchase orders.
Define Payables Configuration > Manage Distribution Sets
For example, create a distribution set that allocates the advertising expense on an
invoice to four advertising departments. Add the distribution set to a supplier site
assignment to use it on every invoice for that supplier site and business unit. If you do
not assign a distribution set to a supplier site, you can assign a distribution set to an
invoice at invoice entry.
Define distribution sets either with percentages or without percentages.
Distribution Sets with Percentages
Use a 100 percent distribution set when the percentage of expenses to allocate is
known.
For example, define a fully allocated distribution set for a rent invoice by assigning 70
percent of the invoice amount to the sales facility expense account and 30 percent to
the administration facility expense account.
Distribution Sets Without Percentages

Use a 0 percent distribution set when the percentage of expenses to allocate is not
known.
For example, define a distribution set with no amounts allocated to the sales facility
expense account and the administration facility expense account. You can then enter
amounts for the distributions during invoice entry depending on variables such as the
monthly head count for each department.
Manage Invoice Tolerances
Invoice tolerances are the allowed variances between invoice, purchase order, and
receipt information.
If variances exceed the specified tolerances, the invoice validation process places an
invoice on hold. For example, if the billed quantity for an item exceeds the quantity
tolerance, invoice validation applies a hold on an invoice preventing payment until the
hold is released.
There are quantity-based tolerances and amount-based tolerances. For each type of
tolerance, you specify percentage or amount limits.
The following figure shows an example of a quantity-based tolerance. The Ordered

Percentage tolerance has a limit of five percent. Ordered Percentage is the
percentage difference above the purchase order schedule line ordered quantity that you
allow suppliers to invoice. In this case, an Ordered quantity hold will be placed on an
invoice if the five percent limit is exceeded.
Payables > Define Payables Configuration > Manage Invoice Tolerances
NOTE: A percentage tolerance of zero indicates that no variance is allowed. An active

tolerance without a tolerance limit value indicates that unlimited variance is allowed.
Manage Invoice Holds and Releases
Define the holds and releases that you manually apply to an invoice. You cannot pay an
invoice that is on hold. Predefined holds and releases are used during the invoice
validation process.
Releasing Holds
Some predefined holds can be released manually. Other holds require that you fix the
exception condition before the hold can be released.
For example, if the sum of the distributions on an invoice does not equal the invoice line
amount, a Distribution variance hold is placed on the invoice. You cannot manually
release a Distribution variance hold. Instead, you must correct the exception condition
by adjusting the distribution amounts and validating the invoice again.
Predefined Holds and Releases
This figure provides examples of some predefined holds and releases.
Payables > Define Payables Configuration > Manage Invoice Holds and Releases
Manage Aging Periods
Aging periods define the day ranges and column headings for the Payables Invoice
Aging report.
Example
The following figure shows the definition of an aging period called Standard Monthly.
The First column, which is called Current, is defined to report invoices that are due for
payment up through 30 days prior to the day you submit the report. For example, if you
run the report on March 3, 2012, the Current column will include an invoice due on July
3, 2012, as well as an invoice due on February 2, 2012.
The Second column, which is called 31-60 Days Overdue, is defined to report invoices
that are due for payment 31 through 60 days prior to the day you submit the report. For
example, if you run the report on March 3, 2012, the 31-60 Days Overdue column will
include an invoice due on January 11, 2012.
Payables > Define Payables Configuration > Manage Aging Periods
Defining Payables US 1099 Tax
The setup tasks for United States (US) 1099 tax reporting are included in the Define
Payables Tax and Withholding task list.
 Manage Tax Regions

 Manage Reporting Entities
Manage Tax Regions
Use tax regions for United States (US) 1099 electronic media combined filing reporting.
Tax regions include reporting limit amounts and methods.
Payables > Define Payables Tax and Withholding > Manage Tax Regions
Reporting limit amounts represent the minimum amount for determining whether to
report on payments to a supplier. If no limit amount is specified, Payables assumes that
the limit is zero.
Reporting limit methods can be set to one of the following values:
 Same as federal: Uses the federal reporting limit instead of the region reporting
limit amount.
 Compare individually: Compares the reporting limit amount to the sum of

payments for each US 1099 miscellaneous income tax type.
For example, the reporting limit for region X is 600 USD. If you make a total of
two 400 USD payments to a supplier in region X, and classify each payment as a
different 1099 miscellaneous type, Payables does not report the supplier to
region X because neither individual payment type exceeded the region X
reporting limit. In this case, Payables reports the supplier only to the federal tax
authorities.
 Compare sum: Compares the reporting limit amount to the sum of payments for
all US 1099 miscellaneous income tax types.
For example, the reporting limit for region X is 600 USD. If you make a total of
two 400 USD payments to a supplier in region X, and classify each payment as a
different 1099 miscellaneous income tax type, Payables will report this supplier to
the region X tax authority because the sum of the payments exceeds the region
X reporting limit. In this case, Payables reports the supplier to both federal and
state tax authorities.
Manage Reporting Entities
A reporting entity is a person or organization that has a unique tax identification

number (TIN).
Reporting entities are used for United States (US) 1099 reporting. US 1099 reports
accumulate the totals for all primary balancing segment values that are assigned to a
reporting entity to derive the total amount paid.
For each reporting entity, assign one or more primary balancing segment values.
Payables > Define Payables Tax and Withholding > Manage Reporting Entities
Example
An enterprise defines a reporting entity called Headquarters, which is comprised of
Company 1, Company 2, and Company 3. Each company is represented by a primary
balancing segment value.
When submitting a US 1099 report, Headquarters is entered as the reporting entity.

Payables prints the accumulated payments for Companies 1, 2, and 3 on the US 1099
Report. The report sums up the paid invoice distributions that have these company
balancing segment values in their accounts.
Related Reports
 US 1096 Report
 US 1099 Report
 US 1099 Invoice Exceptions Report
 US 1099 Supplier Exceptions Report
 US 1099 Payments Report
 US 1099 Electronic Media Report
Defining Payment Options

Manage Interest Rates
The Define Payment Options task list consists of the Manage Interest Rates task.
Define interest rates for calculating and paying interest on overdue invoices.
You can add, change, or delete a rate at any time. Interest is calculated using the
interest rate in effect the day after the invoice is due. When a rate is not defined, there is
no interest calculated and no interest invoice created.
Payables > Define Payment Options > Manage Interest Rates
Invoice Approval Rules
Oracle Fusion Payables provides predefined configurable rules for invoice approval.
You can:
 Add rules using the Approval Management extensions (AMX) of the Oracle
SOA Suite and Oracle Human Workflow.
 Administer rules using the Oracle Business Process Management (BPM)
Worklist Application interface.
Every invoice that requires approval must be approved before the invoice can be paid.
When you initiate approval for an invoice, the invoice approval task invokes a set of
approval rules created in AMX to build the list of approvers. AMX sends out approval
notifications to the first set of approvers, and every time it receives a response to an
approval notification, AMX sends out approval notifications to the next set of approvers
on the approval list. This process is repeated until all approvals are complete.
Invoice Request Approval
An invoice request is an invoice created through Oracle Fusion Supplier Portal that
is not associated to a purchase order and that is pending approval by the requester.
Once a requester approves an invoice request, the invoice request becomes an invoice.
You cannot disable or configure this initial approval flow.
Set up additional approvals for an invoice request after the initial approval by the
requester, by configuring the rule set InvoiceRequestApprovalRuleSet. The rule set
contains a predefined rule called IgnoreInvoiceRequestApprovalRuleSetRule, which
ignores participants. To use the rule set, delete the predefined rule and then add new
rules.
The following figure shows the predefined rule for the rule set
InvoiceRequestApprovalRuleSet.
Project > Define Common Applications Configuration for Financials > Define
Approval Management for Financials > Manage Task Configurations for
Financials > FinAPInvoiceApproval (11.1.2.0.0) link > Data Driven tab >
InvoiceRequestApprovalRuleSet
Invoice Approval
The rule set InvoiceApprovalRuleSet contains the following predefined rules:
 ManagerApprovalRule: Approval of an invoice with an amount greater than or

equal to 1000 by an immediate supervisor.
 AutoApprovalRule: Automatic approval of an invoice with an amount less than
1000.
The following figure shows the predefined rule for the rule set
InvoiceApprovalRuleSet.
Project > Define Common Applications Configuration for Financials > Define
Approval Management for Financials > Manage Task Configurations for
Financials > FinAPInvoiceApproval (11.1.2.0.0) link > Data Driven tab >
InvoiceApprovalRuleSet
NOTES:
 To use predefined rules, you must change the user name for the Top
Participant field to the highest approver in the supervisory hierarchy to whom
the invoice approval must be sent.
 For more information on approvals, see the Approval Management topic in the
Appendix.
Predefined Approval Task
The FinApInvoiceApproval task configuration has event-driven and data-driven

settings. The event-driven settings define escalation, expiration, and notification
policies. The data-driven settings define assignment and routing policies, and consist
of the following predefined rule sets:
 InvoiceRequestApprovalRuleSet for invoice request approval.

 InvoiceApprovalRuleSet for invoice approval.
The following figure shows the predefined task FinApInvoiceApproval and its
predefined rule sets.
Setup and Maintenance work area > Implementation Projects tab >
XXImplementation Project > Define Common Applications Configuration for
Financials > Define Approval Management for Financials > Manage Task
Configurations for Financials > FinAPInvoiceApproval (11.1.2.0.0) link > Data
Driven tab
NOTE: For more information, see the Define Approval Management topic in the
Appendix.
Defining Subledger Accounting Rules
Begin configuring Oracle Fusion Subledger Accounting from the Setup and
Maintenance work area.
Define Subledger Accounting Rules Task List
Implementation Projects > <Your implementation project>. Expand your specific
product task list to access the Define Subledger Accounting Rules task list.
This graphic displays the tasks to complete to set up Subledger Accounting for your
product. You can determine the task lists and tasks that are included when you define
the Configure Offerings attributes. You can include either the Manage Subledger
NOTE: See the Oracle Fusion Accounting Hub Implementation guide for additional
Initial Setups
the Oracle Financials offering.
Subsequent Maintenance
 Choose your implementation project.

 Set the context by choosing an existing subledger application as the scope.
 Access the setup tasks from the task list.
Payables Event Classes and Types
Oracle Fusion Payables provides predefined accounting event classes and

accounting event types. You can modify the accounting setup to create accounting for
some events and not for others.
The following table lists the predefined event classes and event types.
 Explain key concepts in Oracle Fusion Payables.

 Explain automated invoice processing.
 Define common options for Payables and Procurement.
 Define general Payables options.
 Define Payables configuration.
 Define Payables US 1099 tax.
 Define payment options.
 Explain invoice approval rules.
Lesson 9: Configuring Oracle Fusion Payments - Payables
Lesson 9: Configuring Oracle Fusion Payments -

Payables
After completing this lesson you should be able to:
 Set up formats: Mandatory setup.

 Set up transmission configurations: Mandatory setup if you are going to
transmit to a payment system or bank.
 Set up payment systems: Mandatory setup if you are going to transmit any
electronic payment information.
 Set up system security options: Optional, but very strongly recommended.
 Set up disbursement payment methods: Optional since Payments predefines
many payment methods.
 Set up payment method defaulting rules: Optional setup.
 Set up payment codes: Optional setup.
 Set up payment process profiles: Mandatory setup.
 Set up disbursement system options: Optional setup.
Setups and the Disbursements Process
The following concepts are applicable to setups and the disbursements process.
 Payment method: The method, such as electronic or check, by which your

company, pays a supplier invoice, customer refund, or employee expense report.
 Validations: Rules used to verify that transactions are valid and contain all
required attributes before further processing is performed. Validations can be
performed on documents payable, payments, or payment files.
 Payment process profile: Defines how Oracle Fusion Payments manages the
document payable, payment, and payment file throughout the payment process
steps.
 Payment process request: A grouping of documents payable selected for

payment processing. This grouping is originated by the invoice selection process.
The payment process request contains one or more documents payable to be

paid and optional payment processing instructions.
 Document payable: A transaction, such as an invoice, that is selected for
payment. Typically, these are represented by Oracle Fusion Payables invoice
payment installments. Similar documents payable are grouped together into
payments during the payment process.
 Payment: A transfer of funds to a supplier, customer (for refunds), or employee
(for expense reimbursements).
 Payment creation rules: User-defined rules for grouping documents payable
into payments.
 Payment file: A grouping of payments to be paid the same way, along with
aggregate payment information. The payment file is transmitted to a bank for
further processing and payment or printed as a check run.
 Payment file creation rules: User-defined rules for grouping payments into
payment files.
 Bank instructions: Codes and text that appear in the electronic payment, which
are used to provide additional payment processing instructions for the intended
payment system.
 Format: A data file on which an Oracle Business Intelligence Publisher (Oracle
BI Publisher) template is used that contains prescribed formatting attributes, such
as location, font, and font size. Formats enable payment systems or financial
institutions to understand transactional messages.
 Transmission configuration: Specifies specific transmission details, which
must be associated with one transmission protocol.
 Payment system: A data file on which an Oracle Business Intelligence Publisher
(Oracle BI Publisher) template is used that contains prescribed formatting
attributes, such as location, font, and font size. Formats enable payment systems
or financial institutions to understand transactional messages.
 Payment file register: A report that displays the contents of a payment file.
 Positive pay: A document sent by your company to its payment system or bank
to inform it of payments made by check.
 Separate remittance advice: A notice sent to an external payee that lists the
invoices your company has electronically paid to the external payee's bank
account.
 Regulatory report: Reports required by a regulatory body, such as a level of
government, the central bank, or an individual bank.
Overview of Disbursements for Oracle Fusion

Payments
Oracle Fusion Payments is a product in Oracle Fusion Applications, which serves as a

disbursement and funds capture engine for other Oracle Fusion Applications. As the
central payment engine, Payments processes transactions, such as invoice payments
from Oracle Fusion Payables and settlements against credit cards and bank accounts
from Oracle Fusion Receivables. Payments provides the infrastructure needed to
connect these applications and others with payment systems and financial institutions.
The centralization of payment processing in Payments offers many benefits to your

company. Your company can efficiently centralize the payment process across multiple
business units, currencies, and geographical regions.
This Disbursements module covers selected disbursement setups of Payments.

Disbursement is the process of paying funds owed by your company to creditors, such
as suppliers. A payment can take an electronic form, such as EFT or wire, or a printed
form, such as a check. The Define Disbursements activity allows you to configure the
ability to disburse funds by setting up payment methods with validations and setting up
payment process profiles.
Key Decision and Best Practices for Payment

Processing
Key Decision:
How much of the payment process should I automate?
Best Practice:
Any combination of manual and automated steps can be used. It is not desirable to be
completely automated or completely manual. The best practice is to automate
everything except manual review of either selected invoices or proposed payments.
Advantages of straight through processing:
 Fewer touch points require less effort.

 Exceptions are handled outside the payment process, whereas good
payments are not held up by the few exceptions.
Advantages of tight manual control:
 Allows manual review and confirmation of payments in process.

 Allows steps to be manually initiated to accommodate specific timing
needs.
Key Decision and Best Practices for Organizational

Structure
Key Decision:
Is my payment processing organizational structure centralized, decentralized, or a
payment factory?
Best Practice:
Advantages of decentralized processing:
 Enables each business unit to create its own payment process.

 Enables each business unit to decide who and when to pay.
Advantages of centralized processing:
 Reduces manpower costs by centralizing payment process decisions and

exception handling.
 Reduces payment processing costs by pooling payments into fewer payment

files.
 Efficiencies of scale allow some users to specialize in payment processing.
Advantages of a payment factory:
 Enables each business unit to decide who and when to pay.

 Reduces payment processing costs by pooling payments into fewer
payment files.
Key Decision and Best Practices for Payment

Selection Criteria
Key Decision:
What invoice selection criteria should I use?
Broad invoice selection criteria:
 Creates as few payment process requests as possible.

 Recommended for a Centralized Processing model.
 Payment process templates can be fewer and more generic.
Best practice: Ensure that only one payment process profile is active per unique set of
transactional attributes (business unit, payment method, disbursement bank account,
and currency).
Expenses can then derive the payment process profile automatically per payment,
instead of forcing all payments in a payment process request to have the same payment
process profile.
Targeted invoice selection criteria:
 Creates as few payment process requests as possible.

 Recommended for a Decentralized or Payment Factory model.
 Allows different types of payments to be managed in separate processes,

such as expense reports on Monday, domestic supplier payments on
Tuesday, and so on.
Best practice: Create specific payment process templates for each type of payment
using pay groups, payment priorities, or other targeted selection criteria.
Configuring Payment System Connectivity
Setup and Maintenance work area > All Tasks tab > Search field: Task Lists and
Tasks > Name field: Payments > Search button > Define Invoicing and Payments
Configuration folder > Configure Payment System Connectivity folder.
This section of the lesson covers the following tasks in the Configure Payment System
Connectivity setup activity:
 Manage Formats
 Manage Transmission Configurations
 Manage Payment Systems
NOTE: Whether you implement only the Define Disbursements setup activity, only the
Define Funds Capture setup activity, or both, you must also perform set up tasks for
the Configure Payment System Connectivity setup activity.
Prerequisites for Configuring Payment System Connectivity
Before you can set up the Configure Payment System Connectivity activity, you
must define the following prerequisites in the Setup and Maintenance Area work
area within the Financials offering:
 Define legal entities.

 Define business units.
 Define internal bank accounts (disbursement bank accounts of the
deploying company).
 Define Oracle Business Intelligence Publisher (Oracle BI Publisher)
templates.
For information on the Define Legal Entities for Financials task list, see the Defining
Enterprise Structures lesson in this course.
For information on the Define Business Units task list, see the Defining Enterprise
Structures lesson in this course.
Setup and Maintenance work area > Search: Tasks region > Name field: set up
banks > right arrow icon.
TIP: You must set up banks, bank branches, and the deploying company's
internal bank accounts. For information on the Set Up Banks, Branches, and
Accounts task list, see the Manage Banks, Manage Bank Branches, and Manage
Bank Accounts lessons in this course. For additional information on setting up the
bank account, see the Cash Management lesson in this course.
NOTE: On the Create Bank Account page, you select whether the internal bank
account (disbursement bank account of the deploying company) will be used for Oracle
Fusion Payables, Oracle Fusion Receivables, and/or Oracle Fusion Payroll.
Format Concepts
The following concepts are applicable to formats:

 Data extract: Transactional data that is extracted from the Oracle Fusion
Payments and Oracle Fusion Receivables transactional tables. For the funds
capture extract, data can be from funds capture transactions, settlement batches
and Receivables transactions. For disbursement and related extracts, data
comes from the payments, payment files, and document payables tables.
 BI Publisher template: A document belonging to an Oracle application that
defines the layout of various types of formats according to formatting
requirements of specific financial institutions.
 Message direction: Inbound from payment system to your company, or

outbound, from your company to your payment system.
Formatting Messages
Successful transmission of a message, whether a payment file, a positive pay file, or

other type of content, requires coordination between sender and receiver. The sender
must format the message according to payment system or regulatory specifications, so
the receiver can understand it and process it correctly.
The message must:
 Adhere to prescribed standards so it can navigate the transmission path to

the receiver.
 Identify the sender and convey specific details about the relationship
between the sender and receiver.
The transactional data that is available to the formatting process is contained in a data
extract. A format is applied to the data in a data extract and the result is a formatted
file, such as a payment file, positive pay file, or other output.
Validations can be associated with formats and are used to ensure valid transaction
data.
Manage Formats
Configuration folder > Configure Payment System Connectivity folder > Manage
Formats task > Go to Task icon > Manage Formats page.
In Oracle Fusion Payments, formatting is the placement of data in a file by using an

Oracle Business Intelligence Publisher (Oracle BI Publisher) template that contains
prescribed formatting attributes, such as data location, font type, and font size. Banks,
payment systems, and countries have specific electronic formatting requirements for
payment files and settlement batches.
Each format in Payments corresponds to one Oracle BI Publisher template. Payments

uses Oracle BI Publisher templates to format funds capture and funds disbursement
transactions according to the formatting requirements of specific financial institutions
and payment systems.
The purpose of setting up formats is to associate them with Oracle BI Publisher

templates to correctly format funds capture and disbursement transactions.
You can use existing Oracle BI Publisher templates or modify them with minimal effort
by using a standard text editor, such as Microsoft Word. For example, when a payment
system or financial institution requires a change to its payment file format, the change
can be made quickly by modifying the appropriate Oracle BI Publisher template.
Payments has given special consideration to the complexity of creating fixed position
and delimited formats. Oracle BI Publisher's eText feature is used for these format
types. eText allows the format layout to be presented in an understandable tabular
structure.
On the Manage Formats page, the first step in setting up a format is to select the
specific type of format you want to set up.
You perform subsequent setup steps on the Create Format page where you associate
a specific Oracle BI Publisher template with the type of format up are setting up. Note
that multiple types of formats can be used for a single payment system. Examples of
different types of formats include disbursement payment file formats and funds
capture settlement formats.
Formats task > Go to Task icon > Manage Formats page > Select Type of format >
Create button > Create Format page.
You can also assign validations, whether predefined or user-defined, to validate

transactions that use the format you are setting up.
PREREQUISITE: Before you can set up formats, you must set up the corresponding
templates in Oracle Business Intelligence Publisher (Oracle BI Publisher). To set
up Oracle BI Publisher templates, see the guide entitled Oracle Fusion Middleware
Report Designer's Guide for Oracle Business Intelligence Publisher, which you can
view at http://docs.oracle.com/cd/E25054_01/bi.1111/e13881/toc.htm.
Key Decision and Best Practices for Using Formats
Key Decision:
What formats should I use?
Best Practice:
Favor standards-based payment formats that can be used with multiple banks.
 EDIFACT formats, such as PAYMUL, MT100, and MT103.

 NACHA formats, such as Generic, CCD, PPD.
Find out what payment formats your processing bank supports.
Modify predefined payment formats using Oracle BI Publisher.
 An XML extract provides Payments data.

 Use .rtf templates to create or modify layouts for checks and reports.
 Use eText files to create fixed-position layouts for transmission and automated
payment processing.
 For a detailed discussion of tailoring formats to your needs, see Working with
Fusion Payments Formats: Article ID 1413989.1 on Oracle Support
(http://oracle.support.com).
Transmission Configuration Concepts
The following concepts are applicable to payments transmission:
 Transmission protocol: Defines the method of transmission. Examples include

File Transfer Protocol and HTTP Put.
 Tunneling configuration: A type of transmission configuration that helps
transmit data through a transmission servelet that can securely connect to your
payment system without exposing internal data.
Manage Transmission Configurations
Transmission Configurations task > Go to Task icon > Manage Transmission
Configurations page.
To set up a transmission configuration, the first step is performed on the Manage

Transmission Configurations page where you select a specific protocol, which is the
method of transmission.
The second step is performed on the Create Transmission Configuration page where
you enable electronic connectivity with your payment system by specifying parameter
values for the protocol you selected in the first step.
Transmission Configurations task > Go to Task icon > Manage Transmission
Configurations page > Select Protocol > Create button > Create Transmission
Configuration page.
A transmission configuration defines a value for each parameter in a transmission

protocol. The values in a transmission configuration are specific to one payment
system or financial institution. For example, a transmission protocol may require
parameters, a Socket IP Address, and a Socket Port Number. Your payment system,
which accepts that protocol, will give you the values that it expects to receive for those
parameters. Those values are entered in the Socket IP Address and Socket Port
Number fields.
NOTE: The transmission configuration is subsequently assigned in the funds capture

process profile for funds capture transactions or in the payment process profile for
disbursements.
.
Key Decision and Best Practices for Using Transmission

Configurations
Key Decision:
Which transmission configurations should I use for payment processing?
Best Practice:
You need two transmission configurations:
 A tunneling configuration to exit the firewall.

 A transmission configuration for the payment system server.
Your transmission configuration must point to the tunneling configuration.
NOTE: The tunneling configuration should not point to any other tunneling configuration,
including itself.
Key Decision and Best Practices for Using Transmission

Protocols
Key Decision:
Which transmission protocols should I use for payment processing?
Best Practice:
Find out what your processing bank supports.
Favor transmission protocols that are predefined in Oracle Fusion Payments.
Use funds capture process profiles for greater configurability in transmission and
formatting.
Payment System Concepts
The following concepts are applicable to payment systems:
 Payment system: An external organization that provides financial settlement

services. Payment systems process electronic funds capture transactions and
disbursements. The payment system can be the bank at which your company
has its bank accounts or it can be a third party processor that connects
companies and financial institutions.
 Payment system account: An entity that represents your company's account
with its payment system.
 Processor payment system: A service provider that interacts directly with
banks and card institutions such as Visa, MasterCard, and American Express to
process financial transactions.
 Gateway payment system: A service provider that acts as an intermediary

between your company and a payment processor.
 Internal payee: Your company, which receives funds from customers by credit
card payments or direct debits to bank accounts.
 Internal payer: Your company, which makes disbursements. Your company
disburses funds to pay suppliers, to make customer refunds, and to reimburse
employee expenses.
 Payment instrument: A credit card, debit card, or bank account used by your
company to collect a payment from an external payer, such as a customer.
A payment system has specific transmission requirements, which are
represented by the following questions:
 What formats is it capable of receiving?

 What transmission protocols does it understand?
 What attributes does it require in the messages it receives to identify the
sender or process the message?
Manage Payment Systems
Payment Systems task > Go to Task icon > Manage Payment Systems page >
Create button > Create Payment System page.
A payment system is an external organization that provides financial settlement

services. The payment system can be the bank at which your company has its bank
accounts or it can be a third-party processor or gateway that connects companies and
financial networks.
Your company may choose payment systems to process its funds capture
settlements and, possibly, its electronic disbursement payment files. Payment
systems are not required for printed disbursement payments, such as checks, but may
be required for related services, such as positive pay or other reporting.
The purpose of setting up payment systems is to define the external organizations that
Oracle Fusion Payments collaborates with to process your funds capture and
disbursement transactions.
When setting up a payment system on the Create Payment System page, you
perform the following actions:
 Specify the types of payment instruments the payment system will support
for funds capture transactions.
 Specify which file formats and transmission protocols are accepted by the
payment system.
Settings Required by Payment System
The Settings Required by Payment System region allows you to specify the settings
that the payment system requires from each internal payer or payee. These settings can
be used to identify the internal payer or payee as a client of the payment system, or to
provide other processing information. You can specify the type of data required for each
setting and whether the setting's values should be secured by masking them.
NOTE: The payment system generally provides the values for these settings, which you
enter as part of the payment system account.
Payment System Account
Your relationship with the payment system is defined on the Edit Payment System
Accounts page as a payment system account. The payment system account
contains a relationship-specific value for each of the attributes required by the payment
system. For example, the payment system may require a Submitter ID and Submitter
Password to be included in any message sent to it. Each attribute is represented by a
setting on the payment system account.
Payment Systems task > Go to Task icon > Manage Payment Systems page >
Create button > Create Payment System page > Save and Add Accounts button >
Edit Payment System Accounts page.
NOTE: You can have multiple processing relationships with a payment system, so
multiple payment system accounts can be set up in Payments for a specific payment
system.
Key Decision and Best Practices for Using Payment Systems
Key Decision:
What payment systems should I use for funds capture payment processing?
Best Practice:
Leverage existing banking or processing relationship:
 Your bank may process transactions or have a partnership with a processor.

Leverage the following processor with existing integrations with Oracle Fusion
Payments:
 Chase Paymentech (certification pending).

NOTE: Student Activity, Setting Up a Disbursement Payment File and Funds
Capture File Formats, a Transmission Configuration, a Payment System, and a
Payment System Account
Defining Disbursements
Configuration folder > Define Disbursements folder.
The Define Disbursements activity allows implementers to configure the ability to

disburse funds, such as setting up payment methods with validations and setting up
payment process profiles.
The setup for implementing Oracle Fusion Payments is provided in the Setup and
Maintenance work area as part of the Financials offering. This section of the lesson
covers the Define Disbursements setup activity.
This section of the lesson covers the following setup tasks:
 Manage payment methods.

 Manage payment method defaulting rules.
 Manage payment codes.
 Manage payment process profiles.
 Manage disbursement system options.
Prerequisites for Defining Disbursements
Before you can set up the Define Disbursements setup activity, you must define
the following prerequisites in the Setup and Maintenance Area work area within
the Financials offering:
 Define legal entities.

 Define business units.
 Define internal bank accounts of the deploying company.
 Define payment system.
 Define formats.
 Define transmission configuration.
 Set up Oracle Business Intelligence Publisher templates.
For information on the Define Legal Entities for Financials task list, see the Manage
Legal Entity lesson in this course.
For information on the Define Business Units task list, see the Manage Business
Units lesson in this course.
TIP: You must set up banks, bank branches, and the deploying company's
internal bank accounts. For information on the Set Up Banks, Branches, and
Accounts task list, see the Manage Banks, Manage Bank Branches, and Manage
Bank Accounts lessons in this course.
NOTE: On the Create Bank Account page, you select whether the deploying
company's internal bank account will be used for Oracle Fusion Payables, Oracle
Fusion Receivables, and/or Oracle Fusion Payroll.
To define payment systems, see the section entitled Configuring Payment System
Connectivity in this lesson. You have already completed this setup.
To define formats, see the section entitled Configuring Payment System

Connectivity in this lesson. You have already completed this setup.
To define transmission configurations, see the section entitled Configuring Payment

System Connectivity in this lesson. You have already completed this setup.
To set up Oracle Business Intelligence Publisher templates, see the guide entitled
Oracle Fusion Middleware Report Designer's Guide for Oracle Business
Intelligence Publisher, which you can view at
http://docs.oracle.com/cd/E25054_01/bi.1111/e13881/toc.htm.
Payment Method Concepts
The following concepts are applicable to payment methods:
 Payment method: The method, such as electronic or check, by which your

company, pays a supplier invoice, customer refund, or employee expense report.
 Usage rules: Usage rules for payment methods determine which payment
methods are valid to be used on which documents payable.
 Validations: Rules used to verify that transactions are valid and contain all
required attributes before further processing is performed. Validations can be
performed on documents payable, payments, or payment files.
 Internal payee: Your company, which receives funds from customers by credit
card payments or direct debits to bank accounts.
 Payment method defaulting rule: Rule for determining which payment method
is defaulted by Payments onto the document payable during entry.
 Source product: Product that submitted the payment request.
 Source document: Product from which a document originates, such as an
invoice in Oracle Fusion Payables and a customer refund in Oracle Fusion
Receivables.
Manage Payment Methods
A disbursement payment method is a method of payment that your company uses to

pay a supplier, customer, or employee. The payment method can be electronic, such
as EFT or wire; or printed, such as a check. You can use a disbursement payment
method to pay one or more external payees.
The purpose of creating disbursement payment methods is to:
 Define the disbursement payment methods you want to use to make

payments.
 Define usage rules to limit the use of disbursement payment methods to
specific business units, legal entities, and other attributes.
 Assign validations to disbursement payment methods for running on
documents payable, payments, and payment files.
Level of Granularity
The level of granularity that you need for your disbursement payment methods is a
factor to consider before you define them. You must decide whether to set up more or
less granular disbursement payment methods.
The least granular payment methods are those that are predefined in Oracle Fusion
Payments, such as Check or Electronic. With this approach, you can associate each
payment method with many payment process profiles and payment formats. This
approach requires less knowledge from source product users, such as invoice entry
clerks, but may involve more work later in the payment process
Alternately, you can define more granular payment methods. When you do this, you
can benefit from adding validations to the payment method, which are targeted for
specific transactions. An example of a very granular payment method is Italian EFT, to
which you might add a validation that is specific to Italy. With a more granular setup,
validations are run early during invoice entry and thus, errors can be fixed more quickly.
When you use very granular payment methods, it is important to also set up payment
method defaulting rules, so there is no added burden during invoice entry to manually
select one appropriate payment method from the many available. You can also use
supplier-specific defaults, an optional feature which can be enabled in the Payment
Method Default Basis region on the Manage Disbursement System Options page.
When you need to override the default, usage rules narrow the list of payment methods
by displaying only those that match invoice attributes.
Creating Usage Rules for Payment Methods
Configuration folder > Define Disbursements folder > Manage Payment Methods
task > Go to Task icon > Create icon > Create Payment Method page.
When creating a disbursement payment method in Oracle Fusion Payments, you create
usage rules on the first tab. Usage rules specify when a disbursement payment method
can be used on documents payable by source products. By creating usage rules for
payment methods, you enable or disable payment methods for each source product
integrated with Payments. You can provide different usage rules for different source
products and change whether and when the payment method is available.
By default, payment methods are available on all transactions, but by creating

usage rules for payment methods on the Usage Rules tab of the Create Payment
Method page, you can limit the use of a payment method based on the following
transaction conditions:
 Source product.
 Business unit.
 First party legal entity.
 Transaction type.
 Domestic or foreign currency.
 Domestic or foreign payee location.
Not all source products that are integrated with Payments have usage rule options.
Some products, such as Oracle Fusion Fixed Assets, create transactions that are
imported into Oracle Fusion Payables, and are included in Payables usage rules. Other
products, such as Oracle Fusion Expenses, have fixed usage rules on supported
payment methods.
The payment method that the source product user sees in the source product depends
on the usage rules specified. For example, suppose you have a payment method that is
specific to one country. You could create a usage rule so that the payment method is
available for only the one business unit associated with that country. A user entering an
invoice for any other business unit would not see that payment method available to
select. Usage rules, combined with payment method defaulting rules and user-
definable validations, make straight-though processing possible.
Using Validations
Validations are rules that ensure that transactions are valid before they are printed or
submitted electronically to payment systems. You use validations to ensure that
disbursement transactions, such as invoices, payments, and payment files meet specific
conditions before they can be paid. You can assign validations to payment methods
and payment formats. A validation can be executed at the document payable, payment,
or payment file level.
In payment processing, it is critical that payment files sent to payment systems and
financial institutions are valid and correctly formatted. If this is not done, the payment
process is slowed, which results in additional time and cost due to problem resolution.
Oracle Fusion Payments helps you achieve straight-through processing by ensuring
that payment-related details are valid.
Oracle Fusion Payments always validates as early as possible for a given object and
setup. Document payable validations that are associated with payment methods are
enforced earlier in the process than those associated with formats. If you want
validation failures to be handled by the same person who is entering the invoice, you
can opt to associate the validation with the payment method. This is ideal for business
processes where each person has full ownership of the items entered. However, if you
want focused invoice entry, while validation failures are handled centrally by a specialist
or a more knowledgeable user, you can opt to associate the validation with the format.
To assign validations, you can choose from the following options:
 Creating user-defined validations.

 Choosing from a library of predefined validations.
The following table shows the objects you can validate and when validations are
executed for the applicable setup.
Creating or Assigning Validations to Payment Methods
Configuration folder > Define Disbursements folder > Manage Payment Methods
task > Go to Task icon > Create icon > Create Payment Method page.
When creating a disbursement payment method in Oracle Fusion Payments, you create
or assign validations on the second tab. Validations are associated with the payment
method and they catch errors during entry on documents payable.
On the Validations tab of the Create Payment Method page, you can assign
predefined validations or create user-defined validations for this payment method.
Validations are rules that check the validity of documents payable, payments, or
payment files.
Creating User Defined Validations
A user-defined validation explicitly specifies the object to which the validation

applies:
 Document payable.
 Payment.
 Payment file.
User-defined validations are basic validations that correspond to simple operations.
These validations can be used as components, or building blocks, to build more
complex validations. For example, user-defined validations enable you to validate the
following conditions:
Length of a value.
Example: Payment Detail must be less than 60 characters for your bank-specific
payment file format.
Whether a field is populated.

Example: Remit-to bank account is required when payment method is Electronic.
Whether content of a field is allowed.

Example: Currency must be USD when using your domestic payment file format.
Choosing Predefined Validations
Payments provides a library of predefined validations. You can associate these

predefined validations with any payment method or payment file format you create.
Many of the payment formats provided by Oracle have predefined validations
associated with them by default.
Predefined validations are groups of individual validations that work together for a
specific purpose. Many of the predefined validations that you can associate with
payment formats are country-specific. Predefined validations cannot be modified,
although some have parameters you can set to define specific values.
Key Decision and Best Practices for Validations
Key Decision:
What validations do you need?
Best Practice:
Use predefined validations designed to match specific formats.
Add comprehensive validations for any transaction attribute to ensure that you
catch errors before they are sent to the bank.
 Layer them on top of predefined validations when formats or regulations change.

 Use them to create entirely new validations for your own formats.
Associate validations with a payment method so documents payable are
validated during invoice entry.
 Provides immediate feedback.

 Resolves errors and makes payments quickly.
 Requires knowledgeable invoice entry personnel.
 Requires a larger number of payment methods with different, associated
validations.
Validate after the payment process request submission if the validation is
associated with a format.
 Allows a specialized payment process manager to resolve errors.

 Allows fewer payment methods.
 Requires less knowledgeable invoice entry personnel.
Manage Payment Method Defaulting Rules
Configuration folder > Define Disbursements folder > Manage Payment Method
Defaulting Rules task > Go to Task icon > Manage Payment Method Defaulting
Rules page > Create button > Create Payment Method Defaulting Rule page.
A payment method defaulting rule determines which payment method defaults onto a
source document, such as an invoice in Oracle Fusion Payables or a customer refund in
Oracle Fusion Receivables. During setup of the payment method defaulting rules, you
specify conditions under which a payment method acts as a default.
A payment method can default onto a source document based on:
 Source product.
 Business unit.
 First party legal entity.
 Transaction type.
 Whether domestic or foreign currency.
 Whether domestic or foreign payee location.
Oracle Fusion Payments applies the payment method defaulting rules in the prioritized
order you specify. For example, if the first rule is a match, Payments stops and defaults
that rule's corresponding payment method onto the invoice. Further, suppose you
specify that the payment method for all documents processed by Payables is first,
Check, and second, EFT. In this case, if the conditions for payment method Check
match those on the invoice, then payment method Check defaults onto the invoice.
If the conditions for payment method Check do not match those on the invoice, then
Payments determines whether the conditions for payment method EFT matches. If the
conditions for payment method EFT match those on the invoice, then payment method
EFT defaults onto the invoice.
The following factors may, depending on setup and data, influence payment
method defaulting:
 Whether the option, Based Only on Payment Method Defaulting Rules

Setup, or the option, Override Defaulting Rules when Default Method Set
for Payee, is selected as the payment method default basis in the System
Settings subregion or Business Unit Level Override region on the Manage
Disbursement System Options page.
 The prioritized order of the payment method defaulting rules.
 The content of the payment method defaulting rules, compared with the
attributes of the transaction.
 The defaults set in Oracle Fusion Payables for supplier, address, and
supplier site.
Manage Payment Codes
To locate the Manage Payment Codes task, navigate as follows:
Tasks > Name field: Enter Payments > Click Search button > Expand Define
Invoicing and Payments Configuration folder > Expand Define
Disbursements folder.
Oracle Fusion Payments enables you to specify payment codes that are required by
financial institutions. Payment codes can provide details to banks or payment systems
about transaction handling, bank charges, or payment reasons.
Types of payment code include the following:
 Bank instruction codes.
 Delivery channel codes.

 Payment reason codes.
Configuration folder > Define Disbursements folder > Manage Payment Codes task
> Go to Task icon > Manage Payment Codes page > Create button > Create
Payment Code dialog box.
From the Type choice list, you can select the type of payment code you wish to create.
Note that Local instrument, as seen in the choice list, is not available in FusionV1.
NOTE: It is during invoice entry that you select an applicable payment code or it
defaults from the applicable supplier or supplier site.
Bank Instruction Codes
Bank instruction codes are values that contain information or instructions that need to
be passed to a bank or financial institution at the payment file level. Up to two bank
instructions can be entered on a payment process profile. When that payment
process profile is used during the creation of a payment file, the bank instruction values
are copied directly to it. The values are made available to the formatting process by the
extract. If the payment format specifies the use of one or both bank instructions, the
value or values will be passed to the bank in the header level of the payment file.
Payments provides many predefined bank instruction codes.
Delivery Channel Codes
Delivery channels are instructions that tell the bank how to make the payment to the
payee. A default delivery channel value can be set on the supplier or supplier site. A
value defaults from the lowest of these levels with a value populated, onto the invoice in
Oracle Fusion Payables. On the invoice, it is displayed with the installments and can be
manually overridden there.
When an installment is paid, the delivery channel is copied from the document payable
to the payment, only if all documents payable in the payment have the same delivery
channel value. By enabling delivery channel as a document grouping rule on the
payment process profile that is used, you can ensure that documents payable will
only be grouped into a payment with other documents payable when they all have the
same delivery channel value.
Payments provides many predefined delivery channel codes.
Payment Reason Codes
Payment reason codes are generally country-specific identifiers provided by a

country's government or central bank. These codes provide the payment system or
bank with additional details about the reason for the payment for regulatory reporting
purposes.
Payments provides many predefined payment reason codes.
Prerequisites for Defining Payment Process Profiles
Before you can set up a payment process profile, you must complete the
following setups:
Payment format
--Configure Payment System Connectivity task list.
Payment system
Payment system account

Transmission configuration
Payment method
--Define Disbursements task list.
Configuration folder > Define Disbursements folder.
Payment Process Profile Concepts
The following concepts are applicable to payment process profiles.
 Payment process profile: Defines how Oracle Fusion Payments manages the
document payable, payment, and payment file throughout the payment process
steps.
 Document payable: A transaction, such as an invoice, that is selected for
payment. Typically, these are represented by Oracle Fusion Payables invoice
payment installments. Similar documents payable are grouped together into
payments during the payment process.
 Payment process request: A grouping of documents payable selected for
payment processing. This grouping is originated by the invoice selection process.
The payment process request contains one or more documents payable to be
paid and optional payment processing instructions.
 Payment: A transfer of funds to a supplier, customer (for refunds), or employee

(for expense reimbursements).
 Payment file: A grouping of payments to be paid the same way, along with
aggregate payment information. The payment file is transmitted to a bank for
further processing and payment or printed as a check run.
 Payment file register: A report that displays the contents of a payment file.
 Positive pay: A document sent by your company to its payment system or bank
to inform it of payments made by check.
 Separate remittance advice: A notice sent to an external payee that lists the
invoices your company has electronically paid to the external payee's bank
account.
 Regulatory report: Reports required by a regulatory body, such as a level of
government, the central bank, or an individual bank.
Manage Payment Process Profiles
A payment process profile is a payment attribute assigned to documents payable,

which specifies how Oracle Fusion Payments manages the following throughout the
payment process:
 Documents payable.
 Payments.
 Payment files.
The processing type, which can be Electronic or Printed, drives much of the rest of
the setup. If you change the processing type, different fields are available.
Configuration folder > Define Disbursements folder > Manage Payment Process
Profiles task > Go to Task icon > Manage Payment Process Profiles page > Create
button > Create Payment Process Profiles page.
Payment process profiles include several types of information, such as specifications for
payment file formatting and transmission. The payment method and other invoice
attributes drive the assignment of a payment process profile to each document payable,
and the payment process profile drives every subsequent step of the payment process.
A payment process profile controls payment processing for the disbursement

flow and provides a blueprint to:
 Tie setups together.

 Control usage of the payment process profile.
 Specify payment formatting, printing, and transmission behavior.
 Control creation of payments and payment files.
 Automate report generation.
Creating Usage Rules for a Payment Process Profile
button > Payment Process Profile page.
A payment process profile specifies the details of the disbursement payment process,
such as specifications for document payable grouping, payment grouping, and payment
file formatting.
By default, payment process profiles are available on all transactions, but by

creating usage rules, you can limit the use of a payment process profile based on
the following transaction conditions:
 Payment method.
 Disbursement bank account.
 Business unit.
 Currency.
Controlling the Use of Payment Process Profiles
When you set up a payment process profile, you specify the values on a transaction that
are compatible with it. You can specify whether the payment process profile can be
used on a specific document payable based on its payment method, disbursement bank
account, business unit, and currency. For example, if the payment format associated
with the payment process profile only allows a specific currency, then enter that
currency in the usage rules so that the payment process profile can only be used on
documents payable with the appropriate currency.
The payment process profile that is applied to a document payable depends, in part, on
the usage rules specified on the Usage Rules tab of the Create Payment Process
Profile page. When you submit a payment process request, Payments compares the
attributes of each transaction to the payment process profile provided on the Submit
Payment Process Request page. Any transactions whose attributes are in conflict with
that payment process profile's usage rules will fail validation. If no payment process
profile has been selected, Payments compares the attributes of each transaction to all
existing payment process profiles to determine if there is one payment process profile
for which the usage rules are a unique match with the transaction attributes. If a match
does not occur, a custom hook implementation or user intervention is needed to
determine the appropriate payment process profile to use.
Enabling Straight-Through Processing
To enable straight-through processing, it is important that usage rules be no broader

than necessary. For example, having two payment process profiles in which the usage
rules could both apply to the same document payable will lead to user intervention to
differentiate between the two. However, if one of the two is specific to Business Unit X
and the other to Business Unit Y, then there is no ambiguity and the system can
uniquely identify which payment process profile to apply to the document payable
without user intervention.
Specifying a Payment System for an Electronic Payment

Process Profile
button > Create Payment Process Profiles page.
Specifying Transmission Behavior
When you set up a payment process profile, you specify whether it can be used for
printed or electronic payment processing. As the implementors, you tie the payment
system and transmission configuration setup entities into the payment process profile.
This defines where and how files are transmitted. The transmitted file will be either a
payment file or, if the process is creating printed documents, a positive pay file.
If the payment process profile will be used for electronic payment processing, you also
select a payment system and enter details that allow the application to electronically
transmit files to that payment system within the context of a payment system account.
A payment system account is information that represents your processing relationship
with your payment system.
If the payment process profile will be used for printed payment processing, a payment
system is not required for payment file handling, but you can optionally select a
payment system and transmission details so the system can electronically transmit
positive pay files to your bank. A positive pay file is a document that you send to your
payment system or bank to inform it of payments made by check.
Specifying Document Behavior for a Payment Process Profile
button > Create Payment Process Profile page.
Controlling Creation of Payments
When you set up a payment process profile, you specify document grouping rules
and document limits. These settings are used when grouping documents payable into
payments.
An enabled grouping rule for an attribute means that two documents payable that share
the same value for an attribute can be grouped into the same payment. If the values are
different, they will be in separate payments. A disabled grouping rule for an attribute
means that the attribute will not apply when documents payable are built into payments.
Payment Detail Formula
A payment detail formula is a custom PL/SQL expression that drives the informational
text that is sent to the bank or payment system for each payment. The Payment Detail
Formula field on the Create Payment Process Profile page, Payment tab, Document
Limits region, must contain a PL/SQL expression written by a database administrator.
This PL/SQL expression, which can reference columns of the documents payable table,
is used by Oracle Fusion Payments to generate payment detail in the form of text that
becomes part of the payment.
An example of a payment detail formula is PO_NUMBER || ' ' ||

CALLING_APP_DOC_REF_NUMBER || ';'. This formula tells the application to create
payment detail by concatenating the purchase order number and the source product's
document payable reference, separated by a space. For example, suppose there are
two documents payable in the payment. If document payable ABC associated with PO
123 is combined with document payable DEF associated with PO 124, then the
concatenation for the documents payable in the payment results in the following
payment detail:
123 ABC;124 DEF;
When the Build Payments program builds documents payable into payments, it uses
the PL/SQL expression you entered in the Payment Detail Formula field to generate
text from fields in the document payable table. This informational text displays in the
Payment Details field in the Remittance Information region on the Payment page.
Payments then places the payment detail text into the applicable payment format.
Depending on the bank or payment system and the format type, the financial institution
may process the payment detail text into its system, or it may just use the payment
detail text as information only.
Specifying Payment Behavior for a Payment Process Profile
button > Create Payment Process Profile page > Payment File tab.
Controlling Creation of Payment Files
Payment grouping rules determine which attributes the application uses to group
payments into payment files. As the implementors, you can set rules to determine which
payments can be grouped together into payment files and which cannot. You can also
limit the total amount or number of payments in a payment file.
Additional controls that you can specify include:
 Naming and location of output files.

 Payment sorting rules.
 Bank instruction message text .
Specifying Report Generation for a Payment Process Profile
button > Create Payment Process Profile page > Reporting tab.
Generating Automatic Reports
Finally, when you set up a payment process profile, you can specify your preferences
for reports, including formats and report conditions, as well as automated report
generation.
The following reports are available for automatic generation when the payment
process profile is used:
 Payment file register.

 Positive pay.
 Separate remittance advice.
 Regulatory report.
NOTE: Student Activity, Setting Up an Electronic Payment Method, a Payment
Method Defaulting Rule, a Payment Process Profile, and a Report
Manage Disbursement System Options
Configuration folder > Define Disbursements folder > Manage Disbursement
System Options task > Go to Task icon > Manage Disbursement System Options
page.
Disbursement system options are system-wide payment options that control
disbursements made by the internal payer to suppliers. Oracle Fusion Payments
provides two levels of system options; enterprise-level system options and business
unit-level system options, by operating unit or legal entity. The purpose of setting up
disbursement system options is to specify how the payment process runs at the
enterprise and business unit-levels.
The internal payer, or deploying company, that disburses payments can set system
options for payment features. Payments predefines one enterprise-level system option
on the Manage Disbursement System Options page. When you access this page,
you can view the default system options for the entire enterprise. Enterprise-level
system options are updateable if you have been assigned security update permission.
NOTE: You can only view and update those business units to which you have security
access.
 Set up formats.
 Set up transmission configurations.
 Set up payment systems.
 Set up system security options.
 Set up disbursement payment methods.
 Set up payment method defaulting rules.
 Set up payment codes.
 Set up payment process profiles.
 Set up disbursement system options.
Lesson 10: Configuring Oracle Fusion Assets

 Explain Oracle Fusion Assets functions.

 Manage Assets key flexfields and value sets.
 Manage system controls.
 Manage fiscal years and calendars.
 Manage locations.
 Manage asset books.
 Manage asset categories.
 Review optional implementation steps.
Understanding Oracle Fusion Assets
Oracle Fusion Assets is part of the Oracle Asset Lifecycle Management solution.
It is a complete asset management solution that accurately maintains the
financial information of your property and equipment, and helps you to meet
global accounting and tax requirements.
Oracle Fusion Assets:
 Automates asset management and simplifies fixed asset accounting tasks.

 Uses a unified source of asset data to provide visibility into your assets
worldwide.
 Provides data and function security.
 Uses automated business flows to streamline standard asset management tasks,

such as asset additions, asset transfers, disposals, reclassifications, financial
adjustments, and legacy data.
Oracle Fusion Assets Lifecycle
Oracle Fusion Assets:
 Supports the end-to-end asset lifecycle from asset acquisition to retirements.

 Improves the capital asset management by providing more visibility, tracking, and
control for the capital assets.
Assets Tasks
Use Assets to perform standard asset management tasks:
 Additions
 Financial adjustments
 Reclassifications
 Transfers
 Retirements
Legacy Data Conversions
Assets provides automated business flows to help streamline data conversions from
other systems.
Accounting
Assets adapts to various countries' tax and accounting laws to accommodate fluctuating
economies, unplanned depreciation, and other unforeseen circumstances.
Reports
Assets provides standard accounting, operational, and registry reports for ease of
reconciliation and analysis.
Use reports to inform the fixed asset manager of additions, transfers, retirements, or
other changes, ensuring that the asset information remains accurate.
NOTE: Instructor Demonstration Viewing an Asset
Implementing Oracle Fusion Assets
Implementing Oracle Fusion Assets requires:
 Planning and setting up Assets-specific information, such as: key flexfields,

system controls, fiscal years, calendars, categories, locations, depreciation rules,
and asset books.
 Converting and reconciling existing asset information from and with the
previous system.
There are four implementation phases to be considered when planning your Assets
implementation:
 Planning the Implementation
 Setting Up Oracle Fusion Assets

 Converting Existing Asset Information
 Reconciling with the Previous System
Planning Your Implementation
Consider your organizational structure and business dimensions. By carefully

evaluating your business needs, you can design and set up Oracle Fusion Assets to
take advantage of its flexible tools for recording and maintaining asset information.
Implementation planning includes the following:
 Inquiring About Your Company's History

 Obtaining Existing Asset Information
 Determining the Conversion Period
 Decide on Oracle Assets Setups
Inquiring About Your Company's History
Before implementing Oracle Fusion Assets, ensure you have answered the following
questions:
 What accounting changes have occurred in the company's history?

 Have the calendar, fiscal year, or prorate rules changed?
 Has the company been acquired or have there been any mass adjustments?
 What are the future plans of the company?
 What is the strategic plan of the company?
 How may future events affect the accounting procedures of the company?
Obtaining Existing Asset Information
Based on your existing asset information:
 Decide how to bring the information into Oracle Fusion Assets. Consider the new
implementation as an opportunity to clean up the asset data.
 Obtain and review the existing asset information and how the company is
currently maintaining its asset inventory. Find out, for example, what data is
available, how many assets exist, and what detailed information is stored.
 Determine the location of the data, how to access it, the type of format it is in,
and who has the authority to access the information.
 Decide how to import the information into Oracle Fusion Assets by using the
Mass Additions interface table FA_MASS_ADDITIONS. Consider using the
Assets features of the Oracle Application Development Framework (ADF)
Desktop Integration.
Determining the Conversion Period
Determine the best time to convert your assets:
 Many companies find that it is convenient to convert at fiscal year-end because

year-end numbers are easy to reconcile, and year-to-date figures are correct in
the new year.
 If you convert in mid-fiscal period, consider keeping the previous assets
system running in parallel with Oracle Fusion Assets until year-end for
reconciliation, if possible.
Decide on Oracle Assets Setups
Decide on key Oracle Fusion Assets setup steps such as:
 Key Flexfield Structures

 Asset Books
 Asset Categories
 System Controls
 Fiscal Years and Calendars
 Prorate Conventions
 Locations
 Asset Keys
NOTE: These steps will be discussed in more detail later on in this lesson.
Prerequisite Setup
The following steps are prerequisites before implementing Oracle Fusion Assets:
Oracle Fusion General Ledger
 Ledgers
 Currencies
 Currency Rates
 Conversion Rate Types
 Cost Center as a segment in the chart of accounts (optional)
Human Capital Management (HCM): Employees
Oracle Fusion Payables: Suppliers
Financials Common Module: Reference Data Sets
Oracle Fusion Subledger Accounting: Accounting Methods
Oracle Fusion Assets Implementation Steps
Begin in the Setup and Maintenance work area > Select the All Tasks tab > In the
Search region, enter Define Fixed Assets Configuration in the Name field > Select
the Search button.
It is recommended that Oracle Fusion Assets implementation steps be performed in

the following order (required setups are in bold and marked with an asterisk):
 Manage Fixed Assets Value Sets*

 Manage Fixed Assets Key Flexfields*
 Manage System Controls*
 Manage Fiscal Years*
 Manage Asset Keys
 Manage Asset Locations*

 Manage Asset Calendars*
 Manage Prorate Conventions*
 Manage Asset Books*
 Manage Asset Categories*
 Define Subledger Accounting Rules

 Manage Depreciation Methods
 Manage Bonus Rules
 Manage Ceilings
 Manage Distribution Sets
 Manage Fixed Assets Profile Options
 Manage Fixed Assets Lookups
 Manage Fixed Assets Descriptive Flexfields
Managing Assets Key Flexfields and Value Sets
You must define the following three key flexfields:
Asset Category Flexfield
The Asset Category flexfield groups assets by financial information.
Asset Location Flexfield
The Asset Location flexfield groups and tracks assets by physical location.
Asset Key Flexfield
The Asset Key flexfield groups assets based on non-financial information.
Value Sets
Before defining key flexfields, you must first define value sets for each segment you
plan to use for your flexfields.
NOTE: Assets flexfields will be discussed further in later topics.
Managing System Controls
System controls provide information about the structure of your company.
Defining Your System Controls
Navigate to: Setup and Maintenance work area > Define Fixed Assets
Configuration > Manage System Controls
Enterprise Name
The enterprise name establishes the name that appears on Oracle Fusion Assets
reports.
Oldest Date Placed in Service

The oldest date placed in service controls what dates are valid to place assets in
service and on what date to begin your calendars. You can only update the oldest date
placed in service before you assign any calendars to depreciation books.
Flexfield Structures
 Define your company's Category, Location, and Asset Key flexfields

structures, which will be used to record transactions.
 Define your Category, Location, and Asset Key flexfields before defining
system controls.
 Configure flexfield segments to capture data that represents the values of
attributes.
 Define any number of segments for each flexfield, but Assets supports only one
structure.
NOTE: The administrator must choose a structure for each key flexfield that will be used
to record transactions.
Automatic Asset Numbering
The starting asset number defines the number to begin automatically numbering your
assets. Some asset numbers may be skipped.
Manually entered asset numbers must be less than the starting asset number
established for automatic numbering. For example, automatic numbering starts at
50,001; manual numbering must be between 1 and 50,000.
Mass additions can be automatically numbered with a unique number when using
the prepare mass additions automatically feature.
Asset numbers with a letter in them are not reserved for automatic asset numbering,
since the automatic numbers are a numerical sequence.
If you are converting from another system, you can enter a starting number greater
than the number of assets you want to convert so converted assets keep the same
number from the previous system.
Example: If you are converting 75,000 assets, you can enter 100,001 as the starting
number to reserve the numbers 1 to 100,000 for manual asset numbering. Note that
adding the 75,000 assets will increment the automatic numbering sequence by 75,000
and automatically numbered assets will begin at 175,001.
System Controls Implementation Considerations
Before setting up system controls, consider the following:
 You must define your Category, Location, and Asset Key flexfields before
defining system controls.
 The enterprise name is displayed on all reports. Ensure you define the
enterprise name appropriately.
 The oldest date placed in service controls the valid dates on which assets can
be placed in service and the date on which calendars begin.
 Automatic numbering of assets begins with the starting number defined in your
system controls, so you need to ensure that the starting number is appropriate.
Knowledge Check: System Controls
You must define your Category, Location, and Asset Key flexfield structures
before defining system controls.
1. True
2. False
Knowledge Check: System Controls Answer
You must define your Category, Location, and Asset Key flexfield structures
before defining system controls.
1. True
2. False
Managing Fiscal Years and Calendars
You must first define fiscal years. You then define asset calendars based on those fiscal
years.
Fiscal Years
Fiscal years group your accounting periods.
Calendars
Calendars are based on the fiscal years you set up.
 Depreciation calendar: Determines the number of accounting periods in a fiscal

year.
 Prorate calendar: Determines what rate is used to calculate annual depreciation
by mapping each date to a prorate period.
Defining Fiscal Years
A fiscal year is:
 A standard set of periods used to prepare annual financial statements for

reporting and tax purposes.
 Also referred to as a financial year or budget year.
 Normally a twelve-month period, but this varies from business to business and
country to country.
Defining Fiscal Years
 Define the start date and end date for each of your fiscal years starting from the
earliest date placed in service through at least one fiscal year beyond the current
fiscal year.
 Define at least one calendar for each fiscal year to break the fiscal year into
multiple reportable periods, such as months.
 Set up multiple fiscal years and assign different fiscal years to your different
corporate books to meet the various reporting and tax requirements.
Important
At the end of each fiscal year, the Calculate Depreciation program automatically
generates the dates for the next fiscal year and calendars, if they are not defined.
Fiscal Year Implementation Considerations
Before defining fiscal years, consider the following:
 Prepare a list of all the assets that need to be entered.

 Sort the assets in the order of the date placed in service.
 Ensure the calendar for the tax book uses the same fiscal year name as the
calendar for its associated corporate book.
Defining Asset Calendars
Calendars break down your fiscal year into accounting periods.
Define your calendars with as many periods as necessary for your reporting and tax
regulation requirements.
Asset books:
 Must have a depreciation calendar and a prorate calendar.

 Can use the same calendar as both the depreciation and prorate calendar.
Initially set up all calendar periods from the period corresponding to the oldest date
placed in service to the last day of the current fiscal year.
Set up at least one period before the current period. At the end of each fiscal year,
Oracle Fusion Assets automatically sets up the periods for the next fiscal year.
Example
To define a 4-4-5 calendar, set up your fiscal years, depreciation calendar, and prorate
calendar with different start and end dates, and fill in the uneven periods. You can
divide annual depreciation proportionately according to the number of days in each
period or evenly in each period.
Depreciation Calendar
The depreciation calendar determines the number of accounting periods in your

fiscal year.
Prorate Calendar
The prorate calendar determines what rate Assets uses to calculate annual
depreciation by mapping each date to a prorate period, which corresponds to a set of
rates in the rate table.
The Calculate Depreciation process uses the prorate calendar to determine the
prorate period that is used to choose the depreciation rate.
Calendar Implementation Considerations
Before defining calendars, consider the following:
 Corporate books can share the same calendar.

 Multiple books can use a single calendar.
 Tax books must use the same fiscal year as their associated corporate book.
 Tax books can have different calendars than their associated corporate
books.
 Depreciation and prorate calendars must be defined before defining asset
books.
 Different calendars can be set up for reporting and tax purposes, depending
upon statutory requirements.
 All calendar periods must be set up from the period corresponding to the oldest
date placed in service to the last day of the current fiscal year.
 At least one period must be set up after the current period.
 Define calendars only after you have finished defining system controls and
fiscal years.
Knowledge Check: Fiscal Years and Calendars
You must first define asset calendars before defining fiscal years.
1. True
2. False
Knowledge Check: Fiscal Years and Calendars

Answer
You must first define asset calendars before defining fiscal years.
1. True
2. False
You must first define fiscal years, and then you define asset calendars based on those
fiscal years.
Prorate Convention Concepts
Oracle Fusion Assets uses prorate and retirement conventions to determine how
much depreciation to take in the first and last year of an asset's life.
Assets can be acquired at any time in a given period. Therefore, prorate conventions
must account for every date in the fiscal year for assets to depreciate properly.
Other considerations:
1. The prorate convention and the date placed in service determine the prorate
date.
2. Assets uses the prorate date to determine the prorate period in your prorate
calendar.
3. Assets prorates the depreciation taken for an asset in its first fiscal year of
life according to the prorate date.
Example 1
You use the half-year prorate convention. The prorate date of all assets using that
convention is the midpoint of your fiscal year, so assets acquired in the same fiscal
year take the same amount (half a year's worth) of depreciation in the first year.
Example 2
You use the following month prorate convention. The prorate date is the beginning
of the month following the month placed in service, so the amount of depreciation
taken for assets acquired in the same fiscal year varies according to the month they
were placed in service.
Retirement Conventions
If you do business in a country that requires you to use a different prorate convention for
retirements than for additions, define retirement conventions to determine how much
depreciation to take in the last year of life, based on the retirement date.
If you retire the asset before it is fully reserved, then Assets uses the prorate date from
the retirement convention to determine how much depreciation to take in the asset's last
year of life.
Prorate Convention Implementation Considerations
Initially set up all your prorate conventions from the convention period
corresponding to the oldest date placed in service through the end of the current
fiscal year. At the end of each fiscal year, Assets automatically sets up your prorate
conventions for the next fiscal year.
Review your reporting authority's depreciation regulations. Your reporting

authority's depreciation regulations determine the amount of depreciation to take in the
asset's first year of life.
Example 1
Regulations require that you prorate depreciation according to the number of months
you hold an asset in its first fiscal year of life. In this case, your prorate convention has
twelve rate periods, one for each month of the year.
Example 2
Regulations require that you prorate depreciation according to the number of days that
you hold an asset in its first year of life. In this case, the fiscal year depreciation amount
would vary depending on the day you added the asset. Thus, your prorate convention
contains 365 prorate periods, one for each day of the year.
Align the prorate convention with the prorate calendar.
In the following example, you use the mid-month prorate convention:
NOTE: Student Activities Managing Fiscal Years and Managing Asset Calendars
Managing Asset Locations
Asset locations track the physical location of assets. Assets can be reported on and
transferred based on their locations.
 Define locations based on the current and anticipated future assignments of

assets.
 Ideally, use standardized location names or abbreviations where the names
are too long, since locations are used for grouping, tracking and reporting
purposes.
Location Key Flexfield Implementation Considerations
Planning Your Location Flexfield Structure
 Choose the number of segments, the length of each segment, the name, and the
order of each segment in your Location flexfield.
 Define the Location flexfield structure based on the asset tracking requirements
of your enterprise.
 Important: Plan your flexfield carefully. Once you begin entering assets using
the flexfield, you cannot change it.
Defining Your Flexfield Segments
 You must define a state segment and up to six other location segments.
 If you do business internationally (or plan to do so in the future), you should
create a segment for Country to track the country an asset is in.
 You may also want to include segments such as state, city, and site.
 If you track asset locations in more detail, for example, if you use barcodes, you
can also add segments for the building and room number.
 The location name (all segments concatenated) appears on forms and reports,
which display only a limited number of characters. You may want to abbreviate
some location segment values.
Defining Asset Locations
Define location combinations by using Location flexfield segment values.
Managing Asset Books
You can set up an unlimited number of independent asset books. Each book has its
own set of accounting rules and accounts so that you can organize and implement
your fixed assets accounting policies. When you define a tax book, you must specify an
associated corporate book.
NOTE: After a book is created, roles are automatically created and can be assigned
to users to provide access to the asset books.
Corporate Books
When defining asset books, keep in mind that corporate books:
 Hold all asset information and are used to post journal entries for all accounting
activity, including depreciation to the relevant primary ledger in accordance with
corporate policy and business practices.
 Must be assigned to a primary ledger.
Tax Books
When defining asset books, keep in mind that tax books:
 Are used to comply with statutory rules for depreciating assets. Data can be
copied from the corporate book on a regular basis, excluding depreciation
information.
 Can use a different calendar than their associated corporate book, provided
both calendars use the same fiscal year.
 Can optionally be used to post journal entries to either the corporate book's
primary ledger or to its secondary ledger.
Use the Perform Periodic Mass Copy process to transfer assets and transactions
from the corporate book to the tax book.
Asset Books and Ledgers, Subledgers, and Business

Units
When defining asset books, keep in mind the asset books' relationship to ledgers,
subledgers, and business units.
 Asset books are linked to ledgers.

 Asset books are not directly linked to business units.
 Business units are assigned to primary ledgers.
 Business units can interact with corporate asset books assigned to the same
ledger.
 Asset tax books provide alternative asset accounting.
In the following example:
 The corporate book is populated by Oracle Fusion Payables and business

units in the same primary ledger.
 The tax book is populated by Oracle Fusion Assets.
 The tax book uses alternate accounting.
 The tax book can post accounting entries to the corporate book's primary
ledger or to its secondary ledger, as required.
Asset Book Implementation Considerations
Consider the following when defining asset books:
 Access to asset data is secured at the asset book level.

 Define asset books according to your depreciation and accounting
requirements.
 Set the default accounts for retirement and deferred depreciation
transactions at the book level.
 Select the reference data set for each setup object to restrict their values
during transaction entry.
 Define tax book rules to copy transactions from the corporate book.
 Enable group assets for your book and select the group asset rules.
Defining Your Asset Book: Multiple Depreciation

Requirements
In this example, your company has operations in the United States only, and you
need to prepare financial statements for reporting purposes. Additionally, your
company must meet depreciation requirements under federal and state laws.
Recommended: Create a corporate book and two associated tax books.
Defining Your Asset Book: Multiple Currency

Representations
In this example, your company has operations in Singapore, and the company is a
subsidiary of a US company. Your company must prepare its financial statements in
Singapore dollars (SGD) for reporting purposes, and in United States dollars (USD)
to fulfill the parent company's US generally accepted accounting principles (GAAP) and
consolidation requirements.
 Primary currency: SGD

 Reporting currency: USD
Recommended: Create a corporate book that is assigned to the primary ledger with
the primary currency SGD and the reporting currency USD.
Important: When you define the corporate book for the primary ledger with
reporting currencies, Oracle Fusion Assets automatically creates a reporting
book for each reporting currency of the ledger.
You need to perform transactions only in the primary currency. Assets automatically
generates currency representations for the transactions in all the reporting
currencies.
In Assets, you can view transaction details, run reports, and create accounting
entries in both the primary and reporting currencies.
Defining Your Asset Book: Multiple Accounting

Representations
In this example, your company has operations in the United States. Your company
needs to prepare its financial statements under both US Generally Accepted
Accounting Principles (GAAP) and International Financial Reporting Standards
(IFRS).
Recommended: Create a corporate book for the US GAAP primary ledger and an
associated tax book for the IFRS secondary ledger. Both the primary and
secondary ledgers should use the same chart of accounts and currency.
Implementation Questions
Implementation Questions (continued)
Knowledge Check: Managing Asset Books
Can I create more than one corporate book for a ledger?
1. Yes
2. No
Knowledge Check: Managing Asset Books Answer
Can I create more than one corporate book for a ledger?
1. Yes
2. No
You can create an unlimited number of corporate books for a primary ledger.
Reference Data Sharing Across Asset Books
Use reference data sets to share reference data across books and to restrict
access to reference data by book.
Oracle Fusion Assets contains a common set of predefined set-enabled objects to

meet the business needs of sharing reference data across books.
You can also create new reference data sets to limit the access to certain setup
objects in one or more books.
The following set-enabled objects are available in Assets:
Depreciation methods
Prorate conventions
Bonus rules
Depreciation ceilings
Asset lookups:
 Queue names
 Asset descriptions
 Retirement types
 Unplanned types
For more information, see the Define Reference Data Sharing topic.
Reference Data Sharing: US Company Example
In this example, your company is headquartered in the United States and has two
subsidiaries. There are three corporate books and your company wants to eliminate
duplication of reference data.
Recommended: Use the predefined reference data set Common to share reference
data across all the books.
Reference Data Sharing: Multinational Company

Example
In this example, your company is a multinational company with operations in the

United States and Japan. The company has two corporate books: US CORP and
JAPAN CORP. Because the depreciation methods used in these two countries are
different, US depreciation methods should not be available to JAPAN CORP and
Japanese depreciation methods should not be available to US CORP.
Recommended: Define two reference data sets and segregate the methods.
NOTE: Student Activity Managing Asset Books
Define Subledger Accounting Rules
Oracle Fusion Assets provides the predefined subledger accounting method Standard
Accrual. You can create additional subledger accounting methods if necessary.
Accounting Event Model
Accounting Event Model Example:
The following is an example of an accounting event model for a loan application:
Process Category
accounting rules. You can assign a transaction view, system transaction identifiers, and
optionally user transaction identifiers and processing predecessors for an event class.
The transaction view should include all columns that have been mapped to system
transaction identifiers for the accounting event class as well as the user transaction
identifiers.
System transaction identifiers uniquely identify transactions from the source systems.
An identifier is the primary key of the underlying subledger transaction. At least one
system transaction identifier must be defined for the accounting event class.
User transaction identifiers constitute the user oriented key of the underlying subledger
transaction, and are typically drawn from one or more database tables. These identifiers
are primarily used in accounting events inquiry and on accounting event reports, to
uniquely identify transactions. You can specify up to ten columns from a view that are
available for inquiry and reports. As part of the implementation, an individual with
technical support personnel (not a functional user) defines the view (called a transaction
view) which will be used to store the identifiers.
The processing predecessor establishes an order in which the Create Accounting

process processes events selected for accounting.
Assets Accounting Event Classes
Oracle Fusion Assets provides the following predefined accounting event classes:
 Addition
 Adjustment
 CIP Addition
 CIP Adjustment
 CIP Category Change
 CIP Retirement
 CIP Source Line Transfer
 CIP Transfer
 CIP Unit Adjustment
 Capitalization
 Category Change
 Deferred Depreciation
 Periodic Depreciation
 Reserve Transfer
 Retirement
 Retirement Adjustment
 Source Line Transfer
 Terminal Gain and Loss
 Transfer
 Unit Adjustment
 Unplanned Depreciation
How should events be grouped together into accounting event classes?
The determinants:
 Whether they share common information. For example, if there is a significant

amount of shared information across event types, they may be logically grouped
into an event class.
 Whether you would like to be able to share accounting rules across the events.
For example, most rules can be shared if they are in the same event class.
 Whether accounting treatments can be simplified by storing the rules at the class
level. For example, the data is different per transaction, but the accounting
treatment is the same.
impact. For accounting event types, specify whether their accounting events have
accounting impact. When the Create Accounting process is submitted, it only accounts
business events that are enabled for accounting.
Managing Asset Categories
Asset categories group assets that share financial accounts and usually
depreciate using the same rules.
Use categories to group assets for transaction and reporting purposes.
Asset categories must be assigned to asset books with default accounts and
depreciation rules. The default account values are used to account asset
transactions in this category. The depreciation rules are automatically defaulted to
assets when they are added.
Defining Asset Categories
Configuration > Manage Asset Categories
General category information includes a description of the category, and default

information such as whether assets in this category are leased or owned, personal or
real property, and whether they are capitalized. You can also specify if assets are by
default in physical inventory or are enabled in Oracle Fusion Assets.
Asset categories also contain:
 General Ledger accounts

 Default depreciation rules
 Tax book depreciation rules
 Default subcomponent depreciation rules
 Group asset depreciation rules
Defining Default Depreciation Rules
Define depreciation rules with care for each category, because Oracle Fusion Assets
automatically defaults the rules to assets when they are added.
Defining Oracle Fusion General Ledger Accounts
 Define the balance sheet accounts carefully, because they cannot be

changed once assets are added to the category.
 Define asset clearing accounts that are used in the processing of invoices from
Oracle Fusion Payables.
Category Key Flexfield Implementation

Considerations
Planning Your Asset Category Flexfield Structure
 Define the structure after reviewing your company’s business needs to ensure
assets are grouped according to depreciation rules.
 Define your Asset Category key flexfield so that you can create categories and
group assets by financial information in relevant categories.
Important: Plan your flexfield carefully. Once you begin entering assets using the
flexfield, you cannot change it.
 Organize category hierarchies so that valid subcategory values depend on a

major category value. For example, in the category Vehicle-Owned, the second
segment can be used as a minor segment.
 Define at least one subcategory segment to allow for distinctions within a major
category.
 Define up to seven segments for your Asset Category key flexfield.
Important: Oracle Fusion Assets displays only a limited number of characters on its
forms and reports, so you may want to use only two or three segments so that all of
them can be displayed. Also keep in mind that you must define depreciation rules for
each category flexfield combination, so more segments require more setup and
maintenance effort.
NOTE: Student Activity Defining Category Key Flexfield Values
Category Implementation Considerations
When implementing asset categories, consider the following:
 Define the Category flexfield such that assets are grouped according to
depreciation rules.
 Organize category hierarchies such that valid subcategory values depend on
a major category value.
 Ensure that the category is compliant with the chart of accounts.
 Set up default accounts and rules for each Category flexfield combination
and for each book.
Define depreciation rules with care for each category, because they will be
automatically defaulted to assets.
 Assign a category to an asset book before entering assets with that category in
that book.
NOTE: Following the Knowledge Check questions there is a Student Activity Managing
Asset Categories.
Knowledge Check: Managing Asset Categories
Asset categories group assets that share financial accounts.
1. True
2. False
Knowledge Check: Managing Asset Categories

Answer
Asset categories group assets that share financial accounts.
1. True
2. False
Optional Implementation Steps
You can implement the following optional setup steps in Oracle Fusion Assets:
 Manage distribution sets

 Manage profile options
 Manage lookups
 Manage descriptive flexfields
 Manage asset keys
 Manage depreciation rules
Managing Distribution Sets
Configuration > Manage Asset Distribution Sets
Distribution sets allow you to automatically assign a predefined set of one or more
distributions to a new asset mass addition.
Defining Distribution Sets
Define distribution sets to allocate percentages of asset units to different

depreciation expense accounts, locations, and employees.
Define one or more distributions in a set.
Change the distribution information for a distribution set at any time.
Important: If you change the distribution information for a distribution set, note that
it does not affect assets already assigned to that distribution set.
Managing Profile Options
Set profile options to specify how Oracle Fusion Assets controls access to and
processes data, such as:
 The number of requests you can run in parallel

 The timing diagnostic message value
 The amount of database information retained in a concurrent process
 The cache reset value
 The batch size used for bulk processing in mass processes
 The book selected by default in Assets pages
Profile Options Settings
The following table displays the names, default values, and the effect each profile
option has on your Oracle Fusion Assets setup:
Profile Options Settings (continued)
Profile Options Settings (continued)
Managing Lookups
of the items from such lists to enter a value on the application UI.
Oracle Fusion Assets comes with the following predefined lookups. You can define
additional lookups if required for your business.
NOTE: For more information, see the Lookups topic in the Appendix.
Managing Descriptive Flexfields
Use Oracle Fusion Assets descriptive flexfields to record additional information

about assets that is not included in the standard information on Assets pages.
For example, you can set up a descriptive flexfield for each asset category to collect
information relevant to your business, such as the license number for cars and the
square footage for buildings. When you assign a new asset to a category, you enter
the additional information in a descriptive flexfield.
NOTE: For more information on defining descriptive flexfields, see the Descriptive
Flexfield topic in the Appendix.
Assets provides the following descriptive flexfields:
Managing Descriptive Flexfields (continued)
Managing Descriptive Flexfields (continued)
Managing Asset Keys
Define asset keys to group assets or identify groups of assets quickly.
Define asset key combinations. You must first define Asset Key flexfield segment
values before defining asset keys.
Assign the same asset keys to multiple assets to easily identify similar assets.
Provide additional descriptive data to group assets by project or other functional

group.
Asset keys are similar to asset categories in that they allow you to group assets.
However, asset keys do not have any financial impact.
Asset Key Flexfield Implementation Considerations
Planning Your Asset Key Flexfield Structure
 Define the Asset Key flexfield structure based on your asset tracking
requirements.
 You can assign the same asset key to many assets to easily find similar assets.
 Asset key setup is required even though it is not required that you capture this
information during entry.
 Important: Plan your flexfield carefully. Once you begin entering assets using
the flexfield, you cannot change it.
 Define up to 10 segments.
 If you choose not to track assets using the asset key, you must define at least
one segment without validation, because the Asset Key flexfield structure is
required to set up the system controls.
Knowledge Check: Managing Asset Keys
The Asset Key flexfield groups assets by financial information.
1. True
2. False
Knowledge Check: Managing Asset Keys Answer
The Asset Key flexfield groups assets by financial information.
1. True
2. False
The Asset Key flexfield groups assets based on non-financial information.
Managing Depreciation Rules
Depreciate assets to decrease the value of an asset due to obsolescence or use.
 Use predefined depreciation methods or create your own custom

depreciation methods.
 Accommodate additional depreciation in the early fiscal years of an asset life
using bonus depreciation. Bonus depreciation is frequently used in the United
States for tax books.
 Limit the amount an asset depreciates using depreciation ceilings.
 Restrict or share depreciation elements for books by setting up reference data
sets.
Defining Depreciation Methods
Oracle Fusion Assets has many predefined depreciation methods. You can define
additional methods, if necessary.
Defining Depreciation Methods (continued)
Defining Bonus Rules
Bonus rules help you to calculate additional depreciation as required under special
provisions in certain countries. Bonus rules can have different bonus rates for each
year of the asset's life. You can modify the rate at any time for current and future fiscal
years.
Use bonus rules with corporate books as well as tax books. Bonus rates let you
increase the annual depreciation expense for assets using flat-rate, straight-line, table-
based, and formula-based depreciation methods.
You can:
 Charge bonus expense and reserve to an account that is different from the
normal depreciation expense and reserve.
 Set up negative bonus rates to amortize bonus reserve.
NOTE: After assigning a bonus rule to an asset, it cannot be removed. If you need to
remove a bonus rule, set up a bonus rule with a 0 rate and assign it to the asset.
Defining Depreciation Ceilings
Depreciation ceilings allow you to limit the annual depreciation expense for certain
types of assets.
 Depreciation expense ceilings limit the annual amount of depreciation expense

you can take on an asset.
 Depreciation cost ceilings limit the recoverable cost of an asset.
There are two types of depreciation limits allowed:
 The annual amount of depreciation expense.

 The recoverable cost of an asset.
For example, for tax purposes, the depreciation amount for luxury cars in the United
States is limited to $11,060 for the first year for assets placed in service after
12/31/2009 and before 1/1/2011.
Knowledge Check: Depreciation Methods
What type of depreciation method should you use when depreciation must be
spread evenly across the life of an asset?
1. Calculated (straight-line)
2. Flat-rate
3. Table
Knowledge Check: Depreciation Methods Answer
What type of depreciation method should you use when depreciation must be
spread evenly across the life of an asset?
1. Calculated (straight-line)
2. Flat-rate
3. Table
 Explain Oracle Fusion Assets functions.

 Manage Assets key flexfields and value sets.
 Manage system controls.
 Manage fiscal years and calendars.
 Manage locations.
 Manage depreciation rules.
 Manage asset books.
 Manage asset categories.
 Review optional implementation steps.
Lesson 11: Configuring Oracle Fusion Expenses

NOTE TO INSTRUCTOR: A few days before you start the Expenses lesson, it is
recommended that you confirm that the four sample transaction files are in their proper
location before performing the Uploading Corporate Card Transaction File
demonstration.
After completing this lesson you should be able to:
 Set up expense templates: Mandatory setup.

 Set up Expenses system options: Mandatory setup.
 Setup conversion rates and policies. Mandatory setup.
 Set up and modify expense report approval rules: Mandatory setup.
 Set up corporate card issuers: Mandatory if you want to implement corporate
cards.
 Set up corporate card programs: Mandatory if you want to implement
corporate cards.
 Upload a corporate card transaction file. Mandatory if you use corporate
cards.
Overview of Oracle Fusion Expenses
The expense-to-reimbursement cycle starts with your company defining its expense
and reimbursement policies. Your company then determines the expenses that can be
reimbursed. It also establishes controls to enforce expense and reimbursement
policies and to detect fraud.
When business expenses are incurred, employees create and submit their expense
reports. The expense reports are routed to the appropriate approvers for review and
approval. When the approvals are complete, the expense reports may be audited to
ensure compliance with company expense and reimbursement policies. The employees
or corporate card issuers are then reimbursed for incurred business expenses.
Periodically, your company adds new automated controls and analyzes employee
expenses to further refine its expense and reimbursement policies and to identify
noncompliance.
NOTE: The Audit functionality will be available in a future release.
Expense Reimbursement Flow
Oracle Fusion Expenses enables users to enter expenses online and using a
spreadsheet. When users submit expense reports, they are routed for approval.
Expenses integrates with Oracle Service Oriented Architecture (SOA) suite of
applications and Approvals Management Extensions (AMX) for human workflow
within the SOA suite to provide configurable expense report approval rules. These
approval rules determine the set of approvers who are required to approve the expense
report and they are notified. Approved expense reports are processed for
reimbursement to the employee and corporate card issuers.
Expenses uses Oracle Fusion Payables to process expense reports for reimbursement.
Once manager approval is complete, expense reports undergo various processes
before the relevant details are sent to the Payables Invoice Open Interface tables for
payment request generation. A payment request is a type of invoice to pay third parties,
such as employees and corporate card issuers. Payables creates payment requests
using information in the Payables Invoice Open Interface tables.
During payment request creation, Payables rejects records in the Payables Invoice
Open Interface tables if there are errors, such as dates in closed accounting periods or
invalid payment methods. The created payment requests are then validated. Payables
additionally generates the accounting for the payment requests. Payables then sends
payment requests to Payments for payment processing to pay employees and
corporate card issuers.
Knowledge Check: 1
What are the major functionality areas of Oracle Fusion Expenses?
1. Incur Expenses, Scan Expenses, Approve Expenses, Reimburse

Expenses
2. Incur Expenses, Enter Expenses, Approve Expenses, Audit Expenses,
Reimburse Expenses
3. Incur Expenses, Fax Expenses, Approve Expenses, Audit Expenses,
Reimburse Expenses
4. Fax Expenses, Approve Expenses, Audit Expenses, Reimburse Expenses
Implementing Prerequisite Products
Expenses requires installation of the following mandatory prerequisite products:

Expenses optionally requires Oracle Fusion Project Costing and Oracle Fusion Tax
to support features, such as project-based expenses and tax recoverability. Oracle
Fusion Global Human Resources components are also available for creating and
maintaining employees.
Setting Up Prerequisite Products
To use mandatory products with Oracle Fusion Expenses, you must set up the following
products with specific setups:
Oracle Fusion General Ledger
 Expense accounts
 Expense clearing account
 Conversion rates and rate types
Oracle Fusion Payables
 Multiple currencies
 Payment request defaults
 Payment terms
 Card issuer liability account
Oracle Fusion Payments
 Disbursement payment methods

 Payment method defaulting rules
 Payment method validations
Setting Up Oracle Fusion Expenses
Tasks > Name field: Expenses > Search button > Define Expenses Configuration
folder.
The setup for implementing Oracle Fusion Expenses is provided in the Setup and
Maintenance Work Area as part of the Financials offering. The Define Expenses
Configuration activity encompasses all the setups for Expenses.
This setup activity is broken down into the following individual activities:
 Define Expense Policies and Rules

 Define Credit Card Data
 Define Image Processing
NOTE: If you do not plan to implement corporate cards, the Financials offering has a
filter where you can exclude the Define Credit Card Data activity.
Configuring Expense Policies and Rules
The Define Expense Policies and Rules setup activity enables companies to set up
information required to implement Expenses and enforce their corporate expense
policies. This includes expense types that are allowed in their companies, corporate
policies regarding the expenses, and expense report approval rules.
Define Expense Policies and Rules
folder > Define Expense Policies and Rules folder.
To enforce compliance with your company's expense report policies, Oracle Fusion
Expenses provides you with the Define Expenses Policies and Rules activity in the
Setup and Maintenance work area that enables you to perform the following high level
tasks:
 Manage Expense Report Templates.

 Manage Expense System Options.
 Manage Conversion Rates and Policies.
 Manage Expense Report Approval Rules.
Expense Template Concepts
The following terms are applicable to expense templates:
 Expense template: A grouping of related expense types that are defined for a
specific business unit. Examples of groupings of related expense types include
expense templates for travel, education, and relocation.
 Default expense template: The first expense template that you create on the
Create Expense Template page with corporate card expense type mapping.
 Expense Type: A potential expense that you can incur that has been defined by
the administrator during setup.
 Expense Item: The actual expense that was incurred and is always associated
with an expense type during expense entry on an expense report.
Considerations for Defining Expense Templates
An expense template is a grouping of related expense types that are defined for a
specific business unit. Examples of groupings of related expense types include expense
templates for travel, education, and relocation.
Expense templates enable companies to control the expense types visible to each
business unit. Additionally, if your company processes corporate card transactions and
you want the expense types to be automatically assigned during corporate card
transaction processing, you must set one expense template as a default expense
template.
Before you create expense templates, it is advisable to consider the following actions:
 Using expense templates.

 Defining default expense templates.
 Inactivating expense templates.
Using Expense Templates
Employees select a specific expense template, followed by an expense type, when they
create expense items in the Create Expense Item dialog box to add them to a new or
existing expense report for business or personal expenses incurred.
The following rules apply to expense templates:
 Each business unit can have multiple expense templates associated with it.
 Expense templates cannot be shared across business units.
IMPORTANT: If your company is established in multiple countries, you must create one
expense template per business unit. If your users use multiple languages within a
business unit, then you must implement the expense templates in each of those
languages.
Defining Default Expense Templates
folder > Define Expense Policies and Rules folder > Manage Expense Report
Templates task > Go to Task icon > Manage Expense Report Templates page >
Create button > Create Expense Template page > Expense Types tab.
folder > Define Expense Policies and Rules folder > Manage Expense Report
Templates task > Go to Task icon > Manage Expense Report Templates page >
Create button > Create Expense Template page > Card Expense Type Mapping tab.
A default expense template is the first expense template that you create on the Create
Expense Template page with corporate card expense type mapping. The application
automatically sets such a template as the default expense template, whether or not
you select the Set as default check box on the Create Expense Template page. You
can also change the default template from one to another, as long as the one you are
changing to has corporate card expense type mapping.
The purpose of a default expense template is to default expense types to credit card
transactions so when employees visit the Expenses work area to create expense
reports, they can see the expense types assigned to the corporate card transactions.
The default expense template uses the corporate card expense type mapping to
associate expense types with the corporate card transactions. This association
occurs when the corporate card feed file containing corporate card charges is uploaded
to Expenses.
The following rules apply to default expense templates:
 Each business unit can have only one default expense template associated
with it.
 For any business unit, you can have a default expense template associated
with it, with additional expense templates.
 For any business unit, you can have a default expense template associated
with it, with no additional expense templates.
IMPORTANT: You cannot implement Expenses if neither a default expense template
nor an expense template is associated with a business unit.
NOTE: A default expense template is required for each business unit that processes
corporate card transactions.
Inactivating Expense Templates
Deploying companies do not typically inactivate expense templates because they

cannot use them after the end date. It is therefore advisable to leave the Effective End
Date field blank, unless you intend to retire the expense template. Any expenses that
are incurred after an end date cannot be reported using an inactivated expense
template. It is more likely that you would inactivate individual expense types, rather
than inactivating an entire expense template.
To inactivate an expense template, enter a date in the Effective End Date field on the
Create Expense Template page. You can also inactivate individual expense types in
the same way on the Create Expense Type or the Edit Expense Type page, but the
expense template end date overrides the end date for individual expense types.
NOTE: If the current date is past the expense template end date, an employee can still
use the inactivated template to enter expenses on the expense report for the period in
which the expense template was active.
CAUTION: If you decide to inactivate a default expense template, then no corporate

card mapping occurs if no other default expense template is identified.
NOTE: Student Activity, Creating an Expense Template and Expense Types,

Defining Itemizable Expense Types, and Using the Expense Types in an Expense
Report
Specifying a Receipt Required Policy
Expenses provides receipt functionality for which you can specify options. If your
accounts payable department requires a receipt for each expense, then you must
specify the following for each expense type that you define on the Create Expense
Type page:
 A receipt requirement rule that reflects your company's receipt policy. A

receipt can be required for cash only or corporate card and cash.
 An expense amount, above which a receipt is required.
 Warning and error tolerance percentages so the application knows when to
warn the user, if opted, of a receipt required policy violation or, in the case
of an error, actually prevent submission of the expense report.
Warnings are tracked by the application. You can view them in the Expense Items
region on the Edit Expense Report page, whereas errors are not tracked because they
prevent submission of the expense report.
Conversion Rate Policy Concepts
The following terms are applicable when specifying a conversion rate policy:
 Conversion rate: Ratio at which the principal unit of one currency can be
converted into another currency.
 Conversion rate type: Corporate, Spot, or User.
 Default conversion rate: An option that determines whether conversion rates
show on expense reports by default. This option applies to cash transactions
only.
 Warning tolerance percentage: Percentage added to the base rate that sets
the maximum rate without warning.
 Error tolerance percentage: Percentage added to the base rate that sets the
maximum rate without an error.
Specifying a Conversion Rate Policy
folder > Define Expense Policies and Rules folder > Manage Conversion Rates and
Policies task > Go to Task icon > Manage Conversion Rates and Policies page >
USA1 Business Unit link> Edit Conversion Rates and Policies: USA1 Business
Unit page.
PREREQUISITE: Before you can manage conversion rates and policies, you must first
define conversion rates and conversion rate types in Oracle Fusion General
Ledger. If a conversion rate is not defined for the applicable reimbursement currency in
General Ledger, then Expenses cannot enforce the conversion rate policy.
You can define conversion rate behavior for each business unit in your company. These
definitions enable you to enforce conversion rate policies and to validate the conversion
rates that employees enter for foreign currency receipts. If you enter a conversion rate
value in an expense report, or override a defaulted value, the value you enter is
validated against the current conversion rate definitions.
NOTE: Conversion rate behavior applies only to cash expenses, not to corporate card
expenses. The default conversion rate, therefore, is only applicable to cash
transactions.
All business units accessible to the user are displayed on the Manage Conversion
Rates and Policies page. On the Edit Conversion Rates and Policies page, you can
specify the following conversion rate behavior:
 Type of conversion rate, whether Corporate, Spot, or User.

 Whether you want the conversion rate to default onto a newly created
expense report.
 Warning and error tolerance percentages so the application knows when to
warn the user, if opted, of a conversion rate policy violation or, in the case
of an error, actually prevent submission of the expense report.
 Warning and error tolerance percentages, if opted, for specific currencies.
The following table illustrates how warning and error tolerance percentages work for
conversion rate policies.
If the employee enters a cash amount for a meal of 25 GBP on the expense report and
indicates a conversion rate above 1.65795, a warning displays, if opted, that reminds
the employee to use a conversion rate less than 1.65795. Warnings are tracked by the
application. You can view them in the Expense Items region on the Edit Expense
Report page.
If the employee enters a cash amount for a meal of 25 GBP on the expense report and
indicates a conversion rate above 1.7369, the application prevents submission of the
expense report. Consequently, errors are not tracked by the application.
Knowledge Check: 2
Can you prevent users from submitting an expense report if they do not have a
receipt for an item requiring receipts?
1. Yes
2. Sometimes
3. No
4. Depends upon the situation
Knowledge Check: 3
When is a receipt required policy violation invoked?
1. When you select the Display warning to user check box on the Edit
Conversion Rates and Policies dialog box.
2. When you select the Display receipt missing policy warning to user check
box on the Create Expense Type page.
3. When you select This expense type used in itemization only check box on
the Create Expense Type page.
4. When you select the Receipt missing check box for the expense item on
the Create Expense Item page.
Knowledge Check: 4
Can you have a conversion rate policy violation without alerting the user?
1. Yes, if you do not select the Display warning to user check box on the Edit
Conversion Rates and Policies page.
2. No
3. Never
4. Occasionally
Knowledge Check: 5
How do you configure a conversion rate policy where the user is prevented from
entering any value over the conversion rate in the application?
1. Enter an error tolerance of 1 (one)

2. Enter an error tolerance of 0 (zero).
3. Enter an error tolerance of -1 (minus one)
4. Enter an error tolerance of .01 (point zero one)
NOTE: Student Activity, Setting Warning and Error Limits on a Conversion Rate
Demonstration
NOTE: Student Activity, Viewing a Conversion Rate Policy Warning and Error
Expenses System Options Concepts
The following terms are applicable to system options:
 Payment method: A method of payment, such as check, cash, or credit.

 Terms and agreements: Expense report policies and rules that employees are
typically asked to accept before submitting their expense reports.
 Bar code: A printable bar code that uniquely identifies each employee's expense
report.
 Reimbursement currency: The currency in which the employee is reimbursed.
Manage Expenses System Options
folder > Define Expense Policies and Rules folder > Manage Expenses System
Options task > Go to Task > Manage Expenses System Options page.
The Manage Expenses System Options page enables you to set application options
that control various processes in expense reporting across all business units or for
specific business units.
The following are selected application options and their impact:
 Enable Payment Method: Controls whether users can select a reimbursement

payment method in the expense report.
 Enable Terms and Agreements: Controls whether users are required to select
a check box that indicates they have read the company policies before submitting
the expense report.
 Display Bar Code: Controls whether the bar code is displayed in the expense
reports and in printed copies. This option enables you to fax receipts, along with
the expense report cover sheet with the bar code on it, to a server that uses
image processing technology to automatically attach receipts to expense reports.
 Allow Reimbursement Currency Selection: Controls whether users are
allowed to choose their own reimbursement currency during expense entry.
Manage Expense Report Approval Rules
Approval rules are configurable rules for expense report approval. Oracle Fusion
Expenses integrates with Oracle BPM Worklist and Approvals Management
Extensions (AMX) in the Oracle Service Oriented Architecture (SOA) suite of
applications to provide configurable expense report approval rules. AMX, in turn,
integrates with Oracle Fusion Global Human Resources to provide supervisory,
position, and job hierarchies, as well as identification of approvers. By using the BPM
Worklist interface, you can define new approval rules or modify existing ones.
To manage approval rules, you must be a BPM Worklist administrator, such as a

financial application administrator.
If you are authorized to manage approval rules, you can:
 Define new approval rules.

 Modify existing approval rules.
 Understand and apply properties of rules and rule sets.
Approval Rules Overview
Navigator menu > Setup and Maintenance link > All Tasks tab > Name field: Define
Approval Management for Financials > Search button > Define Approval
Management for Financials folder > Manage Task Configurations for Financials
task > Go to Task icon > BPM Worklist application.
If you are authorized to manage approval rules, an Administration link displays in the
upper right corner of the Oracle BPM Worklist. To define new approval rules or modify
existing ones, click the Administration link, click the Task Configuration tab, click the
Data Driven tab to display the Data driven configuration page, and then select the
FinExmWorkflowExpenseApproval task from the left hand pane named Tasks to be
configured.
Oracle Fusion Expenses provides the following seven predefined rules sets to
support various approval scenarios:
1. Approval by supervisor based on report amount.

2. Approval by project managers in parallel mode.
3. Approval by cost center owners in parallel mode.

4. Approval by a specialist based on expense types in parallel mode.
5. Approval by project managers in serial mode.
6. Approval by cost center owners in serial mode.
7. Approval by a specialist based on expense types in serial mode.
Each rule set contains one or more approval rules. Each approval rule has an approval
condition and a list of approvers. The list of approvers derived for each rule set is
called a participant. To generate the list of approvers, each rule requires a list builder
to be associated with it.
NOTE: Each expense report can only satisfy one rule within a rule set. If an expense
report does not satisfy any rule in a rule set, the approval process errors and an incident
is reported in Oracle Enterprise Manager Grid Control.
Considerations for Configuring Approval Rules
Your company has a unique set of expense policies. If your company requires special
approval for certain types of expenses such as entertainment or gifts to customers, you
can implement an approval rule based on expense types. This allows you to route
expense reports with these expense types to approvers with expertise in their
respective areas.
To reduce approval delays, you can expedite reimbursement to employees by:
 Setting up automatic approval rules for insignificant amounts.

 Implementing the Expiration and Escalation Policy region in the Event
Driven tab for vacation approval rules.
All approvals other than automatic approvals require at least one approver. Evaluate
what type of approval hierarchy (List Builder) you need for each approval rule, whether
Job, Position, or Supervisory.
For example, you may need any of the following:
 One level of Supervisory approval for expense reports containing less than
$1,000.
 Human Resources specialist Job approval for relocation expenses.
 Cost center owner’s Position approval for charges to another cost center.
If you require cost center owners to approve charges to cost centers other than yours,
you must define cost center owners. If you use Position approval, you must set up a
Position hierarchy in Global Human Resources. However, if you already have a
Position hierarchy and your approval requirements follow the same hierarchy as that in
Global Human Resources, you can use your existing Position hierarchy in the approval
rules. Approvals Management Extensions (AMX) integrates seamlessly with Global
Human Resources, so there is no need to redefine any of the same hierarchies in
Global Human Resources.
Configuring Approval Rules
Navigator menu > Setup and Maintenance link > All Tasks tab > Name field: Define
Approval Management for Financials > Search button > Define Approval
Management for Financials folder > Manage Task Configurations for Financials
task > Go to Task icon > BPM Worklist application > Tasks to be configured pane:
FinExmWorkflowExpenseApproval (1.0) task > Event Driven or Data Driven tab.
The expense report approval task has two types of configurations associated
with it as follows:
 Event Driven configuration: Captures the assignment and routing policies, the
expiry and escalation rules, and how the approvers are notified.
 Data Driven configuration: Captures the expense report approval rules and
how the approvers are derived.
The Data Driven configuration displays all predefined rule sets. Each rule set contains
one or more approval rules. Each approval rule has an approval condition and a list of
approvers. To generate the list of approvers, each rule is associated with a hierarchical
list of approvers known as the List Builder.
The following rules apply to the predefined rule sets:
 Within a rule set, you can add a new rule, or modify or delete an existing
rule.
 You can exclude a rule set from the approval process.
 All active rule sets are executed for each expense report.
 Rules within each rule set are executed in the order in which they are
defined.
 For each expense report, only one rule applies in a rule set.
 If an expense report does not satisfy any rule in a rule set, the approval
process errors and an incident is reported in Oracle Enterprise Manager
Grid Control.
 Rules can be defined in draft status for later activation.
NOTE: Since only one rule can apply in a rule set for each expense report, you must
configure the rules at the most granular level applicable and use priority within the
rule to differentiate overlapping conditions.
TIP: If you need approval rules that are specific to a business unit, then you must add it
to the condition.
NOTE: Student Activity, Modifying Approval Rules Demonstration
Configuring Credit Card Data
The Manage Credit Card Data activity has two main functions:
 To support the setup required to process corporate card transactions.

 To upload and process corporate card transactions for reimbursements.
To perform these functions, two work areas exist as follows:
 Setup and Maintenance work area: For setting up corporate card programs,
corporate cards, and related details.
 Corporate Cards work area: Provides an overview of all corporate card
processes and the actions to be taken.
Define Credit Card Data
folder > Define Credit Card Data folder.
To enforce compliance with your company's corporate card usage policies, Oracle
Fusion Expenses provides you with the Define Credit Card Data activity in the Setup
and Maintenance Work Area that enables you to perform the following high level
tasks:
 Manage Corporate Card Issuers.

 Manage Corporate Card Programs.
Overview of Corporate Card Transaction Processing
The Define Credit Card Data activity encompasses 14 tasks and is part of the overall
flow of uploading and processing corporate card transactions for reimbursement to
employees and corporate card issuers. Before you can manage credit card data activity,
you must work with your corporate card issuers to establish connectivity and to
determine the transaction file format and its delivery frequency.
Uploading and Validating Corporate Card Transactions
After establishing a secure connection, your company can start receiving the corporate
card transaction files. Expenses loads the corporate card transaction file and validates
the transactions. If they are present in the file, Expenses loads summary and detail
transactions. All valid corporate card transactions are created as expense items and are
available for inclusion in employees' expense reports.
All invalid corporate card transactions are available for corporate card administrators to
review and correct. After correction, these transactions go through the validation
process again and become available for expense reporting.
Processing Corporate Card Transactions
Employees submit corporate card transactions in their expense reports. The expense
reports containing corporate card transactions are processed to determine the
reimbursement amounts to employees and corporate card issuers.
A separate payables document is created to pay corporate card issuers for Both Pay
transactions. Both Pay transactions are those where the employee pays the corporate
card issuer for personal expenses and your employer pays the corporate card issuer for
business expenses.
To pay corporate card issuers for Company Pay transactions, which is where your
company pays the corporate card issuer for corporate card and cash business
expenses, but the employee does not pay the corporate card issuer for personal
expenses, a payables document is created for corporate card issuers from the valid
transactions. The Manage Invoices activity creates the necessary accounting and the
Manage Payments activity process the payables documents and pays the corporate
card issuers and employees.
Manage Corporate Card Issuers
folder > Define Credit Card Data folder > Manage Corporate Card Issuers task > Go
to Task icon > Manage Corporate Card Issuers page > Create icon > Create
Corporate Card Issuer dialog box.
folder > Define Credit Card Data folder > Manage Corporate Card Issuers task > Go
to Task icon > Manage Corporate Card Issuers page > Amex Card Issuer link > Edit
Corporate Card Issuer: Amex Card Issuer page.
To implement corporate cards, your company selects one or more corporate card
issuers based on your geographical region and the services they offer. Once a card
issuer is selected, the card issuer and your company creates an agreement to outline
the services and the payment details. A credit card program represents the agreement
between your company and the card issuer.
The card issuer can create one or more company accounts depending on how your
company wants to manage the program.
The card issuer can set up your company account at any of the following levels:
 Division level.
 Cost center level.
 Other level.
Corporate cards are then issued against each company account. The company can
receive the transactions by a transaction feed file that is uploaded into Expenses.
Configuring Corporate Card Issuers
You can set up a corporate card issuer, which is a bank that issues corporate cards,
through the Manage Corporate Card Issuers page by entering the card issuer's name
and site information.
To enable your company to pay a corporate card issuer, you enter a default payment
method, whether check, EFT, or wire, in the Address Payment Information region on
the Edit Corporate Card Issuer page, as well as bank account information. Then you
associate the newly created card issuer with your company account on the Create
Company Account page.
By selecting a payment currency and payment terms on the Create Company Account
page, you complete the payment information necessary to pay the corporate card
issuer.
NOTE: Student Activity, Defining a Corporate Card Mapping Rule, Creating a

Corporate Card Program and Company Account Number, and Assigning the
Mapping Rule to the Corporate Card Program
Corporate Card Programs Concepts
The following terms are applicable when defining corporate card programs:
 Transaction detail wait days: Number of days the application is set up to hold
the main transaction data while waiting for Level 3 detail transaction data from a
merchant, which may or may not arrive.
 Employee matching rule: A rule that automatically assigns a new corporate
card to an employee.
 Transaction summary mapping rule: A mapping rule that automatically
populates expense type for summary transactions.
 Transaction details mapping rule: A mapping rule that automatically populates
expense type for detailed transactions.
 Company account: A unit of the deploying company in the card issuer's system.
 Market code: A code provided by the card issuer that identifies the deploying
company's market.
 Billing control account number: An account number that identifies an
organization within the deploying company.
 Clearing expense account: An expense account that temporarily holds
accounting for corporate card transactions.
Manage Corporate Card Programs
A corporate card program is an agreement between the corporate card issuer and
your company that governs the issuance of corporate cards to the employees of your
company and the payment to the card issuer. Your company can have a single card
provider that provides corporate cards for the employees globally, which is referred to
as a global card program, or you can have multiple card providers that provide
corporate cards for the employees based on the region and the services needed.
A corporate card program consists of one or more company accounts that represent a
specific organizational hierarchy in your company. Corporate cards are issued under
each company account.
Each company account is associated with:
 A card issuing bank, known as a card issuer.

 Payment terms.
 Other agreements.
Your company can choose to receive electronic files containing the corporate card
transactions of its employees on a regular basis. The file format and method of delivery
are agreed to and set up before your company starts processing the corporate card
transaction files through Oracle Fusion Expenses.
Configuring Corporate Card Programs
folder > Define Credit Card Data folder > Manage Corporate Card Programs task >
Go to Task icon > Manage Corporate Card Programs page > Create icon > Create
Corporate Card Program page.
To receive and process corporate card transaction files from a corporate card issuer,
you must set up a corporate card program. To set up card programs, you must have
the Corporate Card Administrator role.
To enable corporate card transaction processing, you can set up the following:
 Transaction detail wait days.

 Employee matching rule.
 Mapping rules for deriving expense types for the corporate card
transactions.
Transaction Detail Wait Days
If you want Expenses to wait for the transaction details to arrive before releasing it for
inclusion in expense reports, you can set up transaction detail wait days. The wait
period for each transaction is the minimum of the wait days for the corporate card
transactions and the wait days for the merchant.
Employee Matching Rule for New Cards
If you choose to enable automatic corporate card creation, you must select an
employee matching rule that the corporate card transaction upload and validation
process can use to uniquely match a new card to an employee in the application.
Expenses automatically creates the card and assigns it to an employee using the
specified rule. If the rule fails to identify a unique match, Expenses leaves the card
unassigned. A corporate card administrator can, however, manually assign a card to an
employee and activate it.
Mapping Rules
You can set up a transaction summary mapping rule and a transaction details
mapping rule to automatically derive the expense types for the corporate card
transactions from the transaction codes in the charge file.
The rules are used as follows:
 Transaction summary mapping rule: Used to derive expense types of main

transactions.
 Transaction details mapping rule: Used to derive expense types of detail
transactions.
You must specify the type of transaction codes that appears in the charge file in the
transaction summary mapping rule column and the transaction details mapping
rule column.
Specifying a Corporate Card Usage Policy
Expenses enables you to set up corporate card usage policies to enforce the use of
corporate cards. These policies increase your control of the cards by enforcing
compliance with the usage policies.
You specify corporate card usage policies in the Edit Corporate Card Usage Policy
dialog box by initially specifying cash limits for expense categories. A cash limit is a
cash ceiling, above which an employee must pay the expense by using a corporate
card. An expense category represents a grouping of expense types. For example, the
expense category of Airfare represents the following group of expense types:
International Air and Domestic Air.
In addition to the cash limit, you must also specify tolerance percentages for
warnings or errors as they relate to the cash limits for the expense categories. The
following table illustrates how the warning and error tolerance percentages work for
corporate card usage policies.
If the employee enters a cash amount over $105 for a car rental on the expense report,
a warning displays, if opted, that reminds the employee to use a corporate card, instead
of cash, for car rental charges over $100. Warnings are tracked by the application. You
can view them in the Expense Items region on the Edit Expense Report page.
If the employee enters a cash amount over $110 for a car rental on the expense report,
the application prevents submission of the expense report. Consequently, errors are not
tracked by the application.
NOTE: If no cash limits are defined, the application enables you to submit cash
expenses of any amount.
NOTE: Student Activity, Setting Up a Corporate Card Usage Policy Warning

Demonstration
NOTE: Student Activity, Uploading a Corporate Card Transaction File

Demonstration
 Set up expense templates.

 Set up Expenses system options.
 Set up conversion rates and policies.
 Set up and modify expense report approval rules.
 Set up corporate card issuers.
 Set up corporate card programs.
 Upload a corporate card transaction file.
Lesson 12: Configuring Oracle Fusion Receivables

 Understand key concepts in Oracle Fusion Receivables.

 Complete the necessary prerequisite setups before configuring
Receivables.
 Set up a minimum configuration necessary to operate Receivables.
 Understand additional implementation considerations for setting up
transactions.
receipts.
revenue management.
 Understand key concepts concerning customers and parties.
Key Concepts in Oracle Fusion Receivables

Order to Cash
The Order to Cash flow begins with the ordering process. The ordering process leads to
the shipping of goods, followed by invoicing the customer and concluding with the
receipt of payment and reconciling the bank statement.
The order to cash flow includes these activities:
1. Order: The order is entered with information that includes the customer, ship-to,
bill-to, payment terms, order type, price list, unit price, and warehouse. Then the
order is booked and the order proceeds through the workflow process. If the
order is for a shipping item and the quantities are available, the process includes
shipping execution.
2. Shipping: The order is pick released, which generates the move order. Once the
item is brought from subinventory into the staging area, it is ready to be placed
on a shipping vehicle. After this, the ship confirm process is run.
3. Billing: AutoInvoice imports invoices, credit memos, and on-account credits from
other systems into Oracle Fusion Receivables. In Receivables, invoices are
printed and sent to the customer.
4. Revenue: Revenue recognition manages revenue processing.
5. Receipt: When payment is received, a receipt is generated and posted in the
Receivables subledger.
6. Collections: When necessary, Advanced Collections manages the collection
efforts until payment is received.
7. Reconciliation: In Cash Management, the system pulls information from posted
receipts and matches this information to the bank statements for reconciliation.
This course describes the setups necessary to enable transaction, receipt, and revenue
processing for a new Business Unit in Oracle Fusion Receivables.
Receivables Process
The Receivables process follows this flow:
 Create invoices manually or using AutoInvoice.

 Review and update invoice information.
 Print invoices individually or as a balance forward bill and send to customers.
 Enter and post receipts for customer payments.
 Collect payments from delinquent customers.
 Transfer subledger accounting entries to General Ledger.
Prerequisite Setups for Oracle Fusion Receivables
You must ensure that the following Financials setup tasks are completed in the
order indicated before you configure Oracle Fusion Receivables:
1. Define Legal Entities for Financials:
 Manage Legal Entity

 Manage Legal Entity Registrations
 Manage Legal Reporting Unit
 Manage Legal Reporting Unit Registrations
2. Define Chart of Accounts of Enterprise Structures for Financials:
 Manage Charts of Accounts

 Manage Account Hierarchies
 Manage Accounting Calendars
3. Define Ledgers:
 Manage Currencies
 Manage Conversion Rate Types
 Manage Accounting Periods
 Manage Daily Rates

4. Define Accounting Configurations of Enterprise Structures for Financials:
 Manage Primary Ledgers

 Specify Ledger Options
5. Define Business Units:
 Manage Business Unit

 Assign Business Unit Business Function
6. Define Transaction Taxes
7. Define Implementation Project and User Assignments
8. Define Users for Credit Memo Workflow
9. Complete Receivables Common Tasks
 Manage Receivables Descriptive Flexfields

 Manage Receivables Lookups
 Manage Receivables Profile Options
 Define Subledger Accounting Rules
Review Implementation Project Tasks and Assign

User Assignments
Review these common application tasks, in the order indicated, to ensure the
setup of your implementation project for your Receivables users:
1. Define a Reference Set

2. Define a Business Unit and Associate the Reference Set
3. Assign the Receivables Business Functions to the Business Unit
4. Create Receivables Users
5. Manage Data Roles
6. Provision Roles to Receivables Users
7. Assign Implementation Project Tasks to Receivables Setup User
1. Define a Reference Set
Use the implementation project and reference data set to control and manage the setup
tasks involved in defining Financials.
 Open the implementation project.

 Select the Financials offering for the implementation project.
 Save and open the implementation project.
 Drill down to the Manage Reference Data Sets page.
 Create a new reference data set.
2. Define a Business Unit and Associate the Reference Set
Define a business unit and associate the reference data set that you previously created
with the business unit.
 Use the Create Business Unit page to define a business unit.

 Enter the reference data set that you previously defined as the default set.
 Use the Save and Go to Task: Manage Business Unit Set Assignment menu item
to verify that the default set is assigned correctly.
 Use the Scope Selection: Business Unit window to add the business unit that you
just defined as the scope.
3. Assign Receivables Business Functions to the Business Unit
Enable Receivables business functions for the business unit.
 Use the Assign Business Functions page to enable the Receivables business
functions Billing and Revenue Management and Customer Payments for the
business unit.
 Use the Assign Tasks window in the Implementation Project page to assign the
implementation tasks Verify Data Role Generation for Business Unit
Business Function and Provision Roles to Implementation Users for
Business Unit Business Function to IT_SECURITY_MANAGER.
4. Create Receivables Users
Use the New Person – New Hire flow in HCM to create Receivables users.
5. Manage Data Roles
When you enable Receivables business functions for the business unit, the Receivables
business unit based data role template BillingRevMgtandCustPayment automatically
creates data roles for the six seeded Receivables job roles:
 Billing Manager
 Billing Specialist
 Accounts Receivable Manager
 Accounts Receivable Specialist
 Revenue Manager
 Revenue Analyst
In addition, the Financials Setup business unit based data role template
FinancialsFunBusinessUnit automatically creates a data role for the seeded Financial
Setup job role Financial Application Administrator.
The set based data role templates FinancialsArSetId and FinancialsFunSetId do not
automatically generate data roles. IT_SECURITY_MANAGER needs to manually
generate these data roles in the Authorization Policy Manager pages using the Verify
Data Role Generation for Business Unit Business Function.
6. Provision Roles to Receivables Users
 Assign, or provision, the data roles to users in order to grant them access to
specific job roles, such as Billing Manager or Revenue Manager, for the given
business unit.
 IT_SECURITY_MANAGER provisions data roles to users using the Provision
Roles to Implementation Users for Business Unit Business Function. Use
the Oracle Identity Manager to query users and provision one or more of the data
roles.
7. Assign Implementation Project Tasks to Receivables Setup User
Assign the Define Receivables Configuration Task List to the setup user defined in the
Knowledge Check: Implementation Project and User

Assignments
A reference data set appears by default when you create a business unit.
1. True
2. False
Data roles are created by default when you enable business functions for a
business unit.
1. True
2. False
The two Receivables business functions are:
1. Revenue Management and Receipts Processing

2. Billing and Revenue Processing and Customer Data
3. Billing and Revenue Management and Customer Payments
4. Billing Management and Revenue and Customer Management
Knowledge Check: Implementation Project and User

Assignments Answer
A reference data set appears by default when you create a business unit.
 False. You first create an implementation project and reference data set. Then
you create a business unit and associate the reference data with it.
Data roles are created by default when you enable business functions for a
business unit.
 True. The Receivables business unit-based data role template

BillingRevMgtandCustPayment automatically creates data roles for the six
seeded Receivables job roles.
The two Receivables business functions are:
 Billing and Revenue Management and Customer Payments
Define Users for Credit Memo Workflow
There are two seeded rule sets for credit memo workflow:
 Collection agent rule set

 Non-collection agent rule set
These two seeded rule sets refer to two approval groups that are not seeded. The
approval groups are:
 Collection_Manager_Approval_Group
 Billing_Manager_Approval_Group
You must define two seeded approval groups and assign users to the groups.
1. Create one approval group called Collection_Manager_Approval_Group and

one approval group called Billing_Manager_Approval_Group.
2. Assign the users that you want to each approval group. NOTE: You must assign
the user with the Billing Manager role to the Billing_Manager_Approval_Group
and the Collection Manager role to the Collection_Manager_Approval_Group.
Define Subledger Accounting Rules
Process Category
identifiers.

Receivables Accounting Event Classes
The event classes for Oracle Fusion Receivables are:
 Adjustment
 Miscellaneous Receipt
 Receipt
 Chargeback
 Credit Memo
 Debit Memo
 Invoice
The determinants:

Initial Setups

Simple Configuration for Oracle Fusion Receivables
You can create an operational Oracle Fusion Receivables environment with seven
configurations. The remaining configurations are either optional or have
predefined values.
Perform these seven tasks in the order indicated:
1. Set Receivables System Options

2. Define Receivables Activities
3. Define AutoAccounting Rules
4. Define Receipt Classes and Receipt Methods
5. Define Remit-to Addresses
6. Define Approval Limits
7. Define Statement Cycles
It is also helpful to keep in mind reference data sharing as you develop your
implementation. The following Receivables objects are based on reference data
sets:
 Transaction Types
 Transaction Sources
 Payment Terms
 AutoCash Rule Set
 AutoMatch Rule Set
 Application Exception Rule Set
 Revenue Scheduling Rules
 Revenue Contingencies
 Remit-to Addresses
 Memo Lines
 Lockboxes
Set Billing and Revenue Receivables System Options
The Billing and Revenue System Options contain parameters that affect
transactions:
 Print Remit-to Address: Option to print your remit-to address on customer

statements.
 Print Home Country: Option to print your home country on customer statements
that refer to addresses in that country. Enabling this option is required to run the
Create Customer Statements program.
 Unallocated Revenue Account: This option is only required if using Cash Basis
accounting. It records the unallocated revenue when you apply a cash receipt
with a balance other than zero to an invoice with a zero balance.
Set System Options for Salespersons
Define salespersons to allocate sales credits for transactions:
 Require Salesperson: Enable this option to require that you enter salespersons
when entering transactions.
NOTE: If you intend to use revenue accounting, you must enable the Require
salesperson system option. Revenue accounting requires that you assign sales
credits to all transactions that can be adjusted for either revenue or sales credits.
 Sales Credit Percent Limit: Enter a value in this field to limit the percentage of
revenue plus non-revenue sales credit that a salesperson can have on any
transaction line.
NOTE: If you do not enter a value in the Sales Credit Percent Limit field, then
no sales credit limit validation is performed during revenue accounting.
Set System Options for Transactions and Accounting
 Header Level Rounding: Assign a special account for rounding differences

when converting foreign currency transactions to your ledger currency.
If you enable this option, then Receivables displays a rounding distribution line
for all transactions, regardless of currency. If the transaction is in the ledger
currency, then the amount of this line is zero.
Caution: You cannot disable this option once you enable it and save your
system options.
 Automatic Journal Import: Option to automatically import the batches you

transfer.
 Days per Posting Cycle: Option to let you process the transactions you are
posting in smaller groups to ensure that you do not run out of rollback space
during posting.
For example, if your accounting period is 30 days and you set this value to 30,
the posting program uses only one cycle. If your accounting period is 30 days
and you set this value to 17, the posting program uses two cycles. It is therefore
recommended to set this field to a value that is less than the number of days in
your accounting period.
 Allow Change to Printed Transactions: Option to allow updates to printed

transactions. This option also determines whether you can update a customer
address when printed, posted, or applied transactions are assigned to that
address.
Important: You cannot update a transaction if it has activity against it, regardless
of how you set this option. Examples of activity include payments, credit memos,
adjustments, accounting, and inclusion of the transaction on a balance forward
bill.
 Allow Transaction Deletion: Option to allow a transaction to be deleted from

Receivables after it has been saved. If you do not enable this option, all
Receivables users are prevented from deleting transactions.
NOTE: If an installation is legally required to use document sequences with

gapless numbering for transactions, then you should not enable this option.
Set Cash Processing Receivables System Options
 AutoApply: Enable the Use AutoApply option to use AutoApply to process

receipts for the business unit. This applies to manually entered receipts, receipts
created through Excel upload (ADFdi integration) and receipts created through
lockbox processing. AutoApply attempts to process receipts even when there is
invalid or only partial information available to match receipts to transactions. The
AutoApply process matches transactions to receipts and either applies receipts
automatically or presents transaction recommendations for receipt application to
you for manual processing.
If you use AutoApply, you can use an AutoMatch rule set to help define how to
match customers to receipts and receipts to transactions to complete receipt
processing.
Use the Days to AutoApply a Receipt field to specify the number of days that
AutoApply attempts to apply a receipt to a transaction. Use this field if your

customers often pay for transactions before they are created. AutoApply looks for
and attempts to apply open receipts for the number of days that you specify. If
you do not enter a value in this field, AutoApply tries to apply the receipt only
once.
Important: If you do not enable AutoApply, and if you do not set up an AutoCash
rule set to indicate how to apply receipts, then Receivables leaves all receipts
that you create unapplied.
 AutoMatch Rule Set: The AutoMatch rule set provides information that is used
by AutoApply to complete the process of applying receipts to transactions. The
settings in the AutoMatch rule set provide these recommendations:
Customer recommendations: The matching process recommends customers
for lockbox receipts that have invalid or missing customer information.
Transaction recommendations: The matching process recommends one or
more transactions for receipt application for both lockbox and manual receipts.
 AutoCash Rule Set (optional): Use an AutoCash rule set to indicate how to
apply receipts to transactions in cases where there is no transaction reference
available for the receipt. Receivables first looks for the AutoCash rule set defined
for the customer profile either at the customer site or customer level to apply the
receipt.
 Allow Unearned Discounts: Enable this option to allow unearned discounts.

Unearned discounts are discounts a customer takes after the discount period
passes. You define discount periods when defining your payment terms.
NOTE: The system options record is the only place that determines whether you
can accept unearned discounts for the given business unit.
 Discount on Partial Payment: Enable this option to allow discounts to be taken

for partial payments. If this option is enabled, you can still choose not to allow
discounts on partial payments at the transaction level when defining payment
terms.
 Require Billing Location: Enable this option to require that a bill-to site be
associated with a receipt. If enabled, Receivables does not create receipts that
do not have a bill-to site. If you enable this option, you should also enable the
Require Billing Location option when defining a lockbox.
Use this option if you have customers without statement sites. If you do not
enable this option, and you have receipts for customers without statement sites
and without a bill-to site associated with the receipt, the unapplied amount of the
receipt will not appear on any of the statements for this customer.
 Automatic Receipts: The Invoices per Commit field determines the number of
invoices the Automatic Receipt program processes before saving. The Receipts
per Commit field determines the number of receipts the Automatic Receipt
program processes before saving.
Suggestion: Set Receipts per Commit to a large number to avoid intermediate

saves in the program. You should use numbers that are large enough to handle
your largest automatic receipt batches.
 Chargeback Due Date: The default due date to use when creating a
chargeback:
Current Date: The system date.

Deposit Date: The receipt deposit date.
Open Invoice Due Date: The due date of the invoice or debit memo.
Receipt Date: The date that the receipt was entered.
 Application Rule Set: When you apply a receipt or credit memo to a transaction,
the Application rule set determines how Receivables reduces the balance of the
line, tax, freight, and late charge amounts on a transaction.
Receivables uses the Application rule set assigned to the transaction type of the
open debit item to process payment applications. If no Application rule set is
assigned to the transaction type, then Receivables uses the Application rule set
assigned to system options.
Set Cash Processing Receivables System Options for

Accounting
Use the Accounting section of Cash Processing System Options to specify

accounting flexfields for recording receipt activity. These include:
 Realized Gains Account: Records gains on foreign currency conversion rate

fluctuations between the time the transaction is entered and the time the receipt
is applied.
 Realized Loss Account: Records losses on foreign currency conversion rate

fluctuations between the time the transaction is entered and the time the receipt
is applied.
 Cross Currency Rounding Account: Records any rounding error amounts

created during a cross currency receipt application.
Define Receivables Activities
Setup and Maintenance work area > All Tasks tab > Search field: select Task lists >
Name field: enter Receivables > Search button > Define Receivables Configuration >
Define Common Accounts Receivable Configuration > Manage Receivables Activities:
Go to Task icon.
Receivables activities provide default accounting information for all activities other
than transactions and receipts. Use the available Receivables activity types to set up
this default accounting information according to your requirements.
Receivables provides these activity types:
 Adjustment: Use activities of this type to make adjustments to transactions. You

must create at least one activity of this type.
 Bank Error: Use activities of this type when entering miscellaneous transactions.
You can use this type of activity to help reconcile bank statements using Cash
Management.
 Credit Card Chargeback: Use activities of this type to record credit card
chargebacks. This activity includes information about the general ledger clearing
account used to clear the chargebacks. Receivables credits the clearing account
when you apply a credit card chargeback, and then debits the account after
generating the negative miscellaneous receipt.
 Credit Card Refund: Use activities of this type when processing refunds to
customer credit card accounts. This activity includes information about the
general ledger clearing account used to clear credit card refunds. You must
create at least one activity of this type to process credit card refunds.
 Earned Discount: Use activities of this type to adjust a transaction, if payment is

received within the discount period (determined by the transaction payment
terms). You must create at least one activity of this type.
 Late Charges: Use activities of this type when you define a late charge policy.
You must define a late charge activity if you record late charges as adjustments
against overdue transactions. If you assess penalties in addition to late charges,
then define a separate activity for penalties.
 Miscellaneous Cash: Use activities of this type for entering miscellaneous

receipts. You must create at least one activity of this type if you plan to enter and
record miscellaneous receipts.
 Payment Netting: Use activities of this type when applying a receipt against
other open receipts. You can define multiple receivables activities of this type,
but only one Payment Netting activity can be active at any given time.
 Prepayments: Use activities of this type when creating prepayment receipts.

You can define multiple receivables activities of this type, but only one
Prepayment activity can be active at any given time.
 Refund: Use activities of this type to process non-credit card refunds.
 Unearned Discount: Use activities of this type to adjust a transaction if payment

is received after the discount period (determined by the transaction payment
terms). You must create at least one activity of this type.
 Receipt Write-Off: Use activities of this type when writing off receipts. You must
define the general ledger account to credit when you write off an unapplied
amount or an underpayment on a receipt.
Receivables Activity Setup
Define Receivables activities to default accounting and tax information to specific

Receivables transaction activities. The steps are:
 Select a business unit.
 Select an Activity Type.
 Select a GL Account Source to indicate how Receivables derives the

accounts for the expense or revenue generated by this activity:
Activity GL Account: Allocate the expense or revenue to the general ledger

account that you specify.
Distribution Set: Allocate the expense or revenue to the distribution set that you
specify. (Miscellaneous Cash activity type only)
Revenue on Invoice: Allocate the expense or revenue net of any tax to the
revenue account or accounts specified on the invoice. (Adjustment, Earned

Discount, or Unearned Discount activity types only)
Tax Rate Code on Invoice: Allocate the net portion using the expense/revenue
accounts specified by the tax rate code on the invoice. (Adjustment, Earned
Discount, or Unearned Discount activity types only)
 Select a Tax Rate Code Source:
None: Allocates the entire tax amount according to the specified GL Account
Source. Choose this option if you do not want to separately account for tax.
Activity: Allocate the tax amount to the asset or liability tax accounts specified
by the Receivables activity.
Invoice: Distribute the tax amount to the tax accounts specified by the tax rate
code on the invoice. You cannot choose this option if the activity type is
Miscellaneous Cash or Late Charges.
 Enter the GL account, distribution set (if applicable), and tax rate code (if
applicable).
 Complete the remaining setup steps, if applicable.
Receivables Activities Tax Rate Code Source Usage
The value of the Tax Rate Code Source determines how Receivables calculates and
accounts for tax on adjustments, discounts, and miscellaneous receipts.
This example shows how Receivables derives the general ledger accounts for revenue
and tax on an adjustment using the assigned Adjustment receivables activity.
You want to adjust an invoice by decreasing the line amount of $500 by $120. If
the Adjustment receivables activity is set with a Tax Rate Code Source of:
 None: Receivables does not calculate tax. The entire adjustment amount is
applied to the revenue account.
 Invoice: Receivables uses the tax rate code on the original invoice to distribute
the tax amount.
Define AutoAccounting Rules
Define Customer Billing Configuration > Manage AutoAccounting Rules: Go to Task
icon.
AutoAccounting rules provide default accounting information for transactions that

you enter manually or import using AutoInvoice. You must define AutoAccounting
before you can enter transactions in Receivables. When you enter or update a
transaction, you can override the default general ledger accounts that AutoAccounting
creates.
Define an AutoAccounting record for each account type. You can then assign either a
table name or constant value to each segment of the account.
The account types are:
 AutoInvoice Clearing: The clearing account for imported transactions.

Receivables uses the clearing account to hold any difference between the
specified revenue amount and the selling price times the quantity for imported
invoice lines. Receivables only uses the clearing account if you have enabled this
option on the transaction source used for imported transactions.
 Freight: The freight account for transactions.
 Receivable: The receivable account for transactions.
 Revenue: The revenue and late charges account for transactions.
 Tax: The tax account for transactions.
 Unbilled Receivable: The unbilled receivable account for transactions.

Receivables uses this account when the transaction uses the In Arrears invoicing
rule. If the revenue scheduling rule on the transaction recognizes revenue before
the invoicing rule bills it, Receivables uses this account.
 Unearned Revenue: The unearned revenue account for transactions.

Receivables uses this account when a transaction uses the In Advance invoicing
rule. If the revenue scheduling rule on the transaction recognizes revenue after
the invoicing rule bills it, Receivables uses this account.
AutoAccounting Rules Table Names and Constant

Values
When you define AutoAccounting rules, enter either the table name or constant value
that you want Receivables to use to retrieve information for each accounting flexfield
segment of a given account.
Use a constant value if you want AutoAccounting to always use the same value for a
given segment. You must ensure that you enter information that is valid for this
segment. For example, if you defined your Company segment as a two-character
segment with valid values ranging from 00 to 10, you must enter a two-character value
within this range.
When you use a table name, make sure that the general ledger accounts are defined
for the source. For example, if you select the Company segment to be derived from the
transaction type for Revenue, the revenue account must be entered for all transaction
types.
The tables are:
 Bill-to Site: Use the bill-to site of the transaction to determine this segment of
revenue, freight, receivable, AutoInvoice clearing, tax, unbilled receivable, and
unearned revenue accounts.
 Salesperson: Use the salesperson table to determine this segment of revenue,

freight, receivable, AutoInvoice clearing, tax, unbilled receivable, and unearned
revenue accounts.
If you select this option for AutoInvoice clearing, tax, or unearned revenue
accounts, Receivables uses the revenue account associated with the
salesperson on the transaction.
If you select this option for the unbilled receivable account, Receivables uses the
receivable account associated with the salesperson on the transaction.
If the transaction has a line type of Line with an inventory item of Freight,
AutoAccounting uses the revenue scheduling rules for the freight account rather
than the revenue account.
 Standard Lines: Use the memo line or inventory item on the transaction to
determine this segment of revenue, AutoInvoice clearing, freight, tax, unbilled
receivable, and unearned revenue accounts.
If you select this option for AutoInvoice clearing, freight, tax, unbilled receivable
or unearned revenue accounts, Receivables uses the revenue account
associated with the memo line item or inventory item.
 Tax: Use the tax account assigned to the tax rate codes on the transaction.
 Transaction Types: Use the transaction types table to determine this segment
of revenue, freight, receivable, AutoInvoice clearing, tax, unbilled receivable, and
unearned revenue accounts.
Define Receipt Classes and Receipt Methods
Define Customer Payments > Manage Receipt Classes and Methods: Go to Task icon.
The receipt class and related receipt methods provide default accounting information
for receipts.
Receipt Class and Receipt Method Relationship
The relationship between receipt class, receipt method, and bank account allows for
accounting defaults during receipt processing.
When you create a receipt:
 Specify the receipt method and one of the remittance bank accounts assigned to
the receipt method to use for the receipt.
 Accounting for the receipt is derived from the general ledger accounts assigned
to the remittance bank account.
 Receivables processes the receipt according to the receipt class that the receipt
method is associated with.
 For automatic receipts, Receivables uses the automatic processing settings on
the receipt method.
Defining Receipt Classes
The receipt class determines the processing steps that are required for receipts. These
steps include automatic or manual creation, the remittance method, the bank clearance
method, and whether receipts require confirmation by the customer.
Specify for each receipt class:
Creation Method: How to create receipts:
 Manual: Standard, batch, and lockbox receipts.

 Automatic: Bank account transfer and credit card receipts. Oracle Fusion
Payments processes funds capture.
Remittance Method: How to derive the remittance account for automatic receipts:
 No Remittance: Receipts that are not remitted.

 Standard: Regular remittance.
 Factoring: Factored remittance.
 Standard and Factoring: Use the receipt class for either standard or factored
remittance.
Clearance Method: How to reconcile receipts before posting to general ledger:
 Direct: Clear at time of receipt entry.

 By Automatic Clearing: Clear using the Clear Receipts Automatically program.
 By Matching: Clear receipts manually in Cash Management.
NOTE: This is the preferred method of clearing receipts. Receipts cleared

through Cash Management automatically generate reconciliation accounting
entries that are posted to general ledger.
Defining Remittance Banks for Receipt Methods
Associate remittance bank information with each receipt class and receipt
method combination:
 You can assign more than one remittance bank to each receipt class and receipt
method combination.
 Specify the bank name, branch, account, and currency for your remittance bank.
You must designate one remittance bank account as Primary for each currency.
 Specify the general ledger accounts that Receivables uses when you enter or
apply receipts using this remittance bank account.
 Legal entities are linked to remittance bank accounts. All receipts inherit the legal
entity from the bank account, and all refunds inherit the legal entity of the original
receipt.
Define Remit-to Addresses
Define Customer Billing Configuration > Manage Remit-to Addresses: Go to Task icon.
The remit-to address is the address that customers use to send payment for their open
debit items. You must assign a remit-to address to all transactions either entered
manually or imported using AutoInvoice. During the import process, AutoInvoice rejects
all invoices for which it cannot determine a remit-to address. If you do not wish to set up
a remit-to address for each location, you can set up one remit-to address with a default
assignment. Receivables will then use this address for all locations or for any locations
for which you do not have specific location assignments. This ensures that AutoInvoice
will not reject invoices because it could not determine a remit-to address.
Define default remit-to addresses to ensure that:

 Receivables is able to provide a default remit-to address when you enter
transactions
 AutoInvoice will not reject invoices because it is not able to determine a remit-to
address
You can manually enter a remit-to address on a transaction. You can also use the
Remit-to Address pages to automatically assign remit-to addresses to bill-to sites
in these ways:
 Country only: All customer bill-to sites in the selected country are assigned the
specified remit-to address.
 Country and state/region: All customer bill-to sites in the selected state or
region of the country are assigned the specified remit-to address.
 Country, state/region and postal codes: All customer bill-to sites in the
designated postal code or range of postal codes in the selected state or region
are assigned the specified remit-to address.
For United States remit-to addresses, you can only have one default remit-to address
for each country and state combination. For example, you can have one default remit-to
address for United States/California, one for United States/Nevada, and so on.
Suggestion: Define lockbox addresses as remit-to addresses to let customers know

where to send payment.
Define Approval Limits
Define Common Accounts Receivable Configuration > Manage Approval Limits: Go to
Task icon.
Define approval limits for your users for specific transactions and amount ranges per
currency. You can only assign approval limits to users that are defined in your system.
The combination of user, document type, and currency identify a specific approval limit
record. You can, for example, define multiple approval limit ranges for the same user
and document type in each currency defined in your system.
The three document types identify the transactions that a user can approve:
 Adjustment: Define Adjustment approval limits by currency and amount for each
applicable user for both creating and approving adjustments.
If an adjustment amount is within your approval limit, Receivables updates the
customer balance to reflect the adjustment. If it is outside your approval limit,
Receivables assigns the adjustment a status of Waiting Approval until someone
with the appropriate approval limits either approves or rejects it.
 Credit Memo Refund: Define Credit Memo Refund approval limits by currency
and amount. Receivables uses approval limits with this document type whenever
you attempt to electronically refund an on-account credit memo.
 Receipt Write-off: Define Receipt Write-off approval limits by currency and
amount. Receivables uses approval limits with this document type whenever you
attempt to write off either an unapplied receipt amount or an underpayment on a
receipt.
You cannot write off a receipt amount that is outside your approval limit range. In
addition, the approval limits for write-offs are separate from, but cannot exceed,
the system options write-off limits.
Define Statement Cycles
Define Accounts Receivable Balance Monitoring > Manage Statement Cycles: Go to
Task icon.
Define statement cycles to determine when to send statements to your customers.

Statements communicate activity to your customers about invoices, credit memos, debit
memos, payments, on-account credits, chargebacks, and adjustments.
To define a statement cycle:
 Assign the interval to use for the cycle—weekly, monthly, quarterly.
 Enter the dates on which to print statements for the cycle.

 Indicate whether to skip certain statement dates.
 Optionally enhance statements by creating custom messages.
Enter these profile settings on each customer bill-to site that will use this
statement cycle:
 Enable the Send statement option.

 Enter the statement cycle that you defined.
 Enter a value in the Minimum Statement Amount field. Receivables generates
statements for customers that have a minimum outstanding balance in the given
currency greater than this value.
 Optionally enable the Print remit-to address system option. If you enable this
option, Receivables prints the remit-to address on the related statements.
You can alternatively define a statement site for a given customer. For statement sites,
Receivables generates a single, consolidated statement for all the customer bill-to sites,
rather than a statement for each site. You can only define one active statement site per
customer.
To define a statement site:
 Assign the designated site the Statements business purpose.

 Set the Statement, Dunning, and Late Charges Site Profiles Used profile
option to Yes.
Use the Create Customer Statements program to print customer statements. If

you print statements for a specific customer, then:
 If you defined a statement site for the customer, Receivables uses the statement
cycle defined in the customer account profile as the default statement cycle to
use for printing.
 If you did not define a statement site, Receivables uses the statement cycle
defined in the customer site profile for each applicable bill-to site included in the
print run.
If you do not select a customer, then Receivables prints statements for all customers
that have a statement cycle that matches the statement cycle you enter for the print run.
Knowledge Check: Simple Configuration to Operate

Receivables
The order in which to perform the seven configuration tasks is:
1. System Options; Receivables Activities; Receipt Classes and Receipt Methods;

AutoAccounting Rules; Remit-to Addresses; Statement Cycles; Approval Limits
2. System Options; AutoAccounting Rules; Receivables Activities; Receipt Classes
and Receipt Methods; Approval Limits; Remit-to Addresses; Statement Cycles
3. System Options; Receivables Activities; AutoAccounting Rules; Receipt Classes
and Receipt Methods; Remit-to Addresses; Approval Limits; Statement Cycle
The receivables activity Tax Rate Code Source value determines how Receivables
calculates and accounts for tax on invoices.
1. True
2. False
Receipts uploaded via spreadsheet require a receipt class with a manual creation
method.
1. True
2. False
You can write off any receipt amount within your approval limits.
1. True
2. False
Knowledge Check: Simple Configuration to Operate

Receivables Answers
Name the order in which to perform the seven configuration tasks.
 System Options; Receivables Activities; AutoAccounting Rules; Receipt

Classes and Receipt Methods; Remit-to Addresses; Approval Limits;
Statement Cycles
The receivables activity Tax Rate Code Source value determines how Receivables
calculates and accounts for tax on invoices.
 False. The Tax Rate Code Source determines how Receivables calculates and
accounts for tax on adjustments, discounts, and miscellaneous receipts.
Receipts uploaded via spreadsheet require a receipt class with a manual creation
method.
 True. The Manual creation method is for manually entered receipts and receipts
uploaded in batch, including via spreadsheet.
You can write off any receipt amount within your approval limits.
 False. You can write off any receipt amount within your approval limits, provided
the amount is not outside the range of write-off amounts defined in Receivables
system options.
Implementation Considerations for Transactions
Depending on your requirements, you may need to configure, or update the

defaults for, various setups related to transactions.
Additional implementation considerations for transactions include:
 Define Transactions Types

 Define Payment Terms
 Define Transaction Sources
 Set Up Document Sequences in Receivables
 Set Up Balance Forward Billing
 Define Memo Lines
 Implement AutoInvoice
Define Transaction Types
Define Customer Billing Configuration > Manage Transaction Types: Go to Task icon.
Transaction types provide a number of default settings that help to characterize your
transactions. You should set up transaction types before you enter transactions.
Use transaction types to:
 Set up specific transaction details for each transaction class: debit memo, credit
memo, on-account credit, chargeback and invoice.
 Assign a legal entity to the transaction.
 Define accounting for transactions, including whether transaction entries update

customer balances and whether Receivables posts transactions to general
ledger.
 Determine the natural application setting.
 Define transactions for late charges, freight and tax classification code.
 Determine the creation sign.
Define Transaction Types in Order
Define transaction types in this order to properly associate one transaction type with
another:
 Credit memo
 Invoice
 Debit memo
 Chargeback
Defining credit memo transaction types first lets you assign a credit memo to the Invoice
transaction type. When you create a credit memo for the invoice, the credit memo
transaction type is used.
Legal Entity Assignment
If you are using a shared accounting environment, you can assign a legal entity to a
transaction type to appear by default on the transaction. Receivables looks for and
assigns a legal entity to a transaction according to this hierarchy:
 Legal entity of the transaction type assigned to the transaction.

 Legal entity of the transaction source assigned to the transaction.
 Default legal entity assigned to the business unit.
Excluding Late Charge Calculation
Enable the Exclude from late charges calculation option to exclude from late charges
specific categories of transaction.
Tax Classification Code Assignment
You can optionally enable the Default tax classification code option to default a tax
classification code to transaction lines. You use tax classification codes as determining
factors in tax calculation.
Using Natural Application
Applications of receipts or credit memos to transactions are processed differently,

depending on the settings of the Natural Application Only and Allow Overapplication
options on the transaction type:
Natural Application Only Selected, Allow Overapplication Not Selected
 Receivables allows any application that reduces the transaction amount toward
or to zero without changing the sign of the transaction.
 For example, if the transaction amount is +$500, Receivables allows the
application as shown in the top section of the diagram.
Natural Application Only Not Selected, Allow Overapplication Selected or Not

Selected
 Receivables allows any application that either reduces or increases the

transaction amount, even if the application changes the sign of the transaction,
as shown in the bottom section of the diagram.
Define Payment Terms
Define Customer Billing Configuration > Manage Receivables Payment Terms: Go to
Task icon.
Use payment terms to identify due dates, discount dates, and installment details for
customer open items. You assign payment terms to customer profiles or to customer
information on transactions.
The formula used to determine the amount due is:
Amount Due = Relative Amount/Base Amount * Invoice Amount
For example: Relative Amount = 60%/Base Amount = 100% would be 60% of Invoice
amount.
Note: The base amount is the denominator for the ratio that Receivables uses to
determine the amount due for installments of invoices to which you assign this payment
term. The sum of the relative amounts for all of the payment schedules that you define
for these payment terms must be equal to the value that you specify as the base
amount.
Use these settings for payment terms:
 Enter the number of days before the due date that the invoice should be printed.
 Enable the Allow discount on partial payments option to let your customers
take discounts for partial payments on items associated with payment terms. A
partial payment is a payment that is less than the remaining amount due. If you
do this, you must also ensure that the Discount on partial payment system
option is enabled.
 Use the Discount Basis field to determine what amount Receivables uses to
calculate discounts for the particular payment terms. If the payment terms use
installments, you can assign discount percentages to each installment.
 Use the Installment Option field to determine how to allocate the freight and tax
charged to transactions with split terms. You can either distribute tax and freight
charges across all installments, or allocate all freight and tax charges to the first
installment.
Define Transaction Sources
Define Customer Billing Configuration > Manage Transaction Sources: Go to Task icon.
Transaction sources have these uses and recommendations:
 Transaction batching and numbering, where applicable.

 Assign default values to transactions.
 Assign a legal entity to transactions.
 Select validation options for imported transactions.
 Create a transaction source for late charges, if applicable.
 Set up for automated non-credit card refunds.
 Enable the Copy Document Number to Transaction Number option to use the
same value for both the document number and the transaction number for
transactions assigned to this source. You must enable this option if you are using
Gapless document sequences.
Setup Objects to Create before Transaction Sources
Depending on your requirements, create these setup objects before creating your
transaction sources:
 Transaction types: Define the transaction types that you want to appear by
default on transactions assigned to your transaction sources.
 Invoice transaction flexfield: Define the reference information that you want to
capture in the invoice transaction flexfield and display on imported transactions,
such as a purchase order number.
 Credit memo transaction source: Define a transaction source for credit memos
before you define a transaction source for invoices. Use this transaction source
to number the credit memos created against invoices differently from the invoices
they are crediting.
Legal Entity Assignment
If you are using a shared accounting environment, you can optionally assign a legal
entity to a transaction type to appear by default on the transaction. Receivables looks
for and assigns a legal entity to a transaction according to this hierarchy:
 Legal entity of the transaction type assigned to the transaction.

 Legal entity of the transaction source assigned to the transaction.
 Default legal entity assigned to the business unit.
Transaction Source for Late Charges
If the late charge policy for any of your business units is to create either Interest
Invoices or Debit Memos, then create a separate transaction source for late charges.
Create a transaction source for Interest Invoice or Debit Memo late charges with Type
Imported. The transaction source Type is Imported because the Interest Invoice and
Debit Memo creation is done as a batch process that calls the Invoice API. You then
assign this source in the System Options pages.
Automated Non-Credit Card Refunds
You can set up Receivables to automate the refund process for non-credit card
transactions. Receivables submits the refund request to Payables, and Payables in turn
transacts refunds via Payments.
To set up for automated refunds:
1. Create a Refund receivables activity.

NOTE: Use the Credit Card Refund activity type for credit card refunds.
2. Set the Receipt Handling for Credits field to Refund in the transaction source.
You set this option to Refund for both credit card and non-credit card automated
refunds.
Set Up Document Sequences in Receivables
Use document sequences to assign unique numbers to Receivables transactions,

receipts and adjustments, in addition to the number generated for each activity.
Use of document sequencing in Receivables is optional, though it is required for

automatic receipts in order to automatically generate receipt numbers during automatic
receipt processing.
To implement document sequences in Receivables:
1. Set the Sequential Numbering profile option to Always Used or Partially Used:
 Always Used: You must enter a document number when entering transactions
or receipts.
 Partially Used: You can enter a transaction or receipt even if no sequence exists
for it. Use this value if you want to use sequential numbering for automatic
receipts only.
2. Set the Document Number Generation Level system option to generate a
document number when the transaction is saved or when the transaction is
completed.
3. Define document sequences.
4. Assign document sequences to document categories.

Receivables creates a document category for every receipt method, transaction type,
and receivables activity that you define.
NOTE: If you have Oracle Fusion General Ledger installed and you enabled sequential
numbering, then you must define sequences, categories, and assignments for your
journal entry categories before you can post.
Implementing Gapless Transaction Numbering
Use gapless transaction numbering to ensure that document numbers are assigned to
transactions in order and with no breaks. Gapless transaction numbering is a
requirement for certain government and local authorities.
To implement gapless transaction numbering when creating document sequences:
 Set the Sequential Numbering profile option to Always Used.

 Define a transaction source with the Copy document number to transaction
number option enabled.
 Do not enable the Allow transaction deletion system option.
Set Up Balance Forward Billing
Define Customer Billing Configuration > Manage Balance Forward Billing Cycles: Go to
Task icon.
Balance forward billing consolidates customer transactions and payment activities into
one bill. The bill is sent to the designated customer account or customer bill-to site
according to the defined balance forward billing cycle.
The balance forward bill provides customers with a complete picture of their beginning
balance, activities during the billing period, and their current outstanding balance. The
single bill with single payment terms also simplifies the process of customer payment.
To set up balance forward billing:
 Define a balance forward billing cycle.

 Define balance forward billing payment terms.
Set up the related customer account and customer site profiles for balance
forward billing:
 Set the Enable balance forward billing option.
 Set the Bill Level and Bill Type.

 Assign a balance forward billing cycle and balance forward billing payment terms.
Define Memo Lines
Define Customer Billing Configuration > Manage Standard Memo Lines: Go to Task
icon.
Use memo lines to define goods or services that are sold frequently, but have not been
defined as inventory items, such as Annual Maintenance Contracts or Consulting
Services. You can assign memo lines to debit memos, on-account credits, debit memo
reversals, chargebacks, and invoices.
Use the line type of Line to create a memo line for non-inventory items. If the price is
constant, you can enter a default unit price to use when this memo line is selected.
Use line types of Charges, Freight, or Tax to create memo lines specific to these
transaction details. You can use tax memo lines on transactions if your tax definition
lets you enter manual tax lines on transactions. After you enter a tax memo line on a
transaction, you can specify the amount of tax to assign to the transaction line.
Implement AutoInvoice
AutoInvoice imports and validates transaction data from other financial systems and
creates invoices, debit memos, credit memos, and on-account credits in Receivables.
You use a custom program to transfer transaction data from an external system into the
AutoInvoice interface tables. The AutoInvoice import process selects data from the
interface tables and creates transactions in Receivables.
Transactions that fail the import process are transferred to the

RA_INTERFACE_ERRORS_ALL table. You can correct these errors and upload again.
Implementation considerations for AutoInvoice include:
 AutoInvoice system options

 AutoInvoice grouping rules and line ordering rules
 Transaction source settings for AutoInvoice
 Profile options for AutoInvoice

 Transaction flexfields
Setting Up for AutoInvoice
System Option Settings for AutoInvoice
Use the AutoInvoice section of the Billing and Revenue tab of the System Options
pages to set these system options:
 Enable the Purge interface tables option to automatically purge the AutoInvoice
Interface tables after running AutoInvoice. Receivables deletes the records that
have successfully transferred into permanent Receivables tables.
Do not enable this option if you want to purge the table manually.
 Enter in the Maximum Memory in Bytes field the value that represents the
amount of memory to allocate to AutoInvoice for validation. The default is 65535
bytes. For best results, enter a value that is the maximum number of records that
you import—rounded to an even number—multiplied by 1024.
 Enter in the Log File Message Level field a value from 0 to 5 to indicate the
amount of detail that you want to display in the AutoInvoice log file. For day-to-
day business needs and to improve performance, set the level to 0. If you
experience errors while running AutoInvoice, you can set the output to a higher
level to review more detailed information in the log about the errors.
 Enter the Accounting and System Items segments that are most often selected
by AutoInvoice. Receivables uses this information to increase AutoInvoice
performance.
Optional Setups for AutoInvoice
You can optionally create these objects for Imported transaction sources:
 AutoInvoice Line Ordering Rules: Create line ordering rules to define how to
order transaction lines within the transactions created by AutoInvoice.
 AutoInvoice Grouping Rules: Create grouping rules to define how to group

transactions created by AutoInvoice. You assign a line ordering rule to a
grouping rule.
 AutoInvoice clearing account: Define an AutoInvoice clearing account, if you

intend to enable the Create clearing option. AutoInvoice puts any difference
between the revenue amount and the selling price times the quantity for a
transaction into this account.
Transaction Source Settings for AutoInvoice
Create transaction sources of type Imported to use with the AutoInvoice program. Use
the AutoInvoice Options and Import Information sections of an Imported transaction
source to define how AutoInvoice validates imported transaction lines assigned a
particular transaction source.
In the Import Information section, where applicable, select Number, Value, Segment
or ID for each option to indicate how AutoInvoice validates information.
 Select Number to import a record into the interface tables using its assigned
number.
 Select Value to import a record into the interface tables using its actual name.
Use Value if you intend to use the transaction source to import data from a non-
Oracle system.
 Select Segment to use the flexfield segment.
 Select ID to use the internal identifier of the record. If you use an Oracle system,
then ID is quicker because of the shorter character length.
 Select Amount or Percent to indicate how AutoInvoice validates Sales Credits
and Revenue Account Allocations on transaction lines.
Profile Options
Set these profile options for AutoInvoice:
 ID Flexfield Code: Specify the ID of the flexfield code used by AutoInvoice.

 Maximum Lines per AutoInvoice Worker: Specify the maximum number of
lines per AutoInvoice worker.
 Source Code: Specify the source code used by AutoInvoice.
 Use Parallel Hint: Enable parallel hints in AutoInvoice.
 AutoInvoice Gather Statistics Allowed: If you set this profile option to Yes,
then when you submit AutoInvoice, the program first analyzes the interface
tables (RA_INTERFACE_LINES_ALL, RA_INTERFACE_DISTRIBUTIONS_ALL,
and RA_INTERFACE SALESCREDITS_ALL) and gathers statistics to determine
how best to execute the transaction import. If the number of records to be
imported and the number of worker processes are approximately the same as
the previous submission of AutoInvoice, then you can set this profile option to No
and skip this analysis.
Transaction Flexfields
Receivables uses the transaction flexfield to uniquely identify each transaction and
transaction line you import using AutoInvoice. Transaction flexfields are also used to
refer to and link transaction lines.
You must define both a line-level and a header-level transaction flexfield. All segments
in the line-level transaction flexfield that refer to header information must also exist in
the header-level transaction flexfield. For example, if you define a line-level transaction
flexfield with four segments, and only the last two segments refer to line-level
information, define the header-level transaction flexfield using the first two segments.
If you do not create Reference and Link-to transaction flexfields, then Receivables will
use the line-level transaction flexfield structure to link and reference different lines. You
do not have to define separate Reference and Link-to transaction flexfields in this case.
However, if you are planning to create a customized form to enter interface data to
display the Reference and Link-to transaction flexfields, then you must define these
transaction flexfields. These flexfields must have the same flexfield structures as the
line-level transaction flexfield.
Implementation Considerations for Receipts
Depending on your requirements, you may need to configure, or update the

defaults for, various setups related to receipts.
Additional implementation considerations for receipts include:
 Define AutoCash Rules

 Define Application Rules
 Define AutoMatch Rules
 Define Receipt Application Exception Rules
 Implementation Considerations for Lockbox
Define AutoCash Rules
Define Common Accounts Receivable Configuration > Manage AutoCash Rule Sets: Go
to Task icon.
Receivables uses the AutoCash rule set, if one is available, to apply a receipt in cases
where there is no transaction information for the receipt. The AutoCash rule set
determines how to apply a receipt to customer open debit items and update the
customer account balance. The rule set consists of general settings and a combination
of the five available rules for applying receipts.
When you apply a receipt, Receivables uses the first rule in the AutoCash rule set. If the
first rule in the set does not find a match, Receivables uses the next rule in the
sequence, and so on until it can apply the receipt. If none of the rules in the rule set
apply, Receivables places the remaining amount either unapplied or on-account,

depending on the setting of the Remaining Remittance Amount option.
The general settings are:
 Discount: Specify whether to calculate earned or unearned discounts on receipt

applications.
 Late Charges: Indicate whether to include late charges in the open balance
calculation.
 Items in Dispute: Indicate whether to include items in dispute in the open
balance calculation.
 Remaining Remittance Amount: Indicate how to save remittance amounts from
partial payment applications: as unapplied or on account.
Enter the rules to use in the rule set, and the order in which Receivables should use
them to apply receipts. The five available rules are:
 Match Payment with Invoice: This rule applies a receipt to a single invoice,
debit memo, or chargeback only if the receipt amount exactly matches the
amount of the debit item.
 Clear the Account: This rule applies a receipt only if the receipt amount exactly
matches the customer open balance.
 Clear Past Due Invoices: This rule applies a receipt only if the receipt amount
exactly matches the customer past due account balance.
 Clear Past Due Invoices Grouped by Payment Terms: This rule applies a
receipt only if the receipt amount exactly matches the sum of the customer credit
memos and past due invoices.
 Apply to the Oldest Invoice First: This rule applies receipts to customer debit
and credit items, starting with the item with the oldest due date.
Define Application Rules
Define Customer Payments > Manage Application Rule Sets: Go to Task icon.
An Application rule set determines how Receivables reduces the balance due on line,
tax, freight, and late charge amounts when you apply a payment or credit memo to a
transaction.
You must set up at least one Application rule set and assign it to system options. You
can also assign Application rule sets to transaction types to indicate how to process
payment applications for the related transactions. During receipt processing, if no
Application rule set is assigned to a transaction type, Receivables uses the Application
rule set assigned to system options.
You can arrange the order of the line types and application rules in an Application rule
set according to your requirements. Each line type must appear in an Application rule
set, and appear only once. The Overapplication rule is always last in the sequence.
The application rules are:
 Line First - Tax After: This rule first applies the payment to the open line
amount, and then applies the remaining amount to the associated tax.
 Line and Tax Prorate: This rule applies a proportionate amount of the payment
to the open line and tax amount for each line.
 Prorate All: This rule applies a proportionate amount of the payment to each
open amount associated with a debit item.
 Overapplication: This rule applies any remaining receipt amount after the
balance due for all charges has been reduced to zero.
The Tax Treatment option determines how to reduce the tax amount in relation to the
line amount when a payment is applied. The tax treatment options are:
 Prorate: Proportionately reduce the net amount of the line and associated tax
amounts.
 Before: First reduce the open tax amount, and then apply any remaining amount
to the line.
 After: Reduce the open line amount, and then apply any remaining amount to
the associated tax.
Assign the Rounding Correction option to one of the line types in an Application rule
set. When an amount is prorated across more than one line type, Receivables adjusts
the line amount of the line type with the Rounding Correction option enabled to
account for the rounding adjustment.
Define AutoMatch Rules
Define Customer Payments > Manage AutoMatch Rule Sets: Go to Task icon.
An AutoMatch rule set helps to complete the process of applying receipts to

transactions. The settings in the AutoMatch rule set provide these recommendations:
 Customer recommendations: The matching process recommends customers

for lockbox receipts that have invalid or missing customer information. If the
customer information is missing, it cannot create a customer recommendation.
 Transaction recommendations: The matching process recommends one or
more transactions for receipt application for both lockbox and manual receipts if
the match(es) are not within the defined threshold.
AutoMatch Threshold Settings
The AutoMatch threshold settings have the following meaning:
 Customer Recommendation Threshold: The qualifying percentage necessary

to add customer information to a receipt. If the calculated score for a customer
account number is above this threshold, then the AutoApply process adds this
customer information to the receipt. The system will provide recommended
matches if it does not find a match within the threshold.
 Minimum Match Threshold: The qualifying percentage necessary to define the
relative importance of customer, transaction and amount matches when deciding
the final match score. If the calculated score for one or more transactions is
above this threshold, the AutoApply process recommends the transactions for
receipt application, in order of the highest percentage match.
NOTE: The minimum match threshold must be less than the customer
recommendation threshold and the combined weighted threshold.
 Combined Weighted Threshold: The qualifying percentage necessary for the
AutoApply process to apply a receipt to a transaction automatically. This
percentage is the sum (always 100%) of the qualifying percentages defined for
the supplied customer information, transaction information, and actual
transaction amount that is considered for receipt matching.
 Days of Closed Invoices Threshold: Determines which closed transactions to
include in the AutoMatch process. All transactions that were closed on or before
the number of days provided as the threshold value are considered for
application or recommendation.
AutoMatch Calculation
The threshold qualifying percentages defined in the AutoMatch rule set are compared to
the resulting scores of each customer account number or transaction number that is
analyzed by the matching process.
The matching process derives a recommendation in this way:
1. If applicable, remove characters and spaces from the number as defined by the
AutoMatch rule set string handling.
2. Apply the formula (Levenshtein algorithm) to the resulting string to obtain the
score. This formula is:
1 - (number of changes required to make the recommended string match the
provided string / length of the larger string)
3. Compare the resulting score to the applicable threshold.
For example, transaction number 10010 is provided by lockbox for a receipt application.
This number does not exist, but Receivables finds the number AR10001. The
recommendation for this number is calculated in this way:
1. The AutoMatch rule set string handling settings indicate that the first two
characters are to be removed from a string under consideration.
Receivables removes AR, leaving the number 10001.
2. It will take one change for 10001 to match 10010. Therefore, the score for this
match is (1 - 1/5) = 80%.
3. The 80% score exceeds the Combined Weighted Threshold value of 70%, so the
receipt is automatically applied to transaction AR10001.
Define Receipt Application Exception Rules
Define Customer Payments > Manage Receipt Application Exception Rules: Go to Task
icon.
Use Receipt Application Exception Rules to manage remaining amounts after

SmartReceipts/AutoApply, which can be from manual receipts, Excel uploaded receipts,
and lockbox receipts.
The AutoApply process uses the details of the Receipt Application Exception Rules
either to process overpayments and underpayments automatically or to present
overpayments and underpayments for user review and manual adjustment:
 If there is an overpayment, the application exception rule indicates whether to

refund the amount to the customer, place the amount on account, write off the
amount, or leave the amount unapplied.
 If there is an underpayment, the application exception rule indicates whether to
allow write off of the remaining open balance amount on the transaction.
Exception Rules
Each exception rule in Receipt Application Exception Rules consists of a condition, the
amount and percentage that applies to the condition, and the action to take when this
condition arises:
 The Action field contains the receivables activities that you have defined for
Adjustment, Receipt Write-off, or Refund.
 The underpayment or overpayment amount is accounted for in the general ledger
accounts belonging to the applicable receivables activity.
 The User Review Required option indicates whether the action is processed
automatically or requires manual review and approval.
For example, the exception rule:
Over Payment >= 100 Refund
means that after the receipt is applied, if the remaining overpayment is greater than
$100, then a refund will be generated.
The exception rule:
Under Payment < 5 Write-off
means that if a receipt application results in an underpayment of less than $5, then the
remaining amount will be automatic unless User review is required.
Implementation Considerations for Lockbox
Define Customer Payments > Manage Lockbox: Go to Task icon.
Implementation considerations for lockbox include:
 Receipt Sources and Receipt Class

 Lockbox Transmission Formats
 Lockbox Batch Size
 Receipt Match By
Receipt Sources and Receipt Class
Define receipt sources for lockbox processing to assign the receipt class, receipt
methods, and remittance banks that you want to use.
Lockbox Transmission Formats
Receivables uses the lockbox transmission format that you specify in the Process
Receipts Through Lockbox: Import program submission to ensure that data is
correctly transferred from the bank file into the AR_PAYMENTS_INTERFACE_ALL
table. The transmission format contains information such as the customer account
number, bank account number, the amount of each receipt to apply, and the transaction
numbers to which to apply each receipt.
You must ensure that you create transmission formats that accept customer reference
and customer reason codes. Work with your banks to ensure the entry of the correct
codes for your lockbox.
Lockbox Batch Size
Use the Batch Size field to enter the number of receipts to assign to each receipt batch
during lockbox processing. If you do not want the lockbox process to separate your
lockbox submission into multiple receipt batches, complete these steps:
 Enter a number in the Batch Size field that is larger than the number of receipts
in the lockbox transmission for this lockbox.
 Enable the Complete batches only option when you submit your lockbox
transmission.
Receipt Match By
Use the Receipt Match By section of Lockbox pages to enter settings that can automate
the processing of receipt applications:
 AutoApply: Enable the Use AutoApply option to use AutoApply to process

receipts for the lockbox. You must also enable this option at the system options
level for the applicable business unit.
 AutoMatch Rule Set: Use an AutoMatch rule set to provide recommendations
for customers and transactions.
 Match Receipts By: Use the Match Receipts By rule to identify the document
type to use to match receipts to open debit items. There are six document types
available for matching:
Transaction number
Sales order number
Purchase order number
Balance forward billing number
Shipping reference
Contract number
You assign document types to the Match Receipts By rules on customer and site
profiles, lockbox records, and Cash Processing system options. These assignments
indicate the preferred document type references to use to match customer receipts to
transactions. During lockbox processing, Receivables attempts to match receipts to the
reference numbers provided, such as a transaction number or a purchase order
number, depending on the references that the customer usually provides. When a
matching document is found, it looks for the Match Receipts By rule to use to
determine whether to match with this document. Receivables searches for a Match
Receipts By rule in the order:
 Customer site
 Customer
 Lockbox
 System options
If a rule is found that matches the document reference, Receivables matches and
applies the receipt to the transaction. If an applicable rule is not found, Receivables
applies the receipt using the AutoCash rule set defined for the customer.
If the AutoCash rule set is unable to apply the receipt, Receivables assigns the receipt a
status of Unapplied. In addition, if there is no Match Receipt By setup anywhere in the
system, Receivables also assigns the receipt a status of Unapplied. You must then
manually apply the receipt.
Best Practices for Automatic Receipts
These recommendations apply to setting up for automatic receipts:
Oracle Fusion Payments: Configure Funds Capture processing in Oracle Fusion

Payments.
Receipt Source: Receivables provides the automatic receipt source Automatic

Receipts. The only update to make is to enter a value in the Last Number field to
indicate how to number receipt batches.
Receivables System Options: Set the Receivables system options for automatic
receipts.
Receipt Classes: Set up receipt classes for use with automatic receipts:
 Creation Method: Automatic.

 Remittance Method: Standard, Factoring, or Standard and Factoring.
 Require confirmation option: Use this option in accordance with the
agreements you have with your customers. If some customers require
confirmation of automatic receipts while others do not, then set up more than one
receipt class.
NOTE: You can use the Receipt Confirmation Threshold Amount system
option to enter an amount below which automatic receipts do not require
confirmation.
Receipt Methods: Set up receipt methods within a receipt class to specify how
automatic receipts are processed:
 Number of Receipts Rule: Set this rule according to your needs. For example,
the One Per Customer rule creates one automatic receipt for all invoices
belonging to a customer with the same receipt method. In this way you can pay
multiple invoices with a single receipt.
NOTE: The Number of Receipts Rule assumes an additional grouping by

payment instrument. For example, if you use the One per Customer rule, and two
invoices belonging to the same customer are to be paid with different credit
cards, the automatic receipt process create two receipts, one for each credit card
number.
 Receipt Maturity Date Rule: This rule determines the maturity date to give the
receipt when it is applied to invoices with different due dates. When you remit a
receipt, the remittance bank uses the maturity date to determine when to transfer
funds from the customer bank account to your remittance bank account.
 Lead Days: Enter the number of days before the invoice due date that an invoice
can be selected for application by the automatic receipt process using this receipt
method. This option is useful, for example, when customer confirmation is
required. You can set the value to the number of days normally required to
receive confirmation.
 Customer Payment Method: Enter the bank account or credit card payment
method to use for automatic receipts. You can create multiple receipt methods to
support different payment methods.
 Funds Transfer Error Handling: Use this section to map the corrective actions
in Receivables to each error code that you anticipate from the third party system
that you will use for payment. This mapping is used to automatically perform the
corrective actions on the errors.
 Minimum Receipt Amount: Use this field on the remittance bank account pages
to enter an amount below which automatic receipts are not created. This
prevents creating automatic receipts for small amounts. You can also enter a
minimum amount in the customer and customer site profiles.
Document Sequences: Unless you intend to use the Receipts inherit transaction
numbers option on the receipt method that you will use for automatic receipts, then you
must set up document sequencing to enable automatic receipt numbering.
If you are using document sequences, make sure that the Sequential Numbering
profile option is set to Partially Used or Always Used.
Customer and Site Profiles: Assign receipt methods and payment instruments to
customer and customer site profiles. You can also enter minimum receipt amounts for a
customer or site.
Best Practices for Automatic Receipt Application
These recommendations apply to setting up for automatic receipt application:
 AutoApply: Enable AutoApply in Cash Processing system options and on your

lockboxes to enable maximum automatic application rates. The features in
AutoApply, AutoMatch and Receipt Application Exception rules allow users to
provide as little or as much information as necessary to process receipts.
 AutoMatch: Use the threshold scores in AutoMatch to define rules that can
augment automatic receipt application success rates. For example, give more
weight to transaction scores if you know that the paying customer can usually be
identified.
 Receipt Application Exception Rules: Use Receipt Application Exception rules

to manage your small over and under payments automatically. Managing these
payments automatically saves you from investing unnecessary resources in
researching and manually processing small amounts.
 Match Receipts By: The Match Receipts By feature helps you individually
manage receipt processing for your customers according to the document
references that they usually provide.
Sometimes customers provide inconsistent match references, for example,
sending a purchase order number one time and a waybill number another time.
You can enable the Automatically update receipt match by option on the
customer account or site profile to update the Match Receipt By rule for this
customer as the references change.
Implementation Considerations for Revenue

Management
Depending on your requirements, you may need to configure or update the

various setups related to revenue management.
Implementation considerations for revenue management include:
 Settings for Revenue Recognition

 Revenue Scheduling Rules
 Define Revenue Policies
 Define Revenue Contingencies
Settings for Revenue Recognition
These settings influence revenue recognition on your transactions:
 Salesperson System Options

 Revenue Adjustment Reason Lookup Type
 AutoAccounting based on Standard Line
Salesperson System Options
You must enable the Require salesperson system option for revenue accounting.
Revenue accounting requires that you assign sales credits to all transactions that can
be adjusted for either revenue or sales credits. If you do not normally track sales credits,
and you want to use revenue accounting for revenue adjustments only, use the default
salesperson value of No Sales Credit.
Optionally enter a value in the Sales Credit Percent Limit field to limit the percentage
of revenue plus non-revenue sales credit that a salesperson can have on any
transaction line. If you do not enter a value for this system option, then no sales credit
limit validation is performed during revenue accounting.
Revenue Adjustment Reason Lookup Type
Use the Revenue Adjustment Reason lookup type to define reasons specific to your
requirements for making revenue adjustments.
AutoAccounting based on Standard Line
If AutoAccounting is set to derive accounting segments based on standard line, the

transaction line must be either an inventory item or a memo line, and not a user-entered
line. Otherwise, AutoAccounting cannot derive a valid account code combination.
Revenue Scheduling Rules
Define Customer Billing Configuration > Manage Revenue Scheduling Rules: Go to
Task icon.
Revenue scheduling rules determine the accounting period or periods in which to record
revenue distributions for transactions.
Assign revenue scheduling rules to transactions according to your requirements. Each

transaction line must have revenue scheduling rule information, including the rule name,
rule type, revenue period and number of revenue periods, date to start recognizing
revenue, and, where applicable, an end date.
The rule type on the revenue scheduling rule calculates the revenue distributions on the
transaction:
 Daily Revenue Rate, All Periods: This rule type uses a daily revenue rate to
accurately calculate revenue distributions across all accounting periods, including
both full and partial periods. This rule type provides the most precise revenue
recognition schedule.
 Daily Revenue Rate, Partial Periods: This rule type uses a daily revenue rate
to accurately calculate the revenue for partial periods only. This rule provides you
with an even, prorated revenue distribution across the full periods of the
schedule.
 Fixed Schedule: This rule type requires both a period type (such as weekly or
monthly) and the number of periods over which to recognize revenue. The
revenue is then evenly divided across the periods.
 Variable Schedule: This rule type also requires a period type, but not the
number of periods. The number of periods is calculated automatically either
when you enter a transaction manually or import using AutoInvoice.
Define Revenue Policies
Define Revenue Management Configuration > Manage Revenue Policies: Go to Task
icon.
Use the revenue policy to make automatic revenue recognition decisions for manually
entered and imported transactions.
You specify revenue policies for each applicable business unit. When you enter
transactions either manually or using AutoInvoice, Receivables evaluates each
transaction according to the revenue policy. If a transaction or transaction line exceeds
the policy definitions, Receivables:
 Assigns a revenue contingency to the transaction or transaction line.

 Defers revenue on the transaction or transaction line.
 Recognizes revenue on the transaction or transaction line according to the
details of the contingency.
Revenue policies provide contingency monitoring in these areas:
 Credit Classification: Assign up to three levels of risk. Receivables compares

these risk levels to the credit classification assigned to the profile of the customer
on the transaction. A contingency is assigned to the transaction if the applicable
customer has a credit classification that matches one of the credit classifications
defined in your revenue policy.
 Payment Terms: Enter the maximum time period in days before payment terms
become extended. The contingency is assigned to the transaction if its payment
terms exceed the payment terms threshold of your revenue policy.
Define Revenue Contingencies
Define Revenue Management Configuration > Manage Revenue Contingencies: Go to
Task icon.
When you enter or import transactions, Receivables evaluates each transaction and
decides whether to immediately recognize revenue, or temporarily defer revenue to an
unearned revenue account based on the contingencies assigned to the transaction.
Revenue is subsequently recognized according to the removal event assigned to each
contingency.
Contingencies can expire automatically based on specific events. Examples include:
 Payment: The contingency on a transaction is removed when payment is

received.
 Time: A pre-defined time period has elapsed, expiring the contingency and
allowing the recognition of revenue.
 User Action: An event is recorded, such as proof of delivery, that allows for the
removal of a contingency.
You can also expire contingencies manually at any time. Once a contingency expires,
Receivables can recognize revenue on the related transaction or transaction lines.
Receivables provides predefined revenue contingencies to assign to your customer

transactions. You can also define your own contingencies based on the predefined
contingencies, and you can define revenue contingency assignment rules to control
which contingencies are assigned to which transactions.
This table describes the predefined revenue contingencies and their corresponding
contingency removal events:
Knowledge Check: Additional Implementation

Considerations
Natural Application means that you can apply a receipt of any amount to a
transaction of any amount.
1. True
2. False
Receivables looks for and assigns a legal entity to a transaction in which order:
1. Transaction type; transaction source; business unit

2. Transaction source; transaction type; business unit
3. Transaction type; transaction source; ledger
The AutoMatch rule set applies receipts automatically whenever it finds a match.
1. True
2. False
If the Match Receipt By rule cannot apply a receipt automatically, then you must
apply the receipt manually.
1. True
2. False
If you do not track sales credits and you use revenue accounting for revenue
adjustments only, then do not enable the Require Salesperson system option.
1. True
2. False
Knowledge Check: Additional Implementation

Considerations Answers
Natural Application means that you can apply a receipt of any amount to a
transaction of any amount.
 False. Natural Application only allows applications against transactions that

reduce the transaction amount toward or to zero.
Name the order in which Receivables looks for and assigns a legal entity to a
transaction.
 Transaction type; transaction source; business unit

The AutoMatch rule set applies receipts automatically whenever it finds a match.
 False. The AutoMatch rule set can result in automatic application. It is based
upon the comparison of the generated match score in comparison to the
thresholds established. The rule set recommends one or more transactions for
receipt application, and recommends customers for receipts that have invalid or
missing customer information.
If the Match Receipt By rule cannot apply a receipt automatically, then you must
apply the receipt manually.
 False. If the Match Receipt By rule cannot apply a receipt automatically,

Receivables applies the receipt using the AutoCash rule set defined for the
customer. If the AutoCash rule set is unable to apply the receipt, then you must
manually apply the receipt.
If you do not track sales credits and you use revenue accounting for revenue
adjustments only, then do not enable the Require Salesperson system option.
 False. You must enable the Require salesperson system option for revenue
accounting. If you want to use revenue accounting for revenue adjustments only,
use the default salesperson value of No Sales Credit.
Customers and Parties
Create customers to properly record and account for sales transactions, as well as
identify other attributes of the selling relationship. Key concepts related to customers
and customer activities include:
 Party
 Customer
 Customer Account
 Site
 Relationship
 Contact
A party is an entity that can enter into a business relationship with another party, such
as buying and selling goods or offering services. A party is either an organization or a
person. A party exists separately from any business relationship that it enters into with
another party.
A customer is a party, either an organization or a person, with whom you have a selling
relationship. This selling relationship can result, for example, from the purchase of
products and services or from the negotiation of terms and conditions that provide the
basis for future purchases.
A customer account represents the attributes of the business relationship that a party
can enter into with another party. The customer account has information about the
terms and conditions of doing business with the party.
A site is a locationdescribed by an address. A party site is the place where a party is

physically located. An account site is a party site that is used in the context of a
customer account.
A party relationship is the role of the party in the context of another party. Examples
include affiliate, subsidiary, partner, employee of, or contact of. An account
relationship between different customer accounts of a party allows for the sharing of
billing, shipping, and payment information.
A contact is a person who communicates for or acts on behalf of a party or customer

account.
Manage Customers
Managing customers includes these activities:
 Create customer profile classes.
 Create customer, customer account and customer site records. Create at least
one customer account for each customer record, and at least one customer site
with a bill-to site business purpose for each customer account. You must have a
bill-to site in order to create transactions under the customer account.
 Assign profile classes to customer accounts and customer bill-to sites.
 Define relationships between parties and between customer accounts (both

reciprocal and non-reciprocal). You use customer account relationships to
manage the sharing of billing and shipping services and payment activities
between two accounts.
 Review and update customer information. If you use the Oracle Fusion Trading
Community Model, you can also manage the control of duplicate and redundant
party information.
Manage Customer Profile Classes
Use profile classes to organize customer accounts and sites into categories that reflect
the needs of your enterprise. The profile class record contains generic options that you
can set in different ways to group your customers into broad categories, such as by
industry, location, size, credit worthiness, business volume, or payment cycles.
After you assign a profile class to an account or site, you can customize details of the
profile class to meet specific requirements for that account or site. For example, a
particular site may transact business in a separate currency, or the site may be subject
to additional late charges or penalty charges. These updates apply only to that
particular account or site and do not affect the profile class record itself.
Profile class updates and assignments are managed using effective date ranges. Each
profile class that you assign or update supersedes the previous profile class for the
given date range. In this way you can manage over time the changes that take place in
customer behavior or customer requirements.
 Key concepts in Oracle Fusion Receivables.

 Prerequisite setups that you need to complete before configuring
Receivables.
 How to set up a minimum configuration necessary to operate Receivables.
 Additional implementation considerations for setting up transactions.
 Additional implementation considerations for setting up receipts.
 Additional implementation considerations for setting up revenue
management.
 Key concepts concerning customers and parties.
Lesson 13: Configuring Oracle Fusion Payments – Receivables
Lesson 13: Configuring Oracle Fusion Payments –

Receivables
 Set up funds capture payment methods: Optional setup.

 Set up funds capture process profiles: Mandatory setup.
 Set up internal payees: Mandatory setup.
 Set up routing rules: Mandatory setup. NOTE: Either a default payment system
and a funds capture process profile or one routing rule must exist.
Setups and the Funds Capture Process
The following concepts are applicable to setups and the funds capture process.
 Internal payee: The deploying company's business unit or group of business

units that receive payments from external payers, such as customers, by credit
card payments, direct debits to bank accounts, and by bills receivable
transactions sent to banks.
 Authorization: The first step in collecting funds from a credit card. For credit
cards, an authorization reserves a specified amount.
disbursements. The payment system can be the bank at which the deploying
company has its bank accounts or it can be a third party processor that connects
 Funds capture process profile: A key setup entity that holds rules for funds
capture processing, including formats, transmission configuration, and settlement
batch creation.
 Remittance: Funds retrieved or captured from the customer by a payment
system through electronic payment methods, such as credit cards, purchase
cards, and direct debits of bank accounts.
 Settlement: A funds capture transaction that moves funds from the account of
the cardholder or the bank account owner into the account of the internal payee.
 Settlement batch creation rules: User-defined rules that build settlements into
settlement batches.
 Settlement batch acknowledgment: A file provided by a payment system in
response to a settlement batch, indicating that the payment system has read and
can understand the settlement batch or payment file.
Overview of Funds Capture for Oracle Fusion

Payments
Oracle Fusion Payments is a product in Oracle Fusion Applications, which serves as a

funds capture and disbursement engine for other Oracle Fusion Applications. As the
central payment engine, Payments processes transactions, such as invoice payments
from Oracle Fusion Payables and settlements against credit cards and bank accounts
from Oracle Fusion Receivables. Payments provides the infrastructure needed to
connect these applications and others with payment systems and financial institutions.
Funds capture is an automated process, which is typically performed by a payment

system through electronic payment methods, such as credit cards, purchase cards,
and direct debits of bank accounts, where payment is retrieved, or captured, from the
customer (external payer) who owes a debt to your company or one of its business units
(internal payee). The external payer provides Payments with pertinent payment
information, such as a credit card, debit card, or bank account numbers.
Defining Funds Capture
Tasks > Name field: Define Funds Capture > Search button > Define Funds Capture
folder.
covers the Define Funds Capture setup activity.
This section of the lesson covers the following setup tasks:
 Manage Funds Capture Payment Methods.

 Manage Funds Capture Process Profiles.
 Manage Internal Payees.
Prerequisites for Defining Funds Capture
Before you can set up the Define Funds Capture setup activity, you must define
the following prerequisite setups in the Setup and Maintenance Area work area
within the Financials offering:
 Manage Formats: Configure Payment System Connectivity setup activity.

 Manage Transmission Configurations: Configure Payment System
Connectivity setup activity.
 Manage Payment Systems: Configure Payment System Connectivity setup
activity.
 Manage System Security Options: Define Payments Security setup activity.
 Manage Banks: Set Up Banks, Branches, and Accounts setup activity.
 Manage Bank Branches: Set Up Banks, Branches, and Accounts setup activity.
 Manage Bank Accounts: Set Up Banks, Branches, and Accounts setup activity,
which is a setup in Oracle Fusion Cash Management.
 Manage Receipt Classes and Methods: Define Customer Payments setup
activity, is a setup in Oracle Fusion Receivables.
Tasks > Name field: Payments Security > Search button > Define Payments
Security folder.
For information on this setup, see the Prerequisites for Configuring Payment System
Connectivity section in the lesson entitled Configuring Oracle Fusion Payments for
Payables.
Tasks > Name field: Define Receivables > Search button > Define Receivables
Configuration folder > Define Customer Payments folder.
NOTE: For information on setting up formats, transmission configurations, and
payment systems, see the Configure Payment System Connectivity lesson.
NOTE: For information on setting up system security options, see the Defining
Payments Security lesson.
NOTE: For information on setting up receipt classes and methods, see the Simple
Configuration for Oracle Fusion Receivables lesson.
Funds Capture Concepts
The following concepts are applicable to funds capture:
 Funds capture process profile: A key setup entity that holds rules for funds
capture processing, including formats, transmission configuration, and settlement
batch creation.
 Authorization: The first step in collecting funds from a credit card. For credit
cards, an authorization reserves a specified amount.
 Authorization response: The response from the payment processor that
indicates whether the authorization was successful or not.
 Settlement: A funds capture transaction that moves funds from the account of
the cardholder or the bank account owner into the account of the internal payee.
disbursements. The payment system can be the bank at which the deploying
company has its bank accounts or it can be a third party processor that connects
 Settlement batch: A group of transactions, typically settlements and credits, that

are sent to the payment system together in a file. Settlement batches are
generally used with a processor payment system.
 Acknowledgment: A file provided by a payment system in response to a
settlement batch, indicating that the payment system has read and can
understand the settlement batch or payment file.
 Internal payee: The deploying company's business unit or group of business
units that receive payments from external payers, such as customers, by credit
card payments, direct debits to bank accounts, and by bills receivable
transactions sent to banks.
 Routing rules: Rules that determine which payment system account and which
funds capture process profile are used to process funds capture transactions.
 Payer notification: A message sent to each payer after the settlement or
settlement batch is transmitted, notifying them of a funds capture transaction that
will charge their credit card or bank account.
 External payer: An external party, such as a customer, who remits funds for
payment to the internal payee, which is the deploying company.
Manage Funds Capture Payment Methods
Setup and Maintenance work area > Search: Tasks pane: Define Receivables >
right arrow > Define Receivables Configuration folder > Define Funds Capture
folder > Go to Task icon for Manage Funds Capture Payment Methods task >
Manage Funds Capture Payment Methods page > Create icon > Create Funds
Capture Payment Method dialog box.
A funds capture payment method is a payment method by which an external payer,

such as a customer, chooses to remit payment to the internal payee, which is the
deploying company.
Payments supports the following funds capture payment methods for automated
funds capture processing:
 Credit cards.
 Bank account transfers.
Payments predefines the following funds capture payment methods for the
following instrument types:
 Credit cards.
 Bank account transfers.
Payments predefines the following funds capture payment methods for the
following payer-initiated instrument types:
 Check.
 Wire transfer.
NOTE: For payer initiated instrument types, Payments records the transaction, but
does not perform any processing for these payment methods.
In the Create Funds Capture Payment Methods dialog box, you can define new funds
capture payment methods for bank account transfers only. Once the funds capture
payment methods are set up, they are available for selection by the source product user
while creating or updating external payers.
Key Decision and Best Practices for Funds Capture Payment

Methods
Key Decision:
What funds capture payment methods should I accept, and what additional features
should I implement?
Best Practice:
Support customers' payment methods:
 Support the payment methods that your customers use.
Implement the following credit cards features to reduce credit card processing
fees:
 Company card support.

 Address verification.
 Card verification code.
Manage Funds Capture Process Profiles
A funds capture process profile is a key setup entity that contains all the rules
necessary for processing funds capture transactions. It tells Oracle Fusion Payments
how to communicate with a specific payment system, and includes the payment
system accounts to be used for processing funds capture transactions. During
processing, the funds capture process profile is derived from transaction routing rules,
which are created during the setup of internal payees.
A funds capture process profile contains rules that control each of the following
steps of the funds capture process:
 Building settlements into a settlement batch.

 Formatting messages.
 Transmitting funds capture messages to the payment system.
Formatting Messages
folder > Click Go to Task icon for Manage Funds Capture Process Profiles task >
Manage Funds Capture Profile page > Select Processing Type choice: select a
processing type > Create button > Create Funds Capture Process Profile page.
When the processing type is Credit Card, an Authorization region is displayed on the
Create Funds Capture Process Profile page. When the processing type is Bank
Account, a Verification region is displayed instead of the Authorization region. In
either case, you select the format in which your payment system expects to receive the
online message. This outbound format instructs Oracle Fusion BI Publisher how the
message should look. You also select the format in which you expect to receive an
inbound response from the payment system.
The Settlement region on the Create Funds Capture Process Profile page enables
you to select a format in which your payment system expects to receive the settlement
message. The settlement will be online for a gateway payment system and in a batch
for a processor payment system. You also select the format in which you expect to
receive an inbound response from the payment system.
On the Settlement Response Processing region, you can select formats for
contacting your payment system to retrieve an acknowledgment, and for receiving the
response from the payment system, which indicates whether the transaction succeeded
or failed. Acknowledgments can be pushed by the payment system to your company, or
your company may need to retrieve acknowledgments from the payment system.
On the Notification to Payer region of the Create Funds Capture Process Profile
page, you can optionally select a notification format and the method of notification
delivery to the payer. Payer notification is a message sent to each payer after the
settlement or settlement batch is transmitted, notifying them of a funds capture
transaction that will charge their credit card or bank account.
Building Settlements into a Settlement Batch
folder > Go to Task icon for Manage Funds Capture Process Profiles task > Manage
Funds Capture Profile page > Select Processing Type choice list: select a
On the Creation Rules tab of the Create Funds Capture Process Profile page, you
select settlement grouping rules. When a specific grouping rule is enabled, Payments
ensures that settlements within one settlement batch all share the same value.
Settlements with disparate values trigger the creation of as many settlement batches as
there are unique value combinations. For example, if you select Business Unit and
Settlement Date as grouping rules, then only settlements with the same business unit
and settlement date are grouped in a settlement batch when the funds capture process
profile is used.
You can also limit the size of a settlement batch by amount or number of settlements.
Transmitting Messages to the Payment System
folder > Go to Task icon for Manage Funds Capture Process Profiles task > Manage
Funds Capture Profile page > Select Processing Type choice list: select a
A funds capture process profile is specific to one payment system and its payment
system accounts. On the Accounts tab of the Create Funds Capture Process
Profile page, you specify payment system accounts to be used with the funds capture
process profile. For each payment system account you enable, you can select up to
three transmission configurations, one each for:
 Authorizations or verifications.
 Settlements.
 Acknowledgments.
The payment system account provides identifying information to the payment

system, and the transmission configurations tell Payments how to transmit the funds
capture transaction to the payment system.
Manage Internal Payees
folder > Go to Task icon for Manage Internal Payees task > Manage Internal Payees
page > Create icon > Create Internal Payee page.
In Oracle Fusion Payments, the internal payee is a business unit or group of business
units within your enterprise that collect funds from customers. An internal payee also
has a business relationship with a payment system, in which the payment system
processes funds capture transactions for the internal payee.
For funds capture transactions, you can have multiple internal payees because different
business units or legal entities within one enterprise may want to process transactions
through different payment systems or use separate relationships with one payment
system.
When you create an internal payee, you must specify the following information:
 Business units for which this internal payee processes transactions.
 Payment instrument types that the internal payee accepts.

 Payment system accounts that provide identification and other information
to the payment system.
Configured Processing Types
The Configured Processing Types region enables you to specify the types of payment
instruments the internal payee will accept to receive funds from customers.
Purchase Card Detail
A purchase card is a special type of credit card that is issued by your company to its
employees. The card is generally used by the employees for purchasing corporate
supplies and services. Payments are made by your company to the card issuer.
Purchase cards, also known as procurement cards, possess more features,
capabilities, and controls than standard consumer credit cards.
Three levels of data can be captured for a purchase card and sent by a merchant to
your company through the payment system as follows:
Level I: Transaction data consists of only basic data. A standard credit card transaction
provides Level I data to the payment system. Your company cannot derive any special
benefits from purchase card usage if the merchant passes only Level I data.
Level II: Transaction data, such as tax amount and order number, in addition to Level
I data.
Level III: Transaction data that consists of line item detail, which provides specific
purchase information such as item description, quantity, unit of measure, and price.
This information is very useful to your company to help streamline accounting and
business practices and to merge payment data with electronic procurement systems.
NOTE: Payments supports Level III data for both payment processors and gateway
payment systems.
Creating and Assigning Routing Rules to Internal Payees
page > Search for an internal payee > Manage Routing Rules button > Manage
Routing Rules page.
You assign routing rules to internal payees during their setup. Each internal payee can
prioritize its routing rules. The routing rule with the highest priority is evaluated by
Oracle Fusion Payments first. If the values in the requested funds capture transaction
match the conditions in the routing rule, that transaction is routed to the applicable
payment system account for processing, and the derived funds capture process
profile is used to define how the transaction is processed.
If the attributes in the requested funds capture transaction do not match the conditions
in the routing rule, the routing rule is disregarded and Payments evaluates the next
routing rule.
If all routing rules are evaluated and none apply, Payments looks for a payment
system account and funds capture process profile specific to the payment method
type entered for the internal payee on the Default Routing region of the Manage
Routing Rules page.
page > Search for an internal payee > Manage Routing Rules button > Manage
Routing Rules page > Select a payment method > Create button > Create Routing
Rule page.
Routing rules route a funds capture transaction to a payment system and payment
system account and determine the funds capture payment profile to be used, which
is based on attributes of the transaction. Payments compares attributes of a funds

capture transaction, such as payment method, amount, and currency against the
conditions in a routing rule. When all of the conditions are met, the specified payment
system account and funds capture payment profile are used for the funds capture
transaction.
The payment system account and funds capture process profile that are used for
an authorization will automatically be used for any further actions on the funds capture
transaction, including settlement and any follow-on refunds.
Key Decision and Best Practices for Internal Payees
Key Decision:
How should I set up internal payees?
Best Practice:
Funds capture transactions are identified by business unit, but are processed
by internal payee. The internal payee models how the enterprise accepts payments for
processing. You can assign multiple business units to one internal payee.
Set up internal payees as follows:
 If all business units require identical processing, create one internal payee to
serve them all.
 If business units require different processing, create one internal payee per
business unit.
NOTE: Student Activity: Creating a Funds Capture Payment Method, a Funds Capture
Process Profile, Modifying an Existing Internal Payee, and Creating a Routing Rule
Defining Payments Security
Tasks > Name field: Payments > Search button > Define Payments Security folder.
covers the Define Payments Security setup activity and its setup task, Manage
System Security Options.
Prerequisite for Defining Payments Security
Before you can set up the Define Payments Security activity, you must set up a wallet
file on the file system of the Financials Domain Enterprise Storage Server (ESS) to
enable encryption of payment information.
To set up a wallet file, perform the following steps:
1. Create an empty Oracle Wallet ewallet.p12 using the Oracle Wallet Manager
utility.
2. Take one of the following actions to create the wallet: Let Payments
automatically generate a secure key and create the wallet or generate a
custom secure key by copying a file containing the bits of the key to the same
directory as the empty Oracle wallet ewallet.p12.
If you would like to use your own system-level encryption key, create a binary key file
containing your 3DES key. Both the ewallet.p12 and the binary key file should be
placed in the same directory, which must be readable and writable by the Weblogic
Server (WLS) container hosting the Payables Java EE application user interface.
1. When you create a wallet file on the Manage System Security Options page,
you must enter the full path of ewallet.p12 in the New Wallet File Location field
in the Edit System Key dialog box. If you are using a user-defined key, you
must enter the full path of the binary key file in the Key File Location field.
2. After you create the wallet file on the Manage System Security Options page, you
must also copy the ewallet.p12 and the binary key file to the same path for the
Application Developer Framework (ADF) user interface servers for the
Receivables and Payables Java EE applications.
NOTE: Any time the system key is updated, this copy action must be
performed.
3. After you create the wallet, ensure that you securely delete the file containing the
key bits by using a utility that supports secure deletion.
Security Options Concepts
The following concepts are applicable to system security options:
 System key: The encryption master key for the entire installation. It is stored in
an Oracle Wallet file and is used to encrypt Payments system subkeys.
 Wallet file: A digital file that stores the system security key used to encrypt
sensitive data. The wallet also performs HTTP client authentication of middle-tier
servers for payment systems that require this level of security.
 System subkey: A digital key that sits within the system key and is used to
encrypt payment instrument data.
 Chained key encryption: An encryption approach used for data security where
A encrypts B and B encrypts C. This is used to encrypt sensitive information in
the database.
 Masking: Partially or completely concealing the digits of card numbers or other
sensitive data in the user interface.
 Payment instrument: A credit card, debit card, or bank account used by a
payee to collect a payment from an external payer, such as a customer.
 Internal bank accounts: The deploying company's bank accounts, which are set
up as disbursement bank accounts in Oracle Fusion Payables and as remit-to
bank accounts in Oracle Fusion Receivables and Oracle Fusion Cash
Management.
 External bank accounts: Bank accounts of the deploying company's customers,
suppliers, or employees.
Manage System Security Options
Tasks > Name field: Payments > Search button > Define Payments Security folder >
Go to Task icon for Manage System Security Options task > Manage System
Security Options page.
The Oracle Fusion Payments system security options enable you to set security options
for payment instrument encryption and payment instrument masking. These
options are used for both funds capture and disbursement processes. Implementation of
the system security options should be part of a complete security policy that is specific
to your organization.
To secure your sensitive data, you can choose from the following options:
 Credit card data encryption.

 Bank account data encryption.
 System key rotation.
 Credit card number masking.
 Bank account number masking.
Scheduled Processes Region
The Scheduled Processes region allows you to monitor the status of the security
programs run from this page.
Key Decision and Best Practices for Security
Key Decision:
What security practices should I follow for payment processing?

Best Practice:
Comply with Payment Application Data Security Standards (PA-DSS), which is the
security standard that is required for processing most types of credit cards.
 Comply with all requirements for accepting credit card payments.

 Minimize risk of exposing sensitive customer data.
 Work with a PA-DSS auditor to ensure compliance to the required security
standards and avoid potential violations.
Encrypt and mask customer credit card and bank account numbers before
importing or entering data into the system.
Use Oracle Wallet Manager to create a wallet:
 Store the wallet in a very secure, limited access file system location.
 Obtain encryption keys externally or let Payments generate them.
 Rotate encryption keys periodically.
Key Decision and Best Practices for Encryption and Masking
Key Decision:
How should I approach encryption and masking?
Best Practice:
 Encrypt and mask supplier bank account numbers before importing or

entering any data in Payments.
 Use Oracle Wallet Manager to create a wallet file.
 Store the wallet file in a very secure, limited access file location.
 Obtain encryption keys externally or have Payments generate them.
 Rotate encryption keys periodically.
Encrypting Credit Card Data
Credit Card Encryption is an advanced security feature within Oracle Fusion

Payments that enables Oracle applications to encrypt credit card data. Use of the Credit
Card Encryption feature assists you with your compliance with the cardholder data
protection requirements of the Payment Card Industry (PCI) Data Security Standard.
Credit card numbers entered in Oracle Fusion Receivables and Oracle Fusion
Collections are encrypted automatically based on the credit card encryption setup you
enable on the Manage System Security Options page.
IMPORTANT: If card numbers are brought into Payments through import or

customization, Oracle recommends that you run the Encrypt Credit Card Data
program immediately afterward.
To run the Encrypt Credit Card Data program navigate as follows: Navigator menu >
Tools menu > Scheduled Processes link > Overview page > Schedule New Process
button > Schedule New Process dialog box > Job radio button > Process Name
choice list: Encrypt Credit Card Data > OK button > Process Details dialog box >
Notify me when this process ends check box > Submit button > Close button > OK
button > Close button.
Encrypting Bank Account Data
Bank Account Encryption is an advanced security feature within Oracle Fusion

Payments that enables Oracle applications to encrypt supplier and customer bank
account numbers.
IMPORTANT: The Bank Account Encryption feature does not affect the employing
company's internal bank account numbers. Internal bank accounts are set up in Oracle
Fusion Cash Management and are used as disbursement bank accounts in Oracle
Fusion Payables and as remit-to bank accounts in Oracle Fusion Receivables.
Supplier, customer, and employee bank account numbers entered in Oracle

applications are encrypted automatically based on the bank account encryption setup
that you enable on the Manage System Security Options page.
IMPORTANT: If bank account numbers are brought into Payments through import or
customization, Oracle recommends that you run the Encrypt External Bank Account
Data program immediately afterward.
To run the Encrypt External Bank Account Data program navigate as follows:
Navigator menu > Tools menu > Scheduled Processes link > Overview page >
Schedule New Process button > Schedule New Process dialog box > Job radio
button > Process Name choice list: Encrypt External Bank Account Data > OK
button > Process Details dialog box > Notify me when this process ends check box
> Submit button > Close button > OK button > Close button.
Rotating the System Key
When you enable encryption in Oracle Fusion Payments, you create one system-level
security key, which is a 168 bit 3-DES key. The system key is the encryption master
key for the entire installation. It is stored in an Oracle Wallet file and is used to encrypt
Payments subkeys.
The Encryption feature enables you to rotate the system key. System key rotation
changes the subkey data, but does not result in a re-encryption of the credit card
numbers or bank account numbers. To secure your payment instrument data, your
security policy should include a regular schedule to rotate the system keys.
The security architecture for credit card data encryption and bank account data
encryption is comprised of the following components:
 Oracle Wallet Manager.

 Oracle Wallet file.
 System key.
 System subkeys.
 Credit card number storage.
 Bank account number storage.
For payment instrument encryption, Payments uses a chained key approach. To

simplify, the chained key approach is used for data security where A encrypts B and B
encrypts C. In Payments, the system key encrypts the subkeys and the subkeys encrypt
the payment instrument data. This approach allows easier rotation of the system key.
Masking Credit Card and Bank Account Numbers
Payments stores all of the Trading Community Architecture (TCA) party's payment
information and its payment instruments, such as credit cards and bank accounts. This
common repository for payment data provides data security by allowing central
encryption management and masking control of payment instrument information.
On the Manage System Security Options setup page, credit card numbers and
external bank account numbers of suppliers and customers can be masked by selecting
the number of digits to mask and display. For example, a bank account number of
XXXX8012 represents a display of the last four digits and a masking of all the rest.
These settings specify masking for payment instrument numbers in the user interfaces
of multiple applications.
 Set up funds capture payment methods.

 Set up funds capture process profiles.
 Set up internal payees.
 Set up routing rules.
Lesson 14: Configuring Oracle Fusion Advanced Collections
Lesson 14: Configuring Oracle Fusion Advanced

Collections
 Understand the setup and maintenance of collections.

 Define aging methods.
 Set up collectors.
 Understand dunning configuration.
 Set up Collections preferences and understand the impact on the
collections process.
 Understand configuring notes.
Instructor Note
Accessing the setups for Collections in this lesson is done from either:
 The All Tasks tab.

 The Search Tasks region.
 The Implementation Project created in Lesson 3.
It is assumed the students have attended the Oracle Fusion Functional Setup
Manager class prior to attending this class. In the Functional Setup Manager
Overview the students hired themselves as employees to be able to create themselves
as collectors.
Oracle Fusion Advanced Collections
This section is an introduction to configuring Oracle Fusion Advanced

Collections:
 Overview and Process in Collections.

 Define Collections in Setup Manager.
 Review the Oracle Fusion Applications Required to Implement Collections.
Collections Overview and Process
Oracle Fusion Advanced Collections provides a streamlined and user-friendly user

interface for collections professionals to easily identify delinquent customers and
manage collections activities for which they are responsible.
Collectors can navigate easily from the Collections Dashboard to the Customer work
area where the focus is on collecting for specific delinquent customers. The information
provided allows collectors to treat each customer uniquely. In turn, this helps improve
customer relations that can directly relate to higher collectability and a lower Days
Sales Outstanding (DSO).
Real-time tools such as managing assigned work, sending dunning correspondence,

taking a payment, processing a dispute and an adjustment makes it simple and easy for
the collector and promotes restoring the customer back into good standing.
Managers can schedule background processes to refresh Dashboard data,

automatically identify delinquent bills, update customer transactional data, and send
dunning letters to customers.
NOTE: Instructor Demonstration Overview of Advanced Collections.
Define Collections in Setup Manager
Begin in the Setup and Maintenance work area > Click the All Tasks tab > In the
Search region, enter Define Collections in the Name field > Click the Search button.
Configuring Oracle Fusion Advanced Collections starts from the Setup Manager
under the Financials folder. The list of tasks to complete the implementation is
arranged in the order they should be completed.
Define Collections (Required setups are in bold and marked with an asterisk.)
 Manage Aging Methods*

 Manage Collectors*
 Manage Dunning Configurations*
 Manage Collections Preferences*
 Manage Collections Lookups
 Manage Collections Note Type
 Manage Collections Note Type Mapping
 Manage Collections Note Descriptive Flexfields
 Manage Collections Task Standard Lookups
 Manage Collections Task Default Profile Options
Related Fusion Applications Requirements
Oracle Fusion Human Capital Management: Required to create employees, jobs, and
roles. These must be created and configured prior to starting a Financials
Oracle Fusion Common Application Configuration for Financials: Used to create

the enterprise model, such as legal entities and business units.
Oracle Fusion Common Financials Configuration: Used to define transaction taxes,

such as tax regimes and authorities.
Oracle Fusion General Ledger: Used to configure the financial structures such as the
Chart of Accounts.
Oracle Fusion Receivables: Used to configure transaction types, receipts, payment

methods, and adjustment approval limits.
Oracle Fusion Payments: Used to configure funds capture settings to support

payment processing.
Manage Aging Methods
Define Aging Methods
Aging Methods are periods of time used to group receivables, debit and credit items to
achieve an understanding of a customer's delinquency profile. Grouping transactions by
buckets of time creates an aging view of the customer.
Oracle Fusion Advanced Collections groups overdue debt by time and assigns work
based on buckets of debt items. For example, aging categorizes receivables into
buckets such as; current, 30 days, 60 days, 90 days, and 120 days and over. The
Manage Aging Methods page consists of two regions: Aging Methods and Aging
Method Details.
 Aging Methods is where you name, select the type, enable, assign the set, and
provide a description of the method.
 Aging Details is where you order your sequence, bucket type, set your day
ranges, and provide your display information for reporting.
Aging Methods are used during the creation of aged dunning plans. Collections
delivers preconfigured aging methods and allows the ability to create new aging
methods based on company requirements. The four Aging Methods delivered with the
Collections product are: 4-Bucket Aging, 5-Bucket Aging, 7-Bucket Aging, and
Statement. You cannot modify these delivered aging methods. However, you can copy
any delivered aging method, that the system renames with the prefix Copy and allows
you to modify the copied aging method.
The Aging Method Set controls access to data and is defined in the Setup Manager
under the Common Applications Configuration for Financials task list. Refer to Lesson 3
covering Business Units and Lesson 10 for more information on Set Assignments.
Begin at the Setup and Maintenance work area > Click the All Tasks tab > In the
Search region > Enter Manage Aging Methods in the Name field > Click the Search
button > Click the Go to Task icon.
NOTE: Student Activity Create Aging Methods.
Manage Collectors
A collector is an individual or a group of individuals, assigned to a customer to conduct

various collections work. Tasks include sending correspondence, reviewing customer
history and collecting payment from customers.
Prior to creating a collector, the individual must be set up as an employee in Oracle

Fusion Human Capital Management (HCM) and optionally as a resource in Oracle
Fusion Customer Relationship Management (CRM) applications in order to create
tasks under Activities.
Setting Up Collectors
Consider the following when setting up individuals as collectors:
 A collector can individually be assigned to one or more customers or can be a

group member that collects from one or more customers.
 Evaluate what are the most appropriate collection needs for your organizations.
 Collectors can be assigned at the customer, account or site level. Determine the
business level at which your organization normally collects from customers.
Research how your organization divides the work and tasks among collectors.
 Collections organization structures can be created in several ways based on the
number of customers. For example, you can group customers according to size,
small to large or divide customers regionally or by the monetary volume you do
with a customer.
Setting Up Collectors
Set up collectors in Setup Manager after you have created the individual as an
employee in Human Capital Management (HCM). Collector setup is used for:
 Determining work assignment on the Collections Dashboard.

 Assigning a collector to a customer under the Profile tab on the Customer work
area.
 Collector name used in the closure section of dunning correspondence.
 There are two user roles delivered with the application: Collections Manager
and Collections Agent.
Search region > Enter Define Collections in the Name field > Click the Search button.
Manage Collectors
 Enter the name of the collector. An alias can be used.

 Select the Type as Employee or Group. You must create individuals as
employees before you can set them up as users, resources or collectors.
 A collector identified as an employee type is assigned to one customer.
 A group assignment is created to assign work and customers to a group of
collectors. You can have multiple collectors in one group.
 Enable and disable collectors by selecting Yes or No. Enter No when you
terminate a collector and enter an inactive date.
 The Collector Set is the reference data set assigned for security purposes.
Reference Data sets are covered in Lesson 3 and more information can be found
in Lesson 10: Common Application Components Appendix.
 Assignment of a collector to a customer is done on the Profile tab in the
Customer work area. The collector can also be assigned in the Profile Class in
Receivables.
 For workload balancing and performance purposes, consider how many
collectors are assigned to customers.
Start in from the Manage Collectors row > Click the Go to Task icon.
NOTE: Student Activity Create Collectors.
Manage Dunning Configurations
Dunning Configuration Overview

Dunning is the business practice of advising delinquent customers about their overdue
payments, usually through correspondence of print, fax or E-mail. The features of
dunning in Collections include the following:
Consider the following when configuring dunning:
 If you have multiple business units you must define at least the Common Set.
 Dunning contacts must be specified at the bill-to site level for each customer.
 To send the same dunning notice to more than one contact, be sure to assign
purpose of Dunning to each contact.
 Review pre-configured dunning templates, create new ones if needed.
 Test dunning with small set of test contacts before running in a live instance.
 Run the Send Dunning Letters process after running Update Dashboard
Summary process.
Seeded Dunning Configurations
The Manage Dunning Configurations page supports the ability to create different
dunning configurations for different reference data sets, depending on operational and
business requirements. Dunning targets collections correspondence to the right
customer contact at the right time.
Seeded Dunning Configurations
Collections includes a number of seeded dunning configurations including the

following:
 Preconfigured dunning templates provide for rapid validation.

 Different dunning methods (aged or staged) can be set up for different reference
data sets.
 Dunning notices are sent to contacts at Bill-to sites.
Start from the Manage Dunning Configurations row > Click the Go to Task icon.
Aged Dunning Type
Companies sending collection letters to their customers based on the oldest aged
transaction can use the Aged dunning method. Delinquent transactions are identified
automatically when the Delinquency Identification concurrent process is run.
Preconfigured dunning notice templates are available, or the deploying company can
create their own dunning notice templates. As the oldest aged transaction moves into
the next aging bucket, the content of the dunning letter can change. A single
consolidated letter can be sent to eliminate sending multiple aged dunning letters to the
same customer who has more than one delinquent transaction. The templates are
associated to aging buckets in the dunning configuration process.
Select the Aged Dunning row under the Dunning Configuration Name > Click the
Edit icon
Staged Dunning Type
Staged dunning is based on the number of days since the last dunning letter was sent,
rather than the number of days transactions are past due. A single consolidated letter
can be sent to eliminate sending multiple staged dunning letters to the same customer
who has more than one delinquent transaction. Delinquent transactions are identified
automatically when the Delinquency Identification concurrent process is run. Staged
dunning letters are sent at delayed intervals defined in the Dunning Configuration
process. These intervals control the timing of each letter
Select the Staged Dunning row under the Dunning Configuration Name > Click the
Edit icon
It is recommended you use the Copy feature to edit an existing seeded dunning
configuration. This feature automatically prefixes the name with the word Copy. You
can then use the Edit icon to make the appropriate changes.
Select the Aged Dunning or Stage Dunning row under the Dunning Configuration
Name > Click the Copy icon
Creating Dunning Configurations
Create new Dunning Configurations if the delivered configurations do not meet your
business needs. Both Aged and Staged dunning are supported. Use the Send
Dunning Letter process to execute and send correspondence. Dunning letters
templates are stored in the Business Intelligence Publisher (BIP) server
Start from the Manage Dunning Configurations row > Click the Go to Task icon.
Click the Create icon
Create Dunning Configuration
 Start by indicating the type of your configuration: Aged or Staged. Provide a

name and description for the configuration.
 Specify the Data Set for this configuration. Dunning can be configured by one
business unit or multiple business units.
 The checkboxes on the setup task page control the kind of transactions included
in dunning letters.
 Enable the configuration by selecting Yes.
 The Dunning Configuration Detail displays the dunning letter templates used
for a specific dunning configuration.
NOTE: Instructor Demonstration Dunning Templates.
Manage Collections Preferences
Manage Collection Preferences consists of two regions:
 Global Preferences configurations are applied to all sets and the default values
appear in Collections Dashboard and Customer work area.
 Preferences configurations are applied to a specific preference set. These
preferences determine the default for collections business levels, aging,
exchange rate, correspondence send method, and correspondence contact for
specific data sets. If no other data sets are set up, these values come from the
Common Set.
NOTE: Data Reference Sets are covered in Lesson 3 and more detailed information
can be found in the Appendix of this course.
Configuring Collections Preferences
Start from the Manage Collections Preferences row > Click the Go to Task icon.
Global Preferences
Selections made in the Global Preferences region define the following:
 Default transaction class that appears.

 Display of closed transactions.
 Display of open transactions.
 Number of days for prior and future transactions to be displayed.
 Maximum number of days to reschedule work.
 Default aging method.
 Delimiter used to separate data.
 The number of characters required to do a search (Using less than 3 impacts
performance).
 Return e-mail address for dunning correspondence.
Preferences
Selections made in the Preference region define the following:
 Preferences applied to a specific Preference Set.

 Collection Business Level. Three business levels - customer, account, and bill
to - determine how collectors see their assigned work on the Collections
Dashboard, how collectors manage their customers, and the content of dunning
letters.
 Open credit aging default on Aging tab.
 Exchange rate for currency conversion.
 Default dunning send method.
 Default dunning contact name.
You can use the preconfigured Collections Preferences for initial proof of concept,
conference room pilots or other pre-production projects to quickly get the system up and
running.
Preference Setting Considerations
 Out-of-the-box Collections Preferences values are defaulted allowing for quick

validation of Oracle Fusion Advanced Collections.
 Use of the Common Set to apply to all Sets or if you need some parameters
unique by Set.
 Only Common Set Aging Methods will display in list of values in Global
Preferences.
 Weekend days are not excluded when considering date range or work scheduled
status date.
 Additional preferences provide the ability to manage collections operations
differently for different Data Sets.
 Business Level: If the Business Level is set at the customer level to view or
modify transactions, this encompasses all of the transaction activity associated
with the customer. For example, a dunning letter at the customer level is
inclusive of transactions at the customer and account level. If the Business Level
is set at the account level to view or modify transactions, the transactions are for
a particular account and include transactions for all the bill-to sites under that
account. If the Business Level is set at the site level to view or modify
transactions, the transactions are specific to the bill-to location.
 Search parameter in the global area defaults to three characters. If you lower this
value, performance in the User Interfaces may be impacted.
Optional Implementation Configurations
You can implement the following optional setup steps in Oracle Fusion Advanced
Collections:
 Manage Collections Lookups.

 Manage Collections Note Type.
 Manage Collections Note Type Mapping.
 Manage Collections Note Descriptive Flexfields.
Manage Collections Lookups
Oracle Fusion Advanced Collections comes with predefined lookups. You can define
additional lookups if required for your business.
Lookups consist of:
1. Lookup Type - A lookup type is a static list of values users use to make entries
in the application. This is the name of the field that appears on the setup UI and
not on the application UI where you make the selection.
2. Lookup Code - An internal application code for each lookup that is not visible to
users.
3. Meaning - The actual UI term associated with the lookup code. It is the item that
appears in the list on the application UI against the specific field name, and can
be selected by the users to indicate their choice.
4. Tag - A label associated with that lookup. Certain product offerings use lookup
tags for functionality that is specific to that product. Refer to the product offering-
specific documentation for more information. If no such use of tag is
documented, the Tag is ignored.
5. Enabled (status) - Determines the availability of the meaning (the value or the
item) within the selection list for that lookup type. If you do not enable it, the value
does not appear in the selection list at runtime.
There are three different categories of lookups:
1. Standard Lookups - These are the simplest form of lookup types consisting of
lookup codes and their meanings.
2. Common Lookups - These lookups are available for internal system
administrative use and are used by more than one application.
3. Set-enabled Lookups - These lookups contain lookup codes that are part of a
reference data. You can use sets to enable different values in that lookup for
different sets of users. At runtime, a selected attribute determines which set-
enabled lookup will be visible to the users. For example, the attribute east-coast
or west-coast in the determinant location determines whether it is the east-

coast or the west-coast location, depending upon the selected lookup.
Lookup codes and their meanings are valid between a specified date range. If a date
range is not specified, the lookup codes and meanings have indefinite validity from the
time they are created.
NOTE: For more information, see the Lookups topic in the Appendix.
Manage Collections Note Types and Mapping
A note is a record attached to an account that is used to capture nonstandard

information received while conducting business. When setting up notes for Collections,
you should consider the following points:
 Note Types
 Note Type Mappings
Note Types
Note types are assigned to notes at creation to categorize them for future reference.
During setup you can add new note types, and you can restrict them by business object
type through the process of note type mapping.
Note Type Mappings
After note types are added, you must map them to the business objects applicable to
your product area. Select a business object other than Default Note Types. You will see
the note types only applicable to that object. If the list is empty, note type mapping
doesn't exist for that object, and default note types will be used. Select Default Note
Types to view the default note types in the system. Modifying default note types will
affect all business objects without a note type mapping. For example, you have decided
to add a new note type of Analysis for your product area of Sales- Opportunity
Management. Use the note type mapping functionality to map Analysis to the
Opportunity business object. This will result in the Analysis note type being an available
option when you are creating or editing a note for an opportunity. When deciding which
note types to map to the business objects in your area, consider the same issues you
considered when deciding to add new note types. Decide how you would like users to
be able to search for, filter, and report on those notes.
Note
Extensibility features are available on the Note object. For more information refer to
the article Extending CRM Applications: how it works. For more information, see the
Extensibility topic in the Appendix.
Managing Note Descriptive Flexfields
Use Oracle Fusion Advanced Collections descriptive flexfields to record additional

information that is not included in the standard information on notes.
NOTE: For more information on defining descriptive flexfields, see the Descriptive
Flexfields topic in the Appendix.
 Key concepts in Oracle Fusion Advanced Collections.
 Understand the Setup Manager Task List and Tasks for Collections.
 Prerequisites setups you need to complete before configuring Collections.
 How to set up a minimum configuration necessary to operate Collections.
 Optional configurations for Collections.
Lesson 15: Configuring Oracle Fusion Cash Management
Lesson 15: Configuring Oracle Fusion Cash

Management
 Understand the setup and maintenance of cash management.

 Define banks, branches, and accounts.
 Configure Bank Statement Processing and Reconciliation.
Instructor Note
Accessing the setups for Cash Management in this lesson is done from Setup
Manager in either:
 The All Tasks tab.

 The Search Tasks region.
 The Implementation Project created in Lesson 3.
It is assumed the students have attended the Oracle Fusion Functional Setup
Manager class prior to attending this class. In the Functional Setup Manager
Overview the students hire themselves as employees and set themselves up as users.
Oracle Fusion Cash Management
This section is an introduction to configuring Oracle Fusion Cash Management:
 Overview of Cash Management.

 Define Cash Management in Setup Manager.
 Review the Oracle Fusion Applications Required to Implement Cash
Management.
Cash Management Overview
Cash Management Overview
Organizations must effectively manage and control their cash cycle. Oracle Fusion
Cash Management is an enterprise cash management solution that allows you :
 to manage bank, branch and accounts information.

 to have comprehensive bank reconciliation capabilities.
 to identify and resolve reconciliation exceptions.
 to manage bank errors and monitor fraud.
Integration across your enterprise allows users to handle payments and settlements and
clear payments and receipts. Those products include:

 Oracle Fusion Receivable.
 Oracle Fusion Payables.
 Oracle Fusion Payments.
 Oracle Fusion Payroll.
Define Cash Management in Setup Manager
Define Cash Management and Banking Configuration
Setup and Maintenance > All Tasks > Search region, enter Financials in the Name
field > Search button > Expand Financials > Expand Define Receivables
Configuration.
The Define Cash Management and Banking Configuration folder contains the set up
tasks for Cash Management.
Expand Define Cash Management and Banking Configuration
Define Cash Management and Banking Configuration (Required setups are in bold
and marked with an asterisk.)
 Define Common Cash and Treasury Management Configuration: General setups

including configuring the profile options, lookups, descriptive flexfields and other
common components for Cash Management.
 Users must have the Cash Manager role to perform the Cash Management
setup. In Oracle Identity Manager (OIM), grant the Cash Manager role to the
implementation users.
 Set Up Banks, Branches, and Accounts*: Create and edit banks, branches,
and accounts used throughout the applications.
 Define Bank Statement Processing and Reconciliation*: Configure setup for
bank statement processing and reconciling bank statements.
 Define Subledger Accounting Rules: Configure application, source, and
accounting methods.
Set Up Banks, Branches, and Accounts
Banks, branches, and accounts fit together on the premise of the Bank Account model.
The Bank Account model enables you to define and keep track of all bank accounts in
one place and explicitly grant account access to multiple business units, functions, and
users. This eliminates the redundant duplicate bank account setup under different
business units when these business units share the same bank account.
Banks
Creating a bank is the first step in the bank account creation. You can create a new
bank from an existing party. If a party with the same name for the same country is found
after the Bank Name is entered, a message prompts you, asking if you want to use that
party to create the bank. The option is available only after the existing party has been
found with the same name and country.
Branches
Once you have created your bank, the next step is to create a branch or branches
associated to the bank. The matching option is also available when creating branches.
To create a new branch without using the matching option, manually enter in the
information required. You can define other branch-related attributes in the page. If you
do not use the matching option when an existing party is found, a branch with the same
party name is created.
Accounts
Once the bank and branch are created, you can proceed to the bank account setup.
Select the bank branch you want to associate to your bank account. Assign the owning
legal entity of the bank account. The legal entity must have a primary ledger associated
with it before it will show up in the Legal Entity list of values. There are four areas
associated to defining the account: general information, control of the account, security
access to the account, and business unit assignment. If this bank account is for
Payables or Receivables the Business Unit Access needs to be added first for the
business units to use this bank account.
Expand Set Up Banks, Branches, and Accounts.
Manage Banks
The user can search for existing banks, view and update them, or create new banks.
Select the row Manage Banks > Click the Go to Task icon.
Provide the following details to create a bank:
 Country.
 Bank Name must be unique within a country.
 Addresses.
 Contacts.
Click the Create icon > Expand Addresses > Expand Contacts.
Manage Branches
Bank Branches
Create a new branch or one from an existing party. A branch can be created from an
existing party using the matching option when the existing party was found with the
same name. You can further define other branch related attributes.
Provide the following details to set up a branch:
 Bank associated to this branch.

 Branch name must be unique within a bank.
 Addresses.
 Contacts.
Select the Manage Bank Branches row > Click the Go to Task icon > Expand
Addresses > Expand Contacts
Manage Accounts
Bank Accounts
Create, edit and view bank account information. Detailed settings at the different tab
levels provide control and access to the bank account information. Assigning a unique
general ledger cash account to each account and use it to record all cash transactions
for the account. This facilitates book to bank reconciliation
Select the Manage Bank Accounts row > Go to Task icon > Expand Additional
Information > Contacts
Account Use
Account use refers to accounts created for Oracle Fusion Payables, Oracle Fusion
Receivables, and Oracle Fusion Payroll. When creating an account to be used in one
or more of these applications you must select the appropriate use or uses.
NOTE: Display the GL account fields by entering a value for bank branch, account
name, account number, currency, and legal entity.
Select the Manage Bank Accounts row > Go to Task icon > Expand Additional
Information > Contacts
General tab
The general tab provides additional information, activating the account, and contact
information for the account.
Control Tab
Assign for Reconciliation the following: Manual Reconciliation Tolerance Rule,

Exchange Rate, Automatic Reconciliation Rule Set, and the Reconciliation Start
Date. Assign for Bank Statement Processing the following: Parsing Rule Set and
Transaction Creation Rules.
Security tab.
User and Role Security
You have the option to further secure the bank account so that it can only be used by
certain users and roles. The default value for secure bank account by users and roles is
No. In Payables and Receivables even if the secure bank account by users and roles is
no, you must have the proper access to the bank account. If the secure bank account
by users and roles is set to Yes, you must be named or you must carry a role that is
named expressly on the bank account in order to use it.
Business Unit Access tab.
Payables and Receivables account access is secured by business unit. In addition to

selecting the appropriate application use or uses, one or more business units must be
granted access before the bank account can be used by Payables and Receivables.
Only business units who use the same ledger as the bank accounts owning legal entity
can be assigned access.
NOTE: Student Activity Create a Bank, Branch, and Account.
Define Bank Statement Processing
In order to load electronic bank statements or use Cash Management's

Autoreconciliation feature, you must define the following processing and reconciliation
rules:
 Manage Bank Statement Transaction Codes that each bank uses to identify
different types of transactions on its statements.
 Manage Parse Rule Sets are used to transform data during the bank statement
import process.
 Manage Bank Statement Transaction Creation Rules allows you to configure
rules to create transactions from unreconciled statement lines to record items
such as bank charges, interest, or other miscellaneous items.

NOTE: These setups are defined independent of the bank accounts. Parse rules and
Bank Statement Transaction Creations rules need to be assigned to the bank accounts
that these rules apply.
Manage Bank Statement Transaction Codes
Bank statement transaction codes are the internal codes that are used on a bank
statement line to identify the type of transaction being reported. These are also referred
to as transaction codes and statement codes.
Expand Define Cash Management and Banking Configuration > Select the Define
Bank Statement Processing and Reconciliation row and Expand > Select the
Manage Bank Statement Transaction Codes row.
Create and Edit Bank Statement Transaction Codes
Create Transaction Codes
Manage Bank Statement Transaction Codes row > Click the Go to Task icon.
Define the transaction codes that each bank uses to identify different transaction types
on its statements. Bank statement transaction codes can be shared across different
bank accounts. Define a bank transaction code for each code that you expect to receive
from each bank that you use. For both Create and Edit enter a code, description, and
transaction type.
Click the Create icon.
Edit Bank Statement Transaction Codes

Balance and Transaction Codes: A single set of internal balance and transaction codes
is maintained within the application. The balance codes are defined in the lookup
CE_INTERNAL_BALANCE_CODES and the transaction codes are defined through the
Manage Bank Statement Transaction Codes task.
Externally reported balance and transaction codes can be transformed to the internally
defined codes using Oracle Fusion Payments Code Map Groups. Each code map
group is assigned to a format, and two code map groups mapping the BAI2 and
EDIFACT opening and closing booked balance codes to the internal balance codes are
provided. SWIFT940 does not require a balance code mapping because it is position
based but a code map group can be created to map the transaction codes to the
internally defined transaction codes. Bank statement codes that are defined as internal
codes do not require a code map.
Manage Bank Statement Transaction Codes row > Click the Go to Task icon.
Because each bank might use a different set of transaction codes, you must define a
bank transaction code for each code that you expect to receive from each bank that you
use. Transaction types include: Automated clearing house, Bank adjustment, Fee,
Check, Electronic funds transfer, Interest, Lockbox, Miscellaneous, and Zero balancing.
For both Edit and Create the domain, family and sub family fields are optional.
Click the Edit icon.
Manage Parsing Rule Sets
Parse Rule Sets are used to transform data during the bank statement import process.
Parse rules move data from one field to another and are most commonly used to parse
data from the statement line addenda field into more specific statement line fields.
Manage Parse Rule Sets row.
Create Parse Rules
When defining parse rule sets consider defining rules for statement line attributes such
as reconciliation reference that will be used for reconciliation matching and identifying
statement lines for external cash transaction creation and accounting.
Expand Define Cash Management and Banking Configuration > Define Bank
Statement Processing and Reconciliation row and expand> Manage Parse Rule
Sets row > Go to Task.
Each parse rule within a parse rule set consists of the following fields:
 Sequence - determines the order in which to process the rules.

 Transaction Code - the code used to determine the statement line type.
 Source - the interface table field that contains the data to be parsed.
 Target - the statement line field that the data will be parsed to.
 Rule - contains the syntax for determining the data within the source field that will
be parsed.
 Overwrite - used to control whether to overwrite existing data in a target field or
skip parsing the data.
The parse rule syntax is described below:
[LITERAL](<[MATCHING TOKEN],[START-END]>)[LITERAL]
Where
LITERAL = A string or character value represented by an identifier that should match

the source data exactly.
MATCHING TOKEN = A token (or set of tokens) which describes the data to extract.
Valid tokens are:
1. N = Extract a valid number

2. . = Decimal position
3. X = Extract an alpha numeric
4. ~ = Extract everything in the source field from the parse position to either the end
of the data or up to the next literal.
5. START = A position to begin extracting data, offset by the parse position. It must
be a valid numeric.
6. END = A position to stop extracting data. END can be either a valid numeric or
the ~ token.
The following table provides examples of Parse Rule Sets:
Payment Setups for Bank Statement Processing
Required setups in Oracle Fusion Payments for Bank Statement Processing:
 Manage Transmission Configurations

 Manage Formats
 Manage Code Map Groups
Payment Setup Details
 Transmission Configuration: Define a transmission configuration to specify the

parameters for transmitting a bank statement file.
 Formats: One format for each of the bank statement formats supported is
delivered with Cash Management. If a new format needs to be added, you can
do so.
 Code Map Groups: The bank statement processing program uses code map
groups for mapping the balance codes and transaction codes that are reported
on the external data file to the ones that are defined internally in Cash
Management. The delivered code map groups provide only very basic
mappings. They can be extended as required and new code map groups can
also be created.
NOTE: Refer to the Configuring Oracle Fusion Payments for Payables lesson for
additional information.
Define Bank Statement Reconciliation
In order to load electronic bank statements or use Cash Management's

Autoreconciliation feature, you must define the following reconciliation rules:
 Manage Cash Transaction Mapping for Payables, Receivables and Payroll.

 Manage Bank Statement Reconciliation Tolerance Rules for amounts,
percentages, or dates.
 Manage Bank Statement Reconciliation Matching Rules for bank statement
lines and system transactions.
 Manage Bank Statement Reconciliation Rule Sets used to group rules.
NOTE: These setups are defined independent of the bank accounts. Reconciliation
Rule Sets need to be assigned to the bank accounts that these rules apply.
Manage Cash Transaction Type Mapping
The transaction type mapping allows you to associate a Cash Management

transaction type to a payment or receipt method or a Payroll payment type. Create this
association by mapping payables payment methods, receivables receipt methods, and
payroll payment types to cash transaction types. Mapping payment or receipt methods
or Payroll payment types to Cash Management transaction types can be helpful for
bank statement reconciliation.
When a transaction code is created, a transaction type needs to be associated to it. A

bank statement line that has the transaction code has a corresponding transaction type.
If a system transaction's payment or receipt method or Payroll payment type is mapped
to the transaction type, the transaction type matching criteria can be used during
autoreconciliation.
Mapping Types:

 Oracle Fusion Receivables
 Oracle Fusion Payroll
Manage Cash Transaction Type Mapping row.
Create Mapping
Click the Go to Task icon.
Payables and Receivables Payment Method Mapping:
 Identify the Type, Transaction Type, and Method.

 To map Payable payment methods to cash transaction types, use Disbursement
type.
 To map Receivables receipt methods to cash transaction types, use Receipt
type.
Payroll Payment Type Mapping: Identify the Transaction and Payment Type
Manage Bank Statement Reconciliation Tolerance

Rules
Tolerance rules allow you to specify date, amount, and percentage tolerances that
prevent or warn you when reconciliation would be a breach of a defined tolerance.
Consider the following:
 Amount tolerances are most often used when reconciling foreign currency
transactions where there may be differences due to rounding or fluctuations in
the exchange rate. They can also be used if a bank includes a processing fee in
the bank statement line amount.
 Date tolerances are primarily used for checks that may be issued on one day and
not clear the bank until days or weeks later. By applying tolerances you can
automate the reconciliation and accounting for these types of transactions.
 If no date or amount tolerance is defined within a rule, it requires an exact
match.
 For manual reconciliation, a tolerance rule can optionally be assigned to a bank
account.
 For automatic reconciliation, a tolerance rule can be associated with a
matching rule in the Rule Set setup and can be applied if the matching rule
matches on date and amount or both.
 The one exception occurs when you assign a tolerance rule that includes
amount tolerances to a non one to one match type matching rule. In this non one
to one match, the amount tolerance is ignored and amounts must match exactly.
Manage Bank Statement Reconciliation Tolerance Rules row.
Create Tolerance Rules
Create Reconciliation Tolerance Rule
Tolerance rules include date, amount, and percentage options. Manual reconciliation
can have a tolerance rule assigned to a bank account. Automatic reconciliation can
have a tolerance rule applied if the matching rule matches on the date, amount or both.
Date Tolerance
Reconciliation date tolerances are defined as day ranges. The date tolerances are to
validate that the source transaction date or dates are within a certain number of days
before and after the bank statement line date or dates.
In manual reconciliation, if a date tolerance is specified in the tolerance rule assigned to

the bank account it applies to all matching scenarios. In the event of a date tolerance
breach, a warning message is displayed, but the user is allowed to reconcile the
statement line or lines and the transaction or transactions. If no date tolerance is
assigned or specified it is required to be an exact date match and a warning message is
displayed. In automatic reconciliation, a tolerance rule that includes date tolerances can
be associated with a matching rule. If the matching rule matches on the date, then the
date tolerance is applied. In this scenario a date tolerance breach prevents
reconciliation.
Amount Tolerance
Reconciliation amount tolerances can only be used in one to one matching scenarios
for both manual and automatic reconciliation. No reconciliation amount tolerances are
allowed in one to many, many to one, or many to many matching scenarios. In these
scenarios the amount of the bank statement line or lines must be equal to the amount of
the transaction or transactions. Reconciliation amount tolerances can be defined as
percentage or amount ranges or both.
If both percentages and amounts are applied, the application uses the most
conservative tolerance depending upon the statement line amount. For example, if the
amount tolerance equals plus or minus $5, the percentage tolerance equals plus or
minus 1%, and the statement line amount is $100, the application first calculates the
percentage amount (1% of $100 dollars = $1). It then compares this to the $5 amount
and uses the smaller amount. In this case it is $1 dollar, so to reconcile a transaction to
this line it must be between $99 and $101.
Exception
In automatic reconciliation, a tolerance rule that includes percentage, and amount or

both, tolerance ranges can be associated with a matching rule. But it can only be
applied if the matching rule is a one to one match type rule. In this scenario of a one to
one type match for both manual and auto reconciliation, any amount difference within
tolerance is automatically created as an external transaction in Cash Management.
Edit Reconciliation Tolerance Rule
Manage Bank Statement Reconciliation Matching

Rules
Matching rules allow you to determine how to match bank statement lines and
application transactions, and help to achieve a higher match rate in Autoreconciliation,
minimizing the need for manual intervention. You define bank statement automatic
reconciliation matching rules and assign them to bank statement automatic
reconciliation rule sets.
Manage Bank Statement Reconciliation Matching Rules row.
Create Matching Rules
Create, edit, copy and delete matching rules to be used for reconciliation.
For each rule, specify the following:
 Rule name.
 Transaction source or sources.
 Match type: one to one, one to many, many to one, or many to many.
 Group by attributes for bank statement or source depending upon match type.
 Matching Criteria: Includes a list of commonly used matching attributes. You can
simply check the attributes to include in their matching rule. Only group by and
amount fields are available for matching if grouping is used.
 Additional Matching Criteria: Allows you to specify additional matching logic or
filtering conditions that must be true for the bank statement line or lines and
transaction or transactions to be matched successfully. Only group by and
amount fields are available for matching if grouping is used.
You can select one or multiple transaction sources in a rule. If multiple sources are
selected in a one to one or many to one matching rule, then the autoreconciliation
program looks for a matching transaction across the selected sources. If multiple
sources are selected in a one to many or many to many matching rule, then the
program first finds all available transactions across the selected sources and then
applies grouping rule to the whole data pool. This means that statement lines can be
reconciled to a group that includes transactions across the different sources. If you want
transactions included in a group to be from the same transaction source then you can
specify Transaction Source as a grouping attribute.
Manage Bank Statement Reconciliation Rule Sets
Manage Bank Statement Reconciliation Rule Sets row.
Bank statement reconciliation rule sets are a group of matching rules and tolerance
rules. They are assigned to a bank account and used to reconcile bank statement lines
with transactions.
Create Rule Sets
You build the rule set and the rule set detail as a parent-child relationship. Each rule set
consists of one or more matching rules that can be prioritized or sequenced. The rules
should be ordered to achieve a greater reconciliation success rate. It is strongly
recommended that one to one rules be sequenced above rules of other types. To
provide an optimum reconciliation rate, you should change the sequence number
depending on how accurately the given rule is likely to reconcile against the correct
bank transactions. For example, transactions from sources for which the bank provides
you a reference ID are likely to have a higher reconciliation rate. These rules should be
placed at the top with a lower sequence number. Conversely, transactions with no
reference ID are likely to have duplicates or lower reconciliation rates, and you should
place them at the bottom with a higher sequence number.
Create Reconciliation Rule Set:
 Enter the name of the rule set.

 Provide a detailed description.
 Sequence 1 defaults initially.

 Enter a Matching Rule.
 Matching Type defaults based on the matching rule.
 Optionally enter a Tolerance Rule.
Reconciliation Rules region > Click the Create icon.
Edit Reconciliation Rule Set
Use the Edit feature to make updates or add and rearrange rule sequences.
Reconciliation Rules region > Click the Edit icon
Manage Bank Statement Transaction Creation Rules
External cash transactions are transactions related to cash activity that have not been
recorded within the system. There are four sources of external transactions:
 Manual entry.
 Import.
 Balancing transactions created during reconciliation for amount variances.
 Bank statement transactions created using the Bank Statement Transaction
Creation program. External cash transactions can optionally be accounted
when reconciled.
Bank Statement Transaction Creation is a program that identifies unreconciled bank

statement lines and creates transactions to record, account, and reconciles the bank
statement transaction. You create the rules to identify the statement lines from which to
create transactions and specify some of the attributes, including accounting options, of
the created transactions.
Manage Bank Statement Transaction Creation Rules row.
Create, Edit, and View Transaction Creation Rules
Rules are created as a separate business object and assigned to a bank account in the
Manage Bank Account page. In the bank account component the rules are able to be
sequenced, such that the application processes the rules in sequential order. The group
of sequenced rules on the bank account constitutes the bank accounts rule set that is
used when running the Bank Statement Transaction Creation Program.
This program is often used to create transactions and account for first notice items such
as bank charges, fees, or interest. It is recommended that you first run
Autoreconciliation and perform any manual reconciliation on a bank statement before
running this program to avoid creating external transaction from bank statement lines
which already have transactions recorded in the application.
Create, delete, edit and view a rule. Each rule identifies a bank statement line and
creates a transaction. You can specify some of the attributes and characteristics of the
created transaction.
Create Bank Statement Transaction Creation Rules
Create a new rule by entering in the required information: Name and Legal Entity.
When the Legal Entity is assigned the Cash and Offset Account appear under the
Accounting checkbox. Enter the Type and Transaction Code and assign the
appropriate general ledger accounts.
Edit Bank Statement Transaction Creation Rules
Make changes to existing rules using the Edit feature. You can Delete a rule, but an
optional alternative is to inactivate the rule by unchecking Active.
View Bank Statement Transaction Creation Rules
Selecting the link in the name column allows you to review the rule information. You
must be in either the Edit or Create mode to make changes or create a new rule.
Click the Name link.
Define Subledger Accounting Rules for Cash

Management
Process Category
identifiers.
NOTE: The Event Class for Cash Management is External Transaction.

The determinants:

Initial Setups

 Understand the setup and maintenance of cash management.

 Define banks, branches, and accounts.
 Set up bank transaction codes.
 Configure Bank Statement Processing and Reconciliation.
Lesson 16: Appendix
Lesson 16: Appendix
Lesson 16: Appendix
Appendix Content
Appendix Sections:
 Common Applications Additional Topics

NOTE: The additional content contained in the Appendix is intended as only resource
material for the student. This material is referred to during the class but is not intended
to be covered as part of the overall course.
Lesson 16: Appendix
Common Applications Additional Topics
 Getting Started with an Implementation.

 Define Application Toolkit Configuration.
 Define Approval Management.
 Define Attachments.
 Define Custom Enterprise Scheduler Jobs.
 Define Document Sequences.
 Define Help Configuration.
 Define Flexfields.
 Define Lookups.
 Manage Menu Customizations.
 Define Profile Options.
 Define Security.
 Define Trees.
 Manage Messages.
Lesson 16: Appendix
Getting Started with an Implementation
This lesson introduces the initial activities in an Oracle Fusion Applications

implementation:
 Preparing Oracle Fusion Applications for:

- User management
- Configuration
- Role management
 Synchronizing users and roles in the Lightweight Directory Access Protocol
(LDAP) with Oracle Fusion Human Capital Management (HCM)
 Creating implementation users
_______________________________________________________
NOTE: These steps are performed after installation and provisioning, and before setting
up enterprise structures and implementing projects. Between preparing users and
synchronizing users and roles from LDAP, your enterprise needs to configure offerings
and set up task lists. Between synchronizing users and roles from LDAP and setting up
enterprise structures, your enterprise needs to create initial implementation users.
Lesson 16: Appendix
Getting Started Objectives
 Anticipate actions required by your enterprise before setting up implementation

users
- Preparing the Oracle Fusion Applications super user for user management and
configuration
- Preparing the IT Security Manager job role for user and role management
 Define implementation users
This lesson does not cover:
 Generating a functional setup task list before implementing users

 Defining users after setting up basic enterprise structure
Lesson 16: Appendix
Overview of Getting Started
In Oracle Fusion Applications, you manage users and security through Oracle Fusion
Human Capital Management (HCM) user management flows, which are included in
each of the offering task lists. However, the HCM task flows require that enterprise
structures have been set up, and yet to add users who can set up enterprise structures
you need to have set up HCM. Therefore, you need to create one or more initial
implementation users who have the access needed for.
 Implementation project management

 Initial enterprise structures management
 User management
For a standard, full implementation of Oracle Fusion Applications, the initial activities
are as follows :
Lesson 16: Appendix
1. The Oracle Identity Management System Administrator user prepares the Oracle
Fusion Applications super user for user management and configuration tasks.
2. The Oracle Identity Management System Administrator user provisions the IT
Security Manager job role with roles for user and role management.
3. The Oracle Fusion Applications super user synchronizes LDAP users with HCM
user management so that users can be provisioned with roles through HCM.
4. The Oracle Fusion Applications super user signs in to Oracle Fusion Applications
and performs the Create Implementation Users task to create one or more IT
security manager and administrator users provisioned with security
administrative entitlement.
5. The newly created IT Security Manager user signs in to Oracle Fusion
Applications and performs the Create Implementation Users task to create
implementation project managers.
Lesson 16: Appendix
6. The newly created IT Security Manager user signs in to Oracle Fusion

Applications and performs the Create Implementation Users task to create users
for enterprise structure setup, and creates a data role for HCM setup and
provisions that role to the enterprise structure setup users.
The procedures named in this lesson for getting started are also presented in Getting
Started with Oracle Fusion Applications: Common Implementation. You can find this
document (ID: 1387777.1) on My Oracle Support, https://support.oracle.com.
Lesson 16: Appendix
Prepare the Super User
Background
Oracle Fusion Applications installation provisioning prompts for creating a super user
name (for example, FAADMIN) and password. This super user is the initial user
available for signing into Oracle Fusion Applications and performing initial user
management tasks. In order to access Oracle Identity Manager for such tasks as Create
Implementation Users, the super user must be registered with an e-mail address in
LDAP. An e-mail address is not created when installing and provisioning Oracle Fusion
Applications.
Scope
 Update the Oracle Fusion Applications super user ID in LDAP (for example
Oracle Internet Directory) with an E-mail address
 Reconcile LDAP and Oracle Identity Manager
Steps
From the Oracle home directory in the Oracle Identity Management (IDM) environment,
run the following command in UNIX as a user with administrative privileges in the
Oracle Identity Management (IDM) domain:
_______________________________________________________
$IDM_ORACLE_HOME /bin/ldapmodify -h oid_host -p oid_port <<EOF
dn: dn_of_super_user_entry
changetype: modify
add: mail
mail:e-mail_address
EOF
Lesson 16: Appendix
_______________________________________________________
where:
- IDM_ORACLE_HOME, oid_host, and oid_port are variables whose values are
determined by your installed environment
- dn_of_super_user_entry is the distinguished name of the user entry in LDAP, for
example: cn=faadmin,cn=users,dc=mycompany,dc=com
- e-mail_address is a fully qualified e-mail address of the form user@domain.com.
Run the LDAP User Create and Update Full Reconciliation scheduled job in Oracle
Identity Manager.
1. Sign in to Oracle Identity Manager (OIM) using the OIM System Administrator
user name.
The default user name of the OIM System Administrator is xelsysadm. Your
enterprise, however, may have chosen another user name and password for the
OIM Administrator. If you do not know the correct user name and password, or
the OIM URL, contact your OIM system administrator. For more information on
OIM, see the Managing the Password of the xelsysadm User section in the
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity
Management (Oracle Fusion Applications Edition).
2. Click the Advanced link in the upper right of the interface.
3. In the System Administration tasks in the Advanced Administration menu, click
Search Scheduled Jobs.
4. Enter the following job name in the Search Scheduled Jobs field.
LDAP User Create and Update Full Reconciliation
5. Select the LDAP User Create and Update Full Reconciliation job in the search
results.
6. Click Run Now in the Job Details page.
7. Confirm job completion in the Job History region of the Job Details page.
Remain signed into Oracle Identity Manager for the preparing the IT Security Manager
job role for user and role management.
Lesson 16: Appendix
NOTE: Student Activity Prepare the Super User, Prepare the IT Security Manager
Job Role, and Synchronize LDAP Users and Roles to Initialize HCM User
Management.
Lesson 16: Appendix
Define Implementation Users
The super user has broad access to Oracle Fusion Middleware and Oracle Fusion
Applications administration. Due to this broad access, your enterprise needs users
dedicated to managing users and applications security, such as an IT security manager
user. With user management entitlement, the super user creates one or more IT
security manager and security administrator users. If your enterprise does not require a
security administrator for Oracle Fusion Applications implementations, proceed with
Creating Implementation Project Managers.
The IT security manager user (or implementation project manager user if an IT security
manager is not needed) creates the implementation users using the Create
Implementation Users task in Oracle Fusion Applications, which accesses the
integrated Oracle Identity Manager provided by Oracle Fusion Middleware. In Oracle
Fusion Applications, this initial implementation user is a user account created in Oracle
Identity Manager only, specifically for setting up enterprise structures, and is not related
to a real person or identity such as a user defined in HCM. Once enterprise structures
are set up, subsequent implementation users can be created in HCM.
_______________________________________________________
NOTE: Depending on the size of your implementation team, you may only need a single
implementation user for security administration, implementation project management,
enterprise structures setup, and application implementation. That single user must then
be provisioned with all indicated roles, and therefore broad access.
NOTE: Student Activity: Create Security Administrators, Create Implementation

Project Managers and Create User for Enterprise Structure Setup.
Lesson 16: Appendix
Getting Started Highlights
 Complete preliminary tasks for creating implementation users

 Create an implementation user so your enterprise can get started with an
implementation
Lesson 16: Appendix
Getting Started Reference Resources
Related Resources:
Oracle Fusion Applications Installation Guide

Oracle Fusion Applications Common Implementation Guide
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity
Management (Oracle Fusion Applications Edition).
Oracle Fusion Middleware User's Guide for Oracle Identity Manager
Fusion Applications Information Technology Management, Implement Applications
Guide
Oracle Fusion Applications Workforce Deployment Implementation Guide
Oracle Fusion Applications Security reference manuals such as Oracle Fusion
Applications Common Security Reference Manuals
INSTRUCTOR NOTE: The listed documents are available in the Technology

Documentation Library, which you can access from:
http://www.oracle.com/technetwork/indexes/documentation/index.html
For example, the security reference manuals for Oracle Fusion Applications 11g
Release 1, Update 1 (11.1.2.0.0) are available at:
http://docs.oracle.com/cd/E25054_01/security.html
Lesson 16: Appendix
Define Application Toolkit Configuration
This lesson describes the following tasks in the Define Application Toolkit
Configuration task list, along with related setup:
 Map Reports to Work Areas

 Set Watchlist Options
Oracle Fusion Application Toolkit (ATK) provides various core components of
Oracle Fusion Applications, including the Watchlist feature and the Reports and
Analytics pane.
Lesson 16: Appendix
Lesson Objectives
 Select reports to appear in the Reports and Analytics pane on specific work
areas.
 Specify the Watchlist categories and items available to users, and perform
other Watchlist setup.
Lesson 16: Appendix
Reports and Analytics Pane
The Reports and Analytics pane provides a central point for users to view and run
operational or analytical reports. The pane is available on:
 Reports and Analytics work area: Includes all reports that the user has access
to. From the Navigator menu, select Tools > Reports and Analytics.
 Other select work areas in Oracle Fusion Applications: Includes reports
specific to the work area.
Each report in the pane is presented as a link, which represents a mapping to an object
in the Oracle Business Intelligence (BI) Presentation Catalog. Objects in the catalog
include:
 Analyses
 Dashboards
 Oracle BI Publisher reports
For a given work area, you can determine which reports are mapped and available to
users in the Reports and Analytics pane by:
 Creating mappings, for example to make custom reports available in the pane.
 Editing predefined mappings, for example to remove mappings to reports that

you do not want users to use.
You can map a report to the Reports and Analytics pane on one or more work areas, so
users might see the same report in different work areas.
Lesson 16: Appendix
Map Reports to Work Areas
To map reports to work areas, use the Map Reports to Work Areas page or the Edit
Settings dialog box. Any changes you make in either UI apply to all users with access
to the mapped work area.
This table shows the difference between the two setup UIs.
Use the Synchronize button to remove mappings to reports that are no longer in the
Oracle BI Presentation Catalog, for all work areas at once.
You can only map reports that you have access to, based on security.
Lesson 16: Appendix
Watchlist
The Watchlist feature:
 Provides a set of shortcuts to items that users want to track or that require users'
attention.
 Is available from the Watchlist menu in the global area or in the Watchlist
region on the Welcome dashboard.
 Consists of Watchlist items organized into Watchlist categories.
For example, under the Expenses category, there is a predefined Watchlist item for
unassigned corporate cards. Each item displays a corresponding count, for example 1.
The user can click the Unassigned corporate cards link to navigate to the work area
where the card can be assigned.
Aside from using predefined Watchlist categories and items, users can:
 Create their own Watchlist items using saved searches. For example, users can
create a saved search for corporate card transactions older than 30 days, and
put that on their own watchlist.
 Set preferences to determine which categories and items are displayed or hidden
in their watchlist.
 Manually refresh the Watchlist to get an updated count for items that are eligible
for refresh.
To set up Watchlist for all users, use the following tasks from the Setup and
Maintenance work area:
Lesson 16: Appendix
 Set Watchlist Options: Enable or disable Watchlist categories and items, and
determine how often item counts can refresh.
 Manage Standard Lookups: Rename predefined Watchlist categories or items.
You cannot delete predefined Watchlist categories and items, nor create any to be
available to all users.
Lesson 16: Appendix
Set Watchlist Options: Disabling Items and Categories
On the Set Watchlist Options page, use the Enabled column to disable or enable
Watchlist categories or items for all users. Disabling any category or item also disables
associated processes involved in calculating the Watchlist item counts.
Reasons for disabling are usually related to system performance. For example:
 Users might create their own Watchlist items based on saved searches that are
too broad, so the Watchlist takes a long time to determine the count. You can
disable these Watchlist items to improve performance.
 To troubleshoot poor performance, you can try disabling specific categories or
items to see which might be the cause.
This table describes the two types of Watchlist items and the impact of disabling each.
Lesson 16: Appendix
If you disable a category, then:
 The category is not available for users to display in their watchlist.

 All Watchlist items within the category are also disabled.
Lesson 16: Appendix
Set Watchlist Options: Defining Refresh Intervals
The Watchlist menu and region are refreshed:
 Automatically, one time, soon after the user first opens the menu or region.
 Manually using the Refresh icon in the Watchlist region, which is enabled after
five minutes since the last refresh.
On the Set Watchlist Options page, use the Refresh Interval in Seconds column to
define how often the query that calculates the count for a Watchlist item can be run. To
optimize Watchlist performance, set longer intervals for items that are less likely to have
frequent count changes.
For example, if compensation statements are provided to employees bimonthly, then

you can lengthen the interval appropriately for a Watchlist item that tracks new
statements.
During a refresh, the query runs for an individual Watchlist item only if the time since the
last query for this item is equal to or greater than the refresh interval.
For example, you set the refresh interval to eight minutes for Watchlist item A, and six
minutes for item B. The query runs for both items in the first Watchlist refresh. Seven
minutes later, the user clicks Refresh. It has not yet been eight minutes since the last
query of Watchlist item A, so the query does not run for this second refresh. The query
does run, however, for Watchlist item B, because more than six minutes have passed
since the last query.
NOTE: Because the Refresh icon is not enabled until five minutes after the last refresh,
you should not set a refresh interval that is less than five minutes. Intervals less than
five minutes are treated as equal to five minutes.
Lesson 16: Appendix
Rename Predefined Categories and Items
Use the Manage Standard Lookups page to edit predefined Watchlist category and
item names, for example, if the predefined display names have terms that your users
are not familiar with.
Query lookup types that end with WATCHLIST, for example

EXM_EXPENSES_WATCHLIST.
 Category: To rename the category, edit the lookup type meaning.

 Item: To rename items within the category, edit the corresponding lookup code
meanings for that lookup type.
Lesson 16: Appendix
Reference Resources
Related Resources:
Lesson 16: Appendix
Highlights
 Select reports to appear in the Reports and Analytics pane on specific work
areas.
 Specify the Watchlist categories and items available to users, and perform
other Watchlist setup.
Lesson 16: Appendix
Define Approval Management
This lesson describes the tasks for approval management setup:
 Configuring approval policies

 Defining approval groups
Lesson 16: Appendix
Lesson Objectives
 Describe the key concepts of approval management.

 Perform basic approval policy configurations.
 Create approval groups and understand how they are used.
Lesson 16: Appendix
Approval Management Overview
Workflow is an automated process in which tasks are passed from a user, a group of
users, or the application to another user or group for consideration or action. The tasks
are routed in a logical sequence to achieve an end result.
A workflow human task is anything that requires attention or action from users.
Examples of tasks include approving an expense report or completing an employee
performance appraisal.
For workflows, Oracle Fusion Applications uses the approval management extensions
of the human workflow services from Oracle SOA Suite, as well as the Oracle BPM
Worklist application.
Oracle SOA Suite:
 Is a comprehensive software suite used to build, deploy, and manage service-

oriented architectures (SOA).
 Provides a human workflow service that handles all interactions with users or
groups in business processes.
Approval management:
 Controls workflows for business objects such as expense reports.

 Enables you to define complex, multistage task routing rules.
 Integrates with the setup in Oracle Fusion Human Capital Management to
derive approvers based on the supervisory hierarchy.
Oracle BPM Worklist provides the UI for:
 Users to access tasks assigned to them and perform actions based on their roles
in the workflow.
 Implementors to perform approval management setup, to define who should act
on which types of transactions under what conditions.
Lesson 16: Appendix
To set up approval management, use the following setup tasks from the Setup and
Maintenance work area, which take you to Oracle BPM Worklist.
 Manage Approval Groups: Optionally create and maintain sets of users who
can act on workflow tasks, for example a chain of approvers for expense reports.
 Manage Task Configurations: Define approval policies that determine how and
when tasks are routed. For example, you can specify that expenses under a
certain amount should be automatically approved and not sent to any approver.
To access these setup tasks, you need the BPM Worklist Administration Duty role,
which is predefined for the Application Implementation Consultant job role.
Lesson 16: Appendix
Key Concepts
Stages
 Stages organize approval flows in logical categories within a task. For example,
within a contract approval task, there can be one stage for contract header
approval and another for line level approval.
 Each task has at least one stage.

 The available stages and their flow (serial or parallel, and specific order) are
predefined.
List Builders
A list builder is a mechanism to determine the task assignees, usually approvers, for
example based on going up the supervisory hierarchy.
The following list builders are based on structures in Oracle Fusion Human Capital
Management (HCM), which must be set up appropriately.
 Supervisory: The hierarchy of employees, with defined job roles, and their
managers. For example, Joe Smith, administration assistant, reports to Alex
Park, manager, who reports to Anna Lee, senior manager.
 Job Level: The supervisory hierarchy with job levels in consideration. The
approval list is generated based on the starting participant specified in a rule and
continuing until an approver with a sufficient job level is found. For example, Joe
Smith, administration assistant (job level 1), reports to Alex Park, manager (job
level 2), who reports to who reports to Anna Lee, senior manager (job level 2),
who reports to Jane Brown, director (job level 3).
 Position: The hierarchy of job positions. Do not select this list builder; the
integration with HCM is not available.
Other list builders include:
 Management Chain: The management hierarchy in LDAP, similar to the

supervisory hierarchy in Oracle Fusion HCM. If you are not using Oracle Fusion
HCM, then you can set up this hierarchy for use with the list builder.
 Approval Group: A set of specific users.
 Resource: A specific user or application role.
Lesson 16: Appendix
Rule Sets and Rules
 A rule set is collection of related rules to map out the policies and routing within
a stage. For example, for a stage for contract approval, there can be one rule set
for legal approval and another for management approval.
 In each rule, you define a condition and specify the routing using a list builder.
Rule sets are predefined for each stage with these characteristics:
 Flow: Serial or parallel, and specific order, for stages with multiple rule sets.
 Business object level: Header or line.
 Voting regime: Consensus approval, majority approval, and so on, for rule sets
that route to a group of users.
Lesson 16: Appendix
Example
This figure shows an example of the flow of stages and rule sets for an expense
approval task. There are four predefined stages, each with one predefined rule set
except the pre-approval stage, which has two rule sets. The rule sets are:
 Requester FYI: The person submitting an expense report receives an FYI

notification.
 Exception Consensus: For extraordinary expenses over a certain amount, a set
of users must first approve. Approvals are based on an Approval Group list
builder and are routed in parallel to all members of a group.
Lesson 16: Appendix
 Header Hierarchy and Line Hierarchy: With serial routing based on a

Supervisory list builder, approvers approve the expense report header or lines.
NOTE:
 To add or edit stages, rule sets, or list builders, including modifying the flow,
technical administrators must use Oracle JDeveloper.
 What you can do in Oracle BPM Worklist is add and edit the rules within rule
sets, to define the conditions and routing.
 Also, you can choose not to use predefined rule sets. For example, if the
Exception Consensus is not necessary for your purposes, you can disable it.
Lesson 16: Appendix
Manage Task Configurations
Use the Task Configuration tab in Oracle BPM Worklist to define approval policies. In
the Tasks to be configured pane, review the predefined tasks in the server domain,
which generally maps to a product family, and edit tasks as needed.
To define approval policies:
1. Select a task in the Tasks to be configured pane and click the Edit task icon
button in the pane toolbar. You are in edit mode and can select other tasks to
edit without clicking Edit task again.
2. Make changes in the Event Driven or Data Driven tabs.
3. Use the Save icon button in the toolbar. Your changes are retained even if you
sign out, but are not yet in effect. To discard all changes, saved or not, use the
Reset icon button.
4. Click the Commit task icon button to deploy your saved changes so that they
are in effect.
Lesson 16: Appendix
NOTE: If the task is not predefined as rule-based, then the behavior does not need to
be changed, and you get a message stating that you cannot edit the task. Technical
administrators can still edit the task in Oracle JDeveloper.
Lesson 16: Appendix
Data Driven Tab
Use the Data Driven tab to define rules that determine routing. Select the rule set within
the appropriate stage. You can add, edit, or delete rules. Select the Ignore this
participant check box if you do not need to use this rule set.
NOTE: Do not use the Add variable button. Technical administrators should define
variables, which can be used in rule conditions, in Oracle JDeveloper.
Each rule consists of an if and then component. The if component contains at least one
condition, to determine when the rule is applied. For multiple conditions within a rule,
you use the and or operators.
The then component defines what happens if the conditions are met. This component
consists of:
 List builder and related attributes: Define how task assignees are derived. For
example, if you select a Job Level list builder, you also define how many levels of
approvals are needed.
 Response type: Indicate if the assignees are required to address the task or if
they are just to receive an FYI notification.
 Automatic action setting: Allows you to set an automatic action on tasks, for
example to automatically approve or reject.
Lesson 16: Appendix
For example, this expense report rule set is in the expense report approval stage.
Within this rule set, the first rule is defined with a condition for expenses over $1,000.
The routing uses the Supervisory list builder to require only the approval of the
requester's manager.
Lesson 16: Appendix
The second rule in this rule set is for expenses at or under $1,000. The routing has the
task creator as the top, or final, participant, so the task essentially goes back to the
requester. Based on the Auto Action Enabled and Auto Action fields, the expense
report would be automatically approved.
NOTE: At least one rule in a rule set must evaluate to true. If multiple rules within a rule
set can be true, then these rules must use the same list builder.
Lesson 16: Appendix
Event Driven Tab
Use the Event Driven tab to define expiration and escalation policies, as well as other
settings for the task.
 Expiration and Escalation Policy: Configure when tasks expire, are escalated,
or renewed. Expired tasks are automatically rejected. For example, you can
define the expiration policy so that if no one acts upon an expense report in two
weeks, then it expires and the requester needs to resubmit it.
 Notification Settings: Send notifications based on task status, for example to

approvers when the task is assigned to them. If the task has rules with the FYI
response type, then notifications are also sent based on the rule conditions. You
can use these notification settings or the FYI rules, or both. For example, you can
delete the notifications in the Notification Settings section if you prefer to use the
FYI rules to send notifications based on certain criteria, not just task status.
 Task Access: Control who can access the task and perform what actions. You
generally do not need to adjust the predefined settings.
Lesson 16: Appendix
 Likewise, you generally do not need to adjust the other settings on this page
unless you have a specific business reason.
Lesson 16: Appendix
Manage Approval Groups
Use the Approval Groups tab in Oracle BPM Worklist to define sets of users that can
be selected for an Approval Group list builder. Tasks would be routed to the specified
group of users. For example:
 You have a special, ongoing project that involves a wide range of employees.
You can create an approval group of the managers involved, who must approve
expenses related to the project.
 You have certain categories of requisitions that require pre-approval from a
select group of people. You can create an approval group containing the users
who must all approve such requisitions in parallel before additional approvals can
be made.
Approval groups:
 Can be nested within other approval groups.

 Are stored at the server level and not shared across domains. For example, you
cannot use the same group for Financials and HCM.
There are two types of approval groups:
 Static: You select specific users to include in the group and specify the flow of
tasks from one user to another. If the group is used in a rule set that is
predefined with parallel routing, then the task is passed to all users in the group
at the same time.
Lesson 16: Appendix
 Dynamic: You use a custom Java class coded by technical administrators to

generate the approval group at run time. The administrator can tell you what to
enter in the Class field.
Lesson 16: Appendix
Example: Setting Up Payables Invoice Approval

Users can easily set up invoice approval rules based on their business process. This
example will demonstrate how an Accounts Payable Supervisor/Manager can approve
an invoice. There are different ways for approving an invoice in Fusion. This example
will illustrate approving invoices from the Invoices Work Area In Fusion Payables.
Note: Approval rules can be based only on invoice header attributes. In EBS R12
approval rules can be based on any attribute of the invoice including header, lines and
distributions.
Assumptions
 Invoice amount less than $1,000 are auto approved
 Invoice amount greater than $1,000 require approval
Setup Data Required

 Invoice approval should be turned on at the Invoice option level
 After the invoice gets created, the user can either initiate approval from the
Invoice Actions drop down list or schedule the Invoice Approval Task Flow ESS
job.
Setup Steps
1. User having the financial administrator role logs into Fusion applications. Click on
Navigator and select Financials under Worklist.
2. The BPM Worklist home page is displayed.
Lesson 16: Appendix
3. On this page the user can view all transactions that require his/her approval.
4. Click on the Administration link.
5. The administration home page is displayed. Click on the Task Configuration tab.
6. Under the “Tasks to be Configured” the user can view all approval task flows that
pertain to Financials. Highlight the “FinApInvoiceApproval” task and click on the
Edit icon.
Lesson 16: Appendix
7. Under the Event Driven tab, the user can view the approval configuration. Click
the Data Driven tab to view the approval rules.
8. Click on the “InvoiceApprovalRuleSet” to view the invoice approval rules.
Lesson 16: Appendix
9. There are 2 rules defined: the first one is the Manager Approval rule and the
second one is the Auto Approval rule. Expand the Auto Approval rule by clicking
on the triangle icon.
10. The above rule states that the invoice would be auto approved if the invoice
amount is less than 1000.
11. Expand the Manager approval rule to view the approval rule details
Lesson 16: Appendix
12. The above rule states that invoices over 1000 would be automatically routed for
approval through the supervisor hierarchy. In this case, it would be the supervisor
associated with the user that created the invoice.
13. To create a new approval rule, click on the drop down list as shown below. The
new rule should check for non-PO invoices over a certain amount and route them
to a specific user, in this case Accounts Payable Supervisor.
14. This would automatically create a new rule
15. Enter a valid rule name. Expand the rule by clicking on the triangle icon.
Lesson 16: Appendix
16. Click on the prompt and then drill down to

Task/payload/getInvoiceHeader1Response/result/invoiceAmount.
17. Click the drop down list to select the condition “more than.”
18. Enter a value on the edit box as shown below.
Lesson 16: Appendix
19. Click on the “+” to add another condition to check if PO Number is blank.
20. Click on the List Builder drop down list and select “Resource”
Lesson 16: Appendix
21. The user can specify users, groups or app Role. The user clicks on the prompt
next to Users and specifies a valid user.
22. The user then saves the approval rule by clicking on the Save icon (“Disk”)
23. Next, the user clicks on Commit Task icon to deploy the approval rule that was
created. The approval rule now becomes active.
Reference Resources
Related Resources:
 Oracle Fusion Middleware Modeling and Implementation Guide for Oracle

Business Process Management
 Oracle Fusion Applications Common Implementation Guide
Lesson 16: Appendix
Highlights
 Describe the key concepts of approval management.

 Perform basic approval policy configurations.
 Create approval groups and understand how they are used.
 Set up invoice approval.
Lesson 16: Appendix
Define Attachments
This section describes the tasks in the Define Attachments task list:
 Manage Attachment Categories
 Manage Attachment Entities
Lesson 16: Appendix
Key Concepts
Attachments are:
 Pieces of supplementary information that users can associate with specific

business objects. For example, users might attach receipts to expense reports.
 URLs, desktop files, or text.
 Stored in a content server, the Oracle Enterprise Content Management
document repository. Where available, users can also select folders or files from
the repository as attachments.
UIs that allow users to add attachments are available throughout Oracle Fusion
Applications, where applicable.
For a particular business object, a user might be able to view, add and edit, or delete
attachments, or have no access at all. For example, if a user does not have access to a
specific expense report, then the same user cannot access attachments for the expense
report.
Attachment entities:
 Identify the business object that attachments can be attached to.

 Are typically named after the primary table or view used to store information
about the business object.
Attachment categories:
 Classify attachments. For example, when users add an attachment to an

expense report, they can select a category to indicate if the attachment is a
receipt, travel itinerary, and so on.
 Can optionally be used to restrict access. For example, users with a specific role
are not given access to one of the expense report attachment categories, so they
cannot select it when adding attachments to their reports. They also cannot see
any attachments assigned to this category.
 Are assigned to attachment entities so that each category is tied to the relevant
business objects.
NOTE: Each attachment entity must have at least one assigned category. Otherwise,
users cannot add attachments for the corresponding business object.
Lesson 16: Appendix
If an entity has only one category, then:
 All attachments added for the corresponding business object are automatically
assigned to that category.
 The Category attribute is hidden in the UIs where users add or view attachments
for this business object.
Lesson 16: Appendix
Manage Attachment Categories
Attachments UIs for users to add or manage attachments are fully functional and do not
require setup. Predefined attachment categories are already assigned to attachment
entities.
You can optionally:
 Create new attachment categories as needed and assign to relevant attachment

entities. For example, your company wants to identify attachments that fulfill a
specific fiscal requirement. You can create a new category and assign it to all
attachment entities representing business objects relevant to the requirement.
 Remove the association of categories to specific entities, for example if a
predefined category is not relevant to any of your users for certain business
objects.
For your changes to appear in attachments UIs for users, the users must sign out and
sign back in to clear the cache for categories. If your new categories are still not
displayed, then it is likely that the specific attachments UI has predefined restrictions on
categories in place. Check with your administrator or help desk.
Use the Manage Attachment Categories task from the Setup and Maintenance work
area to create categories and manage their assignments to entities.
NOTE: The Manage Attachment Entities task from the Setup and Maintenance work
area can also be used to assign categories to entities. You do not need to use this page
unless you are performing additional or technical configuration.
Lesson 16: Appendix
Attachment Category Security
You or a technical administrator can optionally implement data security on attachment

categories, to determine:
 Which categories users have access to when adding attachments.

 What actions they can perform on attachments assigned to those categories.
Each action is captured by predefined privileges:
 Read: Read Application Attachment

(FND_READ_APPLICATION_ATTACHMENT_DATA)
 Update: Update Application Attachment
(FND_UPDATE_APPLICATION_ATTACHMENT_DATA)
 Delete: Delete Application Attachment
(FND_DELETE_APPLICATION_ATTACHMENT_DATA)
For an attachment category or set of categories, assign one or more of the privileges to
roles. For details, see the Oracle Fusion Applications Developer's Guide.
After the security rules are in place, you or your technical administrator can use the
Security Enabled check box on the Manage Attachment Entities page from the Setup
and Maintenance work area to enable this security for specific attachment entities.
NOTE: If security is enabled for an attachment entity before any data security rules are
in place for a particular category, then that category will not be visible to anyone until
rules are in place or security is disabled.
In some cases, data security for categories is predefined. For example, there are
predefined attachment categories for suppliers and receivers. Both types of users can
go to the same page with attachments UI, but see only the categories they have access
to based on security.
Lesson 16: Appendix
Example
For example, the Expense Report attachment entity currently has three attachment
categories:
 Receipts
 Missing Receipts Declaration
 Travel Itinerary
You need to track the mileage of cars that belong to your company. Your users should
record miles traveled in a log book, scan the relevant page, and attach the image file as
part of their expense reports.
The clerks handling the corporate fleet vehicles need to see these attachments, but
should not view the other types of attachments for expense reports. The managers of
users submitting the expense reports can view all categories.
To implement this security:
1. You use the Manage Attachments Category page to create a Mileage

attachment category and associate it with the Expense Report attachment entity.
2. You define data security so that the role for the clerk can see only the Mileage
category, while the role for the manager can see all categories.
3. You select the Enable Security check box on the Manage Attachment Entities
page for the Expense Report entity.
Lesson 16: Appendix
Define Custom Enterprise Scheduler Jobs
This lesson describes the Manage Custom Enterprise Scheduler Jobs tasks
under the Define Extensions > Define Custom Enterprise Scheduler Jobs task
lists.
Lesson 16: Appendix
Lesson Objectives
 Describe what enterprise scheduler job definitions are.

 Identify the purpose of list of values sources.
Lesson 16: Appendix
Manage Job Definitions
An Oracle Enterprise Scheduler job is an executable that users can run to process
data, for example to validate invoices or create journal entries. Some jobs also provide
report output, for example tax reports used for reporting to tax authorities.
Related concepts include:
 Process or Scheduled Process: A unique submission or run of a job. For

example, users can run a process for a specific job to post journal batches for
one accounting period, and submit another process for a different accounting
period. Each run of the same job has a unique process ID.
 Job Definition: The metadata for the job that allows it to be run, for example the
job type, location of the executable, and parameters available to users.
 Parameters: Filters that users can set when they submit a process, for example,
a date range for document creation date. The process then includes only records
with a creation date within the specified range.
Predefined jobs are used in various Oracle Fusion applications. Your technical
administrators can create custom jobs and job definitions based on Java, PL/SQL, or
any other supported technology.
You can optionally update aspects of these custom jobs, including:
 Editing job display names, for example to use terms that are more familiar to
your users.
 Editing parameter display names, using the Prompt field.
 Using the Tooltip Text field to add parameter help text that appears when users
focus on the parameter. For example, you can provide restrictions or
considerations specific to your company's needs.
To edit custom job definitions, access the Manage Job Definitions page from either:
 The Setup and Maintenance work area. You must select the task that contains
the name of the Java EE application to which the job definition belongs. For
example, use the Manage Custom Enterprise Scheduler Jobs for Payables and
Related Applications task for Oracle Fusion Expenses job definitions.
 Oracle Enterprise Manager Fusion Applications Control.
Lesson 16: Appendix
Manage List of Values Sources
A list of values source:
 Determines where a list of values comes from and what the specific values are.
 Are used for job parameters so that users can select a value for the parameter.
Your technical administrator can create lists of values sources, for example, one for
country names to be used for a Country parameter in a job definition. When users
schedule a process based on this job, they can select a country as a value for this
parameter.
The Manage List of Values Sources page is accessed using the same Manage
Custom Enterprise Scheduler Jobs tasks.
Lesson 16: Appendix
Reference Resources
Related Resources:
 Oracle Fusion Applications Administrator's Guide

Lesson 16: Appendix
Highlights
 Describe what enterprise scheduler job definitions are.

 Identify the purpose of list of values sources.
Lesson 16: Appendix
Define Document, Accounting, or Reporting Sequences

In this section, you will learn key concepts about:
Document Sequence
Accounting Sequence
Reporting Sequence
Overview
Transactions are often sequenced for audit or legal compliance purposes, or to ensure completeness by
identifying missing or deleted transactions that should be in a sequence. Some countries have statutory
and legal requirements for legal entity accounting that are met by Sequencing. Oracle Fusion
Applications support three types of sequences:
1. Document Sequence – uniquely numbers a document when it is created
2. Accounting Sequence – uniquely numbers a document when it is finalized
3. Reporting Sequence – uniquely numbers a document when it is reported
Document Sequence
Document sequence is used to provide unique identification to business documents or business events
by assigning unique numbers to each document or event. Using this functionality, you can sequentially
track all the documents and events that are created during transactions.
A document sequence helps in generating an audit trail, which can be used to identify how a particular
transaction passed through various applications. It plays a significant role in identifying failed
transactions. You can create a document sequence to uniquely number documents created by Oracle
Fusion Applications, such as bank statements in Cash Management, invoices in Receivables, or journal
entries in General Ledger.
Lesson 16: Appendix
Document Sequence Types

There are three different types of document sequencing:
Automatic Sequencing: Used when documents are automatically created as part of a business cycle
and need to be assigned sequential numbers to maintain the order and audit trail. For example, invoices
or payments. This option assigns a unique number to each document as it gets generated, and this
unique number is stored in the database. The numbering is sequential by date and time of creation. If you
define a sequence to automatically number documents, you can provide an initial value to begin the
sequence. In absence of a defined value, the default value one (1) is used.
Manual Sequencing: Used when you want the flexibility to manually enter the sequence number or add
a unique code at the time of creating the document. For example, you have two invoices with the same
invoice number from different suppliers. You would want to make each invoice unique by appending the
date or a code to the actual number. In this type of sequencing, the numerical ordering and completeness
of a transaction is not strictly enforced, but it is validated to check if the documents are in sequence. You
can skip or omit numbers when entering the sequence value.
Gapless Sequencing: Used only in certain contexts. It is a type of automatic sequencing with additional
confirmation not to have skipped a single number during assignment. However, it is used for sequencing
only successfully generated documents. As a result, the sequence is maintained for all the documents
that are generated, and no sequence numbers are lost due to incomplete or failed document generation.
For example, you want your order numbers to be in sequence such as 001, 002, 003, and so on,
irrespective of who placed the order. Similar to automatic sequencing, you can set the initial value to
begin the sequence.
Depending on the regulatory and accounting requirements of the countries in which you operate, it may
be necessary to set up a gapless document sequence. Some countries impose strict legal requirements
for maintaining a distinct and auditable number range for financial transactions.
In the subledgers, gapless document sequences are maintained at the business unit level. You cannot
create a single sequence that crosses business units in a subledger product. This very often drives the
creation of a business unit; you will create business units in regulated countries that correspond to the
entities that need to sequence subledger documents.
Lesson 16: Appendix
In General Ledger, document sequences are generated for transactions at the ledger level, that is, all
business units and all legal entities associated with a given ledger will share available General Ledger
numbering sequences. In the rare situation that a local regulatory authority requires gapless General
Ledger document sequencing and gapless subledger document sequencing, it may be necessary to
maintain a one to one relationship between a legal entity, a ledger, and a business unit.
Document Sequence Categories

A document sequence category is a set of documents that share similar characteristics and are formed
into a logical group. You assign a document sequence to a document sequence category.
When you assign a sequence to a category, the sequence numbers for the documents are stored in a
particular table.
Note: Once a document sequence category is created, you cannot change the application, the category
code, or the table name. Therefore, carefully consider these details and plan your document sequencing
requirement before you begin working with the application.
Document Sequence Assignment

Document Sequence assignment involves the following steps:
1. Identify the documents to be numbered before assigning them a document sequence. For each
document sequence, there can be only one active assignment to a document sequence category.
2. Specify whether the document is created automatically (for example, due to a batch process) or
manually.
3. If a determinant type (attribute) was specified for the document sequence, then enter a specific
determinant (value) related to the selected determinant type. When users create documents, the
document sequence to be assigned is determined by finding the active assignment that matches
the correct combination of category, numbering method, and the date range containing the
transaction date.
Accounting and Reporting Sequences

Accounting and Reporting Sequences are the numbering of the accounting entries in respect to subledger
and other accounting feeds. It is distinct from document sequencing, which is used to number invoices,
payment forms, and other fiscal documents such as debit or credit memos. Local regulations may dictate
how accounting entries should be numbered and may require a gapless sequence for completed journal
entries (excluding incomplete journal entries). Accounting and Reporting sequence numbering of journal
entries enables you to:
• Have gapless sequence numbers.
• Sequentially number subledger journal entries. You can generate a sequence number for journal
entries created by subledger accounting, before transferring them to general ledger.
• Sequence number general ledger journal entries.
• Assign sequencing rules to subledger and general ledger journal entries within the context of a
ledger and ledger currency combination.
• Generate reports based on the sequence numbers.
• Sequentially number deferred expense accounting.
Accounting Sequence numbers the journal entries at time of final accounting in Subledger Accounting or at
time of posting in General Ledger. Reporting Sequence numbers the journal entries when a GL period is
closed.
Lesson 16: Appendix
Note: You can choose to sequence journals for ledgers (primary and secondary ledgers) and/or journal
level and subledger level reporting currencies. If using journal or subledger level reporting currencies and
you defined sequences for the source ledger, such as the primary or secondary ledger, the sequence
number generated for the source ledger is not automatically assigned to the reporting currency journal.
You must set up accounting and reporting sequences separately for the reporting currencies if your want
reporting currency journals sequenced.
Defining and Assigning Accounting and Reporting Sequences
Define sequences to generate numbers for journal entries. You can assign the sequence to a ledger and
indicate whether you want the sequence numbers generated in Subledger Accounting or in General
Ledger, and at time of accounting/posting (for Accounting Sequences) or when the GL period is closed
(for Reporting Sequences). You can choose from Accounting Date, Journal Effective Date, Posting Date,
or Reference Date as the date for validating and assigning the sequence. Each sequence is assigned to
a combination of journal source, journal category, accounting event type, accounting entry type, and
document category.
Lesson 16: Appendix
Define Help Configuration
This lesson describes the tasks in the Define Help Configuration task list, which
enable you to set up Oracle Fusion Applications Help:
 Set Help Options

 Assign Help Text Administration Duty
 Manage Help Security Groups
Lesson 16: Appendix
Lesson Objectives
 Set options for the features available in the help system.

 Ensure that the duty enabling users to customize help is assigned to the
appropriate roles.
 Create security groups that are used to restrict access to specific help
files.
Lesson 16: Appendix
Set Help Options
Use the Set Help Options task from the Setup and Maintenance work area to control
the behavior of certain features in Oracle Fusion Applications Help. Some of these
options may not be available, depending on what is set for help feature choices on the
Configure Offerings page in the same work area.
 Collaboration Features: Enable or disable discussion forums and

announcements.
 Web Sites Available from Help Site: Enable or disable links in the global area
of Oracle Fusion Applications Help that go to Oracle web sites.
 Custom Help: Define the name and logo used to identify custom help. For
example, the logo would be displayed next to the title of custom help files in
search results. If you are using Oracle User Productivity Kit (UPK) content as
custom help, enter the default location where the UPK player packages reside.
 Oracle User Productivity Kit: If you are using UPK, you can provide a link in
the global area of Oracle Fusion Applications Help that goes to your UPK library.
NOTE: If you have UPK versions earlier than 3.6.1, then you cannot add UPK
demos as custom help, so the link is the only way for users to access custom
UPK content from the help site.
 Privacy Statement: Optionally replace the predefined privacy statement in the
footer of Oracle Fusion Applications Help with your own statement.
Lesson 16: Appendix
Assign Help Text Administration Duty
Provide help customization access to users, for example:
 Business process owners such as expense audit, requisition, or purchasing

managers, who want to post company policies and procedures for employees in
the help system.
 Training administrators, who want to create custom help with links to training web
pages.
The Application Help Text Administration Duty role allows users to customize help.
This duty is assigned by default to the application administrator roles for each product
family, for example Project Application Administrator. For the full list, see the Oracle
Fusion Applications security reference manuals.
To assign additional job roles to this duty:
1. In the Setup and Maintenance work area, access the Manage Duties task.
2. In the Applications section of the Home tab, select an application and then click
the Application Roles - Search link.
3. Search for the Application Help Text Administration Duty display name and
select it in the search results.
4. In the External Role Mapping section, add your job roles.
Lesson 16: Appendix
Manage Help Security Groups
Use help security groups to restrict user access to specific custom help files. A help
security group is:
 Associated with a set of job roles.

 Assigned to individual help files during help customization.
Only users with at least one of the job roles associated with the help security group can
access the help file that the group is assigned to.
For example, you have a custom help file for expense auditors, titled Expense Audit
Policies and Best Practices. You can restrict access to this help by creating a help
security group associated with the expense auditor job roles, and assigning this group
to your help file. Only users with an expense auditor job role can view this help.
Use the Manage Help Security Groups task from the Setup and Maintenance work
area to create, edit, and delete help security groups.
Lesson 16: Appendix
Reference Resources
Related Resources:

 Oracle Fusion Applications security reference manuals
 Oracle Fusion Middleware Authorization Policy Manager Administrator's
Guide (Oracle Fusion Applications Edition)
 Oracle Fusion Applications Security Guide
Lesson 16: Appendix
Highlights
 Set options for the features available in the help system.

 Ensure that the duty enabling users to customize help is assigned to the
appropriate roles.
 Create security groups that are used to restrict access to specific help
files.
Lesson 16: Appendix
Define Flexfields
This section describes flexfield concepts and tasks for flexfield configuration:
 Flexfield concepts
 Value sets
 Descriptive, extensible, and key flexfields
 Flexfield implementation flow
Lesson 16: Appendix
Flexfield Concepts
Manage flexfields using the tasks of the Define Flexfields activity, which you access in
the Setup and Maintenance Overview work area. Search in the work area for the task
list by entering Define Flexfields.
A flexfield:
 Provides a means to customize applications features without programming

 Extends a business object with additional data fields to capture enterprise
information
 Consists of segments representing different data or values
 Stores data in database table columns, one for each segment
 Displays to end users as attributes of information
 Encapsulates all of the pieces of information related to a specific purpose
The available types of flexfields are:
Lesson 16: Appendix
A single flexfield can capture multiple attributes, which you can display in the user
interface as fields. The figure shows several fields added to an order page by defining a
part number key flexfield, and additionally a descriptive flexfield for capturing part type
and sales representative information.
Lesson 16: Appendix
Of the subset of business objects that are defined to include a flexfield; some can
accommodate descriptive flexfields and others accommodate extensible flexfields, at
the discretion of application development.
Flexfield attributes are available across the deployment, such as in Web Services,
Oracle Business Intelligence, desktop integration with Application Development
Framework, and Oracle Fusion Search. Any UI page presenting the business object
includes the flexfields that extend the business object. Oracle Business Intelligence
reports include flexfield attributes.
Flexfield segments:
 Represent attributes of entities (business objects)

 Can appear:
- Based on a structure or context
- Globally wherever the flexfield is implemented
 Can be made available to an application as groups of attributes called contexts
 Can be assigned a value set that determines which values are valid for the
segment
Flexfield structure is:
 Only relevant to key flexfields

 A specific configuration of key flexfield segments
 Composed of one or more instances, each of which contains the same number
and order of segments, but differs in the allowable values or value sets attached
to the segments.
Flexfield context is:
Lesson 16: Appendix
 Only relevant to descriptive and extensible flexfields

 A grouping of attributes that make segments available to an application
 A set of context-sensitive segments that store a particular type of related
information
- Descriptive flexfield segments can be context-sensitive
- Extensible flexfield segments must be context-sensitive
 A way of reusing the same database column for a similar or different segment
based on different needs
Flexfield category is:
 Only relevant in extensible flexfields

 A grouping of contexts
 A hierarchy of categories
Flexfield usage is:
 Set when the flexfield is registered

 Specifies the application and table the flexfield is associated with
Lesson 16: Appendix
Value Sets
A value set is:
 Specific to your enterprise

 A set of valid values assigned to a flexfield segment, or other entity outside of
flexfields
 The basis of validation for a value entered into a flexfield segment by an end
user
 Defined before configuring the flexfield, because you assign value sets to each
segment as you configure a flexfield
The figure shows a value set being used for a descriptive flexfield segments.
The types of validation are:
 Format only, where end users enter data rather than selecting values from a list
 Independent, where the list of values consists of valid values you specify
Lesson 16: Appendix
 Dependent, where a valid value in a list of values derives from the independent
value of another segment
 Subset, where the list of values is a subset of the values in an existing
independent value set
 Table, where the values derive from a column in an application table, which can
optionally be limited by a WHERE clause
You can apply data security to Independent, dependent, or table-validated value sets
for every usage of it in any flexfield. Oracle Fusion data security enforces value set
security. Based on the roles provisioned to users, data security policies determine which
values of a flexfield segment end users can view or modify.
A value set's usage:
 Specifies the segment where the value set is assigned

 Indicates which flexfields use a shared value set
Value sets can be used outside flexfields, such as:
 Building tree structures, if the value set is independent

If your application has more than one language installed, or there is any possibility that
you might install one or more additional languages for your
application in the future, select Translatable. This does not require you to provide
translated values now, but you cannot change this option if you decide
to provide them later.
Lesson 16: Appendix
Descriptive Flexfields
A descriptive flexfield:
 Is optional
 Provides a way to add custom attributes to entities and define validation and
display properties for custom attributes
 Is enabled for all business entities
 Consists of segments that are made available to end users as individual fields in
the application user interface
Descriptive flexfield segments:
 Correspond to custom attributes of entities

 Are generally standalone and need not be related or treated together with other
segments as a combination
 Are of three types:
- Global segment, which is always available
- Context segment, which determines the context-sensitive segments that are
displayed
- Context-sensitive segment, which is displayed depending on the value of the
context segment
Context segments:
 Need not be assigned a value set

 If assigned a value set, can only use table validated or independent value sets
- The data type must be character
- The maximum length of the values being stored must not be larger than column
length of the context.
Applications development determines the number of segments available for configuring.
During implementation you determine which attributes to add using the available
segments, and the context values and the combination of attributes in each context. The
same segment can be used for different attributes, such as Height in Context1 and
Color in Context2.
For each global and context-sensitive segment, you configure the values allowed for the
segment and how the values that are entered by end users should be validated,
including interdependent validation among the segments.
Lesson 16: Appendix
Extensible Flexfields
Extensible flexfields are like descriptive flexfields, with some additional features.
 You can add as many context-sensitive segments to the flexfield as you need.
You are not dependent on the number of segments predefined and registered for
the flexfield.
 You can configure a one-to-many relationship between the entity and its
extended attribute rows.
- A product business object row can be extended to have multiple contexts.
- A product business object row can have multiple occurrences of the same
context.
 You can configure contexts in groups so the attributes in the context always
appear together in the user interface.
 You can use existing hierarchical categories so that entities inherit the contexts
that are configured for their parents. Contexts are reusable throughout
categories.
An extensible flexfield context:
 Can be defined as single row, the same as descriptive flexfields contexts

 Can be defined as multi row so multiple sets of values can be associated with the
same product business object row
 Can be set for translatable free form text values
 Are reusable throughout extensible flexfield categories
An extensible flexfield category:
 Provides a means of organizing related data in associated contexts

 Can serve to associate any combination of contexts
 Can be in a hierarchy that logically organizes sets of categories that support
inheritance of contexts
An extensible flexfield page:
 Combines contexts into a group that is presented together in the application user
interface
 Corresponds to one extensible flexfield category, with a separate region of the
page for each associated context
Lesson 16: Appendix
Extensible Flexfield Example
You can specify whether end users can enter one set of data, or multiple sets of data,
for a context.
For example, if you have a job positions entity that stores information about different
positions in your organization, you can configure additional contexts that store a list of
requirements for that position.
To start with, the job positions entity includes fields for the following attributes:
 Position ID
 Position code
 Description
 Department
 Location
 Hiring status
 Whether the job is permanent or temporary
 Whether the job is full time or part time
_______________________________________________________
You then can extend the list of job positions in order to capture three classes of
attributes:
 Educational requirements, such as degrees

 Certifications and licenses required for the position
 Travel required for this position
You implement this by setting up context values, corresponding to each group of
custom attributes. Setting up context values means specifying segments for each
context, such as various degrees in an educational requirements context and
various credentials in a certification and license requirements context. You set up
a job position category that contains the three contexts for the three classes of
attributes you want to capture, and set up a page for that category.
_______________________________________________________
Lesson 16: Appendix
When users create a job in the job positions category, they see the additional attributes.
When users define job position requirements, they select the education level,
credentials, and travel required by the position.
Lesson 16: Appendix
Key Flexfields
A key flexfield:
 Provides a means of capturing a key, such as a part number, a job code, or an

account code that represents an entity in your application
 Consists of one or more segments, where each segment can have a meaning
 Is not optional and must be configured to ensure that your applications operate
correctly
 Is provided by applications development, and is configured and maintained with
the Manage Key Flexfields task
 Has one corresponding combinations table containing the complete codes, or

combinations of segment values that makes up the codes
 Can be used in different ways on different pages:
- Combination maintenance page, which is where users maintain individual
combinations directly
- Foreign key page, which is where users manipulate rows containing code
combination IDs (CCID)
- Partial usage page, which is where users may be presented with only parts of
the configuration based on a product's transaction table
A key flexfield structure:
 Defines the following segment options:

- What segments to include
- Number of segment
- Segment sequence
- Segment labels where applicable, for example natural account and primary
balancing in general ledger.
- Value sets
 Sets the maximum number of segments allowed in your key flexfield
combinations table.
 Allows one or more alternate structure instances which can have different value
sets.
 Includes a delimiter to visually separate segment values when the key flexfield is
displayed as a string of concatenated segments in user interfaces or reports.
All key flexfield structure instances:
Lesson 16: Appendix
 Contain:
- The same set of segments
- The same arrangement of segments
- The same properties at the segment and structure levels
 May differ in whether dynamic combination creation is allowed, which means a
new valid combination is inserted into a combinations table from a page other
than the combination maintenance page
Key flexfield segment instances in a key flexfield structure instance may differ in the
following aspects:
 Value set
 Default type and default value
 Tree code defining a hierarchical relationship to other segment values of a key
flexfield registered with a tree structure
 Whether the segment is any of the following
- Required
- Displayed
- Enabled for business intelligence
- Optional or required as a query criterion in a key flexfield combination search
The predefined key flexfields are:
 Account Alias Flexfield

 Accounting Flexfield
 Asset Key Flexfield
 Budgeting Flexfield
 Category Flexfield
 Cost Allocation Flexfield
 Item Categories
 Location Flexfield
 Locator Flexfield
 People Group Flexfield
 Valuation Unit Flexfield
Lesson 16: Appendix
Tips for Managing Key Flexfields
 When you configure a key flexfield, you define metadata about the key flexfield,
such as how many segments are in a structure, how many structures the flexfield
uses, what value sets each segment uses, and so on. For example, you could
use one group of value sets for the US and another for France.
 Be sure to add segments in the order that your key requires. Once deployed, the
order cannot be changed.
 If you change the configuration of a key flexfield, such as the delimiter, the
change affects the previously stored key flexfields with that structure.
 Enable segments to indicate that they are in use and display in runtime.
 Do not change the number, order, and maximum length of segments once you
have acquired flexfield data.
 To protect the integrity of your data, disable a segment if you have already used
it to enter data.
 You can dynamically create new account code combinations when entering data
by enabling dynamic insertion in the Key Flexfield Instance page. At any time,
enable or disable allowing dynamic combination creation. Define cross validation
rules to prevent incorrect account combinations from being created by dynamic
combination creation.
Lesson 16: Appendix
Flexfield Implementation Flow
Managing flexfields involves, registering, planning, configuring, and deploying flexfields.

Applications developers develop and register flexfields. Administrators and
implementors configure flexfields and optionally customize their appearance in the
user interface.
The two types of deployment are for:
Lesson 16: Appendix
 A sandbox-enabled flexfield for testing flexfield behavior in a sandbox MDS

repository that is only accessible to the administrator who activates and accesses
it, not to users generally
 A mainline-enabled flexfield for applying the flexfield definition to the mainline
MDS repository where it is available to end users
After deploying the flexfield to the mainline, you can customize the page where the
flexfield segments appear.
Lesson 16: Appendix
Flexfield Highlights
In this lesson, you should have learned about:
 Flexfield concepts
 Value sets
 Descriptive, extensible, and key flexfields
 Flexfield implementation flow
Lesson 16: Appendix
Flexfield Reference Resources
Related Resources:

Oracle Fusion Applications Extensibility Guide
Oracle Fusion Applications Developer's Guide
To view flexfields in the Oracle Enterprise Repository, see

https://fusionappsoer.oracle.com/oer (https://fusionappsoer.oracle.com/oer/)
Lesson 16: Appendix
Define Lookups
 Lookups, their constituents, and their types

 Managing lookups
Lesson 16: Appendix
Key Concepts
Lookups consist of:
 Lookup Type - A lookup type is a static list of values users use to make entries
in the application. This is the name of the field that appears on the setup UI and
not on the application UI where you make the selection.
 Lookup Code - An internal application code for each lookup that is not visible to
users.
 Meaning - The actual UI term associated with the lookup code. It is the item that
appears in the list on the application UI against the specific field name, and can
be selected by the users to indicate their choice.
 Tag - A label associated with that lookup. Certain product offerings use lookup
tags for functionality that is specific to that product. Refer to the product offering
specific documentation for more information. If no such use of tag is
documented, the Tag is ignored.
 Enabled (status) - Determines the availability of the meaning (the value or the
item) within the selection list for that lookup type. If you do not enable it, the value
does not appear in the selection list at runtime.
Lesson 16: Appendix
As per the settings shown in the table, the users would see the following values in the
list on the application UI to determine the Ticket Class:
 Any
 Business
 Economy
There are three different categories of lookups:
 Standard Lookups - These are the simplest form of lookup types consisting of
lookup codes and their meanings.
 Common Lookups - These lookups are available for internal system
administrative use and are used by more than one application.
 Set-enabled Lookups - These lookups contain lookup codes that are part of a
reference data. You can use sets to enable different values in that lookup for
different sets of users. At runtime, a selected attribute determines which set-
enabled lookup will be visible to the users. For example, the attribute east-coast
or west-coast in the determinant 'location' determines whether it is the 'east-
coast' or the 'west-coast' location, depending upon the selected lookup.
Lesson 16: Appendix
Lookup codes and their meanings are valid between a specified date range. If a date
range is not specified, the lookup codes and meanings have indefinite validity from the
time they are created.
Lesson 16: Appendix
Manage Lookups
Standard, common, and set-enabled lookups are defined in the Standard, Common,
and Set-enabled views, respectively. Applications development may define lookups in
an application view to restrict the UI pages where they may appear.
In lookups management tasks, lookups may be associated with a module and striped by
application taxonomy to provide a criterion for narrowing a search or limiting the number
of lookups accessed by a product specific task such as Manage Purchasing Lookups.
Enabling Lookups
You can create new lookup types and also add new lookup codes and meanings to the
existing lookup types, depending upon the access permissions granted to you. But for
the lookups and lookup values to appear as values in the lists, they need to be enabled.
To enable a lookup type, you need to enable at least one of its lookup codes and that
code must be in a valid date range.
By default, most lookup types are enabled at the time of deployment. You may disable
the ones that you do not require.
You can access this task from the Setup and Maintenance menu.
Customizing Lookups
Lookups can be customized as per the defined customization levels. Therefore, even if
a lookup is available for customization, the extent to which customization is allowed may
vary depending upon the defined customization level. The following levels of
customization are defined.
Lesson 16: Appendix
 User - You can create or modify all parameters of a lookup type.

 Extensible - You can modify only certain aspects of the lookup type such as the
dates, and add new lookup codes, but cannot delete the lookup type.
 System - You cannot add or delete any aspect of the lookup type. You can only
modify its meaning.
Lesson 16: Appendix
Manage Menu Customizations
Use the Manage Menu Customizations task in the Setup and Maintenance work area
to customize the Navigator menu in the global area for all users.
The Manage Menu Customizations page presents the Navigator menu with these
components:
 Groups: Submenus, or categories of items, for example Tools.

 Items: Commands that users select to navigate, for example Setup and
Maintenance, which goes to the Setup and Maintenance work area.
The customizations that you can perform include:
 Using the Rendered check box to determine which groups and items are
displayed or hidden. For example, you can hide a specific item if none of your
users need it.
 Changing the display name of groups and items, using the Label field. For
example, you can use terms that your users are more familiar with.
 Creating items that take users to a web site, by entering a valid URL in the
Destination field. For example, you can add an item that takes users to your
company's expense policies, below the existing item that takes users to the
Expenses work area.
 Creating groups, for example to categorize a set of new items that you are
adding to the menu.
NOTE: Your technical administrator can also create items that take users to a specific
page in Oracle Fusion Applications, or to another application.
Lesson 16: Appendix
Define Profile Options
 Profile Options
 Profile Option Categories
 Profile Option Levels and Values
 Common Profile Options to Set Up
Lesson 16: Appendix
Profile Options
Profile options are global configuration settings that users can modify to change the way
an application works. For example, settings such as user preferences and application
configuration parameters can be modified as per the user's requirements.
You can use profile options to modify:
 The look and behavior of the application's user interface

 User preferences such as settings used for social networking
 The business logic of the application
 Log settings and processing options that determine how and where information is
stored
A profile option is made up of the following:
 Name
 Application and module
 Values
 Categories
 Hierarchy level
You can modify any of these constituents of the existing profile options, but system
administrators must have enabled the profile option for modification.
The use of profile options is guided by the functional requirements. To determine which
profile options to use in the implementation project, refer to the product offering specific
documentation.
Lesson 16: Appendix
Profile Option Categories
Profile options are grouped into categories depending upon the functional area in which
the profile options are used. For example, in Oracle Fusion Receivables, the
Transactions profile option category groups the profile options related to Receivables
transactions processing, such as Require Adjustment Reason, Invoices with
Unconfirmed Receipts, Use Invoice Accounting for Credit Memos, and so on.
Profile option categories facilitate searching and defining data security.
A profile option can be grouped into more than one category.
Lesson 16: Appendix
Profile Option Levels and Values
Profile Option Levels
In an application, the display and availability of profile options depends upon the
hierarchy level at which it is enabled. The different hierarchy levels are:
1. Site level - the lowest level of hierarchy that unless superseded by any other
level provides accessibility to all the users of the application, across the
deployment site. In a multi-tenant environment, Site is scoped per tenant.
2. Product level - the next level in the hierarchy that applies to the selected product
family (product offering within Oracle Fusion, such as Financials) and its specific
users. For the same user, the profile option at this level supersedes any site level
profile option setting.
3. User level - the highest level in the hierarchy that applies to the specific user or
user role and supersedes any product or site level setting that was earlier
associated with the user.
Profile options defined at higher levels override the profile options at the lower level.
Profile Option Values
Profile values determine application behavior that you want at the selected level.
Context such as user session or accessed product determines which profile option
value is associated with the profile option name.
The following example of the profile option FND_LANGUAGE shows how the profile
values determine the default language of the application at various levels.
Lesson 16: Appendix
Lesson 16: Appendix
Profile Options for Common Set Up
You may set up common profile option such as logging that applies to the entire
applications suite. Logging is by default set to SEVERE at the Site level. If you want to
examine in detail the logs for users so that you can diagnose or troubleshoot any minor
problem, you need to set it to FINEST at the User level for a particular user.
As a result, actions of that particular user are captured in the finest level possible. The
benefit of this setting is that it does not affect other users and does not impact logging or
performance at the Site level.
Another example could be the use of profile option FND_CSS_SKIN_FAMILY to

determine the colors and fonts that appear on the application UI. The selected profile
value and the hierarchy level at which the profile option is set determines the
application's look and feel at various levels.
You can find these profile options under the Manage Profile Options task on the Setup
and Maintenance Overview page.
Lesson 16: Appendix
Define Security
This lesson introduces concepts of function and data security in support of

implementation:
 Viewing security details such as role definitions and the roles provisioned
to users.
 Differentiating between provisioning a user with a job role versus a data
role.
 Determining the usefulness for your enterprise of Human Capital
Management (HCM) security profiles, role provisioning rules, and
extending the security reference implementation.
Lesson 16: Appendix
Security Key Concepts
In Oracle Fusion Applications:
 Role-based access control (RBAC) grants function and data access to users
through the roles assigned to them, not to the users directly.
 Function security provides users with access to pages in application user
interfaces and controls the actions that can be performed on those pages.
 Data security allows or restricts access to data in pages depending on policies,
conditions, masking, and encryption.
 Privacy encompasses data that should not be available to other individuals and
organizations, or data whose exposure and use is under the owner's control.
 Access provisioning and identity management involves managing user
identities, user accounts, role assignments, and enterprise role definitions.
 Segregation of duties policies prevent or detect unintentional errors and willful
fraud by separating activities such as approving and processing results.
 Enforcement across tools, technologies, data transformations, and access
methods coordinates transactional and analytical security across all components
of a deployment.
 Enforcement across the information life cycle protects data in transit and at
rest across the phases of a deployment from installation to archive and purge.
 A security reference implementation provides a baseline set of roles, policies,
Human Capital Management (HCM) security profiles, and templates that match
the business needs of most enterprises.
Lesson 16: Appendix
Role-Based Access Control
An enterprise needs to control who can do what on which functions or sets of data
under what conditions.
The who is the user. A user's access is based on the definition of the roles provisioned
to the user. Access is defined as entitlement, which consists of privileges .
The what are the abstract operations or entitlement. The which represents the
resources being accessed. For example, view and edit are actions, and task flows or
rows in data tables are resources.
Three types of roles can be provisioned to users to match the user's function and
position in an enterprise. These enterprise roles, also called external roles, are:
 Job role - specific to a job, and controls access to functions through inherited
duty roles that carry the entitlement necessary for performing specific tasks
associated with the duties of the job, such as access for an accounts payable
manager.
- Abstract role - like a job role, but not specific to a particular job, and controls
common access, such as access for all employees or contingent workers.
 Data role - specific to a job within a dimension of data, and augments the
inherited abstract, duty, or job roles with entitlement to access specific data, such
as access for an accounts payable manager in a particular business unit.
The fourth type of role is the Duty role, also called application role. Duty roles cannot
be provisioned directly to users, but are inherited by enterprise roles to control access to
applications. Duty roles may carry both function and data security grants.
Lesson 16: Appendix
Role definitions consist of a role hierarchy. The following setup tasks manage role
hierarchies.
Lesson 16: Appendix
INSTRUCTOR NOTE: Some setup data such as Receivables Receipt Method and
Payment Method is not secured, and some transaction data such as Receivables
Customer Profile is not secured. Archive data such as Receivables Archive is also not
secured.
Lesson 16: Appendix
 Function security consists of privileges unconditionally granted to a role and

used to control access to:
- a page or a specific widget
- functionality within a page, including services, screens, and flows.
 Data security consists of privileges conditionally granted as data security
policies carried by roles, or granted as Human Capital Management (HCM)
security profiles, and used to control access to data:
- within a business object such as a business unit
- based on user profile
- based on privacy policies
For example, a job role might give view access to the functions needed to access
invoices, but a data role that inherits the job role gives view access to the invoices data
within a business unit, such as the data role Accounts Payable Manager - US which
inherits the job role Accounts Payable Manager for performing accounts payable duties
against the US business unit.
Some data, such as some setup and transaction data, is not secured, in which case
access to a user interface page gives unrestricted access to the data that is accessible
from that page.
INSTRUCTOR NOTE:
Another example of delegated administration is having different IT security manager
users manage users, roles and role assignments within specific Oracle Identity
Management (OIM) organizations instead of having one IT security manager user
manage all users and roles across all OIM organizations.
For an overview of how the various integrated products contribute to security, see
Security Components: How They Fit Together in the Oracle Fusion Application Security
Guide.
Lesson 16: Appendix
Lesson 16: Appendix
Access Provisioning and Identity Management
Access provisioning and identity management involves:
 Creating and managing user identities, , such as specifying the name and other
attributes of a user identity
 Creating and linking user accounts to user identities, such as to a Human
Capital Management (HCM) person or a Supplier contact
 Managing user access control through user role assignment, such as assigning
a role manually to a user or automatically through role provisioning rules
 Managing security on workflow approvals and delegated administration of
approvals, such as having the owner of a sales line of business approve access
to sales roles, rather than having the IT security manager approve such access
You can provision users with access to functions and data through various product
features, such as team definitions in Oracle Projects.
Lesson 16: Appendix
Security Reference Implementation
The security reference implementation is a baseline set of predefined security

definitions.
 Abstract, job, and duty roles in hierarchies that streamline provisioning access
to users.
 Data role templates that generate data roles when enterprise structures are
defined.
 Data security policies that specify actions allowed on data under certain
conditions
 Segregation of duties policies that control risk through integration with the
Governance, Risk, and Compliance Controls (GRCC) product.
- Predefined duty roles carry no inherent segregation of duties risk.
The details of the security reference implementation are presented in the security
reference manual (SRM) for each offering, and can be viewed using the tasks available
for managing roles, templates, and security policies.
In cases where the predefined security reference implementation does not adequately
represent the needs of your enterprise, you can make changes. For example, a
predefined job role may be too narrowly defined. You can create a new job role and give
it a role hierarchy of fewer or different duty roles than a similar predefined job role, and
provision your newly created job role to users who should have broader access.
_______________________________________________________
NOTE: The security reference implementation in Oracle Fusion Applications provides a

complete, predefined security implementation that is applicable to the needs of midsized
(generally between 250 and 10,000 employees), horizontal enterprises and can be
changed or scaled to accommodate expansion into vertical industries such as health
care, insurance, automobiles, or food manufacturing.
INSTRUCTOR NOTE: All functions and actions in Oracle Fusion Applications that need
to be secured are covered by the security reference implementation. It should not be
necessary to create new duty roles, except in cases where functions are being
customized or new functions are being added.
Lesson 16: Appendix
Defining Data Security
Data security controls access to data by the following means:
 Data Security Policy: Grants access to roles by means of entitlement.

 Data Role: Applies data security policies with conditions to users provisioned
with the role.
 Data Role Template: Defines the data roles generated based on enterprise
setup of data dimensions such as business unit.
 HCM Security Profile: Defines data security conditions on instances of object
types such as person records, positions, and document types without requiring
users to enter SQL code.
 Masking: Hides private data on non-production database instances.
 Encryption: Scrambles data to prevent users without decryption authorization
from reading secured data.
Depending on the offering, the Define Data Security activity can include tasks such as
the following:
 Manage Data Access Sets for managing a set of access privileges to one or
more ledgers or ledger sets
 Manage Segment Security for managing balancing or management segment
values to secure data within a ledger
 Manage Role Templates for managing data role templates to update or create
new data roles
 Manage Data Security Policies for managing access to the database resources
of an enterprise
 Manage Encryption Keys for managing encryption keys held in Oracle Wallet to
secure Personally Identifiable Information (PII) attributes
Lesson 16: Appendix
Data Security Policies
A data security policy is a statement in a natural language, such as English, that

typically defines the grant by which a role secures business objects. The grant records
the following.
 Table or view (logical business objects or dashboards)

 Entitlement (actions expressed by privileges)
 Condition (readable WHERE clause identifying entire data object, object
instance, or object instance set)
Data security policies articulate the security requirement "Who can do What on Which
set of data."
For example, accounts payable managers can view AP disbursements for their
business unit. Use the Manage Data Security Policies task to modify data security
policies.
Data security policies that use job or duty roles refer to data security entitlement. For
example, the data security policy for the Accounts Payable Manager job role refers to
the view action on AP disbursements as the data security entitlement.
In the following figure, a user provisioned with the Marketing Analyst job role can view
sales party data for sales account team resources in the user's management chain
based as defined for the Sales Party Review Duty role, which the Marketing Analyst job
role inherits.
Lesson 16: Appendix
The duty roles inherited by the job role can be moved and job roles reassembled
without having to modify the data security.
In the following figure, data security policies are defined for a data role in addition to the
data security policies defined for the base role that the data role inherits.
Lesson 16: Appendix
As a security guideline, data security policies based on user session context should
entitle a duty role. This keeps both function and data security policies at the duty role
level, thus reducing errors.
You use a data role when the data dimension cannot be derived from the current user
session. For example, you cannot know the business unit of a user is authorized to use
the user's session context. You use a data security policy against a duty role if you can
derive the data dimension from a user session context. For example a data security
policy can entitle a user to update a project that the user is a Project Team Member of.
Lesson 16: Appendix
Data Role Templates
Data role templates generate data roles based on enterprise setup. Changes to data
role templates generate new or changed data roles.
The following attributes define a data role template.
 Template Name and Description

 Template Group ID - aids in searching for templates.
 Base Roles - determines the job and abstract roles inherited by the generated
data role.
 Data Dimension - expresses stripes of data, such as territorial or geographic
information you use to partition enterprise data, such as a business unit.
- Dimension value - a specific stripe of data, such as a US business unit, or a
reference data set used in reference data sharing.
 Data Role Naming Rule - determines how the names of the generated data
roles are constructed, such as a concatenation of base role and data dimension.
 Data Security Policies - grants access to a business object such as an invoice,
with an entitlement, such as view.
Use the Manage Role Templates task to create or change data role templates, or
generate data roles from role templates.
If you add a dimension value to your enterprise that is used by a data role template, you
must regenerate roles from that data role template to create a data role for the new
dimension.
If you add a base role to an existing data role template, you can generate a new set of
data roles. If the naming rule is unchanged, existing data roles are overwritten.
If you remove a base role from a data role template and regenerate data roles, a
resulting invalid role list gives you the option to delete or disable the data roles that
would be changed by that removal.
INSTRUCTOR NOTE: For information on working with data role templates, see the
Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager
(Oracle Fusion Applications Edition).
Lesson 16: Appendix
Data Role and HCM Security Profiles
A data role is a type of job or abstract role. Not all job or abstract roles have
corresponding data roles, but if a data role exists, provision the data role to the user, not
the underlying job or abstract role.
A data role carries the function security entitlement inherited from the role hierarchies
and data security entitlement conditionally granted on each object and condition.
Define data roles based on the data security requirements of the enterprise. For control
and performance reasons, data roles commonly limit access within tools, applications,
or areas of a deployment such as departments or cost centers.
Data roles are created using either data role templates or by associating HCM
security profiles with a job or abstract role to define an HCM data role.
Use the Manage Role Templates task to manage the templates that generate data
roles.
Use the Manage Data Roles and Security Profiles task to create and maintain HCM
data roles in Oracle Fusion Human Capital Management (HCM), which uses HCM
security profiles, not data role templates, to define the data security condition.
Lesson 16: Appendix
Defining Users Overview
When business unit and legal employer have been defined as part of setting up
enterprise structures, you define users by using the Manage Users task, or
automatically in Human Capital Management (HCM) when creating person records .
The identity of an enterprise user consists of identifying information about a user.
 HR attributes - represent relatively static and well understood information, such

as first and last name, title, and job function.
 Roles - define the user's purpose and responsibilities.
 Resources - define identifying assets, such as application accounts or physical
devices such as laptops or access cards.
 Relationships - define identifying connections, such as organizational
transactions (for example, approvals)
The difference between users, identities, workers, and partners is as follows:
Lesson 16: Appendix
INSTRUCTOR NOTE: In Oracle Fusion Applications, identities and users correspond

one to one, but not all identities correspond to a user, and not all users are provisioned
with an identity. Some identities stored in HCM and Trading Community Model may not
be provisioned to user accounts and therefore are not synchronized with Oracle Identity
Management (IDM). For example, a contact for a prospective customer is an identity in
Trading Community Model but may not be provisioned with a user account in IDM.
Some users stored in the Lightweight Directory Access Protocol (LDAP) store may not
be provisioned with identities. For example, system user accounts used to run Web
services to integrate third party services with Oracle Fusion Applications are not
associated with a person record in HCM or Trading Community Model. Some identifying
credentials such as name, department, e-mail address, manager, and location are
stored with user data in the LDAP store.
User accounts for some identities that are not employees, such as partner contacts,
may be created in a later transaction using an identity that is already created. Supplier
contacts are created in the Supplier Model, not HCM. Once supplier users are setup,
Supplier Model can be used by internal users to maintain supplier user accounts or
supplier users can maintain their accounts in Supplier Portal.
Lesson 16: Appendix
Creating Users and Importing Users
A user and corresponding identity is usually created in a single transaction, such as

when a worker is created in Human Capital Management (HCM). That transaction
automatically triggers provisioning requests for the user based on role provisioning
rules.
_______________________________________________________
REMINDER: Before creating users, perform the Run User and Roles Synchronization
Process task and monitor completion of the SyncRolesJob process to ensure that the
latest roles definitions can be assigned to users.
NOTE: Student Activity Synchronize LDAP Users and Roles to Maintain HCM User
Management.
Lesson 16: Appendix
Provisioning Users with Roles
Provision users with roles:
 Automatically, using role provisioning rules

 Manually, using delegated administration:
- Users such as line managers and human resource specialists can provision
roles manually to other users.
- Users can request roles for themselves
For both automatic and manual role provisioning, you create a role mapping to identify
when a user becomes eligible for a role.
The following tasks provision users with roles:
 Role Provisioning Rules

- Manage HCM Role Provisioning Rules task
 Role Provisioning
- Manage Users task based on HCM Role Provisioning Rules
Security guidelines:
 Avoid having users entitled to provision roles from being the same users who are
defining those roles.
 Maintain role memberships through role provisioning rules.
- The Manage HCM Role Provisioning Rules task lets you define rules for
provisioning roles to users based on assignment attribute values or CRM party
criteria.
- Supplier Portal provisioning rules apply to users provisioned through the
Supplier application.
 Provision to users only those job roles that are not inherited by data roles you
could provision instead.
INSTRUCTOR NOTE: The Provision Roles to Implementation Users task also
provisions roles, but provisions roles only as an initial task when getting started and
preparing an implementation user for enterprise structure setup.
Lesson 16: Appendix
Role Provisioning Events
New identities, as with new hire, supplier, or partner contact creation, trigger user and
role provisioning events. In addition to user creation tasks, other tasks, such as Promote
Worker Transfer Worker, or user account creation for supplier or partner contacts, result
in role provisioning and recalculation based on role provisioning rules. Deactivating or
terminating an identity triggers revocation of some roles to end all role assignments, but
may provision new roles needed for activities such as pay stub review.
A role is provisioned to a user automatically when at least one of the user's assignments
satisfies the conditions specified in the relevant role-mapping definition. Automatically
provisioned roles are deprovisioned automatically as soon as a user no longer satisfies
the role-mapping conditions. Manually provisioned roles are deprovisioned
automatically only when all of the user's work relationships are terminated; in all other
circumstances, users retain manually provisioned roles until they are deprovisioned
manually.
Segregation of duties (SOD) checks occur when roles are assigned to users, if Oracle
Governance, Risk and Compliance Controls (GRCC) is provisioned in your deployment
and the Governance, Risk and Compliance feature choice is enabled for implementation
projects of the offering. The SOD checks are based on Oracle Application Access
Controls Governor (AACG) policies, and violations can be viewed, managed,
remediated using Define Automated Governance, Risk, and Performance Controls
tasks.
Use Oracle Identity Management (OIM) to configure audits of provisioning events.
Lesson 16: Appendix
Define Security Highlights
 The main concepts of the Oracle Fusion Applications security approach

 Which tasks allow you to view security details such as role definitions and
the roles provisioned to users
Lesson 16: Appendix
Security Reference Resources
Related Resources:

Oracle Fusion Applications Security Guide
Oracle Fusion Middleware User's Guide for Oracle Identity Manager
Oracle Fusion Middleware Authorization Policy Manager Administrator's Guide (Oracle
Fusion Applications Edition)
Oracle Fusion Applications Workforce Deployment Implementation Guide
Oracle Application Access Controls Governor Users Guide
Oracle Fusion Applications Security reference manuals such as Oracle Fusion
Applications Common Security Reference Manuals
INSTRUCTOR NOTE: The listed documents are available in the Technology

Documentation Library, which you can access from:
http://www.oracle.com/technetwork/indexes/documentation/index.html
For example, the security reference manuals for Oracle Fusion Applications 11g
Release 1, Update 1 (11.1.2.0.0) are available at:
http://docs.oracle.com/cd/E25054_01/security.htm
Lesson 16: Appendix
Define Trees
 Trees
 Tree Structures
 Tree Node
 Tree Label
 Tree Versions
Lesson 16: Appendix
Trees
A tree is a hierarchical representation of data within an organization. You can view the
hierarchical relationships among the data entities and determine how they function in a
business scenario.
Oracle Fusion Applications use tree management to enable customers manage

hierarchical relationships between objects such as:
 Departments in HCM
 Organizations in HCM
 Accounting Codes (GL) in Financials
 Trading Community in CRM
A tree helps you in:
 Determining parent-child relationship between the entities

 Setting better access control
 Applying business rules at various stages
Creating a tree involves:
1. Selecting a tree structure

2. Selecting a tree node
3. Specifying a tree label
4. Setting a version
Lesson 16: Appendix
Tree Structures
A tree structure defines the hierarchy for creating trees. Tree structures contain the
metadata of the actual data that is used in Oracle Fusion Applications.
Tree structures contain the core business logic that is manifested in trees and tree
versions. It can be understood as the template for:
 Creating trees
 Versioning trees
 Applying business rules to control the way data flows within a tree
 Setting access control on trees
Therefore, a tree structure is critical to the creation of a tree.
Tree structures are predefined and seeded by the product offering that is using them.
Lesson 16: Appendix
Tree Node
Tree Node determines the hierarchical classification of data. It is the point where a tree
branches into levels. Tree nodes are categorized into the following:
 Root node: The topmost node in the tree structure

 Parent node: The node that branches off into other nodes
 Child node: The node connected to a node higher in hierarchy (parent node)
 Sibling node: Nodes that are at the same level and belong to the same parent
node
 Leaf node: Entities branching off from a node but not extending further down the
tree hierarchy
Lesson 16: Appendix
Tree Label
A tree label is a short name assigned to a tree node. It points directly to the data source
and indicates where a tree branches into other child nodes.
After you define a tree, you may choose to apply one of the available labeling schemes:
 Allow Ragged Nodes - Used if you want to label nodes that have no child
nodes, or label nodes which are at the lowest level in the entire hierarchy.
 Allow Skip Level Nodes - Used for nodes that are at the same level but have
their parent nodes at different levels.
Lesson 16: Appendix
Tree Versions
A tree version is an instance of the tree that you created. Versioning is necessary
before a tree can be used in an implementation. A tree must have at least one version.
Tree versions are also created to keep track of all the changes that a tree undergoes.
The application maintains an audit trail of the changes and automatically versions the
tree based on the updates made to it.
Tree versions bear the following status:
 Active - Indicates that the version is currently used by the application

 Inactive - Indicates that the version is not used by the application
 Draft - Indicates that the version is temporarily used by the application to
perform a 'what-if' analysis and test the version without affecting the Active
version
Tree versions can either be created afresh or duplicated as copies of the existing
versions.
A tree can have more than one tree version, depending upon the business need, but
only one tree version can be 'Active'. In exceptional cases, you can set more than one
tree version to 'Active' but not within the same date range.
Whenever you edit an active tree version, its status automatically changes to 'Draft'. If
you want to use the same tree version, set it to 'Active' on the Manage Trees and Tree
Versions application UI.
Lesson 16: Appendix
Manage Messages
Messages appear in the application to provide information to users. Most of the

messages in Oracle Fusion Applications reside in the message dictionary, which
contains messages that:
 Tell users about errors, such as missing or incorrect data, and how to resolve
them.
 Warn users about the consequences of intended actions.
 Provide general information, for example confirmations in the UI or statuses in
log files.
Some of the predefined messages are common messages, which:
 Can be used in any Oracle Fusion application.

 Have message names that start with FND_CMN.
 Have message numbers between 0 and 999.
For example, the FND_CMN_UNSVED_PGE message can be used in any application
to warn users that unsaved changes made to the page will be lost if they navigate away
from the page without saving.
Use the Manage Messages task in the Setup and Maintenance work area to edit the
text of predefined messages (including common messages) for example, add company-
specific information to a message.
Tasks such as creating new messages, updating message properties and tokens are
administrative tasks and are likely to be performed by system administrators.
Lesson 16: Appendix
Editing Message Text
You may need to edit a message text. The message text contains various components,
most of which are optional. The Short Text and Cause components are displayed to any
user. The user and administrator components are visible to the targeted users, based
on what you set in the Message Mode profile option. However, ensure that the message
can be easily understood by the users irrespective of the application in which it appears.
Some messages have tokens, which are:
 Variables that provide text, numbers, or dates to display in the message.

 Represented in message text by curly brackets.
For example, one of the common messages is: The start date must be earlier than or
equal to {TODAY_DATE}. When the message is actually displayed to users, the
{TODAY_DATE} token is replaced by the system date.
You must never edit a token.

Fin Implementation StudentGuide PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Fin Implementation StudentGuide PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Fusion Applications:

Asara Alim, Tina Brand, Disclaimer

Lesson 5: Configuring Oracle Fusion Subledger Accounting ....313

Lesson 11: Configuring Oracle Fusion Expenses .......................721

Lesson 12: Configuring Oracle Fusion Receivables ...................777

Lesson 1: Introduction to Oracle Fusion Financials

After completing this course, you should be able to:

 Identify the key concepts of Oracle Fusion Financials Offering that

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 1

In this course the instructor:

 Presents introductory modules.

2 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Oracle Fusion Implementation Resources

 Oracle Fusion Financials: Introduction to Financials Implementation (this guide)

 Oracle Fusion Applications Financials Implementation Guide

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 3

 Oracle Hyperion Financial Reporting Administrator's Guide for Oracle Hyperion

 Oracle Fusion Applications Administrator and Implementor Roadmap

 Getting Started with Oracle Fusion Applications: Common Implementation,

4 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

This course is designed to generally follow this agenda:

 Oracle Fusion Financials Course Overview

 Oracle Fusion General Ledger Continued

 Oracle Fusion Tax

 Oracle Fusion Assets

 Oracle Fusion Receivables Continued

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 5

Introduction to Oracle Fusion Financials

This lesson covers the following topics:

6 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Oracle Fusion Financials consists of the following applications:

Organizational Models in Oracle Financials

This course discusses how you might:

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 7

• Secure your information

The Legal Organization

8 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 9

Other Organizational Structures

The Role of Your Legal Entities

Compliance and Disclosure Requirements

10 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

ownership of the goods and transactions managed by such centers.

Representing Your Organization in the System

Organizations and Transactions

Organizational Classifications in Fusion Financials

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 11

Legal Environment Considerations

Around these extremes, several other arrangements are also supported.

If the Regulatory Situation of Your Subsidiaries Requires a Distinct Ledger

12 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Gapless Document Sequencing

If the Regulatory Situation of Your Subsidiaries Facilitates Using One Ledger in

Other Accounting Environment

Ledgers, Multiple Ledgers, Ledger Sets, Balancing Segments, and

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 13

Ledger balances have meaning - they assert that the balance:

Multiple Accounting and Currency Representations

14 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Primary Balancing Segment

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 15

Division Plant Primary Balancing Segment Values

Ledgers and Subledgers