Monday, 25 April 2011

Oracle 12i - How to create accounting and transfer JE's to GL using SLA


Oracle 12i - How to create accounting and transfer JE's to GL using SLA

I. Create Accounting Program:

The Create Accounting program processes eligible accounting events to create subledger journal entries. To create the subledger journal entries, the Create Accounting program applies application accounting definitions that are created in the Accounting Methods Builder (AMB).

The Create Accounting program:
•Validates and creates subledger journal entries
•Optionally transfers the journal entries to GL
•Optionally posts the journal entries in GL
•Generates the Subledger Accounting Program Report, which documents the results of the Create Accounting program

Draft Accounting:
When you select draft accounting, Subledger Accounting creates the relevant journal entries in draft mode. Draft entries are not posted to General Ledger. You can review the resulting entries, update the transactions, or update the accounting rules. Any changes will be reflected when the transaction is processed again for accounting.

Online Accounting (Final):
Final entries are ready to be transferred to General Ledger and cannot be modified. The transactions are considered as processed for accounting. Any changes to the rules will not impact final entries.

Straight-Through Accounting (Final - Post):
If you select Final Post, Subledger Accounting posts the journal entries all the way through to General Ledger. This means that you can update GL balances straight from the invoice entry (or any other transaction entry) window.

Create Accounting Program:
The Create Accounting program creates subledger journal entries. In general, the parameters described in the table above determine which accounting events are processed.
Navigation Paths (example Payables)
Payables: Other > Requests > Run
Receivables: View > Requests (B) Submit a New Request

Paramaters:

1. Ledger - Required; limits accounting events selected for processing to those of a particular ledger. This program is run for primary ledgers or valuation method enabled secondary ledgers. Any reporting currency or secondary ledger associated with the selected primary ledger is also processed; i.e. entries are generated for the selected primary as well as reporting currencies and non-valuation method secondaries.

2. Process Category - Optional; restricts the events selected for accounting to a particular process category. For example, Invoices.

3. End Date - Required; end date for the Create Accounting program; processes only those events with event dates on or before the end date

4. Mode (Draft/Final) - Required; determines whether the subledger journal entries are created in Draft or Final mode

5. Errors Only (Yes/No) - Required; limits the creation of accounting to those events for which accounting has previously failed

6. Report (Summary/Detail/No Report) - Required; determines whether to generate a report showing the results of the Subledger Accounting program in summary or detail format

7. Transfer to General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to transfer the subledger journal entries to General Ledger

8. Post in General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to post subledger journal entries in General Ledger

9. General Ledger Batch Name - Optional; user-entered batch name that appears on the transferred General Ledger subledger journal entries. Transfer to GL option must be set to Yes.

10. Include User Transaction Identifiers (Yes/No) - Required; controls whether the report displays user identifiers' names and values.


Create Accounting Program:
The Create Accounting program generates one or more accounting programs depending on the volume to be processed. The Subledger Accounting Program report is generated by the Create Accounting program and documents the results of the Create Accounting program. It lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events
You can run the report in summary, detail, or no report mode which are described as follows:
•Summary mode provides a summary of events processed and detailed information about their errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.
•No report mode will show an error count without actually generating the report.

II. Transfer Journal Entries to GL Program:

The Transfer Journal Entries to GL program enables you to transfer any eligible journal entries to General Ledger, including those from previous runs that have not yet been transferred to General Ledger.

Note: This program is used if you run accounting online in Final mode (not Final Post) or if you run the Create Accounting program and set the Transfer to GL parameter to No.

The only reason you would want to run the Create Accounting program and set the Transfer to GL parameter to No is if you want to run accounting at different intervals than the GL transfer, for example, you may run accounting every hour but only transfer to GL nightly.

The Transfer Journal Entries to GL program consists of a subset of parameters used in the Create Accounting program as listed below:
–Ledger
–Process Category
–End Date
–Post in General Ledger
–General Ledger Batch Name

III. Oracle Subledger Accounting Program Report:

The Subledger Accounting Program Report is generated by the Create Accounting program and lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events

You can run the report in summary or detail mode as follows:
•Summary mode provides a summary of events processed and detailed information about any errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.

