Updating Customer Site Profile Classes using SOAP Web Services in Oracle Fusion Applications

First off, there are two ways to upload/update Customer Site Profiles in Oracle Fusion Applications:

1. Using File-Based Data Import (FBDI)
2. Using Web Services such as SOAP and REST. 

However, I would recommend using Web Services instead of FBDI because it's more straight-forward and simpler than FBDI. More details can be found in a separate article: When to Use FBDI or WebServices in Oracle Fusion Applications.

This article will talk about how to upload/update Customer Site Profile Classes in Oracle Fusion Applications using SOAP web services and in the future, I will also discuss how to do this using FBDI.

Before we begin, let's first discuss what a Customer Profile Class is. Customer profile Class is a master data setup object that holds attributes that are important to the interaction between the organization and customers in terms of their selling relationship. It holds details such as the Customer's creditworthiness, credit tolerance, credit limit, its default payment terms, statement configurations, and its assigned collector.  A Customer Profile class is also used drive how the system will match receipts together with their invoices and defines how invoices are grouped together. For more in-depth information, check out a separate article: Defining a Customer Profile Class in Oracle Fusion Applications.

Below are some prerequisites before you can actually upload/update Customer Site Profiles using SOAP Web Services:

1. Download a copy of ReadyAPI, a software that will drive the updates to Customer Site Profiles
2. Prepare an "Extraction Report" that will generate the spreadsheet with the required Customer Data.

Since the first prerequisite is pretty straight forward, we'll move on to discuss the second prerequisite: Preparing the "Extraction Report". The script will be run from Business Intelligence Publisher (BIP), a reporting tool that we'll utilize to generate the actual data that will be fed to the Web Service.

To create the extraction report, you would have to create the following in order:

1. A custom Data Model that contains the SQL Script
2. A custom Report with CSV as the Output
3. A custom "dummy" Excel Template

Check out this article for an idea on how to create a custom Data Model (Customize the Data Models of seeded Oracle Fusion Applications reports). In the future, i'll create a step-by-step guide on how to create a custom data model, report and dummy excel template.

The SQL Script to be used in the Data Model is as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

