Journal Processing in Oracle ERP Cloud

This post is an attempt to introduce journal processing in Oracle ERP Cloud.

In order for successful journal processing the ledger needs to be already setup, the target period open and proper security assigned to the user, focus of this post is only on journal entry and related tasks and not the required setups.

Create Journal - This functionality is similar to journal enter in EBS, manual entry of journals.

The other sources of journal entry are:
a. Create Journal in Spreadsheet( Similar to WebADI in EBS)
b. Import Journals - Journals from Sub-Ledgers and Other sources thru the interface tables

I will not get into both the above mentioned options but just focus on manual entry of journals.

From the spring board or welcome screen, navigate to the Journals area.
The spring board and appearance of the screen may differ based on the roles assigned to the user. Journal processing falls under the General Accounting functional area.

The above screen displays the welcome screen(springboard), on selecting Journals the following page is displayed.

The above screen displays the main journal dashboard that can display journals that require approval, import errors, incomplete journals. To the right of the screen when the task pane is clicked, more journal entry task options are displayed. To enter manual journal select Create Journal.

Required fields are labeled with an *, In order to enter and complete a JE you need to enter the accounting period, date, JE Category, Ledger, account combination and dr/cr. amount.
For some one who has used EBS the fields here need no explanation they are pretty much the same. The journal can be saved without completing all fields, or completed and posted. See below

The posting process is submitted and completes as shown below.

Typically due to separation of duties journal posting is separated out and assigned to different user/group. Journals entered can be reviewed and posted from the Manage journals screen as shown below.

That covers manual JE entry and posting in Oracle ERP Cloud. What if you would like to make sure the account has been really impacted, then navigate to account inquiry as below.

I covered the basic JE entry and posting, additional topics in journal processing would be auto posting, allocation, reversal that are not covered in this post. Thanks for reading.

Functional Setup Manager (Oracle Cloud) overview

Folks who have implemented Oracle EBS 11i, R12 would remember to navigate into different screens and responsibilities to complete specific functionality setup, most likely the offline check list available in the implementation documentation is followed. The application would not guide the implementer, so there was possibility of missing some setups thus causing short fall of the desired functionality. The setup process has been completely revamped in the Fusion/Cloud applications, the desired functionality setup can be completed without navigating in and out of different application responsibilities thru FSM(Functional Setup Manager). Setup in Fusion applications involves selecting the offerings interested, the functional area and associated features with in each functional area. The selected features are setup using task list. Now to some screen shots to give an idea of how different the setup process is in Fusion/Cloud.

The above screen shot is the Offering page that lists all the offerings available, offering is collection of functional areas. EX: Financials is an offering that would have functional area related to General Ledger, Payables etc. Note the offering page has links to download the document detailing associated features, setup task list right from the application. The file can be downloaded in Excel/PDF/HTML. This is a great improvement from EBS, the implementer can download the task list in Excel and review all the required tasks and relate them with the task list associated.

The above screen shot relates to the new features option with in the offering page, the implementor or application admin can review the new features that have been released since specific version and decide to either implement or not. I remember in EBS prior to upgrading to new release I had to go thru the new release content document and review what changes were coming in and assess the upgrade, Fusion has made it so easy now. Some of the new features will not require setup and are automatically enabled, all this information is available right in the new features dashboard.

Finally the opt in area for the offering as shown in the above screen shot is the kind of on/off button. EX: You may have implemented General Ledger earlier now your organization decides to implement payables, you just come here and enable payables. Payables will now be eligible to be setup and use.

The above screen shot shows the task list associated with a functional area, in this example for functional area Expenses only the required tasks are shown. The implementer can verify this against the task list downloaded from the offering page just to make sure all tasks are in sync with documentation. Task list can be further filtered to display all tasks associated with the functional area. In order to complete the setup user has to have proper roles and access, Fusion is very different with EBS when comes to security. The best and easiest way to complete setup is by defining an implementation user and associating "Application Implementation Consultant" role to the user. In Fusion all setups are done from the "Setup and Maintenance" section that can be assessed in the navigator, once in the setup section/FSM area user can search for specific setup in the search tasks field this is useful if they do not know the exact offering/functional area where the task resides. EX: Typing "Manage Currency" will search for currency setup. This was an attempt by me to give an intro to EBS folks regarding the change in setup process with some screen shots. FSM has more to it, such as projects, task assignment, upload, download capabilities. I only covered the basics and hope some one could benefit by reading this.