IV. Transfer Journal Entries to GL Report:

The Transfer Journal Entries to GL report is generated by the Transfer Journal Entries to GL program and lists the following:
•Transfer to GL Summary
•Errors

Setting Profile Options:
The profile options listed above relate to data access and security and impact how accounting is generated through SLA in R12.

1. SLA: Enable Subledger Transaction Security in GL
•Use this profile option to combine subledger transactions security with data access security for General Ledger responsibilities when drilling down to multi-organization enabled subledger application. Transaction security in the respective subledger application is always applied when drilling down from subledger transactions to subledger journal entries.

2. SLA: Enable Data Access Security in Subledger
•This profile option determines whether the General Ledger Access Set security mechanism is applied for a subledger application responsibility when viewing, reporting, or creating subledger journal entries associated with a given ledger. The General Ledger Access Set security mechanism is always applied for responsibilities associated with the General Ledger application.
•The profile option enables you to combine data access security with subledger transaction security and therefore control access to subledger journal entries depending on the ledger to which they belong. For example, you can implement a Multi-Org Security Profile that allows you to create Oracle Receivables Invoices for two different operating units each associated with different ledgers but restrict drill-down from the subledger transaction to the associated subledger journal entry based upon the destination ledger contained in the Access Set.

3. SLA: Additional Data Access Set
•The SLA: Additional Data Access Set profile option, in conjunction with the GL: Data Access Set profile option, controls which ledgers and balancing or management segment values you can access when logging onto a responsibility. If SLA: Enable Data Access Security in Subledgers is enabled for the responsibility, you have access only to the ledgers and balancing or management segment values included in the data access sets assigned to the SLA: Additional Data Access Set and GL: Data Access Set profile options.

4. SLA: Allow Reports Journal Source Override
•This profile option applies only to the following reports:
-Open Account Balances Listing
-Third Party Balances Report
•Enable this option to change the Journal Source parameter during report submission. If the option is set to No, then you cannot change the value defaulted during report submission.
For example:
•Should the general ledger data access set security be enforced when generating accounting? For example, should journal entries be created if the user does not have ledger clearance even if they may have multiorg access to the operating unit?
•Should the transaction security model be applied when drilling down from GL? For example, should the user be allowed to inquire on journal entries of certain operating units if they do not have MO access, but have ledger clearance?
•If there are secondary ledgers and data access set security is enforced in the subledger module, then an additional data access set needs to be assigned to the user to enable access to the secondary ledger.
•Should the user be able to run certain reports across data from multiple subledger applications?

Purchasing and Inventory Accounts commonly defined during Setup


Purchasing and Inventory Accounts commonly defined during Setup


1. Purchasing:
Financial OptionsAccounting Information
· Liability Account
· Prepayment Account
· Discount Taken Account
· Rate Variance Gain Account
· Rate Variance Loss Account

Purchasing Options
Accruals
· Expense AP Accrual Account

Receiving OptionsReceiving Account (need one account per inventory organization; they can be the same).

2. Inventory:
Define Organization Parameters - All accounts in this section are required for each inventory organization; they can be the same between orgs.
· Inter-Org Transfer Accounts (required for setup)
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account
Valuation Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)
Other Default Accounts
· Purchase Price Variance Account
· Invoice Price Variance Account
· Inventory Accrual Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account
· Cost of Goods Sold Account (this is a default; each item can have a COGS account as well)
· Average Cost Variance Account (this probably won’t be used, so a suspense account is fine)

Define Subinventory - All accounts in this section are required for each subinventory in each org; they can be the same as the org level, and can be the same between subinventories.
Subinventory Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)

Define Freight Carriers - Need an account for each carrier defined; they can all be identical, overlapping (Ground account vs. Express account) or unique; freight carriers are optional, and may not be set up.

Define Inter-Org Shipping Information
· Inter-Org Transfer Credit Account
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account

Define Overhead· Absorption Account

Define Item - need an account code for each item defined; they can be identical, overlapping, or unique; these accounts are optional since they will default from the subinventory or organization
· Cost of Goods Sold Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account

Sunday, 24 April 2011

Inventory Flexfield Structure Definition FLEX FIELDS


