By: Greg Moler | Director of Imaging Solutions

Does your organization utilize Oracle Fusion Applications such as Oracle Cloud ERP, Cloud Human Capital Management, and Project Portfolio Management cloud?  Are you looking for ways to extend the functionality of these applications?  These platforms store a lot of critical business data, much of which has the potential to be integrated with other third-party applications.  In this article, we explore use cases and considerations for leveraging Oracle BI reports to integrate Oracle Fusion data with external applications.

What are Oracle BI reports?

Oracle’s Fusion Applications including Cloud ERP, Cloud Human Capital Management, and Project Portfolio Management cloud as well as many others, use the Oracle Business Intelligence (BI) platform to provide reports and analytics.  BI reports provide a way to query and report against the underlying data in these platforms.  In the cloud platform, these take the place of traditional database queries.  They can be used in a variety of different functions to extract data for use with external applications.

Use Cases

When it comes to potential use cases for extending your Oracle Fusion application’s data, the possibilities are endless.  If you can think of a need, we can design a way to build it.  In this section, we take a glimpse at some specific use cases for integrating data from Oracle Cloud ERP.

• Automating GL/Project Account Coding: Manually coding invoices can be time-consuming for AP personnel. This process can be streamlined by automating business logic to programmatically apply GL and Project codes to invoices.  For example, often one attribute on the invoices drives the rest of the coding.  Another common scenario is vendor distribution sets, where each vendor has a pre-defined set of charge account strings and percentages that get applied to each invoice.  BI reports can be structured to take input from your 3^rd party application such as vendor id and return coding data.
• Workflow routing and Approval hierarchy: If your application does workflow routing or approval hierarchy, it will need to know which user’s documents should be assigned to. Often, this is based on data on the document and can be retrieved from Cloud ERP.  BI reports can be designed to return the appropriate workflow assignee based on the pertinent ERP data.  If your organization also utilizes Oracle Human Capital Management (HCM), you can extend functionality even further by directly accessing employee data in the approval hierarchy.
• Vendor data: Vendor data stored in Oracle Cloud ERP can be incredibly useful in a variety of different scenarios. For example, vendor identification on invoices, purchase orders, and other documents.  Another common use case is the use of vendor-specific attributes or descriptive flex fields (dffs) defined in Cloud ERP.  These attributes can be easily maintained by the business in the Fusion interface and leveraged in an external application to drive automation such as account coding or workflow routing as described previously.
• Validation data: More than likely, your application will need to be able to validate that the data on the document or object is correct before allowing it to proceed. The information needed to perform this validation is typically stored in Cloud ERP.  For example, validating whether a purchase order had enough open balance available for a line item.  BI reports provide a way to perform these validations, simply by taking input parameters from the external application and returning corresponding data from cloud Fusion.
• Reporting data: Reporting options within Fusion Applications and Oracle Business Intelligence platform can be limited. These reporting capabilities can be supplemented by an external reporting tool.  BI reports provide a way to extract data out of Oracle for analysis and reporting in an outside application.

 Considerations when creating Oracle BI Reports:

When designing and creating Oracle BI reports for integration with an external application, there are many considerations including:

• Data Structure: Design a reusable format for your BI reports so that data is returned in a consistent structure. This will simplify integration points with the reports.
• Data return type: What return data type will your application require? XML? CSV?
• Catalog folder structure: Consider how to organize your catalog folder structure. Which reports function together and should be grouped together?  Which reports should be promoted together between environments?  The easiest way to migrate reports is to use the Archive/Unarchive function on an entire folder.  It is important to consider which reports should be archived together.
• Testing options: The most basic way to test the BI reports is through the Fusion Catalog Manger. This provides a good baseline test.  More than likely, the reports will be called via web service, so the next layer of testing should be done using a tool such as SOAP UI that will allow you to test calling web services.  This will allow you to call the web service and view responses as they will be received by the external application.  Keep in mind that all responses must be decoded before they can be consumed.

Interested in getting more out of your Cloud ERP data?  Contact TekStream to learn about how we can assist with your Cloud Fusion integration needs!

It’s no secret that Oracle licensing can be complicated. Between the never-ending legal jargon, Core calculations, and usage analysis, Oracle licensing can get complex. Often, it’s navigating these licenses, not the underlying technology, that can halt even the most well-intentioned Oracle Cloud migration efforts.