select ACCT.ACCOUNT_NUMBER , hps.party_site_number , ACCT.CUST_ACCOUNT_ID --, 'DEFAULT' SET_CODE , STID.SET_CODE , custprof.CLEARING_DAYS , custprof.CREDIT_BALANCE_STATEMENTS , custprof.CREDIT_CHECKING , custprof.CREDIT_HOLD , custprof.PROFILE_CLASS_ID , decode(custprof.DISCOUNT_TERMS, 'N', NULL, custprof.DISCOUNT_GRACE_DAYS) DISCOUNT_GRACE_DAYS , custprof.DISCOUNT_TERMS , 'Y' DUNNING_LETTERS , custprof.EFFECTIVE_START_DATE , custprof.EFFECTIVE_END_DATE , custprof.LAST_CREDIT_REVIEW_DATE , custprof.NEXT_CREDIT_REVIEW_DATE , custprof.OVERRIDE_TERMS , HP.PARTY_ID , custprof.PERCENT_COLLECTABLE , custprof.SEND_STATEMENTS , custprof.TOLERANCE , coll.NAME CollectorName , custprof.EXCHANGE_RATE_TYPE , RTM.name PaymentTerms , custprof.AUTOCASH_HIERARCHY_ID , null ApplicationExceptionRuleSet , aar.Name AutoMatchRuleSet , custprof.AUTOCASH_HIERARCHY_ID_FOR_ADR , cyc.NAME StatementCycle , grp.name GroupingRule , custprof.CREDIT_CLASSIFICATION , custprof.ACCOUNT_STATUS , custprof.RISK_CODE , custprof.CREDIT_RATING , custprof.CONS_BILL_LEVEL , custprof.CONS_INV_TYPE , custprof.LOCKBOX_MATCHING_OPTION , replace(custprof.PREF_CONTACT_METHOD, 'EMAIL', 'E-Mail') PREF_CONTACT_METHOD , replace(custprof.TXN_DELIVERY_METHOD, 'EMAIL', 'E-Mail') TXN_DELIVERY_METHOD , custprof.PRINTING_OPTION_CODE , custprof.MATCH_BY_AUTOUPDATE_FLAG , custprof.AUTO_REC_INCL_DISPUTED_FLAG , custprof.CONS_INV_FLAG , NULL CREDIT_REVIEW_CYCLE , custprof.CREDIT_ANALYST_ID , custprof.CREDIT_LIMIT , custprof.CREDIT_CURRENCY_CODE , replace(custprof.STMT_DELIVERY_METHOD, 'EMAIL', 'E-Mail') STMT_DELIVERY_METHOD , custprof.ORDER_AMOUNT_LIMIT from HZ_PARTIES hp JOIN HZ_PARTY_SITES hps on HPS.PARTY_ID = HP.PARTY_ID JOIN HZ_CUST_ACCOUNTS ACCT on ACCT.PARTY_ID = HP.PARTY_ID JOIN HZ_CUST_ACCT_SITES_ALL ACTS ON (ACTS.CUST_ACCOUNT_ID = ACCT.CUST_ACCOUNT_ID AND HPS.party_site_id = ACTS.party_site_id) JOIN HZ_CUSTOMER_PROFILES_F custprof ON (hp.party_id = custprof.party_id AND ACCT.CUST_ACCOUNT_ID = custprof.CUST_ACCOUNT_ID) join HZ_CUST_SITE_USES_ALL usg ON (usg.SITE_USE_ID = custprof.SITE_USE_ID and usg.CUST_ACCT_SITE_ID = ACTS.CUST_ACCT_SITE_ID) JOIN HZ_CUST_PROFILE_CLASSES class ON (custprof.PROFILE_CLASS_ID = class.PROFILE_CLASS_ID) JOIN FND_SETID_SETS STId ON (STID.SET_ID = ACTS.SET_ID) join AR_COLLECTORS coll on (coll.collector_id = custprof.COLLECTOR_ID) join AR_STATEMENT_CYCLES cyc on (cyc.statement_cycle_id = custprof.STATEMENT_CYCLE_ID) join RA_GROUPING_RULES grp on (custprof.GROUPING_RULE_ID = grp.GROUPING_RULE_ID) JOIN RA_TERMS RTM ON (custprof.STANDARD_TERMS = rtm.TERM_ID) left JOIN AR_AUTOMATCH_RULES aar on (custprof.AUTOMATCH_RULE_ID = aar.AUTOMATCH_RULE_ID) where custprof.status = 'A' and class.status = 'A' AND ACTS.STATUS = 'A' and hp.party_type = 'ORGANIZATION' AND hp.status = 'A' and custprof.site_use_id is not null and sysdate between custprof.EFFECTIVE_START_DATE and custprof.EFFECTIVE_END_DATE and class.NAME = 'DEFAULT'

This is the script I used to capture all the required information for the WebService Payload that will  update the Customer Site Profile Classes. Feel free to change it according to your Organization's requirements.

