Oracle Fusion Data Mapping Guide

Overview

Auditoria runs its automations on its own copy of a customer's finance data. To create that copy, each field in the customer's system of record (SoR) is matched to a field in Auditoria. This matching is called data mapping. Because mappings are not yet visible or configurable in the product, they are set up by Auditoria during deployment.

This article contains the key concepts and terminology of the data model, the prerequisites for a mapping deployment, the supported systems of record and connection methods, how the mapping workbook is structured, how mapping works, how mappings are configured and checked during a deployment, and the standard Oracle Fusion mappings for the AP business objects: the status value mappings and the field mappings for vendors, vendor bills and bill line items, purchase orders and PO line items, and payments and payment line items.

Before You Begin

Confirm the following before you start a mapping deployment:

• The customer's ERP is a supported system of record. 
• The customer can provide query access (for example, WQL for Workday) and field permissions for the fields to be mapped.
• The mapping workbook for the customer's ERP is available. For the workbook, please see the attachment added to this article.
• Auditoria leads the deployment. An implementation partner works alongside Auditoria.

Key Concepts

This section defines the terms used throughout this guide and in the mapping workbook. Read it first if you are new to Auditoria data mapping.

Data Model

A system of record (SoR) is the customer's source system, such as their ERP, that Auditoria reads from and writes to.

The data model is Auditoria's own structured set of business objects and the fields on each one. It holds a copy of the SoR data that Auditoria works with.

For every business object, the data model defines a set of standard fields that are common across ERPs. A business object's complete field set is these standard fields plus any optional and extended fields. What changes from one ERP to another is how each field maps to the SoR, not the standard fields themselves.

Business Objects (Header-Level and Line-Level)

A business object is a category of finance record that Auditoria models, such as a vendor, a vendor bill, a customer, or a payment. Many business objects have two levels: a header, which holds the document-level details, and line items, which hold the individual lines on that document. For example, a vendor bill has a header and bill line items, and a purchase order has a header and PO line items.

The following table lists the AP business objects in the data model and shows which of them are included in the Oracle Fusion mapping template.

Table 1. AP Business Objects

AR business objects follow the same data model. The Oracle Fusion mapping workbook covers AP objects only.

Table 2. AR Business Objects

Standard and Extended Fields

Every field on a business object has a field type that sets whether it must be mapped. The field type appears in the Type column of every mapping table in this guide and in the workbook.

Table 3. Field types

A few standard fields are only relevant to certain ERPs. For example, Item ID applies to NetSuite. Those fields appear in the data model but are not mapped for ERPs that do not use them.

Calculated and Unmapped Fields

A calculated field is a standard field that Auditoria computes rather than pulling from the SoR, such as the age of a bill or a base-currency total derived from another amount. An unmapped field is a standard field that is not matched to any SoR field, such as Tags or Notes. Both are marked in the workbook and left blank in the source column on purpose. Do not map them.

Status Mappings

A status mapping matches the status values in the SoR to the statuses Auditoria uses, for each business object that has a status, such as invoice, payment, purchase order, vendor, and contract statuses. Each SoR names its statuses differently, so status mappings are set up for each customer and are not carried over from another SoR or another customer. The standard Oracle Fusion status mappings are listed in section 10.

System Roles

A mapping deployment involves the customer, Auditoria, and, where engaged, an implementation partner. The following table lists who does what in a deployment.

Table 4. Roles in a deployment

Supported Systems, Objects, and Connection Methods

Auditoria connects to the following systems of record. The connection method is how Auditoria reads data from, and where applicable writes data to, the SoR.

Table 5. Supported systems of record and connection methods

Not every ERP exposes every business object. SmartResearch applies to Workday only, AR is not offered for Coupa, and Item Receipt applies to the ERPs that use it. Confirm the object set in the ERP's workbook.

Mapping Workbooks (Templates)

The mapping workbook is the per-ERP Excel template that lists the business objects and their fields for that ERP. The customer-facing templates are published on docs.auditoria.ai. The working copy used in a deployment is the "Auditoria [AP or AR] Business Objects ... Data Mapping Template for Implementations" spreadsheet. Auditoria owns the workbook and its versioning.  

For each field, the workbook records the Auditoria field name as seen in the console, the field type (Standard or Extended), a description, the default SoR field name, and a column for the customer's SoR field name or query alias. It also includes status mapping tabs, where each Auditoria status is matched to the SoR's status values.

