Wednesday, 02 February 2011 23:38
Anil Passi
This article contains step by step implementation guide with examples for EBiz Tax in R12. IMPORTANT - To view this article, you must have access to http://docs.google.com
It will take upto a minute for this document to load.
Last Updated ( Saturday, 22 January 2011 19:03 )
Read more...
Tuesday, 21 December 2010 06:12
Anil Passi
Very
often the GL Super Users create manual journals either directly from
the screens or using the Web ADI to upload the journals straight into
General Ledger. However account codes used in these manual journals are
secured via value set security and the cross validation rules. But this
level of security is not enough. For the sake of an example, the GL
Users must not be allowed to tamper with the amount of expenditure a
company has made on Office Furniture for their offices. Let us say that
all the GL Account segment value Office Furniture related expenses are
5115.
A
feature named Third Party account is a feature of R12 which helps keep
the Subledger like Payables or Receivables in sync with General Ledger.
The control account functionality of 11i is now called Third Party account in R12.
Some accounts should only be entered via the Subledger, and not be
allowed for manual journal creation in GL. Hence for those entries, we
can enable the qualifier to flag those as Third Party account.
In
the value set definition screen, query the segment value as shown in
image below. In this case, the Account Segment value is 5115. Against
the segment qualifier, in Third Party Control Account, select value =
Supplier, because in this example we will control the charges to this
account segment via Payables whilst ensuring that Supplier details are
specified. In other words, this configuration will ensure that you
cannot put a charge against office supplier into GL unless you have
specified the Supplier from whom the goods were purchased.
Read more...
Friday, 17 December 2010 07:17
Anil Passi
We have thus far seen the basic fundamentals and a simplistic scenario of Subledger Accounting. In the example that we saw, we created components required for the SLA configuration from ground zero. That is also known as the bottom up approach, where you build the lower level components and then move up the chain to attach your SLA configuration to your Ledger[11i SetOfBook equivalent in R12].
However you never ever use that approach in real life for modules such as Oracle Payables, Oracle Receivables, Oracle Cash Management, Oracle Fixed Assets or Oracle Project Accounting etc. The reason is that, SLA comes pre-configured for all the widely used modules in the EBusiness Suite. All the commonly used rules are already seeded into the SLA config by Oracle, hence all you need to do is to customize those components.Before we see the steps for customization of SLA, let us first do some questions and answersQuestion - I can customize the account generator in Procurement and Fixed Assets. Do I really ever need to customize “Subledger Accounting” in such cases?Answer- The pre-configured SLA by Oracle will use the accounts generated in respective modules as the source. The seeded ADR's will in most cases return the very same accounts that are generated in the respective modules. Effectively "garbage in garbage out", or you can say "quality of the account that goes into SLA, and the same quality accounts are then sent to General Ledger". The message from seeded SLA in most cases is “What you feed to SLA will also be fed into the Oracle General Ledger”. Therefore if you have already customized the account generation workflow in the respective module then you do not require customization in SLA. In fact, the customizations on the seeded SLA configurations must be kept to bare minimum. Although SLA provides you with ability to override accounting definition, however the main reason for creation of SLA was to implement multiple shadow accountings against ledgers.
Last Updated ( Friday, 17 December 2010 10:22 )
Read more...
Monday, 13 December 2010 00:00
Anil Passi
In the SLA articles Part 1 to Part 6, we understood the basic concepts of Subledger Accounting.
In the SLA articles Part 7 to Part 9, we configured SLA for Payables as an example.
In
this article, we will test the configuration to see the results of the
configuration performed in Part 7 to Part 9 of the SLA articles. We will
also explain the results of the test.
Our
SLA setup was done for Payables, hence we will create an Invoice in
Payables and check the accounting entries to reconcile those against our
SLA setup.
Read more...
Friday, 10 December 2010 00:00
Anil Passi
In
previous article we have seen that in SLA, the "Application Accounting
Definition" is created for each module in EBusiness Suite. However, in
any implementation there is a need to perform accounting across various
different modules. For example, a company named "APPS2FUSION UK" might
be running Payables and Receivables and also Project Accounting. Hence
we need to create a SLAM [Subledger Accounting Method] that will take
care of generating the Accounting journal lines for each of the module.
Hence a SLAM is nothing but a grouping of all the AAD's possibly for a
given chart of account.
Using
AAD we specify the Journal creation rules per module. In SLAM we
specify the applications/modules for which the Journals must be built
for the entire organization such as "APPS2FUSION UK" across Payables and
Receivables and Project Accounting. The decision of whether the journal
must be created is delegated to the AAD. As for how the journal is
constructed and how the accounts are derived is delegated to the Journal
Line Definition.
The company such as "APPS2FUSION UK" will have a legal entity in UK, and hence the SLAM will be attached to the UK Legal Entity.
In
the image below we are creating a SLAM named ANIL_SLAM, and attaching
the AAD named ANIL_PAYABLES. This is a simplistic example, because in
reality you will have the AAD's of other applications like Receivables ,
Project Accounting, Fixed Assets etc attached to the SLAM as well.
Read more...
Thursday, 09 December 2010 00:00
Anil Passi
In
the previous part of this SLA article, you have learnt creation of the
Journal Line Definition. Now it is time to create AAD, which is
"Application Accounting Definition".
The
purpose of AAD in SLA is to dictate which "Journal Line Definition"
must be used when a specific event takes place against a specific type
of transaction in a specific module like Payables or Receivables. If you
recollect, the "Journal Line Definition" definition creates a Credit
Line and the Debit Line of a Journal.
Oracle ships out of the box an AAD for every simply module/application that uses SLA.
Hence
for each application like AP,AR,PA,PO etc there will exist an existing
AAD in the Subledger Modules. However, for this example we will create a
new AAD for Payables.
In
the previous article you created a Journal Line Definition that is
responsible for constructing a Journal. However, in AAD screen you will
specify when the Journal Line Definition will be used. In this case, as
per the image below, we are stating that journal line definition
ANIL_JLD should be used for creating journal whenever any event occurs
against an Invoice in Payables.
Read more...
Wednesday, 08 December 2010 00:00
Anil Passi
In this article we will create a Journal Line Definition. You will basically apply the steps learnt thus far into practical implementation.However to create a Journal Line Definition, we need to create the following1. Journal Entry Description for journal line description
2. Journal Line Type to mainly define credit or debit
3. Account Derivation Rules for CCID used in journal line
Therefore typically, two set of JED,JLT and ADR’s are required, with one set each for Credit line, and the other set for the debit line.In this article, we will create these three components. Go to a subledger like Payables and within the SLA menu as shown below, you can open the Journal Enty Description screen. Click on New to create a new JED.
Last Updated ( Sunday, 28 November 2010 08:44 )
Read more...
Tuesday, 07 December 2010 00:00
Anil Passi
The overall flow of the SLA can therefore be depicted as shown in image below. Overall, when you create new definitions in SLA, you can follow the bottom up model.
Last Updated ( Sunday, 28 November 2010 08:43 )
Read more...
Monday, 06 December 2010 00:00
Anil Passi
Regime is a set of conditions mainly political. Effectively one the conditions imposed can be taxation related. In EBiz tax, you can create a new responsibility based on Tax Manager responsibility per OU, by setting MO Operating Unit. Once within this responsibility, you can define the Tax Rules, Rates and condition.
To allow defining taxation for Regimes [a politically governed unit], there is something called as regime to rate flow in R12. Using this you can build taxes based on rules. These tax rules are based on 4Ps, which are product, place, party and process. Using the EBiz Tax module in R12, you can define taxation that will be dependent on one of these four Ps. For example the taxation can vary for consumable product and for engineering products. Likewise for California and New York the taxation can vary. In some countries with agricultural subsidies, the taxation on necessities like food products could be lower.
The country regime is driven by regime to rate flow, and the configurations that we do in regime to rate flow variation factors for variations in taxation rules to be implemented.Any tax in the world is based on either party specific or place specific or product specific or process specific. By process specific it means this is associated with a type of transaction. To begin with we need to know the geographic tax structure of the country and how exactly the product types relate to transactions. The regime to rate flow is a wizard, in which the first thing we do is to create a regime. However the regime itself belongs to Tax Authority, for example Government of Canada. Within the tax authority you can have regime. A Tax authority is the tax administrator of the country. But within the Tax authority there will be different bodies that manage Central Sales Tax or State Sales Tax or VAT etc. These different bodies are called regimes. In 11i the equivalent of Tax Regimes was the Tax Locations. Likewise the different Tax states from 11i are now available as jurisdictions in R12.Within the regimes you can build rules. These rules can be based on 4 Ps. After defining the regime, you will define something called as "Tax". This is a charge that people will incur or recover. Next we need to define jurisdiction which is an optional setup. Jurisdiction for example specifies that a tax "ABC" applies to country "DEF". The tax could be specific to country or to state. Therefore jurisdiction is a geographical location or an area to which this tax applies. The step by step guide for implementing Tax by Location in R12 is given in this Metalink https://support.oracle.com/CSP/main/article?cmd=show&type=ATT&id=557139.1:EBTAXThis document can alternately be downloaded from link http://tinyurl.com/23smd2nYou could have 0% tax or exempt tax or a reduced rate tax as Tax Status, for a regime for a particular tax that you have defined and for possibly a jurisdiction. This is the purpose of tax statuses. After defining the Regime, Tax Name, Jurisdiction, Tax Status- next we specify a Tax Rate. This can be a 10 or 12% etc on the combination of "Regime+Tax Name+Jurisdiction+Tax Status".Based on these the jurisdiction of the transaction, tax, tax status- a Tax rate will be specified. Then tax rules are applied, based on the tax rules, which is a place where you can give the rules based on 4 Ps. Basically, when a transaction occurs, it can determine the Product,Place, Party and processes. There are 8 rules given here, these 8rules generate exceptions to the arrive at the generic tax.
These tax Rules can be based on
a. Place of supply, based on where you are billing or shipping the product
b. Determination of the applicability of the tax
c. Determination of the tax registration
d. Determination of the tax based on status.
e. Tax rate
f. Taxable basis - based on line amount
g. Recovery Rates
h. Calculation tax amount = tax basis * tax rate
There are two type of rules, one is guided rule or expert rules.
Guided rule is a 5 step process, this is like a wizard and is used for creating a new rule.
If the setup is based on existing conditions or factors, then we use expert rules which is a 3 steps process. Expert rules has two less steps because you leverage the existing tax conditions/factors. A typical example could be that if bill to is from London and ship to is from Dublin, then tax should be 5%.In the next article, you will see a step by step guide for creating a new tax regime with a simple rule.
Last Updated ( Sunday, 28 November 2010 08:40 )
Friday, 03 December 2010 00:00
Anil Passi
As we have seen in the Part 4 of SLA, the Application Accounting definition is used to decide two things
a. When a specific event within Subledger example Payables or Receivables becomes eligible for Accounting
b. How the journal is constructed.However, each Primary Ledger[ 11i equivalent of primary set of book] and also each secondary ledger should be able to generate Journals as per their respective legislator requirements for all the modules implemented. This is where "Subledger Accounting Method" [SLAM] comes into the play. If you recollect from previous article, Application Accounting Definition is connected to only one module like Payables or Receivables etc. However a Ledger[11i SOB equivalent] needs accounting entries to be processed across many modules. Hence SLAM provides an umbrella to join accounting entries from various modules so that they can be channelled through to Oracle General Ledger. In other words a SLAM is a collection of accounting definitions for various modules in Oracle Apps. A SLAM is then attached to the Ledger[11i equivalent of Set Of Books].Therefore the flow of accounting entries appears as shown below
Last Updated ( Sunday, 28 November 2010 08:43 )
Read more...
Thursday, 02 December 2010 00:00
Anil Passi
In the SLA Part 2 article you Entities, Event Class and Event Types. In the SLA Part 3 you learnt the high level basics of Journal Line Definitions.
In this Part 4, you will see how the "Journal that gets constructed using Journal Line Definition" is associated with an underlying transaction in the respective module.
Last Updated ( Sunday, 28 November 2010 08:42 )
Read more...
Wednesday, 01 December 2010 07:24
Anil Passi
The Journal Line Definition "defines" how the entire journal is built. To create any journal, one of the key things is to get the CCID or the code combination of segments. SLA needs to know where this CCID will be coming from. You also need to know whether this CCID will be debit or this CCID will go into credit. Therefore you not just require the CCID, but you also need to decide whether a specific CCID will be debited or credited. In SLA, the "Journal Line Type" will specify whether the accounting entry is credit or debit. Also, you can then "attach something called an ADR to this Journal Line Type". The ADR returns the final code combination. Therefore Journal Line type will leverage the JLT+ADR to know which CCID is crediting and which CCID is debiting in the journal. For each and every application there is a combination of event class and event type. Depending upon the combination of event class and event type the accounting gets triggered. The standard SLA out of the box from Oracle meets your requirement by 90%. For example you can fetch the standard accounting from payables or receivables options. However where these standard seeded accounting do not suffice, you can go and modify SLA to meet your business needs. There is something called as Journal Entry Description. When a transaction is transferred as a journal, then every journal has credit/debit and description. The journal has description at header and also at line level. The JED allows you to generate the description of the Journal at both header and line level. For example you may want Customer Name or Customer Number in the journal description for a journal that is initiated from Oracle Receivables module. Using JED in SLA you can build header or line level descriptions.The image below describes the end result journal that is produced by SLA
Last Updated ( Sunday, 28 November 2010 08:42 )
Read more...
Tuesday, 30 November 2010 00:00
Anil Passi
In this article you understand some of the basics fabrics/terminology used in SLA, i.e. Entities, Event Classes and Event Types. It is important for you to understand the variables within SLA engine which influence whether an accounting entry needs to be generated for a specific event within subledger like Payables or Receivables. For example in Procurement, there may be a need to generate accounting whenever a Purchase Order is encumbered. In case of SLA, the activity of "Encumbrance" against a Purchase Order is known as Event Type.
Likewise when a Payables Invoice is Validated, then you may want to create an accounting entry. In this case the "Invoice Validation" is an "Event Type". And your accounting rules for Invoice Validation will be attached against this specific "Event Type".For Payables, an INVOICE transaction and a PAYMENT transactions are known as Entities within SLA.
Entities can be subdivided into various "Event Classes", for example Credit Memo, Debit Memo, Expense Reports, Invoices etc.
Further to this, against the Event classes we define Event Types, for example, whenever your Invoice is validated or cancelled or adjusted, you may want some specific accounts in the General Ledger to be impacted. Event types are therefore the types/list of events against transactions which you wish to account for in General Ledger.
This is explained in the diagram below.
Last Updated ( Sunday, 28 November 2010 08:41 )
Read more...
Monday, 29 November 2010 00:00
Anil Passi
In these article, we will explore the very basics of SLA and why it exists. Firstly, what exactly does SLA do?
SLA is a module which now sits between the SubLedgers like AP/AR etc and the General Ledger. Have a look at this diagram below. As you will notice, SLA can act as a mediator between the subledgers and Oracle General Ledger.  Before we progress, some terminologies of R12 must be revisited. In 11i we had set of books, and in R12 we call them Ledgers. Likewise in R12 we also have secondary ledgers and reporting ledgers. Hence from 11i perspective think of Ledger as Set of Books. As for Subledger, a Subledger is nothing but a module like AP/AR/PO/Inventory etc. In the diagram below, the second scenario is explained whereby let's say that payables module generates a charge account segment combination for an invoice distribution line as A.B.C.D. In such case, if SLA module is not customized, then the very same A.B.C.D combination will be passed to Oracle General Ledger via the SLA. And before you wonder... Yes, SLA module has its own set of tables to capture these accounting entries. Please see the image below.
Last Updated ( Sunday, 28 November 2010 08:40 )
Read more...
Wednesday, 14 July 2010 05:43
Pavan Kotharu
In this article you will learn how to implement a process whereby the information entered by a user in screen can be emailed via PDF to the same user for their electronic signature. For example, in some scenarios, a new employee needs to sign in a form electronically which specifies  the company's policies, terms and conditions . After the employee is hired, then he/she logs into employee self service, and they select various options in a screen. Some of this information may be captured into custom table by embedding custom stack layout regions. After they click Submit button on the page, the business requirement is to email as a pdf attachment. Below is a sample code which gives a basic understanding on how to implement this scenario.
Below are the major steps which are involved in implementing the above functionality:
1) Create an XML publisher page with the required format which should be sent as a pdf attachment to the user.
2) Develop oaf page with the same format for the user to select and fill various options related to the policy.
3) Create a workflow to send the attachment to the user who submits the page.
Last Updated ( Wednesday, 14 July 2010 05:57 )
Read more...
Friday, 09 July 2010 00:52
Anil Passi
In oracle EBusiness Suite, document/attachments for an employee can exist against various different types of records. To access those documents, the back office staff has to navigate to various different responsibilities/menu/screens/navigation paths and search for the record to which documents are attached. For example documents can exist against staff's HRMS person record, against their absence records[medical certificates], qualification records [professional certificates], appraisal records, CRM Service requests [complaints, other issues], SIT's, EIT's etc. It is a huge challenge for the back office HRMS staff to access those attached documents in a simple manner from various different places. The navigation to so many screens can be a nightmare for the back office HRMS team, just to pluck out a single document against for one of their staff members.
I have had multiple clients demanding an elegant solution to the issue around access to these EBusiness Suite documents in a secured and simple way. In this article, I would like to discuss seven different practical implementation options/solutions that can be implemented to achieve a unified yet secured access to documents held within Oracle EBusiness Suite. You can pick the option depending upon your business requirements and subject to the Document Management system that you have implemented.
Before getting into the details, in brief, the seven options are 1. Copy the attachments from different entities into PER_PEOPLE_F entity. 2. Synchronize with Document Management System like Documentum with Oracle EBusiness Suite using third party tools. Also use Attachment repositories to integrate with UCM. 3. Consume document management system's web services, routed via XML Gateway 4. Use SOA Middleware to pull documents from Oracle Apps and push the documents into Document Management System 5. Oracle 11g Database feature to consume document management system's webservice from PL/SQL DB trigger attaching blob attachments 6. Use Business Events, with PL/SQL or Java subscription consuming document management system's webservice 7. Use forms personalization in HRMS Person Screen to enable tools menu
Option 1 - Copy the attachments from different entities into PER_PEOPLE_F entity. This is a simple solution that can be implemented via PL/SQL code as explained below.
Read more...
|
|