Next, open up ReadyAPI and create a new SOAP project and provide the Web Services Description/Definition Language (WSDL) for your Instance. Next, load the Spreadsheet generated from the Report and assign it as a Data Source for the XML Payload below:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://xmlns.oracle.com/apps/financials/receivables/customers/customerProfileService/types/" xmlns:cus="http://xmlns.oracle.com/apps/financials/receivables/customers/customerProfileService/" xmlns:cus1="http://xmlns.oracle.com/apps/financials/receivables/customerSetup/customerProfiles/model/flex/CustomerProfileDff/" xmlns:cus2="http://xmlns.oracle.com/apps/financials/receivables/customerSetup/customerProfiles/model/flex/CustomerProfileGdf/"> <soapenv:Header/> <soapenv:Body> <typ:updateCustomerProfileAsync> <typ:customerProfile> <cus:AccountNumber>${DataSource#AccountNumber}</cus:AccountNumber> <cus:SiteNumber>${DataSource#SiteNumber}</cus:SiteNumber> <cus:CustomerAccountId>${DataSource#CustomerAccountId}</cus:CustomerAccountId> <cus:ProfileClassName>${DataSource#ProfileClassName}</cus:ProfileClassName> <cus:ClearingDays/> <cus:CreditBalanceStatements>${DataSource#CreditBalanceStatements}</cus:CreditBalanceStatements> <cus:CreditChecking>${DataSource#CreditChecking}</cus:CreditChecking> <cus:CreditHold>${DataSource#CreditHold}</cus:CreditHold> <cus:CustomerAccountProfileId>${DataSource#CustomerAccountProfileId}</cus:CustomerAccountProfileId> <cus:DiscountGraceDays/> <cus:DiscountTerms>${DataSource#DiscountTerms}</cus:DiscountTerms> <cus:DunningLetters>${DataSource#DunningLetters}</cus:DunningLetters> <cus:EffectiveEndDate>${DataSource#EffectiveEndDate}</cus:EffectiveEndDate> <cus:EffectiveStartDate>${DataSource#EffectiveStartDate}</cus:EffectiveStartDate> <cus:LastCreditReviewDate/> <cus:NextCreditReviewDate/> <cus:OverrideTerms>${DataSource#OverrideTerms}</cus:OverrideTerms> <cus:PartyId>${DataSource#PartyId}</cus:PartyId> <cus:PercentCollectable/> <cus:SendStatements>${DataSource#SendStatements}</cus:SendStatements> <cus:Tolerance>${DataSource#Tolerance}</cus:Tolerance> <cus:CollectorName>${DataSource#CollectorName}</cus:CollectorName> <cus:ConversionRateType/> <cus:PaymentTerms>${DataSource#PaymentTerms}</cus:PaymentTerms> <cus:AutoCashRuleSet/> <cus:ApplicationExceptionRuleSet/> <cus:AutoMatchRuleSet/> <cus:ReminderRuleSet/> <cus:StatementCycle>${DataSource#StatementCycle}</cus:StatementCycle> <cus:GroupingRule>${DataSource#GroupingRule}</cus:GroupingRule> <cus:CreditClassificationValue/> <cus:AccountStatusValue/> <cus:RiskCodeValue/> <cus:CreditRatingValue/> <cus:BillLevel/> <cus:BillType/> <cus:MatchReceiptsBy/> <cus:PreferredContactMethod>${DataSource#PreferredContactMethod}</cus:PreferredContactMethod> <cus:PreferredDeliveryMethod>${DataSource#PreferredDeliveryMethod}</cus:PreferredDeliveryMethod> <cus:GenerateBill/> <cus:MatchByAutoupdate/> <cus:AutoReceiptsIncludeDisputedItems>${DataSource#AutoReceiptsIncludeDisputedItems}</cus:AutoReceiptsIncludeDisputedItems> <cus:ConsolidatedInvoice>${DataSource#ConsolidatedInvoice}</cus:ConsolidatedInvoice> <cus:CreditReviewCycleName/> <cus:CreditAnalystName/> <cus:CreditLimit/> <cus:CreditCurrencyCode/> <cus:StatementDeliveryMethod>${DataSource#StatementDeliveryMethod}</cus:StatementDeliveryMethod> <cus:OrderAmountLimit/> </typ:customerProfile> </typ:updateCustomerProfileAsync> </soapenv:Body> </soapenv:Envelope>

Provide the Username and Password of the Application User you intend to use to update the Classes. Test out a few customers first one-by-one before doing a full bulk load to ensure you get the correct output.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Overview of Revenue Management in Oracle Fusion Applications

What is Revenue Management?

Oracle Revenue Management Cloud is a centralized, automated Revenue Management product. It enables you to address revenue as defined in the ASC 606 and IFRS 15 accounting standards that came in 2018.

Oracle Revenue Management Cloud is an application that enables you to manage customer contracts and performance obligations easily so that you can address the revenue mandates that are in these new accounting guidelines.

There used to be differences between ASC and IFRS as to how revenue was recognized. But now, the two standards have converged. So the rules for recognizing revenue are now very similar between these two standards. More information can be found on a separate article: Overview of the ASC 606 and IFRS 15 Revenue Management Standards.

Features of Revenue Management

1. Revenue Management allocates revenue according to the published guidelines for the ASC 606 IFRS 15 standard.
2. Identifies and creates customer contracts and performance obligations in those contracts based on both seeded and user-defined rules. 
3. Has a rule-based engine called SubLedger Accounting (SLA) that creates journals for Revenue Management and send them over to either Oracle Fusion Cloud GL or externally, to E-Business Suite GL.
4. Books revenue when performance obligations are satisfied. It processes revenue independently of billing. 
5. Simplifies and automates revenue accounting across product bundles
6. The centralized dashboard to be your system of record for revenue data.
7. Has Pre-defined integration with Oracle E-Business Suite
8. Extract, Transform, and Load (ETL) functionality and Spreadsheet integration.
9. Several core-defined Revenue reports using BI Publisher (BIP) and Oracle Transactional Business Intelligence (OTBI), and also allows users to create their own reporting objects

Key Terminologies in Revenue Management