The default SoR field is the source field a standard field maps to out of the box. The SoR field name or query alias is the customer's own field name, or its alias in a query, that Auditoria reads the value from. Many standard fields map to a default SoR field out of the box; the workbook records those defaults and gives the deployment team a place to capture the customer's actual SoR field where it differs, plus any extended fields.

Published per-ERP mapping workbooks:

• NetSuite AP Data Mapping Template
• Workday AP Data Mapping Template
• Workday AR Data Mapping Template
• Coupa AP Data Mapping Template
• AP Universal Connector Data Mapping Template

How Mapping Works (Fetch, Decode, Encode)

A mapping is the configuration that connects a business object to the SoR. For each business object, a mapping defines three operations:

1. Fetch pulls the records for that business object from the SoR.
2. Decode interprets those records so Auditoria can use them in the app.
3. Encode prepares data that Auditoria sends back to the ERP.

Mappings are prepared from the completed workbook and applied per business object. They are set up in a non-production environment, such as Sandbox or UAT, and promoted to Production.

Configure Data Mappings

Mappings are configured during deployment, not by customer self-service today. The customer completes the workbook, and Auditoria prepares, applies, and validates the mappings.

New Deployment

1. Review the data model and confirm which systems connect and which business objects matter, for AP, AR, or both.
2. Auditoria shares the per-ERP mapping workbook with the customer.
3. The customer completes the workbook with their SoR field details and provides query access and field permissions.
4. Auditoria reviews the completed workbook and prepares the mappings. The customer does not fill in mapping configuration or request fields outside the template; Auditoria analyzes the workbook and adds the required mappings.
5. Auditoria applies the mappings, with a typical turnaround of 1 to 2 days.
6. Auditoria and the customer review the mapped data in the app and confirm it is correct.
7. Go live. Auditoria's automations run on the customer's mapped data.

Figure 1. Data mapping deployment flow between the customer, the implementation partner, and Auditoria

Changes to a Live Tenant

When a live tenant needs new or additional fields, contact Auditoria with the new or changed fields. The full workbook cycle is not repeated; the change is targeted to the fields involved.

How to Read the Mapping Tables

Each mapping table in this article lists the Auditoria field as it appears in the Auditoria console, the field type from Table 3, a description of what the field represents, and the corresponding Oracle Fusion field. 

The Oracle Fusion field column uses three special values:

• Not mapped: the field is not mapped to an SoR field. Auditoria manages or calculates the value.
• Do not map: the field must not be mapped. Auditoria derives the value, for example from the bill to vendor relationship.

Status Mapping

Auditoria normalizes Oracle Fusion status values to a fixed set of Auditoria statuses per object. Statuses determine how a record is treated in Auditoria, for example whether a bill counts as open or paid. The following tables list the standard status mapping for each object; the Description column states the Oracle Fusion condition behind each Auditoria status.

Table 6. Vendor bill (supplier invoice) status mapping

Table 7. Purchase order status mapping

Table 8. Payment status mapping

Table 9. Vendor status mapping

Vendor Field Mapping

The vendor object represents the supplier record: who the supplier is, how to reach them, and which entities they do business with. The following table lists the standard vendor field mappings.

Table 10. Vendor field mapping

Vendor Bill Field Mapping

The vendor bill object represents the supplier invoice: its identifiers, dates, amounts in bill and book currency, status, and payment terms. The following table lists the standard vendor bill field mappings.

Table 11. Vendor bill field mapping

Vendor Bill Line Item Field Mapping

Vendor bill line items carry the line-level detail of the supplier invoice: what was billed, in what quantity, at what price, and how each line is coded. The following table lists the standard bill line item field mappings.

Table 12. Vendor bill line item field mapping

Purchase Order Field Mapping

The purchase order object represents the PO header: its number, dates, the supplier and requester, its status, and its total. The following table lists the standard purchase order field mappings.

Table 13. Purchase order field mapping

Purchase Order Line Item Field Mapping

Purchase order line items carry the line-level detail of the PO: each line's type, coding, price or rate, quantity, and how much has already been billed against it. The following table lists the standard purchase order line item field mappings.

Table 14. Purchase order line item field mapping

Payment Field Mapping

The payment object represents a vendor payment: who was paid, from which bank account, in which currencies, and its processing state. The following table lists the standard payment field mappings.

Table 15. Payment field mapping

Payment line Item Field Mapping

Payment line items represent the bills paid with the payment, one line for each bill, with the amount paid against each. The following table lists the standard payment line item field mappings.

Table 16. Payment line item field mapping