ORACLE FINANCIALS
VOL - I
Multiple Organizations
• Use a single installation of any Oracle Applications product to support any number of organizations, even if those organizations use different ledgers
• Support flexible organizational models
• Secure access to data so that users can only access relevant information • Access one or more operating units using a single responsibility
Major Features
Multiple Organizations in a Single Installation
You can define multiple organizations and the relationships among them in a single
Installation of Oracle Applications. These organizations can be ledgers, business groups, Legal entities, operating units, or inventory organizations.
Secure Access Data Security
Inventory Organization Security by Responsibility Responsibility Determines Operating Unit
Receive Goods Into Any Inventory Organization Automatic Accounting for Internal Requisitions Multiple Organizations Reporting
Types of Organizations 1 Business Group
The business group represents the highest level in the organization structure, such as the consolidated enterprise, a major Branch, or an operation company. The business group secures human resources information.
For example, when you request a list of employees, you see all employees assigned to the business group of which your organization is a part.
Multiple ledgers can share the same business group if they share the same business group attributes, including HR flexfield structures.
2 LEDGER
Ledgers takes the place of second level in the multi org structure, only based on which the legal entity and operating units are going to be decided on. Also remember it is not mandatory for a ledger to have a Legal entity.
Only based on the definition of ledger, the multi org structure is designed / finalized. Therefore it is very vital to perform the ledger setup keeping in mind that it has a greater
Impact on the multi organization structure to be followed by the client and setup by the Implementation team.
Even though Ledgers takes place second level in the above figure, one can say it is the starting point of Multi org structure, since setting up of a business group or validations / functionalities related to business group are less complicated when compared to other elements in the Multi org structure.
In total there are two types of Ledgers available, they are: Primary Ledger
Secondary ledger
Reporting Currencies (Ledger)
3 Legal Entity
A legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to this type of organization.
You can define legal entities using Legal Entity Configurator or Accounting Setup Manager in General Ledger.
4 Operating Unit
An organization that uses Oracle subledgers, such as Oracle Cash Management, Order
Management, Oracle Payables, Oracle Purchasing, Oracle Receivables, and related products. It may be a sales office, a Branch, or a department.
Operating units are not associated with legal entities.
Operating units are assigned to ledgers and a default legal context.
Information is secured by operating unit for these applications using responsibilities. Each user can access, process, and report on data only for the operating units assigned to the MO: Operating Unit (or) MO: Security Profile option.
The MO: Security Profile provides access to multiple operating units from a single responsibility. You can define operating units from the Define Organization window in Oracle HRMS
or from Accounting Setup Manager in General Ledger. 5 Inventory Organization
An organization for which you track inventory transactions and balances, and/or an Organization that manufactures or distributes products.
Examples include manufacturing plants, warehouses, distribution centers, and sales offices.
The following applications secure information by inventory organization: Oracle Inventory, Bills of Material, Engineering, Work in Process
. To run any of these applications, you must choose an organization that has been classified as an inventory organization.
You can create ledgers using the Accounting Setup Manager in Oracle General Ledger and define organizations using the Define Organization window.
HR Organization
HR organizations represent the basic work structure of any enterprise. They usually represent the functional management, or reporting groups that exist within a business group.
In addition to these internal organizations, you can define other organizations for tax and government reporting purposes, or for third party payments.
Organizations in Oracle Projects
Oracle Projects allows you to define organization hierarchies to reflect your company's organizations structure.
You can add Oracle Projects-specific organization types to the organization hierarchy (for example, projects organizations or Expenditure organizations) to help you manage your project control requirements.
You assign project and expenditure hierarchies to operating units. Asset Organizations
An asset organization is an organization that allows you to perform asset-related activities for a specific Oracle Assets corporate book.
Oracle Assets uses only organizations designated as asset organizations
Information Shared Across Organizations
The following information is global. It must be set up once for the enterprise: • Flexfield definitions
• Customer Header (customer site is at the operating unit level) • Supplier Header (supplier site is at the operating unit level) Setup and Implementation Multi-Org
Setting Up a Multiple Organization Enterprise
Steps to implement the Multiple Organization support feature in Oracle Applications. 1. Develop the Organization Structure
2. Define Accounting Setups
3. Assign Balancing Segment Values by Legal Entity (optional), 4. Define Locations,
5. Define Business Groups (optional), 6. Define Organizations,
7. Define Organization Relationships, 8. Define Responsibilities,
9. Associate Responsibilities with Business Groups,
10. Define Security Profile and Multiple Organizations (MO) Profile Options, 11. Verify Order Management System Parameter Settings,
12. Set Application-Specific Profile Options Specific to Operating Units, 13. Define Inventory Organization Security (optional),
14. Implement the Applications Products,
15. Run the Multiple Organizations Setup Validation Report (recommended), 16. Implement Document Sequencing (optional),
17. Set Conflict Domains (optional),
LEDGER
A Ledger is a container of all accounting related information captured through various other modules. Oracle General Ledger Module owns ledgers.
One has to design the ledger in an appropriate way keeping in mind what information it needs to hold. One can have as many ledgers as they want based on their business requirement and operations point
of view.
A ledger saves the accounting information in an organized way as directed by the conditions specified in the accounting options for that ledger.
Implementer defines the format, rules, restrictions for a particular ledger using different setup screens making the user to only enter the information what is relevant for Oracle General Ledger to process further.
One may collect much additional information in different modules as per their business requirement, whereas those are of least importance, since they are all only data which are not subjected to any further processing by oracle.
A well planned/designed ledger saves a lot of time for the company in processing the data and preparing MIS reports for the management in key decision makings.
One will also be knowing that Business intelligence module does this job of producing excellent reports on the daily operations of company and points out key areas and red flags.
However, business intelligence can be used to best effect, only when the base setups, which are in place, are efficient.
Ledger being the foremost setup for any financial modules in E business Suite, one must understand the power, importance and its usage at later stage in many other areas within e Business suite. Ledger is nothing but a combination of all those components.
Without usage of components, ledger cannot function on its own. The components of a ledger are:
1) Chart of Accounts 2) Calendar
3) Currency
4) Accounting Method
They are also termed as 4 C’s. Chart of Accounts
to be a brainstorming and many levels of discussions between Client and the Implementation team to decide on a structure that best suits the business need.
In short, COA decides on what information needs to be collected for every transaction that is being transacted by the business, considering different parameters and key factors.
Calendar
Calendar presents the period for which the business is carried forward. Calendar here represents Accounting calendar.
One will be deciding on the calendar based on their statutory requirement.
Even though every accounting period is going to have a span of 12 months in it, however there is a greater difference on the start and end date of the accounting period.
Currency
Currency represents the list of currencies in which the customer is having businesses. One needs to define/enable the currencies as per their business requirement; there is no harm in enabling all currencies.
Accounting Method
Every business has to follow an accounting method to record their transactions in order to comply with the legal commitments.
Oracle by default has provided seeded accounting methods for usage, however if the clients business demands for customization of an accounting method or creation of new accounting method as per the statutory regulations, then they can create their own accounting method as well.
All the above-discussed components are mandatory in order to define a primary ledger.
For a secondary ledger, in addition to the above component, one needs to select the method of Data Conversion Level followed.
Primary Ledger
It is mandatory that every accounting operation must have one primary ledger
It acts as a Primary repository, which records all accounting related information related to that particular Primary Ledger. One cannot carry out setups without having primary ledger in place.
Primary ledger replaces the Set of books (Ledger in R12) used in earlier versions prior to Release 12. Secondary Ledger
It is not mandatory to have a secondary ledger.
One can have one or more secondary ledgers based on their business requirement. One can never have a secondary ledger without primary ledger is in place.
Since secondary ledger does not perform any new operation on its own, it only represents the information contain in primary ledger in a different way.
Mostly it is used for satisfying the reporting needs.
It is necessary for one to know when one should have a Secondary ledger.
One needs to maintain accounting records in a way, when there is a difference in any of the
parameters below from the primary ledger: Chart of Accounts, Currency, Calendar, Accounting Method and Ledger processing options.
Reporting Currencies (Ledger)
Reporting currencies are purely a representation of transactions saved in the Primary or Secondary ledger in different currency.
This concept was available in Release 11 in the name of Reporting Set of books (Ledger in R12); it is exactly the same in R12, no change apart from the terminology.
Reporting currencies are maintained at different currency conversion levels.
Even though it is not a separate ledger as such, still it can be considered as a different ledger since it acts as a different container apart from the primary or secondary ledger information. LEDGER TYPE PURPOSE
Primary Ledger
Mandatory for any setup related to financial modules Every transaction of the company will be recorded
Acts as a base repository / container of all accounting information. Secondary Ledger
When Client wants Multiple Accounting Representations
When Client wants to represent the information in a different calendar.
When Client wants to represent the information in a different chart of Accounts. Reporting Currencies
HOW TO DECIDE ON A PERFECT LEDGER STRUCTURE
I would explain the usage of the ledgers with a Business scenario. Business Scenario is:
Company SKR GROUPS is implementing Oracle Financials for their business. The summary of their business operations is as follows:
SKR GROUPS, which is based in India, is having their business operation in three countries: 1) Branch I - India
2) Branch II - Australia 3) Branch III - France
And the accounting and reporting requirements are:
Branch Accounting Method Chart of Accounts Accounting Period Branch I Accrual As per Indian Statute April to March
Branch II Cash As per Australia Statute January to December Branch III Accrual As per France Statute October to September
Please advice on the ideal Ledger structure to be designed for the company SKR GROUPS? Now from the above lets us see how many primary ledgers can be created?
One cannot use the same primary ledger if one of its components is different. Branch Chart of Accounts Currency Calendar Accounting Method Branch I Indian Statute INR Apr – Mar Accrual
Branch II Australia Statute AUD Jan – Dec Cash Branch III France Statute EUR Oct - Sep Accrual
From the above table, it is clear that none of the Branches have all 4 components as similar; therefore we need to have 3 Primary ledgers defined for it.
Now apart from that, we need to think of the following practical scenario as well,
to INDIA at a later stage, therefore it must also follow the rules of accounting and statutory regulations in India, so as Branch III.
Therefore, Branch II – Should have a secondary ledger, which will represent the transactions as per the Indian Statute.
Branch III – Should have a secondary ledger, which will represent the transactions as per the Indian Statute. However it is not necessary for Branch I to have secondary ledgers, since the company is based in
INDIA, therefore it need not have multiple accounting representations.
If the client insists on it, we can have 2 secondary ledgers for Branch I, to comply with Australian and France statute.
Now the Branches situated in France and Australia, must be reporting to the company in INDIA on a daily basis, for which they need to convert their business transactions values
in to Indian currencies and then report it to the management.
For performing this operation, we require two Reporting currencies as well.
As discussed earlier, reporting currencies are part of primary ledger setup. Therefore Australia and France primary ledger should have defined INR as its Reporting currencies.
To sum up, the ideal ledger structure would be as follows:
Branch Primary Ledger Secondary Ledger Reporting Currencies
Branch I 1 Not Necessary Not Necessary
Branch II 1 1 1
Branch III 1 1 1
TOTAL 3 2 2
Also there can be one more primary ledger created to consolidate the data between Branch I, II and III,
QUESTION AND ANSWER SECTION
One can have a ledger with no legal entity as per their business requirement. It is not mandatory that every ledger must have a legal entity attached to it. There could be ledgers, which have been created for
consolidation purposes alone.
2. Can there be a Secondary ledger without a Primary ledger? No, it cannot be.
3. Can we have one secondary ledger associated with more than one primary ledger? No, it is not possible.
4. Can we have more than one secondary ledger for a primary ledger?
Yes, you can have one or more secondary ledgers also there is no restriction imposed anywhere on number of primary ledgers one can create.
5. Is it possible to convert a Primary Ledger to Secondary Ledger or vice versa? No, not possible.
Data Access set
Data Access Set is a new feature in Release 12, which is owned by General Ledger. It helps in providing Role Based Access Control to the users.
Every user has access to the data through Responsibilities, these Data Access Sets controls the behavior of a Responsibility when the user tries to access the ledger which is the repository of all accounting related information.
It can control the level of access to be provided and on what information the access can be restricted for a given ledger and responsibility.
We will see about it in more detail in further slides.
It can provide Read only, Read and Write access to an Ledger
It can restrict access to MSV (Management Segment Values) and BSV (Balancing Segment Values) The ledgers and Ledger Sets which are assigned to a Data Access Set must share the same Chart of
Accounts, Calendar and Period Type.
General Ledger automatically creates a Data Access Set whenever a Ledger and/or Ledger Set are created.
Following are the three types of Data Access Sets, Full Ledger
Management Segment Value FULL LEDGER
As the name suggests all changes / restrictions defined under this type of Data Access Set will apply to whole of a Ledger or a Ledger Set.
Either you can have a Read and Write privilege to a Ledger or Read only privilege to a Ledger. For example, You have the Auditors visiting your premises who requires
access to all accounting information, instead of using system administrator to create a new
responsibility with lots of menu exclusions, you can just have a responsibility with the Data Access Set, assigned as READ ONLY. So that the auditors will only have access to view the data and not to edit it (Intentionally or unintentionally!)
BALANCING SEGMENT VALUE (BSV)
Instead of providing access to the whole ledger, if you wanted to provide access only to particular Balancing segment value combinations in a ledger, you can do so.
MANAGEMENT SEGMENT VALUE (BSV) Instead of providing access to the whole ledger, if you wanted to provide access only to particular Management segment value
combinations in a ledger, you can do so.
Management Segment is a segment which has the Management Segment Qualifier attached. Values belonging to that segment are termed as Management Segment Values.
Advantages
Role Based Access Control Security on Data Access
Simplified Setups to create Data Access Security
It does not override the security rules and Cross validation rules Limitations
A Responsibility can have only one Data Access Set
One can have ledgers sharing the same chart of accounts and calendar alone in the single Data Access Set.
In case of BSV or MSV type Data Access Sets, if you select the check box for ALL that does not include all BSV or MSV values.
So many parameters need to be considered before defining it, since it may clash with other setups at General Ledger level resulting in errors.
Following items should have been already defined before creating a Data Access Set, they are: Chart of Accounts
Calendar and Period Type
Ledgers should be defined using the above Chart of Accounts and alendar/period Type If you want to use Management Segment Value type Data Access Set, you must assign
Management segment qualifier to one of your segments well in advance Information required for setup
Following information must be collected before proceeding with the setups: Name to be provided for Data Access Set
Description for the Data Access Set Chart of Accounts to be Used Calendar / Period Type to be used Access Set Type required
Ledger or Ledger Set Name
In case of BSV or MSV access set types, the list of segment values to be defined.
Which value requires Read only access and which value requires Read and Write access. Questions & Answers
6. Which type of Data Access Set is advisable for usage?
The Full Ledger access set type provides better system performance than the Balancing Segment Value or Management Segment Value access set type.
7. Can we have a Data Access Set without defining what type it is? You must specify one of the three types for each data access set. 8. Can one change the type of Data Access Set after defining?
Once defined, you cannot alter the type. You can only add or delete ledgers/ledger sets and segment values specified in the data access set
9. When one should be creating Data Access Set.
When you want the user to be restricted based on the BSV or MSV, you need to create a Data Access Set.
If you are planning to grant full access to ledger, then you are not required to create a Data Access Set,
since system automatically creates a Data access set whenever a Ledger or Ledger Set is created, with the type Full ledger having read and write access.
You can make use of that. How can I find or trace out the system generated Data Access Set.
The system-generated data access set for a ledger/ledger set uses the same name as the ledger/ledger set.
10. Does my Data Access Set override the restrictions provided by Security Rules and Cross Validation Rules?
No, Data Access set does not override Security rules or Cross validation rules.
11. What precaution needs to be taken care for defining Data Access Set with Balancing Segment Values? One must make sure that the BSV values used in the Data access sets must correspond to the BSV values assigned to Legal Entity, using Accounting Setup Manager.
12. What precaution needs to be taken care for defining Data Access Set with Management Segment Values?
Make sure that you do not restrict read and write access to segment values which are used in default accounts, such as Retained Earnings Account etc...
13. Can we have multiple Data Access Sets for a Responsibility?
We can define multiple Data Access Sets for a ledger; however we can assign only one Data Access set per responsibility.
LEDGER SET
In release 12, the concept of Set of books (Ledger in R12) has been enhanced and termed as Ledgers.
Ledgers are of different types, I.e. Primary and Secondary ledgers.
To make working with ledgers easier, the new feature called LEDGER SET has been introduced. As the name suggests it is nothing but a Set or Group of ledgers.
It helps the user in saving time on repetitive tasks performed on ledgers. FEATURES / PURPOSE
A Ledger Set can contain any number of ledgers, there is no specific ceiling proposed so far. A Ledger Set can include another ledger set within.
A Ledger Set can only have those ledgers which are sharing the same: Chart of Accounts
Calendar/Period Type
A Ledger Set can have Primary, Secondary and Reporting currencies attached to it, but they need to have the same Chart of Accounts and Calendar/Period Type combination.
A single ledger can be made use of in Multiple Ledger Sets. ADVANTAGES
One can run concurrent programs or processes for multiple ledgers easily.
Opening and Closing periods
Generating recurring journals, etc
One can generate reports for multiple ledgers in no time.
Reports relating to consolidation
Financial Statement Generator Reports, etc
In case of a ledger set, which contains more than one ledger/ledger set in it, user can optionally set a default ledger for effective usage.
Ledger set can be secured by having a Definition Access Set. LIMITATIONS
You cannot add ledgers that do not share the same chart of accounts and Calendar/Period Type to a Ledger Set.
You cannot have a reporting currency which is of type ‘Balance Level’ in the Ledger set, even if it shares the same Chart of Accounts and Calendar/Period Type.
PREREQUISITES OF SETUP Chart of Accounts
One needs to define a chart of accounts structure in place. Period Type
Period types needs to be defined, which in turn will be used by Accounting Calendar
Calendar
One has to define an Accounting Calendar Existing Ledgers or Ledger Sets
One must have few pre defined ledgers or ledger sets in place. The following details are required in order to define a ledger set.
Ledger Set Short Name Description Chart of Accounts
Calendar Period Type Default Ledger Ledger/Ledger Set
Questions & Answers
14. Can a Ledger Set be created without any ledgers in it
No you cannot create a ledger set without ledgers; you must have at least one ledger or ledger set assigned.
15. Can a Ledger Set be deleted after defining
No one cannot delete a ledger set which has been created. 16. Can one modify the Ledger Set which is already defined?
Yes, you can add or remove Ledgers / Ledger Sets
17. After setting up the Ledger Set, is there any additional setup required before using the same? You must assign the Ledger Set to the profile option GL: Data Access Set.
Oracle General Ledger automatically creates a Data Access Set, whenever a Ledger or Ledger Set is created.
SUBLEDGER ACCOUNTING
Accounting system will have a number of subsidiary ledgers (called subledgers) for items such as cash, accounts receivable, accounts payable, inventory, purchasing likewise.
All the entries that are entered (called posted or booked) to these subledgers will transact through the general ledger account.
For example, when a credit sale posted in the account receivable subledger turns into cash due to a payment, the transaction will be posted to the general ledger and the two (cash and accounts receivable) subledgers as well.
There are instances when items will go directly to the general ledger without any subledger. These items will be linked to your balance sheet but not to your profit and loss statement.
The Concept is more or less addressed same in newly R12 SLA accounting, therefore you should note: A transactional application that generates accounting impact.
Used to store detailed information not needed for a general ledger
Subledgers post summarized activity to a general ledger periodically to maintain centralized account balances for the company
All accounting performed before transfer to the GL and this is achieved by user setup who can do by definable accounting rules.
At the data level, it’s a big change for all the subledgers, though there is a first generation changes we have noticed sometime when 11i Payables where concept of Accounting Events introduced first time and accounting performed at subledger level first before moving into GL.
The same idea has been incorporated in new sub ledger accounting model , indeed a was a real need because of some uneven functionality likes:
1. Inconsistencies in Accounting Generation like Summary vs. Detail 2. Direct to General Ledger vs. Open Interface
3. Inconsistent Drilldown from General Ledger
Also it has been seen inconsistent Mechanisms for controlling Accounting as certain options has been used in existing version:
1. flex biller
2. Account Generator 3. Automatic Offsets
What is sub ledger mean for a non finance person?
A new transactional application that generates accounting impact Used to store detailed information not needed for a general ledger
Sub ledgers post summarized activity to a general ledger periodically to maintain centralized account balances for the company
Why SLA and what does it do?
Oracle Sub Ledger accounting (SLA) is accounting hub in Oracle Application Release 12 (R12). It is used to derive all attributes required to account a transaction in Oracle General Ledger. In R12, SLA is used to derive the very basic accounting attributes like entered amount,
accounted amount, Date, Currency code etc and the complex attributes like Ledger, Code Combination ID, Periods etc.
After deriving these accounting attributes the transactions are then interfaced to GL from SLA. Thus in R12 no sub ledgers (AP, PO, PA etc) interfaces the transactions directly to GL, but all the
transactions are interfaced to GL in following 2 steps: 1. Sub ledgers interface the data to SLA.
2. SLA derives the accounting information and interfaces the data to GL.
SLA gives the flexibility to manage the entire accounting rule at one place, which acts as a single source of truth for GL.
Note: There is no separate responsibility to access SLA setup or the view the transactions generated by SLA. Rather we can access SLA setup and review accounted transactions with
extended menus attached to each sub ledger module
How does SLA works?
1. Register sub ledger transactions in SLA.
After validating / approving / costing the transaction in the respective module, the sub ledger calls SLA API to create a reference of the validated transaction in SLA.
This reference is known as EVENT. Events are created by calling the public API “xla_events_pub_pkg.create_events” provided by SLA.
It is up to the sub ledgers on how to call the API.
For example Oracle Projects call this API from concurrent program “PRC: Generate Cost Accounting Events” and Oracle Payables calls this API while user creates accounting for the Invoice.
While calling xla_events_pub_pkg.create_events, oracle passes a unique id and event class (Will discuss in next step).
Unique ID can be an invoice id or a po_distribution id or an expenditure_item_id etc.
As soon as the sub ledger generates event in SLA, SLA returns unique event_id.
This event_id will then act as a reference to all the accounting entries generated by the SLA.
Once event is successfully created in SLA, means that the transaction is registered in SLA for accounting.
Taking the example of Oracle Projects in 11i where after costing the transaction user need to run the ‘PRC: Interface Cost to General Ledger’ followed by ‘Journal Import’ followed by ‘PRC: Tieback process’.
But in R12 user only need to run “PRC: Generate Cost Accounting Events” which will register events in SLA and thereafter SLA will take care of accounting the transaction and interfacing it to GL.
There is no tieback process in R12, as there is one to one reference of event id between SLA and sub ledger tables.2. How does SLA understand whether unique id is invoice id or a po_distribution id or an expenditure_item_id as SLA uses same table to store all the identifier?
Above we discussed that while creating the event we also need to pass event class. This event class is used to distinguish between the types of transaction passed for processing. To understand this better we will go thru the seeded oracle informationMONTHEND/YEAR END CLOSE PROCESS
I) ORACLE PAYABLES
1. Complete All Transactions for the Period Being Closed
2. Run the Payables AutoApproval Process for All Invoices / Invoice Batches 3. Review & Resolve Amounts to Post to the General Ledger
4. Reconcile Payments to Bank Statement Activity for the Period
5. Transfer All Approved Invoices Payments, Reconciled Payments to the General Ledger 6. Review the Payables to General Ledger Posting Process After Completion
7. Submit the Unaccounted Transactions Sweep Program 8. Close the Current Oracle Payables Period
9. Accrue Uninvoiced Receipts
10. Reconcile Oracle Payables Activity for the Period 11. Run Mass Additions Transfer to Oracle Assets 12. Open the Next Payables Period
13. Run Reports for Tax Reporting Purposes (Optional) 14. Run the Key Indicators Report (Optional)
15. Purge Transactions (Optional)
II) Purchasing
1. Complete All Transactions for the Period Being Closed 2. Review the Current and Future Commitments (Optional)
3. Review the Outstanding and Overdue Purchase Orders (Optional) 4. Follow up Receipts-Check with Suppliers
5. Identify and Review Un-invoiced Receipts (Period End Accruals) 6. Follow Up Outstanding Invoices
7. Complete the Oracle Payables- Period End Process 8. Run Receipt Accruals - Period End Process
9. Reconcile Accounts - Perpetual Accruals
10. Perform Year End Encumbrance Processing. (Optional) 11. Close the Current Purchasing Period.
12. Open the Next Purchasing Period.
13. Run Standard Period End Reports (Optional) III) Inventory/WIP
1. Complete All Transactions for the Period Being Closed. 2. Check Inventory and Work In Process Transaction Interfaces. 3. Check Oracle Order Management Transaction Process. 4. Review Inventory Transactions.
5. Balance the Perpetual Inventory. 6. Validate Work In Process Inventory. 7. Transfer Summary or Detail Transactions
8. Close the Current Oracle Payables and Oracle Purchasing Periods 9. Close the Current Inventory Period
10. Open the Next Inventory Period
11. Run Standard Period End Reports (Optional) IV) Order Management
1. Complete All Transactions for the Period Being Closed
2. Ensure all Interfaces are Completed for the Period (Optional) 3. Review Open Orders and Check the Workflow Status
4. Review Held Orders 5. Review Discounts 6. Review Backorders
7. Review and Correct Order Exceptions 8. Reconcile to Inventory
9. Reconcile to Receivables (Optional) 10. Run Standard Period End Reports V) Receivables
1. Complete All Transactions for the Period Being Closed 2. Reconcile Transaction Activity for the Period
3. Reconcile Outstanding Customer Balances 4. Review the Unapplied Receipts Register 5. Reconcile receipts.
6. Reconcile Receipts to Bank Statement Activity for the Period 7. Post to the General Ledger
8. Reconcile the General Ledger Transfer Process 9. Reconcile the Journal Import Process
11. Print Statements (Optional)
12. Print Dunning (Reminder) Letters (Optional) 13. Close the Current Oracle Receivables Period 14. Reconcile Posted Journal Entries
15. Review Unposted Items Report
16. Open the Next Oracle Receivables Period
17. Run Reports for Tax Reporting Purposes (Optional) 18. Run Archive and Purge programs (Optional)
VI) Assets
1. Complete All Transactions for the Period Being Closed 2. Assign All Assets to Distribution Lines
3. Run Calculate Gains and Losses (Optional) 4. Run Depreciation
5. Create Journal Entries
6. Rollback Depreciation and/or Rollback Journal Entries (Optional) 7. Create Deferred Depreciation Journal Entries (Optional)
8. Depreciation Projections(Optional) 9. Review and Post Journal Entries
10. Reconcile Oracle Assets to Oracle General Ledger Using Reports. 11. Run Responsibility Reports (Optional)
12. Archive and Purge Transactions (Optional) VII) Project Accounting
1. Change the Current Oracle Projects Period Status from Open to Pending Close 2. Open the Next Oracle Projects Period
3. Complete All Maintenance Activities 4. Run Maintenance Processes
5. Complete All Transaction Entry for the Period Being Closed 6. Run the Final Cost Distribution Processes
7. Interface Transactions to Other Applications (AP, GL, FA) 8. Generate Draft Revenue for All Projects
9. Generate Invoices
10. Run Final Project Costing and Revenue Management Reports 11. Transfer Invoices to Oracle Receivables
12. Interface Revenue to General ledger (Project Billing Only) 13. Run Period Close Exception and Tieback Reports
14. Change the Current Period Oracle Projects Status from Pending Close to Closed 15. Advance the PA Reporting Period (Optional)
16. Update Project Summary Amounts
17. Restore Access to User Maintenance Activities
18. Permanently Close the Oracle Projects Period (Optional)
19. Reconcile Cost Distribution Lines with General Ledger (Optional) VIII) Cash Management
1. Load Bank Statements 2. Reconcile Bank Statements
3. Create Miscellaneous Transactions
4. Review Auto Reconciliation Execution Report
5. Resolve Exceptions on the Auto Reconciliation Execution Report 6. Run Bank Statement Detail Report
7. Run Transactions Available for Reconciliation Report 8. Resolve Un-reconciled Statement Lines
9. Run the GL Reconciliation Report
10. Run the Account Analysis Report for the General Ledger Cash Account 11. Review the Account Analysis Report
12. Correct any Invalid Entries to the General Ledger Cash Account (Optional) 13. Perform the Bank Reconciliation
IX) General Ledger
1. Ensure the Next Accounting Period Status is Set to Future Entry 2. Complete Oracle Sub-ledger Interfaces to Oracle General Ledger
3. Upload Journals from ADI (Applications Desktop Integrator) to Oracle General Ledger 4. Complete Non-Oracle Sub-ledger Interfaces to Oracle General Ledger (Optional) 5. Generate Reversal Journals (Optional)
6. Generate Recurring Journals (Optional) 7. Generate Mass Allocation Journals (Optional)
8. Review and Verify Journal Details of Unposted Journal Entries 9. Post All Journal Batches
10. Run General Ledger Trial Balances and Preliminary Financial Statement Generator Reports (FSGs) 11. Revalue Balances (Optional)
12. Translate Balances (Optional)
13. Consolidate Sets of Books (Optional)
14. Review and Correct Balances (Perform Reconciliations) 15. Enter Adjustments and / or Accruals and Post
16. Perform Final Adjustments
17. Close the Current Oracle General Ledger Period 18. Open the Next Oracle General Ledger Period
19. Run Financial Reports for the Closed Period
20. Run Reports for Tax Reporting Purposes (Optional) 21. Perform Encumbrance Year End Procedures (Optional)
Account Payables
It is an ERP solution to effectively manage creditors. The main task is to pay the supplier for the goods &services. It captures information with respect to purchase invoice transaction & payments to supplier. The task of effective control of payables can be achieved using the following tools of management.
1. Timely recording of invoices & suppliers liability.
2. Effective payments to suppliers through invoices validation a approval process & exercising hold whenever needed & availing maximum credit wherever possible.
3. Paying on the due date to avoid overdue interest. You can pay early as per vendor agreement to available maximum discount & the proper mode for payment.
4. It is a subsidiary ledger to GL. It is integrated to other modules like: GL, Assets, Purchasing, Cash Management, Inventory, Projects, Human Resources, Receivables, Invoice Gateways (Oracle Ecommerce), Internet Express, Property Management.
Business Flow Business flow of payables is as under,
1. Invoice Recording: Based on purchasing order suppliers will provide goods & services invoices. In payables invoices are recorded based on invoices received, purchase order, receipt of material & services.
2. Invoice Approval Process: Dunning approval process, placed to delay payment for any variation in purchase order in invoices/receipt of materials.
3. Invoice Accounting: The validated & approval invoices will be accounted.
4. Debit memo issue/Credit memo/receipts/Recording/Accounting: For any variation in purchase order, invoices/receipts/debit memo/credit memo will be issued, which will be recorded & accounted.
5. Advance Payment approval process: Any advance payment to suppliers requesting approval before payment.
6. Payments of Approval invoices: Approval invoices will be paid by using payment documents. It can be single/multiple payments.
7. Payments Accounting: Once payments are a affected, they will be accounted.
8. Refund receipts/record/accounting: Any excess payment will be refunded by the supplier which will be recorded & Accounted.
9. Review of supplier’s liability Outstanding: Done periodically. 10. Transfer periodically to General Ledger.
APPLICATION FLOW
1. Assign General ledger Set of books (Ledger in R12) (Ledger in R12). 2. Define lookups (purchasing, payables, Employee).
3. Define payment terms.
4. Define Distribution set: Full/Skeleton
5. Set of defaults &controls in financial & payable options. 6. Create supplier & supplier site.
7. Standard invoices/credit memo/Mixed invoice entry/Employee expense invoices generation, Approval, Accounting.
8. Prepayment invoices generation/Debit memo issue recording, approval, accounting process. 9. Define payable formats, Bank account, payable documents.
10. Issues of payments, Approval Accounting. 11. Recording of refunds & accounting.
12. Transfer approved invoice transactions & payment transaction to GL. Information Flow
Data can be predefined in following levels shown in ascending order of hierarchy. Financial options
Payables options
Supplier site level
Invoice leader level
Financial Options:
Certain values can be predefined & control options enabled. Values defined at this level will act as default values access various modules like payables, purchasing & asset modules. These values & options cascade documents to next lower level.
Payable Option:
Some additional values & options can be defined. The values are
defined at payables options level act as default exclusively for payables module only. The values define at this level will default to every new supplier being defined.
Supplier level:
Values & options that defaulted from payables options can either be accepted/overwritten with new values & options. The values options defined at this level will default to site being defined at the site level.
Supplier Site level:
Values & options can either be accepted/overwritten if required; It will default to Invoice header level. Invoices Header level:
Values & options defaulted from supplier site level can be accepted /overwritten. It will default to the following 2 level.
Distribution lines level
Schedule payment line level Accepted/Overwritten
Schedule payment line level
Transactions
Purchase Invoice Payments
This transaction will be in functional or foreign currency. Purchase Invoice Transactions:
Standard invoices
Credit Memo
Debit Memo
Mixed invoice
Po default Standard invoice
Quick match standard invoice
Prepayment invoice
Expense report invoice
Withholding tax invoice
Interest invoice Payment Transaction: Manual payment Quick payment Refund Basic Setups
1. Choose Set of books (Ledger in R12)(Ledger in r12) 2. Define financial options
3. Define payable options 4. Open period in payables 5. Define payment terms 6. Define lookups
7. Define discount sets
9. Define bank formats
10. Define bank account& payable document. Financial options
After choosing GL Set of books (Ledger in R12), define financial options which have following regions. Accounting Supplier – Entry Supplier – payables Supplier – Purchasing Encumbrance Tax Human resources
Account payable, purchasing, FA module share these options. Information flow starts from financial option. It defines the defaulting accounting flexfields for Oracle Payables financial transactions which create oracle GL journal entities.
Navigation:
Setup Options Financials Accounting tab:
Future tab:
Number of future periods that we may use in our Set of books (Ledger in R12). In payables there is various period statuses
Never open
Future
Open
Close
Permanently close period. Never Open: Cannot enter transaction at all
Future: It can be entered but they cannot be processed/ posted in GL. Open: Enter post & transfer to GL.
Permanently Closed: It will work for all close period. In close period we can toggle to open period but here u cannot.
GL Account:
Liability – Default liable account for all new suppliers created this value can be overridden during supplier creation.
Prepayment: Default account for each line entered in prepayment type invoice
Future dated payment: This default to all new supplier & bank account for all future data payment. Discount taken: Discount taken on payment
PO rate variance gain/loss: Rate variance when we match invoice to purchasing order/receipts. Expense clearing: payments through credit card, oracle internal expense.
Misc: Misc charges when invoices are imposed through XML gateway (or) high supplier port Supplier – Entry tab:
RFQ only site: If we enable this all suppliers will be defined as only RFQ only site. For these sites no purchase order can be generated.
Hold unmatched invoices: To place a hold on invoice during invoice validation when it is not matched to either purchase order/receipts until the hold is released invoice remain unpaid.
Invoice match option: Purchase order/receipts. It indicates how to match invoices.
Supplier Number Entry: Manually/Automatically. It can be changed at any time. But before changing make sure that the next available now for automatic enter is larger than largest no: already recorded.
Type: Alphanumeric/Numeric
It can be changed at any time, however changing from a no. numeric only is allowed only if all current suppliers no are numeric.
Next automatic no: Top value to be entered at the time of financial option setup for generating unique sequential supplier no.
Supplier – Payables tab:
Payment terms: Immediate/No of days (used to car due dates, discount dates for each invoice entered in invoice workbench.
Payment method: Check/clearing/Electronic/wire recording payments to internal/departmental/inter cost centre.. etc
Electronic: Information about supplier payment is captured by magnetic media which is delivered to a bank through electronic data interchange gateway. The banker uses this information to electronically to the fundamentals from our account to supplier account.
Check: Written order to bank to pay a specific sum of money on demand to a specific person/order.
Wire: To telegraphic is used to manually record. Receipt acceptance days: It refers to grace days to avoid into being added to the invoices for delayed payments. If we enable an option to recalculate schedule payments at another level, payable option approval recalculates the invoices due date based on this value also.
Always take disc: Payables always take disc from my supplier no matter when to make payments.
Pay alone: We can pay each invoice by each payable document. If we don’t enable, we can combine payments of several invoices & pay by single payables documents.
Supplier – Purchasing tab:
Options defined at this region were default for purchase region from the supplier in supplier window. The inventory organization field is applicable to purchasing module.
Ship to location:
Inventory Org : For purchase module transaction use.
Ship via : Default mode of the operation of freight carrier which will duplicate usually to the supplier like road, air, rail...
Freight on board (FoB): Specify the term at which the vendor liability classes Freight items: Specifying freight terms payments methods
Whether it is prepaid /paid by vendor or pay & collect it from supplier/no freight terms.
Encumbrance: It means year making/reserving funds from Out of a budget for a specific use. Encumbrance in application is defined in this region. Controls specified here will be used for payables & purchasing In
Purchasing modules, it is used for requisition &purchase order. In payables, encumbrance for unmatched invoices & also for variance, it matches invoices & purchase order.
Use requisition encumbrance: If you enable this you got to ‘Choose’ the encumbrance type. And the encumbrance type for the requisition is ‘commitment’.
Reserve @ completion: If it is enabled, encumbrance can be created by their preparing requisition, otherwise only the approvers of requisition can create encumbrance.
Use PO encumbrance: You got to choose its encumbrance type, PO& the normally obligation Encumbrance for PO journal for this purchase definition at this level.
Invoice encumbrance level: Encumbrance type to be used for creating encumbrance journal for invoice. TAX:
Default tax code:
It defaults to invoice tax code option in the supplier window. If you choose a tax code for which we have defined different tax for different effective dates, payables will automatically use the tax applicable for each invoices based on invoice date.
VAT Registration: Member state: Location of outcomes to find out whether the company is located in the member state of the E.U.
VAT registration no: Enable recoverable tax:flatRecoverable /Non recoverable
Flat tax type discount as recoverable for reporting, purpose split ‘taxes into’ recoverable& non recoverable lines, automatically calculate tax &profit rate it back into GL account of the taxable distribution. Default recovery rate:
Specify a rate that will default to tax recovery rules & tax codes which we define. Calculate rules:
Rounding rule: No round tax amount in payables & purchase. Up/down/nearest
Precision: Enter a one digit whole no: to indicate which decimal place you want to round automatically to calculate tax amounts in payables & purchase.
Minimum Account table unit:
The smallest monetary unit you want to round the tax amount. Human resources:
Define your company as a single business group/there is several major Branches/operating unit each may be defined as a business group. While defining employer, specifying the business group to which they belong.
Expense reimbursement address: Home/office
The default employee address to which the reimbursement object is to be specified. The value entered here defaults to new employees you create in the persons window when you can optionally over side it.
Use approval hierarchies: On HR you define positions & their hierarchies. The job of individual within an organization.
For e.g.: Account clerkjob
Enable it to define approval pass for documents within purchasing. Employee number: Method Manual/Automatic
Payable Options
It will simplify supplier entry, automatic payment processing, invoice entry. Most of the options can be updated for future transaction any time. There are specification payables modules only. There are 14 tabs /region. 1. Accounting methods, 2. Transaction to GL 3. Payment accounting 4. Currency 5. Supplier 6. invoice 7. matching 8. interest 9. Expense report 10. Payment 11. Invoice tax 12. Withholding tax 13. Tax defaults & rules 14. Reports
Setupoptionspayables
In payable options window we can define control options & default used throughout payables.
Secondary—cash Accrual/Cash basis method of Accounting:
Accrual accounting is mandatory in certain countries. Secondary accrual accounting. Set of books (Ledger in R12) is maintained in few countries in Europe that too on cash basis in order to meet sales tax reporting requisition.
Here sales tax output is by deducting the input tax i.e. tax on supplier invoices from output tax i.e. tax On customer invoices. Input tax can be set of against opening tax only on efficiency an accruing them in the books of account as evidence of payments. It will be captured in separate books maintained on a cash basis & field along with the return.
So the transaction in payables can be journalized in to GL Set of Books (Ledger in R12) based on two type of accounting methods.
For the primary accounting method based on accrual basis, the GL SET OF BOOKS (LEDGER IN R12) will automatically default from the SET OF BOOKS (LEDGER IN R12) .
Secondary SET OF BOOKS (LEDGER IN R12) can be optionally maintained internally even if is not mandatory. But you have to specify the basis on how to journalize the transaction. The options available are
accrual/cash/none. Automatic offset method:
To create multiple liability lines in payable in such a way that all balancing segments are equalized in terms of debits. Credits automatically during invoice validations process.
None/Balancing/Accounting Unbalanced journal:
Invoice Transaction Unbalanced Journal
Dr Cr
C1 100 6420 1000
C2 200 6420 2000
C1 000 2210 3000
C1 100 6420 1000 C2 200 6420 2000 C1 000 2210 1000 C2 000 2210 2000 Account C1 100 6420 1000 C2 200 6420 2000 C1 100 2210 1000 C2 200 2210 2000
The offset entries are created only at the terms of invoice validation process. These types of offset entries are created for prepayment entities to in case of company want to prevent prepayment application. Accordingly for balancing segments – enables the relevant check box.
AP Payable option Transaction to GL:
How payables transacts to a GL interface.
In detail
Summarize by accounting date
Summarize by accounting period. In detail
As many accounting lines (as number of lines in each invoice) transactions are transfered to GL. Summarize by accounting date: Lines summarized account to account date
Summarize by accounting period: It will create the least no of lines because it will sum up a pair accounting for a part period &there one line would be generated.
TR. Reporting books:
Applicable only if we have a reporting SET OF BOOKS (LEDGER IN R12) when we run payables to GL for our primary SET OF BOOKS (LEDGER IN R12) , TR also takes place in repository SET OF BOOKS (LEDGER IN R12) without any explicit program for the same.
Submit journal import:
If you don’t enable transaction when Transfer to GL by the program Transfer to GL will not import it to GL, it will be in the interface. In GL we have to run the program to import it from interface if enabled, the latter program will automatically run.
Allow override at program submission:
Above control if you want to override at the program submission enable it, if you enable it at the time of submitting payable Transfer to GL in the parameters you can override this submission whether to submit journal import/not & change from Transfer in details to summarize by accounting date or period.
Payment Accounting Accounting for payment:
When payment document is issued/ when payment document class.
When both are enabled, it gives the functionality to allow reconciliation accounting .Payment entries that will be created when payment is issued.
Regular payment: AP liability accounting or to cash clearing account.
Future dated payment: On the date of issue AP liability account or to future dated payment account On the date of maturity: Future dated payment account
To cash clearing account. They are unreconciled payment entries once payment is cleared, cash clearing account can be converted to cash account after reconciliation in Cash management module.
Accounting for gain/loss: Foreign currency transaction account for gain /loss when accrual/cash basis is used. Cash basis: Account for currency gain/loss but payment time & payment clearing date. For future dated payment, it will account for payment issued date & payment maturity date & payment maturity date & payment clearing date.
Accrual basis: Between the invoice date & payment issue date. Future dated payment:
Invoice date
Pay issues date
Pay clearing date. Calculate gain/loss:
For each invoice
For total payment
Use future dated payment account:
From payment document
From supplier site Currency
Use multiple currencies
Require exchange rate entry – daily rate /periodic rate
Calculate user exchange rate : If invoice/payment is entered in a currency other than functional currency or an associated fixed rate currency I.e. euro derived currency.
Exchange rate type:
Corporate A standard make rate by senior management for use throughout the organization Reporting:
Spot – Daily exchange rate that is a quoted market rate
User - Used to manually enter in own exchange Rate during invoice entry at payment time:
If functional currency amount is known for any foreign currency invoices, then one can enable this option for the system to calculate the user exchange rate. It is used mainly to import invoices through payables open interfaces.
GL ACCOUNT Realized Gain 6842
Loss 6844 Rounding 6826
Invoices tolerance: To allow variance between invoice, purchase order receipt & tax information, you can specify here the percentage based/amount based tolerance for suppliers.
Pay Group: Normally defined in purchasing lookup. This is to assign pay group for any new supplier for payment in batches& reporting purposes (standard/employee pay group)
Invoice currency: USD Terms date basis:
System/goods receive/invoice/invoice received (It decides the date based on due date basis/discount date basis & prepare the schedule for payment).
Invoice: Terms date will be decided as invoice date & account due date will be calculate. Invoice received: The date on which we receive the invoice.
Pay date basis: Discount/due – override @ supplier & supplier site .If invoices are to be paid by exercising discount option, then the schedule payment is as per the due rate. If they are paid based on due date, then system schedule payment as per due date.
Book charge bearer: Payment of book charges. Internal/supplier/Negotiation: Supplier/Standard
Supplier Negotiation: Supplier will bear the book charges at negotiated rate. Supplier standard: Supplier will bear book charges at standard rate.
Tax reporting: Combined filling program.
A use pay at region – supplier site will default as tax region same will be default in the distribution lines level.
Income tax region: Only when both check boxes are enabled overrides at invoice discount level. Invoice (tab):
Use invoice approval workflow: If disabled, Can’t submit invoice for approval to higher hierarchies.
Workflow process: Approve manually at the user level can forcefully approve even if the approval workflow process is not complete.
Requesting validation before approval:
Allow adjustment to paid invoices:
Recalculate schedule payment:
Automatically create fright discount: If you enable that check box, it uses the freight distribution for the invoice from the next default option freight account. Freight discount will appear as a single line in invoice.
Confirm date as invoice no: When invoice no is not entered, then date will become the invoice no, In such situation a caution in popup window will come.
Allow online validation: Users can select invoices for validation in the invoice workbench to the invoice action window/those validation buttons is invoice batches.
Allow document category override: For invoices besides recording invoice no in case us to wants a special sequence numbering process for entity of invoice in invoice workbench.
They can adopt a document category sequence numbering you have to enable this checkbox & can use add category sequential numbering.
GL date basis: Basis on which invoice will have the default accounting data.
Invoice date
System
Goods record/invoice date
Goods record/system date Prepayment:
Prepayment invoice - Immediate for advance payment. Payment terms: Default payment terms for all
Settlement date: No of days to be adapted to the system date for calculating the date which prepayment can be settled/ applied against any invoices like the prepayment will not be available for application/settlement against any invoices.
Bill prepayment accounts when matching:
Disabled - prepaid account code combination i.e. defined in the supplier site would be defaulted for the prepayment line discount.
Enabled- When matching which PO/Receipts, the prepayment item discount lines will be built taking into account, the natural account segment from the supplier site prepayment account & other segment from the responsible purchase order discount lines/receipt discount lines.
Matching
Allow final matching:
Final match of an invoice to the PO is done by enabling it. Here for any subsequent invoice matched to PO after final match, the system hold will be placed for want of PO equivalent & this hold cannot be released manually.
Allow discount level matching:
Enable: Matching of invoice to PO discount matching of 1/more PO discount with an invoice is possible here disabled. Payable will allow only matching an invoice to a full PO shipment.
Allow matching account overview:
Enable- You can override an account for invoice discount created by matching to a PO matched invoice discount account is overridden in invoice workbench/any imported invoices. In case of using encumbrance accounting/perpetual receipt accrual/PO is project related/PO discount is inventory then such overridden option is not possible.
When matching an invoice to PO payables automatically to the descriptive Flexfield information from PO to invoice if this check box is enabled provided the structure of Flexfield in PO discount is the same as that in invoice discount.
Interest: Controls & options for calculate of information for override invoice/others.
Allow interest invoice: Enable – system will calculate information for override invoice & automatically generate interest invoices.
Prorate access overdue invoice: Enable – prorate the interest amount of the overdue invoice access item discount.
Minimum interest amount: For calculating interest is below this value, and then payable will ignore the calculate interest does not generate any interest invoices.
Interest invoice account codes: Expense &liability Incase if the second checkbox above is disabled, then a single line discount is created for the total interest & overdue invoice with this account code combination. Expense 6820 Liability: whenever allow interest invoice is enabled, then you have to specify the interest invoice liability account code combination in this field -2250 it is used as prepayment process.
Expense Reports
Default template: To enter details of expense of employee is form/template with regular expense
codes/names can be created & used as default template have this will appear in expense report window. The default value/codes/names/which specified can be overridden at the expense report window.
Payment terms: Select a default payment term for expense report payment. It will be assigned to the employee when the employee is made as a supplier during expense report/import.
Expense report pay group:
Employee can be grouped for expense report reimbursement purpose & the pay group can be created at purchasing lookups which can be attached here.
Payment priority: 99 (1- higher priority 99- lowest priority)
Apply advances: To apply advances given to the employee against expense report. Override this option at expense report window.
Automatically create employee as supplier: At the time payable expense report else he has to be defined in the supplier window with classification as employee & by linking employee name & number.
Hold unmatched expense report: Unmatched expense report invoices will be placed on hold during invoice validation.
Payment
Bank account: Default internal bank for our company. It will be used for payment to supplier. It will be default in payment window & payment in batches.
Payment Batch limit: Maximum amount payable for the payment batch, if the payable amount is the batch exceeds this limit, the system shows a warning message but the excess can be optionally allowed. This limit is per payment batch.
EFT user no: EFT customer identifying number: allocated to you by user.
Banker/clearing organization. It is incorporated in the pay document sent to buyers. Additional pay through days:
The number given here is added to default pay through date while initialing a regular payment batch. No of days specified here are the days but the regular payment date & default pay through date. In case it is 10, payable add to the system date & then arrive at default pay date when we run a payment batch.
Allow document category Override:
Separate numbering of payments as voucher number: Besides payable document number sequential numbering can be assigned for payment & the payment voucher will be accordingly numbered sequentially. If you want, you can define a different sequential numbering & override the default setup, if the checkbox is enabled.
DISCOUNT:
Exclude task from disc calculation: Enabled – tax amount will be subtract from invoice header amount discount will be calculated.
Three system of accounting discount Taken:
System account: All discounts Taken will be credited to the system disc taken account define in the financial option level.
Prorate expense: Prorate any disc across invoice discount lines, if exclude tax from discount line is enabled, then disc will prorated across discount expense lines only & not for tax lines.
Prorate task: Prorate to tax discount line only as percentage of the discount amount equal to the percent of tax distribution.
E.g. tax distribution line 20 % of the total distribution amount, then payable prorate 20% of the discount amount against tax lines, only the remaining 80% of discount amount is accounted as discount taken account. SINGLE PAYMENT:
Allow print: To print payments while effecting quick payment.
Allow pre date: We can create payment date prior to system date.
Allow void reissues: Of checks, in cases a check is spoiled, you can void & reissue another check bearing new cheque number in line of the same cheque through payments.
Allow address change: Change address of supplier site at the time of payment instead of sending it to supplier site adds as per the invoice.
XML PAYMENTS:
Automatic confirmation:
If System Company uses XML payments, and this check box is enabled then system will allow automatic confirmation of payment batches based on process payment requirement. XML message from in book indicates that xml payment was successful. If it is enabled, the user will receive workflow information at the confirmation of the payment batch.
REMIT TO BANK ACCOUNT:
Allow remit- to account override:
Normally for direct remittance to supplier bank account, the supplier site will be having a default primary bank account. Enabled – in the payment batch window, the user has got an option to change the remit to supplier bank account.
BANK CHARGES:
Use bank charges: Enabled – you can enter bank charges provided in the supplier region of the payable option bank charge bearer option is exercised.
INVOICE TAX
Requisition tax entry at header:
We can enter the tax amount of the tax code of the invoice at invoice header level itself at invoice workbench. When tax is accounting like this, then distribution lines are generated based on invoice amount after
subtracting the tax amount. Not applicable for imported invoices/for credit & debit memos in invoice workbench.
Use automatic tax calculation: Based on the tax code tax calculation automatically without entering the amount.
CALCULATION LEVEL: For automatic tax calculation, Level at which tax has to be calculated.
Header – Header level amount is split into line & tax amount.
Tax code – Based on tax code attached at header level.
Line – This is always inclusive.
Line: - Tax amount calculation on distribution line amount, It can be inclusive / exclusive if inclusive then check box includes tax in distribution line level should be enabled; otherwise it will be exclusive tax.
Tax code: Calculating tax more/less in the same way as line level tax except that at the time of calculation of tax amount, tax lines which the same tax codes can be grouped & then rounding of tax is done .Rounding off is not done on each tax line but done in tax code grouping level only.
Allow calculation level override: The default level of tax calculation selected in calculation level can be overridden at the supplier site level only if it is enabled.
Distribution amount inclusive tax: - tax calculation at line level/tax code level at inclusive tax then it is to be enabled.
Allow override: if the above check box is enabled, then to override the default method of calculation of tax at supplier site level, enable this,