1. Customer Contract in Revenue Management is not in terms of a physical legal contract, but rather an accounting contract.
2. Performance Obligation is the promise to the customer that needs to be fulfilled so revenue can be recognized. 
3. Performance Satisfaction is the fulfillment of a Performance Obligation. Performance Satisfaction is measured in terms of accounting periods in terms of percentage or quantities.
4. Inventory items are products and services associated with price that your organization sells. This is an important data point in Revenue Management because this will be the basis for standalone selling price and the allocation of the transaction price.
5. Standalone Selling Price (SSP) is the price of a component of a contract if you purchase it separately.
6. Allocation determines the transaction price allocated to various performance obligations in the ratio of SSP. This is based on a relative method of allocation.
7. Transaction Price is the amount of consideration that is expected to be received for the transfer of goods or services. This could be fixed or variable. These are the amounts that are recognized as revenue when the performance obligation is satisfied.

Overview of Revenue Management Cloud

Below is a quick overview of Revenue Management Cloud, including the five steps to revenue recognition and also integration. So you can see integration within other Oracle Cloud products and with products outside of the Oracle Cloud as well.

Revenue Management Cloud can integrate with third-party solutions, including Oracle E-Business suite (EBS). A number of EBS applications such as Receivables, Contracts and Order Management have data that's relevant to this new revenue recognition process. You can use the predefined integration with EBS to bring that data over to the Cloud.

In addition to that, you can integrate to third-party non-Oracle applications. We provide File Based Data Import (FBDI) templates to allow you to use the template, populate them, generate a data file that you can then load to the Oracle Cloud. Or you can also even create a custom program from your third-party non-Oracle application.

In the diagram, there is also inbound integration with fusion receivables and project financial management. Also important is the outbound integration here to the Fusion Cloud General Ledger, or externally, to Oracle EBS GL. This means that a subledger journal is going to be generated and transferred over to GL. Once the Journal Entries have been posted, then the The balances cube (called the "Essbase cube") will be updated and you can create financial statements for your organization.

To know more about these Integrations, check out separate articles on Inbound Integration with Revenue Management Cloud and Integrating E-Business Suite with Oracle Revenue Management Cloud.

In the middle of the Diagram, you can see the five steps to revenue recognition. Below provides a summary of the five steps to revenue recognition:

Five Key Steps to Revenue Recognition

1. Identifying customer contracts. The first step in the process is to identify customer contracts from transaction lines. These contracts can be identified based on common attributes in transaction lines (i.e. Customer Name, Extensible Attributes, etc.). Contract Identification Rules are used to identify these common links together and group them in a contract. The Identify Customer Contracts job set creates the accounting for each stage of the Revenue Recognition Process.

2. Identifying Performance Obligations in those contracts. As mentioned in the terminologies, Performance Obligations are the promises you made to the customer. These are goods or services that you promise to deliver in exchange for payment. Performance Obligation Identification Rules are used to Identify these contractual obligations based on common links in the contract.

3. Calculating transaction Prices. Transaction price is price of the contract or deal. Think of the amount of expected consideration that your organization is going to receive for transferring those goods or services. The amount what you expect to receive from the customer after delivering the service or delivering the product.

4. Allocate the transaction price using Standalone Selling Prices. Determines how much revenue is going to be allocated for each service and product based on the Standalone Selling Price.

5. Recognize the revenue when that performance obligation has been satisfied. 

Revenue Management Process Flow

Before you can effectively use Revenue Management, there are a number of items you would have to configure first, such as registration of source systems, set the standalone selling prices, set the default accounts to use, etc. 

The Diagram below shows the steps to configure Revenue Management:

1. Extract Transform and Load. You would need to register data sources and source systems in Revenue Management to be able to import transactions from other applications. You can import these data using FBDI templates and load them into the Universal Content Manager (UCM) Server, before going into the Revenue Management Cloud tables.

2. Manage Standalone Selling Prices. You need to populate prices in the system to allocate the transaction price of a customer contract. That customer contract is going to products and/or services and each of those products and/or services need to have a standalone price. Revenue Management is going to use these standalone selling prices as the basis to allocate revenue. You can run processes in Revenue Management to calculate the prices or you can load them from a spreadsheet template.

3. Five Steps to Revenue Recognition. The Five steps to revenue recognition is where the actual process takes place. As previously mentioned, the five steps is to identify the customer contract, identify performance obligations, calculation of the transaction price, the allocation of that transaction price, and finally, recognize the revenue when you have satisfied the performance obligations.

