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)

Integrating E-Business Suite with Oracle Revenue Management Cloud

In this Article, you will gain an understanding of how Oracle E-Business Suite integrates with Revenue Management.

Before you can perform more work on these integrations, You need to have reference data in place such as enterprise structures, legal entities, ledgers, business units, Parties, Customers, customer accounts, customer account sites and inventory items in the Oracle Cloud. And you would need to read about Integrating with Revenue Management in Oracle Fusion Applications.

There are predefined programs in E-Business Suite called that extract data from EBS and bring it over to the Cloud. Below programs are run sequentially:

1. Extract Revenue Basis Data program
2. Create Billing Data program 
3. Create Revenue Management Data export file

The file created by the "Create Revenue Management Data export" program gets into the Cloud via the Universal Content Manager, and from there data gets pushed into the Revenue Management interface tables. Data will be validated and create customer contracts in the Revenue Management base tables by running a process called "Identify Customer Contracts".

Identify Customer Contracts will create contracts based on rules. These rules can be predefined or defined by your organization. Once that has been completed, Revenue Management can now perform the five steps to revenue recognition.

There is out-of-the-box integration with the below E-Business Suite modules

1. Order Management
2. Service Contracts
3. Receivables

These E-Business Suite modules have pre-built integration because they contain information relevant to Revenue Management Cloud. Service Contracts would contain contract information, Sales orders in Order Management, and invoices and credit memos information in Receivables.

Required steps to configure E-Business Suite integration with Revenue Management:

1. Apply patches provided by Oracle (25505159 and 
2. Configure system options in EBS Receivables to add a new tab. 
3. Profile Option "AR: Source System Value for Revenue Management"
4. Configure business events using Fusion Web Services
5. Set up EBS Secure Socket Layer (SSL) for consuming Fusion services

For steps 1, 4 and 5, go to Oracle Metalink Support and download the appropriate patches and notes on how to implement these steps. The patches are applicable for releases 12.1.3 and 12.2.x.

After that patch is applied, as we can see here, you're going to see a new tab shown below:

In Setting the profile option, the name of the profile option is "AR: Source System Value for Revenue Management" and the value that you want to set the option is "EBIZ". This is a mandatory setting in order to extract revenue basis data from EBS and bring that over to Oracle Revenue Management Cloud.

Once everything has been configured and set, you may proceed to extract revenue data by running a process in EBS called Extract Revenue Basis Data. Extract Revenue Basis Data is a request set that will run three sub-processes that does the following:

1. Extract Revenue data
2. Extract Billing data. 
3. Create a data export file that will be sent to the Universal Content Manager

After you have run an import process to transfer files into the UCM, the next process that needs to take place is Load Interface File for Import. This process transfers setup or transaction data files from a user-specified location to the interface tables. The interface tables we are discussing here are the Revenue Management interface tables.

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)

Integration with Revenue Management in Oracle Fusion Applications

This article discusses the Inbound Revenue data Integration with Revenue Management in Oracle Fusion Applications. Below are the Objectives of this Article:

1. Understanding inbound integration options with Revenue Management
2. Understanding how Oracle E-Business Suite integrates with Revenue Management
3. Understanding how third party applications integrate with Revenue Management
4. Understanding Outbound integrations with Revenue Management

Before you can perform more work on these integrations, You need to have reference data in place such as enterprise structures, legal entities, ledgers, business units, Parties, Customers, customer accounts, customer account sites and inventory items in the Oracle Cloud. Also, you would need to create a source system and item relationship called Spoke System Relationship.

Defining a Source System

This is part of the prerequisites for integration. Go to the task "Manage trading community source system" and click on "Create" and click on the option "Enable for Items" and also "Enable for Trading Community Members" because we're going to be loading inventory item information as well as customer information into the cloud.

Defining a Spoke System Relationship

A spoke system relationship is a relationship between items and a source system. This is required when integrating with third-party applications. To define a spoke system relationship, you would need to first Define Master Data.

To find out more about Defining a Spoke System Relationship, check out a separate article on Creating Items and Their Spoke System Relationship in Oracle Fusion Applications.

Defining Master Data means that you need customer and inventory item data loaded into Oracle Fusion before you can do integrations. There are predefined templates to upload customer information and import or update inventory items. Once done, you would need to register the source of the integration, called a Source System.

