Known Limitations
This document describes the known limitations of the iPaaS.com integration with Oracle ERP. These limitations reflect the way the integration is designed to work and the capabilities of the Oracle ERP environment it connects to, and they apply to all subscribers using this integration. Everything below is accurate at the time this documentation was written; where a behavior may change with your own configuration, the recommended step is to validate it in a staging environment before relying on it in production.
Table of Contents
Built for One Client's Oracle ERP Configuration
Scheduled Polling, Not Webhooks
No Bulk or Initial-Sync Mode
What the Integration Writes and What It Reads
Order Updates Are Partial
No Automatic Collision-Handling Method Selection
Prerequisites an Order Must Meet Before It Transfers
Extended Price Uses Whole-Number Quantities
Related Documents
1. Built for One Client's Oracle ERP Configuration
This integration was custom-built to work with one client's specific Oracle ERP configuration. Its mappings, prerequisites, and write behavior are shaped by that configuration.
Configuration scope: At the time this documentation was written, behavior with any other Oracle ERP configuration has not been validated. There is no shared or default Oracle ERP host; the endpoint is supplied by the client during installation.
What this means for you: If your Oracle ERP environment differs from the configuration this integration was built against, subscribers or their MiSP should validate every data flow in a staging environment before relying on it in production. Several shipped mappings also carry example values that must be reviewed and replaced for your environment; these are called out in the individual mapping collection descriptions.
2. Scheduled Polling, Not Webhooks
The integration retrieves data from Oracle ERP by polling on a schedule. It does not receive real-time webhook notifications from Oracle ERP when records change.
Transfer timing: At the time this documentation was written, transfers run on the configured poll schedule or when a subscriber runs a Manual Sync. Records created or changed in Oracle ERP are picked up on the next scheduled poll rather than the moment they change.
What this means for you: Expect a delay between a change in Oracle ERP and its appearance in iPaaS.com, bounded by your poll interval. If you need a record sooner, run a Manual Sync for it. The historical look-back on the first poll of each entity is controlled by that entity's Search Poll Days subscription setting.
3. No Bulk or Initial-Sync Mode
The integration transfers records incrementally as they are polled or manually synced. It does not provide a built-in bulk or initial-sync mode for loading a large volume of existing records at once.
Historical loads: At the time this documentation was written, existing records already in Oracle ERP or iPaaS.com are not automatically back-loaded when the integration is first installed.
What this means for you: To load a large set of existing records for the first time, use the supported bulk sync using iPaaS.com and Postman workflow. Ongoing changes are then kept in step through scheduled polling and Manual Sync.
4. What the Integration Writes and What It Reads
Data movement in this integration is directional. Only Orders (Sales Orders) are written back to Oracle ERP; all other entities are read into iPaaS.com only.
Orders (Sales Orders): At the time this documentation was written, Orders are the only entity written to Oracle ERP. They are created and updated in Oracle ERP from iPaaS.com, and they are also read from Oracle ERP into iPaaS.com.
Products, Product Inventory, Companies, Company Addresses, and Order Tracking: At the time this documentation was written, these entities are read from Oracle ERP into iPaaS.com only. The integration does not create, update, or delete these records in Oracle ERP.
What this means for you: iPaaS.com is not a source of truth for Products, inventory, companies, addresses, or tracking in Oracle ERP; changes to those records must be made in Oracle ERP directly. Only order data flows back to Oracle ERP.
5. Order Updates Are Partial
When the integration updates an existing order in Oracle ERP, it sends only the fields that are mapped and have a value. It does not perform a full-record replace.
Unmapped and empty fields: At the time this documentation was written, fields that are not mapped, or that resolve to no value, are omitted from the update and are not cleared in Oracle ERP; they keep their existing values.
Order must already exist: At the time this documentation was written, an update targets an order that has already been created in Oracle ERP. If the order does not yet exist, the update has nothing to target and the transfer stops with an error.
What this means for you: To change a value on an order, map the field and supply the new value; an update will never blank out a field you left unmapped. Create an order before attempting to update it. When an update cannot find the order, the error appears in the iPaaS.com Dashboard / Integration Monitoring / Error Logs.
6. No Automatic Collision-Handling Method Selection
The integration does not expose selectable collision-handling methods, and it does not automatically choose one for you.
Duplicate prevention: At the time this documentation was written, duplicate records are avoided by linking each transferred record to its matching record in the other system, rather than through configurable collision-handling methods.
What this means for you: You will not find collision-method options to configure for this integration. Reliable matching depends on stable identifiers in your data (for example, a stable company name, order number, and SKU), so keep those values consistent across transfers.
7. Prerequisites an Order Must Meet Before It Transfers
Writing an order to Oracle ERP depends on related records already existing. When a prerequisite is not met, the transfer stops with an error rather than creating an incomplete record.
Company must be a registered Oracle ERP customer: At the time this documentation was written, the company assigned to an order must already exist as a customer in Oracle ERP and be linked to that customer in iPaaS.com. The integration does not create the customer as part of the order transfer.
Line SKU must resolve to an existing Oracle ERP item: At the time this documentation was written, each order line's SKU must resolve to a valid item in Oracle ERP. A line whose SKU does not resolve cannot be written, and the integration does not create the item as part of the order transfer.
A matching iPaaS.com Location must exist for inventory: At the time this documentation was written, inventory transferred from Oracle ERP links to an iPaaS.com Location that matches the Oracle ERP warehouse name. The integration does not create Locations; subscribers or their MiSP must create them first, with names that match exactly.
What this means for you: Before enabling order writes, confirm each company used on an order is a registered Oracle ERP customer and linked in iPaaS.com, and confirm every product used on a line is registered as an Oracle ERP item. Before transferring inventory, create the matching iPaaS.com Locations. Prerequisite failures surface in the iPaaS.com Dashboard / Integration Monitoring / Error Logs, and the record can be retried once the prerequisite is satisfied.
8. Extended Price Uses Whole-Number Quantities
The extended-price calculation used on order lines multiplies the unit price by the ordered quantity treated as a whole number.
Fractional quantities: At the time this documentation was written, fractional ordered quantities are not supported by the extended-price calculation. A fractional quantity cannot be calculated and causes the line's extended-price calculation to fail.
What this means for you: Use whole-number ordered quantities on lines that rely on the extended-price calculation. If your business requires fractional quantities on these lines, submit a feature request through your iPaaS.com partner channel describing the requirement.
This document covers eight known limitations of the Oracle ERP integration. For details on how each individual data flow behaves — including the example values that must be replaced for your environment — refer to the Oracle ERP mapping collection descriptions linked below.