4. Accounting. With the use of the SubLedger Accounting Engine, we will create accounting journals based on rules we have set. These rules are created Component by component, there are rules that are going to impact how the description of the journal looks like, what the journal lines are going to have, which accounts, which descriptions, etc. Create Accounting is the process that is going to look at these rules and create the journal.  Once the journal is created, it can be sent to GL, either Cloud GL or E-Business Suite GL. Financial statements such as balance sheet reports, and income statement reports can then be generated from the Essbase Cube.

A Working Example of Revenue Management

Below is an example a contract with a telecommunications company:

Item	Standalone Selling Price	Satisfaction Start Date	Satisfaction End Date	Revenue Recognized
Smart Phone	490.68	07/01/2016	07/01/2016	490.68
Voice Plan	588.82	07/01/2016	06/30/2017	50.01 (1st Month)
Data Plan	392.5	07/01/2016	06/30/2017	33.34 (1st Month)

The customer contract is going to include these inventory items: a smartphone, a voice plan service and a data plan service. Each has a defined standalone selling price, which is key to allocate the revenue properly. There is a time frame on when we can recognize revenue.

As for the Smart phone, we will recognize the revenue immediately, as the performance obligation has been fulfilled right away. For the Voice and Data plan, revenue will be spread out in terms of when the performance obligation will be fulfilled. We cannot recognize revenue immediately because we haven't completely fulfilled the service yet.

At contract inception, you are going to be seeing accounting entries, even prior to billing. So prior to billing, there will already be accounting entries generated under the new ASC606/IFRS 15 standard.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Overview of Revenue Management Configurations in Oracle Fusion Applications

This article shows an overview of Revenue Management Configurations in Oracle Fusion Applications. This article shares some components from another article: Configuring Revenue for Receivables in Oracle Fusion Applications, as that article configures the Revenue Management application to be used by Receivables.

Revenue Management Setups Mapped to the Five Steps to Revenue Recognition

Below are some of the common Revenue Management Configurations shared among other modules:

1. System Options
2. Source Document Type
3. Performance Satisfaction Plans

Below are some the configurations for Revenue Contract with Customers:

1. Contract Identification Rules
2. Performance Obligation Identification Rules
3. Performance Obligation and Implied Performance Obligation Templates (optional)

The Diagram below shows the different Configurations for Revenue Management:

Performance Satisfaction Plan Types. Performance Satisfaction Plan Types (also called Revenue Scheduling Type) indicate how the Revenue will be split. It can be a fixed or variable schedule, or depending on the periods. Performance Satisfaction Plan Types are attached to Performance Satisfaction Plans.

Performance Satisfaction Plans. (also called Revenue Scheduling Rules) dictate if we're going to recognize the revenue at a point in time at once, one period, or over time, multiple periods, etc. We'll be thinking about quantities, percentages, or maybe we'll be thinking in terms of an accounting period on how to recognize the revenue. For more information on Revenue Scheduling Rules and Scheduling Types, check out a separate article: Manage Revenue Scheduling Rules in Oracle Fusion Applications. Performance Satisfaction Plans are attached to a Source Document Type.

Source Document Types. Source Document Type are needed for integrations. Source Document Types are already predefined for integrations with Oracle E-Business Suite and for Oracle Cloud applications. If you are bringing data or integrating to third party applications, you're going to have to define those. Examples of Source Documents are Sales orders, Service contract, Warranty contract, etc. For more information on Source Document Types and Type Codes, check out a separate detailed article about it: Source Document Types and Type Codes in Revenue Management Cloud

System Options. Revenue Management System Options is where you'll be attaching a Source Document Type. You would need to specify revenue clearing account for each Source Document Type to identify the default accounting combination.

This setup can be found in the "Manage System Options for Revenue Management" task.

Aside from Source Document Types, there are different sections in System Options because these are settings for the whole Revenue Management as a product module. Each section is highlighted in detail below:

1. Currency Conversion Section - Here you can specify a Conversion Rate Type for Multicurrency Processing.
2. Integration - here is where we populate Source Document Types and the default Revenue Clearing Account. We also specify the Extraction Start Date. That's when the first extraction is going to take place and going forward, you're going to continue to extract data from that specific source. The data will be extracted from the applications and into the interface tables to creating customer contracts.
3. Oracle Fusion Receivables Transaction Sources - This is a section exclusively for Fusion Receivables. Here, you would have to populate Receivable Transaction Sources. Receivable Transaction Sources pertain to Invoices, credit memos, debit memo that's created in the Cloud Receivables module. When you populate the relevant transaction sources from Cloud Receivables, that indicates that we want to transfer data associated with these transactions to Revenue Management so that we can comply with the Revenue standard. Similar to the Integration section, it also has the  Extraction Start Date field.
4. Revenue Accounting and Thresholds - Here, we can specify the GL accounts for contract liability, contract asset, etc. All the way to the right, we can specify Thresholds Amounts. Thresholds for Transaction Price Exemptions, Discount Exemptions, and then Transaction Price Review. If you populate a threshold amount, what that means is if the customer contract exceeds that amount, then you're going to subject that customer contract to manual review. A human being is going to review the contract and validate it and make sure everything is correct.

To Identify contracts with customers, you need to setup the following (click on each link for a detailed article):

1. Contract Identification Rules
2. Performance Obligation Identification Rules
3. Performance Obligation and Implied Performance Obligation Templates (optional)

The summary of each setup is provided below:

1. Contract Identification Rules. Contract identification Rules will to determine which transaction lines are included in a contract. The idea here is to use Source Document Type Codes (DFFs) to match lines so that you can group them into a contract. Examples of those can be quote numbers, purchase order numbers, etc. 

2. Performance Obligation Identification Rules. Performance Obligation Identification Rule are rules used to group source document lines into performance obligations. The idea here is to look for the common link between source document lines and identify what are the performance obligations of the contract.

A key concept for Contract Identification Rules is the Creation of Contracts while the concept for Performance Obligation Identification Rules is Identify the contract's obligation.

3. Performance Obligation and Implied Performance Obligation Templates. Performance obligation templates are used to define bundles that are routinely sold to customers. An example of this would be where a customer is purchasing a phone. With that phone, they're getting a free car charger. Both the phone and the car charger is a performance obligation and are commonly sold together. The difference between Implied and Non-Implied is with the Implied Performance Obligation, the bundled item isn't from the Source System. Unlike in the Implied Performance Obligation, it comes from the source system.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Configuring Revenue for Receivables in Oracle Fusion Applications

What is Revenue Management? 

Oracle Revenue Management complies with accounting standards that tell the organization to recognize the revenue later after the invoice has been sent. A sample of this would be a multi-period Mobile contract for Voice and Data Subscription, or Streaming Subscription, or a Software Support Contract. 

The concept of Revenue Management is that your organization sells a service or product to your customer, but have not fully delivered that service, we cannot fully recognize the whole revenue for that invoice at once because we have to follow an accounting standard. What Revenue Management does is we prorate our revenue from the start and end of the contract. For Example, the contract was for a 12-month period, that's the bill will be pro-rated for 12 months.

An example we can use for this whole article would be a support service provided by Oracle Corporation for a period of 12 months for $100,000.00. The Support fees would be pro-rated in a 12-month accounting period, instead of having it only at one accounting period. 

Depending on your Requirements, you may need to configure or update the following setups related to revenue:

1. Setup Revenue Recognition
2. Revenue Scheduling Rules
3. Define Revenue Policies
4. Define Revenue Contingencies

Each of these setups will be discussed in detail below.

Setup Revenue Recognition - It's a collection of defaults, options, functionality features that is broken down into two areas, billing-related and cash-processing system options and customer payment system options. Below are the setups for Revenue Recognition:

1. Salesperson System Options - Allows an organization to require a Salesperson when you enter an invoice. The idea here is to assign sales credit to that person that sold the product or service so that they can receive commissions based on their sales.

It also has an implication in terms of revenue recognition, because if you make an adjustment to their revenue, the sales credit of that salesperson will be impacted. If the salesperson gets paid based on revenue, an adjustment will also be made to his or her commission. 

In some cases, you compensate salespeople on revenue and non-revenue, so it doesn't have to equal 100%. You can strictly compensate a salesperson based on revenue. To do this, you can enter a value in the Sales Credit Percent Limit field.

1. Revenue Adjustment Reason Lookup Type – If you create an invoice with revenue recognition rule that has the deferral option turned on, then you need to make sure that you track the reasons for revenue recognition. This Lookup just means you can add reasons to the seeded reasons list so that users can pick the value they need when they are about to recognize revenue manually.

1. AutoAccounting based on a Standard Line - If AutoAccounting is based on standard line, the transaction line must either be an inventory item or a memo line, and not a user-entered line.