Inventory Flexfield Structure Definition for a Food Processing and Distribution Company

Introduction - This real world case study on proposed item structure for a Food Processing and Distribution Company was based on the requirements of business, gathered through discussions during the implmentation project, as well as recommendations submitted by consultants.


1. Objective

The Decision on Inventory Flex fields Structure was taken based on achieving the following Objective:

Ø Item code structure across all Product lines & Products is required to be uniform;
Ø Item code should be simple and short;
Ø Item code numbering should be driven by a simple logic to avoid deciphering the codes by field staff;
Ø Item code should be independent of the personal view of the person defining the item;
Ø Item code should not be dependent on either supplier or customer codes;
Ø Each item should have code and a description to identify the item uniquely;
Ø Code should not be repeated in description and vice-versa;
Ø Expiry date and location of the item should be identified
Ø All items should be properly classified in a logical manner, so that MIS reports can be generated; and
Ø All existing reporting requirements are met, in addition to the reports available in Oracle Inventory.

In Oracle Inventory, an Item should have a System Flex field; in order to take advantage of the Oracle Apps, features, it is also recommended to use Category Sets, Lot number control and Locator to define an Item.

Based on the above, the following item code structure was designed.

2. System Item Flexfield

The System Item Flex field is used to define the Item Code through which an Item in the Inventory is identified uniquely. For the client's business, the System Item Flex field will be:

No. Of segment = 1
Segment Name = Item
Size = 6 Numeric

The segment will have serial no starting from 000001 to 999999. This gives flexibility to have 999999 items in the company. To ensure that items are numbered in a logical manner, range of serial no. will be allocated, so that serial no. can be used only from the range.

As a next step, Description of the item has to be entered to save the item in the system. It is proposed that the name of the supplier/brand, existing description and the package size shall be entered in description, eg. ABC Supplier (Brand), Mod Chicken (Description) and 900 grams (package size) so the description would be 'ABC Supplier Mod Chicken 900 Grams'.

3.Category Set

A Category is a logical major classification of items that have similar characteristics. A Category Set is a set of distinct categories in which an Item can be grouped/classified. E.g. one grouping or classification can be based on “Buying”; another grouping or classification for the same Items can be based on the Physical Inventory attributes. The flexibility of having multiple category sets allows reporting and query on items in a way that best suits business needs.

For our common business requirements across all departments, an Inventory Category Set will be created at the beginning with the following four segments:




*The segment size has been considered keeping in view that most of the business requirements are met. As these 6 segments are required to appear in Reports, GRNs, PO & Invoices hence, having longer size would mean that on the reports, other information might not fit in 80-column Or 128 column Stationery.. However, in system their full description can be entered and maintained. It is also advisable that these categories can be numbered properly to avoid extending the report size.

The values for the above 6 segments will have to be first updated and combinations also created. This will then be available as List of Values (LOV). Every time an item is created, this default category set structure will be attached to the Item, and the values for each of the segments can be selected from LOV. Few items have been classified under four segments:

Once a Category set is attached to an item, reports on its segments i.e. Focus, Brand, Category, Base Product, Product & Size can be generated. For an existing item, a Category set can be delineated, if required, and a new category set attached. Last change audit trail will be available in the system. A new category set can also be created or an existing Category set be disabled.

4. Lot Control

Lot control feature can be utilized to capture the expiry of items in the inventory. It plays a crucial role in the organizations, which are into Food Processing, Pharmaceutical and products that get expired due to elapse of time. It is proposed that the lot control feature can be enabled and used for all products. Basically, system will require a lot number and expiry date to be entered by the user to complete the transaction. Transactions are as follows:

A. Material Receipts
B. Transfer goods from one location to another location and
C. Material Issues

In case of material transfer between locations, user has to choose the lot number, which is already assigned to the items. This will eliminate multiple lot numbers assigned to single item in different locations for a better control. To ease the operations, it is proposed that the ETA date (Expected Time of Arrival) shall be entered as lot number for the item and the user has to input expiry date of the item. Preferably, these lot numbers should be pasted on the Pallets so that the inventory clerk can easily identify the location of the goods.

5. Locator Structure (To be used in Future)