In this blog post, we’re going to take a closer look at how you can leverage your existing Oracle license to support your Oracle Cloud migration efforts to either Oracle Cloud Infrastructure (OCI) or Amazon Web Services (AWS).

What is a Bring Your Own License Model, Anyway?

Simply put, Bring Your Own License (BYOL) is a licensing model that lets you utilize your current on-premise Oracle license to support your Oracle migration and deployment to the Cloud – oftentimes at a significant cost savings.

BYOL on OCI

Is your organization leaning toward migrating your legacy Oracle system to OCI? If you have any existing Oracle software licenses for services like Oracle Database, Oracle Middleware, or Oracle Business Intelligence, you can leverage those existing licenses when subscribing to Oracle Platform Cloud Services (Oracle PaaS).

With BYOL, you can leverage existing software licenses for Oracle PaaS subscriptions at a lower cost. As an example, if you already have a perpetual license for Oracle Database Standard Edition, then you can leverage that license to purchase a cloud subscription to Standard Edition Database as a Service at a lower cost.

The total cost of ownership calculations can be complex with this option as you need to consider your existing cost of support, the added value you will gain from a cloud-based, self-healing, self-patching solution versus the cost of buying the solution outright without using BYOL. TekStream can help you weigh these options if you are thinking about leveraging BYOL for your cloud journey.

How Do You Use Your BYOL for Oracle PaaS?

So, how exactly do you use your existing Oracle software license to support your OCI migration needs? It’s easier than you may think:

• Select specific Oracle BYOL options in the Cost Estimator to get your BYOL pricing.

• Apply your BYOL pricing to individual cloud service instances when creating a new instance of your PaaS service. BYOL is the default licensing option during instance creation for all services that support it.

As noted, when creating a new instance of Oracle Database Cloud Service using the QuickStart wizard, the BYOL option is automatically applied.

Bring Your Own License to AWS

Oracle can be deployed on AWS using the compute resources (EC2). Like a standard server on your datacenter today, when using this migration strategy, you are responsible for the licenses of any software running on the instances (including Oracle database, middleware, or any other software instances).

You can use your existing Oracle licenses to run on AWS. If you choose this licensing approach, it is important to consider a couple of supporting factors.

If you are licensing a product by processor or named users on this platform, you need to consider the Oracle core multipliers referenced in the terms and conditions of your license agreement.

If you are using employee or user-based metrics, you can deploy solutions on AWS with little concern about these issues.

Many Oracle Unlimited and Enterprise License Agreements do not allow usage in AWS. If you are using one of these options for your Oracle licensing, we would recommend reviewing your contracts carefully before deploying these Oracle licenses on AWS.

Is the BYOL Licensing Model Right for You?

Regardless of which Cloud platform you choose (AWS or OCI), a Cloud migration is the perfect opportunity to reexamine your Oracle license structure. Whether you opt for the BYOL licensing model or choose to utilize a new licensing structure, take this opportunity to identify ways to reduce the cost of your overarching licensing structure.

Learn about alternative licensing models by downloading our free eBook, “A Primer on Licensing Options, Issues, and Strategies for Running Oracle CPU-based Licenses on Cloud.”

Need help? TekStream can help demystify the Oracle licensing process. We provide straightforward counsel and, most importantly, identify cost-saving opportunities while still maintaining full licensing compliance.

If you’d like to talk to someone from our team, fill out the form below.

By: William Phelps | Senior Technical Architect

When using Oracle Forms Recognition(“OFR”)  or WebCenter Forms Recognition(“WFR”) with the Oracle Solution Accelerator or Inspyrus, clients often engage consulting companies (like TekStream) to fine-tune extraction of invoice data.  Depending on the desired data to extract from the invoice, the terms “confidence”, “training”, and “scripting” are often used in discussing and designing the solution.  While these techniques justifiably have their place, it may be overkill in many situations.

Chances are, if you are reading this article, that you may already be using WFR.  However, the extraction isn’t as good as desired.  You may have been using it for quite a while, with less-than-optimal results.

In reality, there are several no-cost options that a customer can (and should) perform before considering ANY changes to a WFR project file or attempting to bring in consulting.  This approach is the “don’t step over a dollar to pick up a dime” approach.  Many seemingly impossible extraction issues are truly and purely data-related, and in all likelihood, these basic steps are going to be needed anyway as part of any solution.  There is a much greater potential return on investment by simply doing the boring work of data cleanup before engaging consulting.