When you are entering lines for an invoice in receivables, those lines can be adhoc. If you enter an adhoc line, it's going to be difficult for receivables to generate the required revenue accounting information. It doesn't know how to generate the accounting distributions for that line.

However, if it's an inventory item that you are using in an invoice line, AutoAccounting can generate the accounting distribution. It can also can be a standard line, which means that you are defining products and services outside of the inventory module.

Revenue Scheduling Rules - You can create an invoice with revenue recognition rules. A scheduling rule is a rule that tells receivables how to allocate our revenue into the future. It can be that a revenue scheduling rule that tells receivables not to recognize revenue now, we are going to recognize the revenue manually in the future by processing a revenue adjustment. For more information about Managing Revenue Scheduling Rules, check out a separate article: Manage Revenue Scheduling Rules in Oracle Fusion Applications.

Revenue Policies - Revenue Policies allow your organization to make automatic revenue recognition decisions for manually entered and imported transactions. This works in connection with revenue contingencies.

To create Revenue Policies, go to the Functional Setup Manager, pick the Financials offering, select the Revenue Recognition functional area and choose the Task “Manage Revenue Policies”.

Revenue policies can be based on different criteria such as:

1. Credit classification- When you create a customer, you can assign that customer a credit classification in the customer profile class setup. It can be excellent, average or poor credit. For example, the customer has excellent credit classification, then you might decide to recognize their revenue right away because they are good payers. Or on the other hand, you may want to recognize the revenue later on if the customers have poor credit, as you don’t want to recognize the revenue now and reverse it later on if the customer fails to pay.

1. Refund Policy Threshold- You can use the refund policy threshold column to enter the standard refund period represented in days that you offer to your customers. When you enter or import the transaction, if a line is associated with a contract, receivables analyzes the contract and look at the refund period. And if the contract offers a refund period that exceeds their refund policy, then our contingency is going to be assigned to the line. This is commonly used when your organization might have a certain refund policy where you may allow an unhappy customer a refund within 30 or 45 days. If that's the case, you might want to wait after the refund period has passed to recognize your revenue.

1. Payment Terms Threshold– Based on the Business Unit, payment terms and the transactions, receivables will identify that these are non-standard payment terms and therefore we are going to defer their revenue. This will dictate that we are only going to recognize the revenue after the removal event has happened, such as a customer payment, or after 60 days has passed, etc. For example, if there's an invoice created with these a non-standard NET 45 payment terms, it will be subject to a contingency and revenue will not be recognized unless the customer has already paid.

Revenue Contingencies - provides certain restrictions that you apply on revenue recognition that are going to be removed by an event. For example, the event can be payment, or the event can be that 30 days have passed, and now I feel comfortable that I can recognize the revenue.

How Does Revenue Contingencies Work?

You enter and complete the receivable transactions, either manually or automatically. Receivables will analyze the invoice and look at the contingencies and assignment rules that you have defined. If the customer specified in that invoice and the Business Unit matches the contingencies and assignment rules, it will proceed to determine if are there any restrictions for this invoice. 

If there are no restrictions, then it can go on and recognize the revenue. If it does find contingencies, it will defer the revenue and wait until a removal event takes place. The removal event in this example is a payment. The system will not recognize revenue until the customer pays. Once the customer pays, it will automatically recognize the revenue for that particular invoice. 

Removal Event – Removes the restriction based on an event such as a Payment, number of days passed, etc. For example, if a customer was billed with a non-standard payment term (NET 45), they will be assigned a revenue contingency, in which a payment will be the removal event. Once the customer pays, the restriction will be removed on the revenue, and we will recognize the revenue and report it because there's no risk anymore.

Revenue Contingency Assignment Rules - Defines a rule on how to apply that contingency. You can apply the rule to a given customer or a set of customers.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Overview of Advanced Collections in Oracle Fusion Applications

What is Oracle Advanced Collections?

Advanced Collections provides a comprehensive solution for managing and running the day-to-day collection operations. Advanced Collections can help an organization improve its cash flow, increase collection efficiencies, optimize customer relationships and instill corporate and fiscal discipline.

It allows the collectors to focus and track their on their collection activities with the help of Infotiles, which are containers of important information your collectors need to focus on.

Who uses Oracle Advanced Collections?

Collectors are responsible for following up payments from delinquent and pre-delinquent Customers, tracking their activities and sending dunning letters. They will be responsible in minimizing the risk of financial exposure and making sure that the owed money is collected.