Locators are used to identify physical location where the item is actually stored in the Warehouse/Store. Locator can track item quantity. An Item can also be restricted to a specific locator or a locator can be dynamically assigned to the item on receipt.


In order to use this available feature for better managing the inventory, we need to –
Ø Design the locator storage system based on the warehouse space and use structure for storing items.
Ø Paint the palettes using standard primary colors.
Ø Assign numbers to all the palettes.
Ø Define all the locator addresses in the Inventory system.
Ø Attach item to a locator.

It is proposed to use a Locator segment of Colour & Number, for e.g. R120 would mean RED colour palette number 120. This detail will help in tracking the item during transfers, issues and also during taking physical stock of the items. Proposed locator address structure is given below:


It is proposed that the locator will be defined in the system but the users will be using it once they are well versed with the system. The locators segment have to entered on following transactions:

A. Material Receipt to Warehouses
B. Transfer of goods from one location to another location
C. Movement of Goods within the warehouse
D. Issue of materials to Customers and Vans
E. Receipt of materials from Van and Customers

6. Benefits of the Proposed Item Structure

a. At the time of Item creation, the only User logic built into the item code is the Sub Division to which the item belongs.
b. The Item Code is short with one segment and is uniform across all Products.
c. Company can have up to 999999 items.
d. The Item Code is not dependent on the item code of the Vendor or Customer and is unique to the Client.
e. The probability of making duplicate item code is nil since the Item Code is unique in inventory. f. Items have been classified in an Inventory Category Set with six segments Type, Product Line, Brand and Product. In the existing system the classification is more or less the same. Focus, Brand, Category, Base Product, Product & Size will be available as List of Values for selection, so that typographical errors are avoided. However, it is important that the selection is correct to avoid changing the category subsequently.
g. Inventory Reports can be generated on any of the segments i.e. Item Code, Description, Focus, Brand, Category, Base Product, Product & Size to sort the items in Inventory Organization.
h. An Item can be attached with lot numbers & Locator to identify the location and expiry dates.
i. Stocks can be maintained Expiry date wise

Encumbrance / Budgetory Control in Oracle Applications (PO AP)


Encumbrance / Budgetory Control in Oracle Applications

You can define encumbrance accounting or budgetary control in Financial options window:
Navigation: AP or PO ----> Setup--> Organizations --> Financial Options.

In order to use encumbrance accounting or budgetary control, you must install Payables, Purchasing, and General Ledger modules. You may go to encunbrance region to enable encumbrance accounting and to specify the default encumbrance types which Payables module assigns to your invoices, and Purchasing module assigns to your requisitions and purchase orders.

If you enable encumbrance accounting or budgetary control, Purchasing creates
encumbrances when you reserve funds for a requisition or purchase order. If you use the perpetual accrual method in Purchasing, it reverses the purchase order encumbrances when you inspect, accept, and deliver the units. If you are using the periodic accrual method in Purchasing, Payables reverses the purchase order encumbrances when you create accounting entries for invoices. Payables module creates encumbrances when there is a variance between a matched invoice and the purchase order to which it is matched, and when the invoice encumbrance type is different from the Purchasing encumbrance type.

Oracle EBS provides two predefined encumbrance types that you can use to identify requisition, purchase order, and invoice encumbrances:- Commitment and
Obligation. You can define additional encumbrance types in Oracle General Ledger module in the Encumbrance Types window.

1) Use Requisition Encumbrance
You may enable this option to encumber funds for requisitions. If you enable this option, Purchasing creates journal entries and transfers them to General Ledger to encumber funds for purchase requisitions.

If you enable Use Requisition Encumbrance, you must select an encumbrance type by which you can identify your requisition encumbrance journal entries. Purchasing assigns this encumbrance type to the encumbrance journal entries it creates for purchase requisitions. If you enable Use Requisition Encumbrance, you can indicate whether you want requisition preparer to have the option to reserve funds. If you do not enable this option, only requisition approvers will have the option to reserve funds.

