One record per real customer, assembled from the ERPs, the CRM and the portals, with every source key kept.
Objects are read through Oracle Fusion's REST resources and, for volume, through BI Cloud Connector extracts landed in your lake; the rows stay in Oracle.
| Object | Read from | Fields the domain uses | Freshness |
|---|---|---|---|
| Party and account | HZ_PARTIES · HZ_CUST_ACCOUNTS (REST: accounts) | PARTY_ID · PARTY_NAME · ACCOUNT_NUMBER · TAX_REFERENCE | live through REST; extracts refreshed on schedule |
| Sites and uses | HZ_CUST_ACCT_SITES_ALL · HZ_CUST_SITE_USES_ALL | SITE_USE_CODE (BILL_TO, SHIP_TO) · LOCATION | live through REST; extracts refreshed on schedule |
| Profile and credit | HZ_CUSTOMER_PROFILES · HZ_CUST_PROFILE_AMTS | STANDARD_TERMS · OVERALL_CREDIT_LIMIT | live through REST; extracts refreshed on schedule |
| Orders | REST: salesOrdersForOrderHub | OrderNumber · BuyingPartyId · TotalAmount | live through REST; extracts refreshed on schedule |
The first object above carries the strong keys; the standardised attributes come from the same rows. Two records match when a strong key agrees, or when name and address agree closely and no strong key disagrees.
Writes go through Fusion REST resources or import management. Each call returns the record id or an error, and Lima records both beside the change.
| Interface | Used for | Result |
|---|---|---|
REST crmRestApi/resources/latest/accounts · findDuplicates action before create · import management for volume | golden values approved for write-back: identity; addresses; contacts and roles | the id or error Oracle Fusion Cloud returns, stored beside the change |
Write-back is off per object until a test write succeeds, and approval rules can require a person per object. Reconciliation compares the source row with the golden value on a schedule.
Fusion roles and data-security policies are mapped to Lima access policies once; a person sees the same organisations here as in Fusion.
| Object | On Oracle Fusion Cloud | On Oracle E-Business Suite |
|---|---|---|
| Party and account | HZ_PARTIES · HZ_CUST_ACCOUNTS (REST: accounts) | TCA tables HZ_PARTIES/HZ_CUST_ACCOUNTS with the AR customer interface |
| Sites and uses | HZ_CUST_ACCT_SITES_ALL · HZ_CUST_SITE_USES_ALL | same objects |
| Profile and credit | HZ_CUSTOMER_PROFILES · HZ_CUST_PROFILE_AMTS | same objects |
| Orders | REST: salesOrdersForOrderHub | same objects |
Customer on
Other domains on Oracle Fusion Cloud
The golden record reads the objects above in place. History the pivot needs at scale is landed in your lake by the Backbone, under the same keys, security and audit.
Grant the read access and the write interfaces listed above and agree the refresh method. Nothing is installed in Oracle Fusion Cloud.
Yes. Write-back stays off per object until a test write succeeds; the golden view, the API and the pivots work from day one on reads.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