Below is a quick video Demonstrating how to setup Collectors:

Advanced Collections Infotiles

We have predefined Infotiles for Advanced Collections in the Work Area:

1. Delinquent Infotile - Once an invoice is delinquent, it will get picked up by the processes and allocated against the particular collector with all of the delinquent invoices. Delinquent means that the invoice is still unpaid after its payment term.
2. Promises Infotile - Collectors can see if a customer has broken a Promise to Pay. Promise to Pay is, as the term implies, a promise made by the customer to pay their overdue invoice. If such promise is broken, you can apply collection strategies to that customer to perform Dunning, a phone call, an escalation, etc.
3. Strategy Tasks Infotile - This Infotile shows the Strategies collectors need to work on, such as following up on a payment by making a phone call, or sending a dunning letter. Strategies are Tasks that can either be manual or automated. For more information on Strategy Tasks, check out a separate article, Overview of Collection Strategies in Oracle Fusion Applications.
4. Activities Infotile - This is where you've got other activities that aren't work items from a strategy that you need to complete. So you can create them yourself, or somebody else might create them and assign them to you. And as you can see, when you're in here, the strategy task, you could complete it, cancel it, or reassign it to somebody else if you wanted to. A credit analyst can reassign a case folder to different credit analyst without needing an approval

Advanced Collections Features

Advanced Collections provides a way for Collectors to raise disputes, record payments, record a Promise to Pay.

1. Disputes - Disputes happen when a Customer has a concern regarding the Invoice they are being billed, it may be for a number of reasons such as billing error, a hardware issue, a promised discount, etc. The customer informs the collector about this and the collector can then go in and raise a dispute in behalf of the customer. Once approved, this will then go on to become a Credit Memo. For more information on disputes, check out a separate article, Overview of Collection Disputes in Oracle Fusion Applications.
2. Payment
3. Promise to Pay - As previously mentioned, a Promise to pay is a promise made by the customer to pay their overdue invoice. Payment promises are made after the transaction's payment term is overdue. For Example, if the invoice date is 1-May-2019 and the payment term for that invoice is NET 30, then the due date for an invoice. would be 31-May-2019. However, the customer failed to pay the invoice, thus, a promise to pay can be created to collect either a partial payment or a full payment.
   

Collections Case Folder

Allows you to group together related transactions to increase collection efficiency. Typically, they have the same bill-to customer which is used by a collector to take action on that collections cycle. You can use it to group similar transactions together, perform your collections activity against the entire group simultaneously.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Creating a Manual Refund in Oracle Fusion Applications

This article demonstrates the steps involved in creating a Manual Refund via an On-Account Credit Memo.

1. Navigate to the Receivables Application > Billing Work Area 





2. Click on the Task Panel and create an On-Account Credit Memo:





3. On Create Transaction screen, fill up the necessary details to create a Credit Memo. Make sure the Transaction Class selected is a Credit Memo:



4. Fill up the Bill-To Name and the Ship-To Name, including the Amount and Quantity of the Credit Memo. Also note to use the negative sign for Credit Memos:





5. Once complete, click on Complete and Close to complete the transaction.





6. A confirmation message confirms that the Credit Memo has been created.







7. Next, login as a User with enough privilege credentials in Payables then Go to Accounts Receivables Work Area and click on the task Panel and select Apply Credit Memos










8. Search and Select for the On-Account Credit Memo you created and click on "Issue Refund":





9. On the Issue Refunds screen, populate the required fields and click on "OK". This populates the Payables Open Interface Tables and creates a Payment Request in the form of a Payables Invoice.





10. To verify if the Credit Memo has been applied, go back and search for the Credit Memo in the "Manage Credit Memo Applications" screen. Notice that the Unapplied amount has been reduced to Zero:





11. Next, navigate to the Payables Work Area and check on the Invoice created for the Customer for the refund.










On the Payables Work Area, search for the recently-created Invoice and select it. You can either Account for the transaction or refund the Customer in full.








On the actual Invoice, click on "Actions" and select "Pay in Full":

The Payment Details screen will appear and fill up the necessary details to complete the Payment:








Once done, click on "OK" and a confirmation message will appear:








To confirm if the Payment has been initiated, re-search the invoice and check the Payment Status:

Below is a quick video demonstration of Issuing Manual Refunds in Oracle Fusion Applications

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/

Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)