2)Use PO Encumbrance
Enable this option to encumber funds for purchase orders, purchase order and receipt matched invoices, and basic invoices (not matched). If you enable this option, Purchasing encumbers funds for purchase orders and Payables encumbers funds for variances during Payables Invoice Validation for purchase order and receipt matched invoices. If you enable this option and enter a non-purchase order matched invoice, Payables will encumber funds for it during Payables Invoice Validation. All Payables encumbrances are reversed when you create accounting entries. If you enable Use Requisition Encumbrance, you must also enable this option.

If you enable Use Purchase Order Encumbrance, select a purchase order encumbrance type by which you can identify your purchase order encumbrance journal entries. Purchasing assigns this encumbrance type to the encumbrance journal entries it creates for purchase requisitions and purchase orders. If you use purchase order encumbrance, select an invoice encumbrance type by which you can identify your invoice encumbrance journal entries. Payables module assigns this encumbrance type to the encumbrance journal entries that it creates. It is recommended that you use an encumbrance type different from the Purchasing encumbrance type so you can identify invoice encumbrances

Oracle Purchasing - Setup checklist


Oracle Purchasing - Setup checklist



Defining Purchasing Options


Defining Purchasing Options


Defining Purchasing Options

Purchasing Options window is used to define default values and controls for functions in Oracle Purchasing. You can often override purchasing options when you are creating documents. Defining Purchasing Option is required step to use Orale Purhasing.

Navigation
Purchasing Responsibility=> Setup=> Organization=>Purchasing Options

There are 6 tabs in purchasing options as below:

1. Receipt Accounting (Accrual Options)
2. Control
3. Default
4. Internal Requisition
5. Numbering
6. Tax Default

Each option tab would be explained in next posts

Order Management Profile Options


Order Management Profile Options

Below listed are OM profile options. For viewing the full list, do click http://applearn.blogspot.com. Can anyone help on explaining the purpose of each of the below profile option?

1. AR: Use Invoice Accounting for Credit Memos

2. BOM: Check for Duplicate Configuration

3. BOM: Component Item Sequence Increment

4. BOM: Configurator URL of UI Manager

5. BOM: Default Bill of Material Levels

6. Journals: Display Inverse Rate

7. OM: Administer Public Queries

8. OM: Apply Automatic Attachments

9. OM: Autoschedule

10. OM: Auto Push Group Date

11. OM: Charging Privilege

12. OM: Context Responsibility for Upgraded Orders

13. OM: Credit Card Privileges

14. OM: Credit Memo Transaction Type

15. OM: Cust Item Shows Matches

16. OM: Debug Level

17. OM: Discounting Privileges

18. OM: Estimated Authorization Validity Period

19. OM: GSA Discount Violation Action

20. OM: Included Item FreezeMethod

21. OM: Invoice Numbering Freeze Method

22. OM: Invoice Source

23. OM: Invoice Transaction Type

24. OM: Item Flexfield

25. OM: Negative Pricing

26. OM: Non-Delivery Invoice Source

27. OM: Notification Approver

28. OM: Order Purge per Commit

29. OM: Over Return Tolerance

30. OM: Over Shipment Tolerance

31. OM: Over Shipment Invoice Basis

32. OM: Payment Method for Transactions

33. OM: Reservation Time Fence

34. OM: Return Item Mismatch Action

35. OM: Return Unfulfilled Reference Line Action

36. OM: Risk Factor Threshold for Electronic Payments

37. OM: Schedule Line on Hold

38. OM: Show Discount Details on Invoice

39. OM: Show Line Details

40. OM: Source Code

41. OM: Use Configurator

42. OM: Under Return Tolerance

43. OM: Under Shipment Tolerance

44. QP: Accrual UOM Class

45. QP: Blind Discount Option

46. QP: Bypass the Pricing Engine

47. QP: Item Validation Organization

48. QP: Line Volume UOM Code

49. QP: Line Weight UOM Code

50. QP: Negative Pricing

51. QP: Source System Code

52. QP: Unit Price Precision Type

53. QP: Verify GSA

54. Tax: Allow Ad Hoc Tax Changes

55. Tax: Allow Override of Customer Exemptions

56. Tax: Allow Override of Tax Code

57. Tax: Calculate Tax on Credit Memos

58. Tax: Inventory Item for Freight

59. Tax: Invoice Freight as Revenue

60. Tax: Use Tax Vendor