Sub Ledger Accounting(SLA)

Tightly Secured Oracle ERP! Customer Invoice goes missing in Oracle AR?

I was brought in to help on Oracle R12 Implementation as Finance Functional Generalist; most of work involved post go live support. This is one of the experiences I would like to share, a case of how setup and customization did not go hand in hand.

I received an email from one of the Accounts Receivable Manager that he can not find an invoice in the system that was sent out to the customer, the customer was sent an invoice and payment was received but he could not apply the payment as Invoice was missing.

I started my research and confirmed that there was an order placed, shipped, invoice missing. So how could an invoice that was sent to the customer after the order shipped go missing?

This is what was wrong….

AR System options that control Transaction change and deletion:

1. Receivable provides System options that control ability to change printed transactions and allow transaction deletion. Customers can enable these options as per their requirement. I have always recommended customers to disable these options as a means to control accidental changes or deletion.
These options were set at this site to Allow Transaction Deletion (Enabled) but not Allow change to Printed Transactions (Disabled).

2. Receivables does not allow Transaction to be deleted when it is in a COMPLETE status, normally invoices that are interfaced from another module are valid transactions (Complete). In order to delete a Transaction, the status of the transaction would need to be changed to an incomplete status. Transaction workbench provides a toggle button that can change the status of the transaction to complete or incomplete.
Transaction in an incomplete status is not a valid transaction and hence can be deleted by clicking the delete icon on the tool bar provided the system option Allow Transaction Deletion is enabled.
In order to delete a transaction the prerequisite step is to have the status changed from complete to incomplete. Oracle AR does not allow this change to be made on transactions that have been accounted, payments applied, adjusted or if any other activity exists for the transaction. Transaction can be changed to an incomplete state for a printed transaction (Transaction that has been printed using Invoice print process) provided the system option Allow change to Printed Transaction is turned on.
How does the system keep track of whether an Transaction has been printed or not, Oracle has seeded Invoice print processes that not only perform the function of printing the transaction additionally it updates the transaction to mark the printed status, printed date, printed count.

This is how an invoice that is not yet printed looks in the table.

As the invoice is printed the invoice is updated to show that printing has completed, date printed, printing count fields are populated.

Setup and Transaction processing options implemented at the site:

1.      Allow change to printed transactions – No

2.      Allow transaction deletion – Yes

3.      Accounting is created on transactions at Month end only.

4.      Invoice(Transaction) is printed and sent to customer by a custom process and not the seeded Invoice print process.

Transaction that is entered during an accounting period and that has no activity against it has scope for change as accounting is not created until end of month. As the invoice print process was custom it was not behaving the same way as standard invoice print program, the internal print flags on the transaction were never updated. Invoice that was printed and sent to customer was still flagged in the system as not printed, because the custom process never updated the print status. This was working against the setup not to allow change to printed transactions, as none of the invoices in the system were marked as printed and that means if they were not accounted, paid, adjusted, credited the transaction could be incomplete and deleted.

In addition to using a custom invoice print process that had opened up the opportunity to allow change on transactions that were printed (assumed to be printed as the flags were not set right), the refund process followed was not right too.

Invoice that was generated as a result of an order is a financial transaction representing the sale, if the need arises to credit the customer for a reason like excess shipping charge, customer satisfaction etc. the right way would be to process a Return for Refund in the order system and process it through to AR as a credit memo. Oracle Order Management does allow for Return Orders (RMA for product returns), Refund Order (RMA for refund no product returns), so it is better to link a refund for any reason against a sale in the source system and flow it to the Finance modules. Process being followed here for refunds was different; they would change the invoice as long as the system allows it.
The AR folks would retrieve the Invoice, incomplete it and then make a change to reduce the product or shipping amount and then complete it back.
This process does achieve the desired change to the customer’s balance, but has created a financial transaction that is different from its source system and not only has that it provided scope for human errors.

The lost invoice:
Putting all the pieces together, it was concluded that somebody accidentally or intentionally deleted the transaction assuming the following actions.

·         Order shipped, AR Invoice generated and sent to customer.

·         AR Invoice was never flagged as printed, not accounted as it was generated            during the start of the month.

·         To make a change or accidentally the invoice would have been incomplete and deleted.

·         Payment made by customer and no Invoice could be found

A manual invoice was created and payment applied, to make up for the lost invoice.

It was found that about 15 invoices were missing, that could have been accidentally incomplete and deleted. The culprit here was the custom process that did not update the print flags, ultimately it was fixed.