Prior to Performing a third-party or spreadsheet integration, you must register the source system so that you can then bring data into the Oracle Cloud and over to the Revenue Management interface tables. The Steps to Registering a Source System are:

1. Create a source system within the Trading Community Model
2. Import a source system reference file from a Spreadsheet

Inbound Integration to Revenue Management Cloud

There are multiple ways to bring data into Oracle Revenue Management Cloud. As mentioned, it can be through an FBDI template, or the pre-defined integration with E-Business Suite, or a custom program. The entry point for all solutions would be the Universal Content Manager (UCM).

Integration with E-Business Suite

There is out-of-the-box integration with the below E-Business Suite modules

1. Order Management
2. Service Contracts
3. Receivables

These E-Business Suite modules have prebuilt integration because they contain information relevant to Revenue Management Cloud. Service Contracts would contain contract information, Sales orders in Order Management, and invoices and credit memos information in Receivables. 

There is a predefined program in E-Business Suite that extract data from EBS and brings it over to the Cloud via the Universal Content Manager. In turn, the UCM will populate the interface table and will create contracts in Revenue Management Cloud based on rules. Note that there are required steps to configure E-Business Suite integration with Revenue Management.

For more detailed information on Integrating E-Business Suite with Oracle Revenue Management Cloud, check out a separate article: Integrating E-Business Suite with Oracle Revenue Management Cloud

Integration with other Oracle Fusion Cloud Modules

Oracle Revenue Management also tightly integrates with other Oracle Cloud applications such as Fusion Receivables, Cloud Project Financial Management Contracts since both of these applications contain data that's going to be relevant to the new revenue recognition standard.

For Cloud Receivables, source documents such as invoices, credit memos will be relevant to Revenue Management, while for Project Financial Management, it would be documents like contracts, warranties, etc.

There is a pre-defined process called the Extract Revenue Basis Data from Oracle Fusion Applications that will extract data from the other modules and populate the interface tables. After the interface tables have been populated, a process called "Identify Customer Contracts" needs to be run to validate that data and identify customer contracts, the same process used for E-Business Suite.

Setups for Revenue Management Integration with Oracle Cloud applications

There are some required configuration in the page "Manage System Options for Revenue Management". You would need to configure Source Document Types for both Receivables and Project Financial Management. Source documents are documents such as warranty contracts, specific types of invoices, or credit memos, etc.

You would need to specify revenue clearing account for each Source Document Type to identify the default accounting combination. Also, we see extraction start date. This indicates that starting on this date, the data will to be extracted from the Fusion applications and into the interface tables to creating customer contracts.

Additionally for AR, you need to configure Oracle Fusion Receivables Transaction Sources because every single invoice, credit memo, debit memo that you create in Receivables is associated with a transaction source.

Processing Historical Data

It will be important to load historical revenue and billing data for iterative modeling and comparative analysis. In the Manage System Options page, you will need to provide the start date for that particular integration to indicate how far you are going to integrate that source data for modeling.

The revenue standard was effective January 1, 2018, but you might make a decision to go back two years, or three years for modeling and comparative analysis. You can bring that data on or after January 1, 2014 from the E-Business Suite ERP or Financials Cloud ERP. You can not really bring that data over prior to this date.

Spreadsheet Integration using File-Based Data Import

Oracle Fusion has a number of templates that can be used to bring data over into Revenue Management from third-party applications with the use of File-Based Data Import (FBDI) templates. They allow you to bring revenue basis and billing data into the Cloud and over to the Revenue Management interface tables.

If you decide to go with the FBDI template, there are separate FBDI templates you need to use for revenue data (Revenue Basis Data Import) and billing data (Billing Data Import). The template will contain source header data from the source document, sales order, the warranty contract, and sublines that impact satisfaction information. You can download the FBDI template from Oracle Documentation: File-Based Data Import for Financials.

The Revenue Basis Data Import template will have three tabs, each one for different types of data:

1. Header Data (VRM_SOURCE_DOCUMENTS)
2. Line Data (VRM_SOURCE_DOC_LINES)
3. Satisfaction event information (VRM_SOURCE_DOC_SUB_LINES)