The areas for free improvement should begin by answering the following questions:

1. Does the vendor address data found in the ERP match the address for the vendor found on the actual invoice image?
2. Is the vendor-defined in the ERP designated as a valid pay site?
3. In the vendor data, are intercompany and employee vendors correctly marked/identified?
4. Do you know the basic characteristics of a PO number used by your company?
5. Are the vendors simply sending bad quality invoice images?

Vendor Address Considerations

The absolute biggest free boost that a customer can do to increase extraction is to actually look at the invoice image for the vendor, and compare the address found on the invoice to the information stored in the ERP.  WFR looks at the zip code and address line as key information points.  Mismatches in the ERP data will lower the extraction success rate.  This affects both PO and non-PO invoice vendor extraction from an invoice.

To illustrate this point at a high level, let’s use some basic data tools found within the Oracle database for testing.  The “utl_match” packages will work to get a basic feel for how seemingly minor string differences can affect calculations.

Using utl.match.edit_distance_similarity in a simple query, two strings can be compared as to how similar the first string is to the second.  A higher return value indicates a closer match.

• This first example shows the result when a string (“expresso”) is compared to itself, which unsurprisingly returns 100.

• Changing just one letter can affect the calculation in a negative direction. Here, the second letter of the word is changed from an “x” to an “s”.  Note the decrease in the calculation.

• The case in the words can matter to a degree as well for this comparison. Simply changing the first letter to uppercase will result in a similar reduction.

• Using the Jaro Winkler function, which tries to account for data entry errors, the results are slightly better when changing from “x” to “s”.

Let’s now move away from theory.  In more of a real-world example, consider the following zip code strings, where the first zip code is a zip + 4 that may be found on the invoice by WFR, and the second zip code is the actual value recorded in the ERP.

In the distance similarity test, the determination is that the strings are 50/50 in resemblance.

However, Jaro Winkler is a bit more forgiving.  There is a difference, but it’s closer to matching both values.

The illustrations above are purely representative and do not reflect the exact process used by WFR to assign “confidence”.  However, it’s a very good illustration to visually highlight the impact of data accuracy.

The takeaway from this ERP data quality discussion should be that small differences in data between what appears on the invoice compared to the data found in the ERP matters.  This data cleanup is “free” in the sense that the customer can (and should) undertake this operation without using consulting dollars.

Both the Inspyrus and Oracle Accelerator implementation of the WFR project leverage a custom vendor view in the ERP.

• Making sure this view returns all of the valid vendors is critical for correct identification of the vendor. A vendor that is not found in this view cannot be found by WFR – plain and simple since the WFR process collects and stores the vendor information for processing.
• Also, be sure in this view to filter out intercompany and employee vendor records. These vendor types are typically handled differently, and the addresses of these kinds of vendors typically appear as the bill-to address on an invoice.  Your company address appearing multiple times on the invoice can lead to false positives.
• In EBS, there is a concept of “pay sites”. A “pay site” is where the vendor/vendor site combination is valid for accepting payments and purchases.  Be sure to either configure the vendor/vendor site combination as a pay site, or look to remove the vendor from the vendor view.

PO Number Considerations

On a similar path, take a good look at your purchase order number information.  WFR operates on the concept of looking for string patterns that may/may not be representative of your organization’s PO number structure.  For example, when describing the characteristics of your company’s PO numbers, these are some basic questions you should answer:

• How long are our PO numbers? 3 characters? 4 characters? 5 or more characters? A mix?  What is that mix?
• Do our PO numbers contain just digits? Or letters and digits? Other special characters?
• Do our PO numbers start with a certain sequence? For example, do our PO numbers always start with 2 random letters? Or two fixed letters like “AB”? Or three characters like “X2Z”?

Answering this seeming basic set of questions allows WFR to be configured to only consider the valid combinations.

• By discarding the noise candidates, better identification and extraction of PO number data can occur.
• More accurate PO number extractions can lead to increased efficiency inline data extraction, since the PO data from the ERP can be leveraged/paired, and can lead to better vendor extraction since the vendor can be set based on the PO number.