Third Party Payments in Oracle Payables

Payments are generally made to the original supplier providing the goods or services; however there can be specific arrangements made wherein the suppliers can specify a different party to be paid on their behalf. The payments made to other parties on behalf of the suppliers are termed as Third Party Payments.

Third Party payments help parties involved in business to set off their liabilities without directly paying them. This reduces the direct funds movements and transactions are settled easily.

When customers make payments from their Payables system, there might be instructions from the supplier to make the payment to a different party that is the Third Party. In that case, the remittance of the payment goes to the Third Party. For all legal purpose including 1099, it is treated as a payment to the original supplier.

The Payables department maintains the Supplier information. Establishing Third Party

Payment relationship is part of the supplier maintenance activity.

The Payables clerk may also have information of the Third Party at the time of entering the invoices. The Payables clerk can have the right to override the Third Party defaulted at the time of invoice entry.

The Payments clerk processes the payment for the invoices that are due for payment.

Generally the payments clerk is aware of the Third Party suppliers to whom the payments can be released on behalf of the supplier. The Payment's department has the right to override the actual party to whom the payment can be made at the time of making payments.

This functionality lets you do the following:

• Establish Third Party relationship

• Default Third Party supplier information when creating invoice and processing payments

• Override Third Party supplier information on the Invoice and Payments windows

• Default Remit To Bank Account for the Third Party supplier on Invoice and Payment windows

• While processing payments to Third Party Supplier:

• Uses the address of the Third Party supplier, when the Payment Process Type is

   Printed

• Uses the Bank and Bank Account information of the Third Party supplier, when the           Payment Process Type is Electronic to transfer funds

Oracle Payables introduced third party payments functionality in release 12.1.1.

Setup Supplier Third Party

Third Party supplier needs to be setup in Oracle prior to using the third party payments functionality. In addition to the regular setup of supplier third party supplier needs to be setup, add a relationship between the first party supplier and third party supplier has to be setup.

Supplier relationship is established between suppliers at the site (address) level.

Ex: ASG Shoes Inc is a supplier who requests the payments be made to Fashion Domestic.

In order to establish a third party relationship, ASG Shoes supplier record will need to be related to Fashion Domestic supplier record. Fashion Domestic supplier record needs to be setup in oracle for the purpose of establishing a relationship with the primary supplier.

Supplier can have relationships with multiple third parties, but at any point of time only one third parties can have a relationship that is classified as Primary. During invoice entry and payment entry the third party suppliers that have an established relationship with the main supplier are available to be keyed in the field Remit-To Supplier Name.  Remit-To supplier name field is the key field in the functionality of third party payments.

Manage Supplier Third Party

Third parties (Remit-To suppliers) that have been setup for a given supplier can be managed from the Relationship menu option on the supplier’s page. New relationships can be setup, existing relationships inactivated from this page.

Payables Invoice options useful for Third Party Payments

Third Party supplier functionality has been introduced by providing additional fields on the Invoice and Payment entry screens. These fields are “Remit To Supplier Name”, “Remit To Supplier Site”.

Remit To Supplier information is defaulted to the Invoice entry screen based on the setup of the supplier, if there is a primary relationship that exists the third party supplier is used as remit to supplier. The ability to change the Remit to Supplier information during invoice entry is controlled by the payables system option for invoices. Allow Remit-To Supplier override has to be checked if during invoice entry the Remit To Supplier information can be allowed to change.

Payable Options -

Allow Remit-to Account Override. Check this check box if you want to allow users to change the default primary supplier site bank account during Quick payment and payment batch creation. If you enable this option, you can override the Payables default of the Remit-to field of the Payments window and the Modify Payment Batch window. You can then select an alternate Remit-to account from a list of the supplier site's active bank accounts that use the same payment currency.
Allow Remit To Supplier Override. If this option is enabled, then you can override the default Remit To Supplier Name and Site values at the Invoice windows

Payables Payment options useful for Third Party Payments

Allow Remit To Supplier Override. If this option is enabled, then you can override the default Remit To Supplier Name and Site values at the Payment windows.

Using Third Party Payments Functionality in AP

Third party payment functionality is useful in many situations, but a few common situations are as below:

Supplier’s who do not collect their receivables themselves but Factor to another party.

Supplier has gone Bankrupt and as per the court order the payment needs to be made to a different party.