While the Billing Data Import only has one tab (VRM_BILLING_LINE_DETAILS).

You need to run an import process to get that CSV data file into the Cloud, called "File Import and Export". After the import process takes the data into the UCM server, run the process "Load Interface File for Import" to populates the Revenue Management interface tables. 

This will trigger the process "Validate Customer Contract Source Data" that will validate the data in the inteface. Next, you would need to run "Identify Customer Contracts" to create customer contracts from the Revenue Management base tables.

Custom Program using a SOAP Web Service

If you decide to go with a custom program, you will need two APIs for this integration, the Revenue Basis Data Import API and the Billing Import API. 

You will have to utilize the Web Service API to place a file in the UCM server. After the file is in the UCM server, you run the same process to load the interface tables ("Load Interface File for Import") and proceed to run another process to automate the five steps to revenue recognition ("Identify Customer Contracts"). 

Error Correction for Integrations

There is a spreadsheet template that Oracle provide that allows you to not only correct import errors but check for errors. This function is called "Correct Contract Document Errors in Spreadsheet" and is found by navigating to the Revenue Management work area.

Outbound Integration

With the use of the subledger accounting engine, we are going to generate journals in Revenue Management. Those journals will end up either in a target General Ledger. If your target General Ledger is Fusion GL, We're not going to do any outbound transactions because the journals are going to stay within the cloud.

However, if you are using EBS, what will happen here is that you will run Create Accounting as you normally would do. A data file will be created and sent over to the Universal Content Manager, then you then run a process to import those journal entries from the cloud and into E-Business Suite. This data is going to go to the GL interface tables in EBS. You can then run an import process that takes the data to the EBS GL production tables. It creates the journals. After you create the journals, then you can post those journals in EBS GL.

There are certain setups you have to do in the cloud to allow for this outbound integration with EBS. And so here you see the name of the task, Manage Subledger Application. Pick the desired application ("Revenue Management") and choose the application you'll transfer the Ledgers to. There is an option to transfer to EBS. You have to go with this option here to transfer ledgers externally to EBS.

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 Collection Disputes in Oracle Fusion Applications

What is a collections dispute? 

A Dispute is a situation where a customer is questioning the balance of a transaction, either in partial or in Full. Disputes could also be related to different reasons as well e.g. customer dissatisfaction about the product or service quality etc.

For example, a customer called in and Disputed a product because the delivered product was defective, thus, this can be a basis for a refund or a discount.

Disputes can also be raised even if those transactions are not yet due, there could be various reasons including tax errors, pricing errors due to which the customer would create a dispute.

How do collectors handle collection disputes?

In terms of the processing flow, they navigate to the Collections work area and go to the Transactions tab. There, you would be able to see a list of overdue transactions, as well as specific details on those transactions.

The collector would then pick a specific Dispute section. The collector would handle the dispute based on the interaction with the customer. It could be something like a line subtotal, a percentage of the balance. It can be a specific invoice line, or it might even involve a portion of the tax.

After selecting that specific Dispute section, then the collector should enter a reason, which is very important for reporting and tracking purposes. The reason can be something like a discount. The customer was perhaps expecting at discount that he or she was promised.

There are comments attributes or comment boxes that the collector can use to input details that will be visible to the customer, and another that will allow the collector to input internal comments not visible to the customer. 

Once these steps have been done, then what the collector will do is click on the Submit button to submit the dispute. At this point, the Credit Memo Request Approval is launched. Once approved, the a Credit memo will automatically be created and will deduct the value from the customer invoice.

Configurations for Dispute Processing

Collections Preferences

In the "Manage Collections Preferences" page, under Global Preferences, look for the "Correspondence" settings. There is a setting there that specifies if whether or not to send a dispute notice to the Customer. The idea here is that we will notify the customer that we acknowledge that they have raised a dispute on a transaction. There is a predefined BI Publisher template ("Dispute Confirmation Letter") that includes wording in it that the customer will receive when they get notified of a dispute. You can customize this as your organization requires.

Dispute Reason, Amount and Quantity

Tracking the Dispute Reason will help with reporting. Oracle already has predefined Dispute reasons but you may add more if organization requires their own dispute reasons. 