Avoid trying to be too general with this exercise.  Trying to cast too wide of a net will actually make things worse.  Simply saying “our PO numbers are all numbers 7 to 10 digits long” will result in configurations that pick up zip codes, telephone numbers, and other noise strings. If the number of variations is too many, concentrate on vendors using the 80/20 rule, where 80% of the invoices come from 20% of the vendor base.

General Invoice Quality

Now, one might think “I cannot tell the vendor what kind of invoice to send.”  That’s not an accurate statement at all.  If explained correctly, and provided with a proper incentive, the vendor will typically work to send better invoices.  WFR is very forgiving, but not perfect, and looking at the items in the following list will help.

• Concentrate initially on the vendors who send in high volumes of invoices.
• Make sure the invoices are good quality images containing no extra markings on the image that is covering key data, like PO numbers, invoice numbers, dates, total amount, etc.
• Types of marks could be handwriting, customs stamps, tax identification stamps, mailroom stamps, or other non-typed or machine-generated characters. Dirty rollers on scanners can leave a line across the image.

Hopefully, this article will give an idea of the free things that can be done to increase the efficiency of WFR.

Want to learn more? Contact us today!

By: William Phelps | Senior Technical Architect

One of the thornier issues when working with Oracle’s Forms Recognition Accounts Payable (“AP”) project is simply and correctly determining and extracting a correct purchase order number from the invoice image.  This seemingly mundane task is further complicated when the purchase order number is a mere simple string of digits, much like, and sometimes confused with, telephone numbers, serial numbers, shipment numbers, and similar purely numeric strings found on the invoice.

This is a common problem for many companies using the AP Solution project, and it’s a fair bet that if you are reading this article, your company has the same or similar issue.

Let’s note upfront that there is no one magic solution bullet that will fix all extraction problems.  This article is intended as a fine-tuning methodology once very basic solutions and ERP data cleanup has occurred.  It’s at that point, when the easy stuff has been done that any additional techniques should be applied.  (A certified partner can help make these advanced changes with less overall effort and better end results.)

In general terms, the Oracle AP project provides a process called “PO masking” to allow the customer to tell the software about the general characteristics of their PO number structure.  This approach uses somewhat simple regular expressions (or “masks”) to derive potential strings deemed to be viable PO number “candidates” that it encounters while parsing the invoice text.  This kind of generalized setup almost always produces extraneous candidates.  Often it’s further determined by the process that, from this list of candidates that it extracts, some candidates are deemed a better match based on where the string is found in the document.  It places a lower ranking, called “weighting”, on candidates that may be embedded within the body of the invoice, like the case when the PO number is listed within a line description, and instead places a higher “weight” on a wrong value near the page header or top of the invoice.

A somewhat more educated and targeted way to help Forms Recognition get to that right value will involve an additional detailed look at the list of potential candidates.  During this further programmatic inspection, we can try removing or reducing the “weights” of those potential candidates that we think are misses by using true regular expressions in Visual Basic.

For a very simple example, a given operating unit may have only a handful of unique patterns for their PO numbers. Wide, generalized mask definitions intended for multiple operating units will likely result in more misses.

In WFR using the Inspyrus/Solution Accelerator PO header view (“xx_ofr_po_header_v”), the operating unit is available in the view alongside the PO number.  Using this information indirectly, the PO candidate weights can be altered to increase the accuracy of the extraction.

In these cases, the incoming invoice should be coming from a process that is pre-assigning the correct operating unit.  Since we will know the general PO number patterns for each operating unit, the list of extracted potentials can then be whittled down to a very precise list. (The real work is in determining the exact regular expression per operating unit, which is beyond the scope of this post.)

For today’s example,

• Open the AP Solution project in WFR Designer and edit the script for the Invoices class.
• On the UserExits script page, add the following function at the very bottom of the sheet. (Be sure to only add custom code in designated or legal areas of the script page for supportability.)

Then, in “UserExitPONUmberPostEvaluate” on the same script sheet, update the subroutine with the PO filtering code below:

Save the project file and try processing those problem vendors and purchase order numbers again.

Variations of this code have been deployed at several customers, resulting in much-improved PO number extraction rates.  This increased extraction success rate translates into less manual correction and increased invoice processing throughput since PO lines can then also be paired with a greater success rate automatically.

As noted earlier, a certified partner can help make these kinds of advanced changes with less overall effort and better end results.

Contact us if this express lane to regular payments sounds like a great idea!