The key to making third party payments is by establishing a relationship in the supplier screen, making sure the payable options for Remit to supplier are setup in the system as desired to provide the ability to change the Remit information in Invoice Entry and Payment Entry.

Paying close attention to the field’s Remit to Supplier, Remit to Supplier Site and in case of electronic payment Remit to Bank Account during invoicing and payments is very important.

Approval Management options for AP and OIE

Oracle Internet Expenses (OIE) has traditionally integrated with HR for the approval hierarchy creation along with seeded workflow APEXP. Expense report submitted by an Employee would require approver from Employee's Supervisor who has been setup with required approval signing limit, if the immediate Supervisor does not have enough signing limit the workflow would pass the document to the next Supervisor. This process of finding the approver with required signing limit using the Employee HR Hierarchy has been the core of the logic embedded in the APEXP Workflow.
Customer's Implementing OIE had to customize the APEXP Workflow if their requirements around Expense report approval were different than the seeded workflow.

Oracle Payables up to the release of 11.5.10 did not have the functionality of Invoice approval seeded, clients that needed an approval process on Invoices had to use custom approach or use an offline approach.
Payables was enhanced to provide the Invoice approval functionality by means of an integrated Invoice Approval Workflow and use of OAM (Oracle Approvals Management) for deriving the approvers list.
This enhancement was available to the existing clients who were already on 11.5.10 by means of certain patch sets.

OAM has since undergone a name change and is now more familiar as AME (Approval Management Engine). AME is a rules engine that can provide a list of approvers to the calling application. Customer's can configure AME for a particular business transaction by use of simple static or dynamic values base on sql statements for generating an approver list.

AME has been integrated with Payables for the Invoice approval at the same time it also integrates with OIE (Oracle Internet Expenses). OIE approvals can now happen either by use of the old and traditional HR Hierarchy logic embedded with in the APEXP workflow or use AME and generate an approver list as per the business needs. Customer's who needed the Expense report to follow a different path of approval than the traditional HR hierarchy need not have to open up the APEXP workflow and customize rather they could use AME.

AME for Payables Invoice approval is the only option.

Having provided the introduction or overview of the approval process in AP and OIE, I would like to present a real time situation.

I had the opportunity to work on a project where the customer was implementing Oracle EBS R12; they were going to use Payables and OIE. We first started addressing the payables invoice approval requirement, I configured AME for use with payables and the solution was finalized. Internet Expenses requirement for the customer were reviewed and they were not complex, the approval process was the Employee HR Hierarchy and we knew the standard Internet Expense flow would fit the needs.

As we started testing Internet Expenses none of the expense report would be routed to the Employee's supervisor rather they would become eligible for Payables approval. We were surprised, why would the traditional HR hierarchy not be used for approval?

Little digging thru....the solution or issue was addressed.

Oracle AME can be turned on or off  at an application level, as I mentioned earlier Payables Invoices have to go thru AME where as Internet Expenses can go thru HR(Traditional approach) or AME.
Payables (SQLAP) is the application that owns both the Payables Invoice Approval and Expense report functionality, even though OIE (Internet Expenses) is considered an application by itself it really is considered part of the Payables application.

That was the issue, we intended to use AME for AP but for OIE we did not need AME and were happy with the seeded HR Approach, but since we turned on AME for Payables application OIE would not use the HR approach.

This setup for AME is controlled by the Profile ‘AME:Installed’, to enable approval for Payables set this profile value to  ‘Yes’. This essentially means you would want to use AME for Payables application and that means both Invoice approval and Expense report approval.

I would think it would have been more appropriate to have the option for the customer to choose AME at a Transaction type within an application. I should have had an option to say AP INVOICE  - AME  Y and AP EXPENSE REPORT - AME N.

Well that was the issue, and here is the solution.

Having decided to use AME for Invoice approval but for OIE we had to take the traditional HR approach.
We let the profile for AME turned on for Payables, which makes both Invoice and Expense report to follow AME as per setup. Expense report workflow was tweaked to ignore the AME profile setup and assume that AME is not installed thus passing the Expense report to take the HR hierarchy. Key is to change the functionality of AME Enabled process in the APEXP Workflow.

If AME is enabled the process takes a different route

We need to make it believe that AME is not enabled.

That will take the traditional route as below, this was the desired approach.

This approach worked for the customer requirement of using AME for Invoice approval and ignore AME for Expense reports.

Applied this approach on couple of implementations to workaround the issue of  having one profile option for both Business transaction types.

Hope this helps for some one dealing with a similar situation!