To add more Dispute Reasons, go to the Functional Setup Manager > Financials offering > Collections Functional area > search for the task "Manage Collections Lookups". Search for the Lookup "IEX_DISPUTE_REASONS". You can see there some of the sample Dispute Reasons that are going to be available to the collector such as Receivables error, cancellation, credit and re-bill, duplicated billing, free product, late payment. You may add more by clicking on the "+" Icon and populating the required fields.

The dispute amount is going to default based on the section that you select such as Subtotal, Tax, and Invoice Lines. Note that the Amount and Quantities cannot be greater than the actual current Amount or Quantity. 

Credit Memo Request Approval Process

As mentioned, the collector can initiate the dispute in the Collections work area by navigating to the Transactions tab and picking the transaction in question and raising a dispute. The collector would select a section in the transaction (i.e. line, tax, etc.) and would populate the disputed amount and/or quantities and click on the Submit button. The Credit Memo Request Approval workflow process is then is launched. The Credit Memo Request Approval is a workflow process managed by the Approval Management Extensions engine (AMX), which dictates to whom the approval goes to. This is usually the collector's direct manager.

Receivables Transaction Types

Make sure that receivables transaction types are configured for dispute processing. For example, a transaction type of invoices, debit memos, chargebacks must be associated with a Credit Memo type for dispute,

That way, when the Credit Memo Request Approval process is initiated, and receivables attempts to create a credit memo, it will be able to do so. It will look at the invoice, it will look at the transaction type, and from there, it'll know which Credit Memo Type to use.

Below is a quick video a demonstrating a Collection Disputes 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)

Defining a Scoring Model Calculation for Credit Management in Oracle Fusion Applications

Scoring Models help your organization calculate a credit score for customers. That credit score, in turn, will allow your credit analyst, your credit manager, to arrive at a decision. Scoring model calculation involves several data points connected to ranges. In addition, these data points are rated in terms of importance, referred to as the Weight.  From these variables, we will arrive at a credit score that we assign to the Customer.

Data Point Ranges

·       As the name implies, Data point ranges provide a range that the data point will be assigned a Score. Take the example below:

Range	From	To	Score
Current Balance	$0	$1000	10
Current Balance	$1000	$2000	20
Current Balance	$2000	$3000	30

If the customer's balance falls between $0 to $1000 then the score would be 10, and if the customer's balance is within $2000 to $3000 then the score would be 30. A data point range can be numeric or alphanumeric. For numeric ranges, note that there shouldn't be any gaps to ensure the customer gets assigned a score. 

For alphanumeric data point ranges, its a bit more complex. The way it works is that the From and the To range must be the same. Below is an example:

Range	From	To	Score
Range 1	A2B	A2B	10
Range 2	B3B	B3B	20

This means if the data point is exactly "A2B" it gets assigned a score of 10 and if the customer's balance exactly "B3B" then score would be 20.

Data Point Weight

Defining the Data Point Weights should be thought out carefully. Spend some time thinking about the importance of the different data points as that's going to impact the score that the customers are going to receive. Data Point Weights should reflect your organizational policy as you define the scoring model. Depending on how your organization see things, it may assign more weight to the Day Sales Outstanding metric versus the Overdue Amount, or the number of delinquent transactions.

Data Point	Weight in Percentage
Number of Invoices Paid Late	25
Days Sales Outstanding	25
Total Amount Due	50

In the example shown above, the Total Amount Due holds the highest importance, hence it is given the largest weight in percentage. As for the other data points, they are equally important and are assigned only 25% of the total data point weight.

Data Point Score

A sample Data Point score in a Case Folder would be shown below:

Data Point Category	Data Point	Value	Points Earned
Billing and Payments	Percentage of Invoices Paid Late	57	50
Billing and Payments	Days Sales Outstanding	15	60

The value corresponds to the Data Point range below:

Data Point	From	To	Score
Percentage of Invoices Paid Late	0	50	50
Percentage of Invoices Paid Late	51	100	100
Days Sales Outstanding	0	3	10
Days Sales Outstanding	3	6	20
Days Sales Outstanding	6	10	30
Days Sales Outstanding	10	15	60

Below is a quick demonstration of Defining a Scoring Model for Credit Management 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)