Contents
Summary
ID Format
Deleted Record Support
Custom Field Support
Mapping Collection Status
Duplicate or Conflicting Mappings
Supported Child Collections
System Caveats
Integration Flow
Mappings
Error Handling
Testing & Validation
Additional Notes
Related Documents
Summary
This documentation covers the mapping collections that capture Oracle ERP sales orders into iPaaS.com as Transaction records. The parent Sales Order collection maps the order's identity and header fields and links the order to its iPaaS.com Company; three child collections carry the order's line items, billing and shipping addresses, and shipment tracking; and a standalone tracking collection updates tracking on orders already present in iPaaS.com. All of these collections read from Oracle ERP into iPaaS.com — they never write back to Oracle ERP. Transfers are driven by scheduled polling and on-demand Manual Sync; the integration does not use webhooks.
ID Format
Manual Sync ID Format
Sales Order, Order Line, Order Address, and Order Tracking (child): Enter the Oracle ERP order number on the iPaaS.com Manual Sync page. Transferring an order this way brings across the order together with its line items, addresses, and tracking.
Order Tracking Standalone: Enter the standalone tracking identifier, which is made up of three parts joined by pipe characters — the line identifier, the order number, and the delivery identifier (line identifier | order number | delivery identifier). All three parts are required to locate a specific tracking record.
External ID Format (saved after sync)
On the first successful transfer, iPaaS.com saves the Oracle ERP order number as the external ID on a dedicated, platform-managed external-ID record. That external-ID record is the primary match used to route subsequent updates to the same transaction rather than creating a duplicate. The TransactionNumber field mapped on the transaction additionally provides visibility of the Oracle ERP order number on the transaction and serves as a fallback matching key: when no external-ID record yet exists for an incoming order, the integration links to an existing iPaaS.com transaction whose transaction number matches, then records the external-ID link for future transfers.
Each child record — line item, address, and tracking — is likewise saved with its own external-ID link so subsequent transfers update the same iPaaS.com record rather than creating a duplicate. Standalone tracking records resolve their parent transaction from the Oracle ERP order number and attach to it, so the corresponding order must already be present in iPaaS.com.
Deleted Record Support
Not supported. These collections capture records from Oracle ERP into iPaaS.com and do not delete records in either system. Deletes are not implemented for the Sales Order, Order Line, Order Address, or Order Tracking entities. Sales orders are the only records this integration writes back to Oracle ERP, and that write path supports creating and updating orders only — there is no delete operation.
Custom Field Support
None. These collections do not configure or require any custom fields. The order date and last-update date are captured into iPaaS.com as ordinary mapping destinations, not as configurable custom fields.
Mapping Collection Status
All five collections are Enabled. None of them has a mapping filter applied, so every order, line, address, and tracking record retrieved is processed.
Trigger Events:
Scheduled Polling: The integration periodically checks Oracle ERP for records created or updated since the last successful poll and transfers them to iPaaS.com. How far back the initial poll reaches is governed by subscription settings: the Transaction Search Poll Days setting controls the sales-order poll, and the Transaction Tracking Search Poll Days setting controls the tracking polls (for both the child Order Tracking collection and the standalone tracking collection). Order lines and addresses are not independently poll-driven — they are retrieved as part of the parent order.
Manual Sync: Any of these collections can be transferred on demand from the iPaaS.com Manual Sync page, regardless of the polling schedule.
These collections do not use webhooks. No Inbound Data Flows or webhook configuration is required or available for them.
Duplicate or Conflicting Mappings
This integration does not implement selectable collision-handling methods. There is no collision-method setting to choose on these collections. Instead, duplicates are avoided by linking each incoming record to an existing iPaaS.com record through external-ID links (and, for the parent order, the transaction-number fallback described under ID Format), and by matching prerequisites such as companies and products by their business keys before linking.
Two overlap situations are worth planning for:
Opposite-direction order collections. This integration also includes opposite-direction collections that write sales orders from iPaaS.com to Oracle ERP. Those collections operate on the same order data but in the reverse direction (iPaaS.com to Oracle ERP), while the collections documented here only capture orders from Oracle ERP into iPaaS.com. If both the capture (to iPaaS.com) and write-back (from iPaaS.com) directions are enabled for the same orders, decide which system is the source of truth for order data so that changes are not repeatedly copied back and forth between the two systems.
Child tracking versus standalone tracking. The child Add/Update Oracle ERP Sales Order Tracking TO iPaaS.com collection and the Add/Update Oracle ERP Sales Order Tracking Standalone TO iPaaS.com collection operate on the same iPaaS.com Transaction Tracking data. The child collection transfers tracking as part of the parent order transfer; the standalone collection transfers tracking on its own and attaches it to an order already present in iPaaS.com. Before enabling both, review their mapping filters and Add/Update settings so that tracking for the same order is not processed by conflicting configurations, and decide which collection is the source of truth for a given set of tracking records.
Supported Child Collections
The parent Add/Update Oracle ERP Sales Order TO iPaaS.com collection transfers the following child collections automatically as part of each order transfer:
Add/Update Oracle ERP Sales Order Line TO iPaaS.com: Transfers the order's line items, one record per line, linked to the parent transaction.
Add/Update Oracle ERP Sales Order Address TO iPaaS.com: Transfers the order's billing and shipping addresses, linked to the parent transaction.
Add/Update Oracle ERP Sales Order Tracking TO iPaaS.com: Transfers the order's tracking records (carrier and tracking number), linked to the parent transaction.
The Add/Update Oracle ERP Sales Order Tracking Standalone TO iPaaS.com collection has no parent and is not transferred automatically as part of an order. It updates tracking on transactions that already exist in iPaaS.com, resolving each record's parent transaction from the Oracle ERP order number. It is documented here because it overlaps with the child tracking collection — see Duplicate or Conflicting Mappings.
System Caveats
Oracle ERP Caveats
Read-only source: These collections only read from Oracle ERP. They never create, update, or delete orders, lines, addresses, or tracking in Oracle ERP.
Order identity: Orders are identified and matched by their Oracle ERP order number. A stable order number in the source is required for reliable matching across transfers.
Whole-number quantities: The line extended-price calculation treats the ordered quantity as a whole number. A fractional quantity cannot be calculated and causes the line's extended-price calculation to fail.
Billing versus shipping selection: Each address draws from the Oracle ERP invoice-to values when it is the primary billing address and from the ship-to values otherwise. The primary billing flag on the source record drives this selection.
Carrier drives shipping method: The Oracle ERP carrier name is the value matched against iPaaS.com Shipping Method names. Keep carrier names consistent with the Shipping Method names configured in iPaaS.com.
iPaaS.com Caveats
Company link required: A transaction must resolve to an iPaaS.com company (or otherwise carry a customer or email address) or iPaaS.com rejects the record. The related company is transferred automatically as a prerequisite when it does not already exist.
Transaction number matching key: iPaaS.com uses the mapped TransactionNumber as the fallback key to match an incoming order to an existing transaction before the external-ID link is established. Ensure the mapped order number is unique and stable per order.
Product match by SKU: Each line is matched to an iPaaS.com product by SKU. Ensure line SKUs are stable and correspond to real Oracle ERP items so products link correctly. A referenced product that does not yet exist in iPaaS.com is transferred automatically as a prerequisite.
Shipping Method must exist: The ShippingMethod value must match the name of a Shipping Method configured in iPaaS.com for tracking to associate with the correct method.
Standalone tracking requires an existing transaction: A standalone tracking record links to its transaction by the Oracle ERP order number. The transaction must already be present in iPaaS.com; if the order number does not resolve to a transaction, the tracking record cannot be attached. Transfer the sales order first so its transaction exists before transferring standalone tracking.
Integration Flow
When a scheduled poll runs or a Manual Sync is initiated, the integration processes a sales-order transfer in the following order:
Trigger and retrieve. A scheduled poll looks back over the window set by Transaction Search Poll Days (or Transaction Tracking Search Poll Days for tracking) and selects records created or updated since the last successful poll; a Manual Sync retrieves a specific order by its Oracle ERP order number. The integration reads the order and its line items, addresses, and tracking from Oracle ERP.
Resolve prerequisites. The order's company is matched to an existing iPaaS.com company by customer account number and, if it does not yet exist, is transferred automatically first; a company that cannot be resolved blocks the order transfer. For each line, the referenced product is matched in iPaaS.com by SKU and transferred automatically if missing.
Match the transaction. The integration checks for an existing iPaaS.com transaction using the external-ID record first, then the transaction-number fallback, so that a matching order is updated rather than duplicated.
Map and process children. Header fields are mapped and standard defaults are applied; line items, addresses, and tracking are processed through their child collections and linked to the transaction.
Create or update in iPaaS.com. The transaction and its children are created or updated in iPaaS.com, and external-ID links are recorded for the order and each child so future transfers update the same records.
Standalone tracking. Standalone tracking records flow independently of the order transfer. Each record resolves its parent transaction from the Oracle ERP order number and attaches to that transaction, which must already exist in iPaaS.com.
Order updates are additive with respect to fields the integration maps: only mapped fields are written on each transfer. If Oracle ERP is temporarily unavailable when a transfer is triggered, the transfer fails and an error appears in the iPaaS.com Dashboard under Integration Monitoring / Error Logs; the record can be retried through Manual Sync or on the next scheduled poll.
Mappings
None of the five collections has a mapping filter applied, so no filtering conditions are shown. Every record retrieved through scheduled polling or Manual Sync is processed.
Field requiredness in the tables below reflects how iPaaS.com treats each destination field: Required fields must be present for the record to be accepted; Recommended fields improve completeness and reporting but do not block the transfer; Optional fields add detail only. Static mappings set a fixed value on every record; subscribers or their MiSP who need a value to reflect each record's real state in Oracle ERP can replace the relevant Static mapping with a Field or Dynamic Formula mapping.
Add/Update Oracle ERP Sales Order TO iPaaS.com
Description: Captures Sales Order records from Oracle ERP and creates or updates the matching Transaction records in iPaaS.com. Maps the order's identity and header fields, links the order to its iPaaS.com Company, and applies standard transaction defaults.
Field Mapping Table
Mapping Type | Source Field (Oracle ERP) | Destination Field (iPaaS.com) | Description |
Dynamic Formula | Dynamic Formula | SystemId | Required, and must be greater than zero. Supplies the iPaaS.com system identifier that ties the transaction to the originating system. The value is provided automatically by the integration at transfer time; subscribers do not need to configure or change it. Formula: SpaceportSystemId |
Field | ORDERNUMBER | TransactionNumber | Required. Sets the transaction number from the Oracle ERP order number. On the first successful transfer the order number is saved as the external ID on a dedicated external-ID record (the primary match for subsequent updates); the transaction number additionally provides visibility of the order number and serves as a fallback matching key when no external-ID record exists yet. Map a stable, unique order number so orders match correctly and duplicates are avoided. |
Dynamic Formula | Dynamic Formula | CompanyId | Required in practice. A transaction must carry at least one of a company, a customer, or an email address; this integration supplies the company link, resolved from the Oracle ERP customer account number. If no matching company is found, the formula returns no value. The related company is transferred automatically as a prerequisite, so subscribers do not need to pre-create it. Formula: return await GetiPaaSCompanyIdByAccountNumber(CUSTOMERNUMBER); |
Static | Order | Type | Required. Set to the fixed value Order for all records, because this collection captures sales orders. Allowed values: Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return, Job. |
Static | Pending | Status | Required. Set to the fixed value Pending for all records. Allowed values: Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, Draft. |
Field | ORDEREDDATE | ORDERED_DATE | Recommended. Captures the Oracle ERP order date into the transaction. Improves record completeness and supports date-based reporting; the transfer will not fail if the source value is empty. |
Field | LASTUPDATEDATE | LAST_UPDATE_DATE | Recommended. Captures the Oracle ERP last-update date into the transaction. Improves record completeness and supports change tracking; the transfer will not fail if the source value is empty. |
Add/Update Oracle ERP Sales Order Line TO iPaaS.com (Child)
Description: Captures the line items of a sales order from Oracle ERP and creates or updates the matching Transaction Line records in iPaaS.com, one record per order line. Maps each line's product SKU, quantities, unit price, description, and tax, calculates the extended price, and applies standard line defaults. Lines are transferred as part of the parent order.
Field Mapping Table
Mapping Type | Source Field (Oracle ERP) | Destination Field (iPaaS.com) | Description |
Field | LINENUMBER | SequenceNumber | Recommended. Preserves the order in which lines appear on the order. Improves line ordering and readability; the transfer will not fail without it. |
Field | ORDEREDITEM | Sku | Required for this collection. Because the line Type is fixed to Product, the SKU must resolve to an existing product or variant in iPaaS.com. The line is linked to an existing iPaaS.com product by SKU; if no matching product exists, the product is transferred automatically as a prerequisite as part of the parent order transfer. Map a stable, unique SKU so lines match to the correct product. |
Field | ORDEREDQUANTITY | Qty | Recommended. Carries the quantity ordered for the line and feeds the extended-price calculation. |
Field | SHIPPEDQUANTITY | QtyShipped | Recommended. Records how much of the line has shipped; the transfer will not fail without it. |
Field | USERITEMDESCRIPTION | Description | Optional. Improves line readability; the transfer will not fail if the source description is empty. |
Field | TAXVALUE | EstimatedTaxAmount | Recommended. Carries the line's tax value; improves tax reporting completeness but the transfer will not fail without it. |
Static | Pending | Status | Required. Set to the fixed value Pending for all lines. Allowed values: Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, Draft. |
Static | Product | Type | Required. Set to the fixed value Product for all lines, because these lines represent stock-tracked goods. Because the type is Product, each line's SKU must resolve to an existing product or variant in iPaaS.com. Allowed values: Product, Giftcard. |
Field | UNITSELLINGPRICE | UnitPrice | Recommended. Carries the per-unit price for the line and feeds the extended-price calculation. |
Dynamic Formula | (Multiplies unit selling price by ordered quantity — see Dynamic Formula Documentation below.) | ExtendedPrice | Recommended. Calculates the extended price by multiplying the Oracle ERP unit selling price by the ordered quantity. The ordered quantity is treated as a whole number; a fractional quantity cannot be calculated and causes the calculation to fail. When either the unit price or the quantity is missing, no extended price is calculated. |
Dynamic Formula Documentation — ExtendedPrice
var extendedPrice = CalculateExtendedPrice(UNITSELLINGPRICE, ORDEREDQUANTITY);
return extendedPrice;
Add/Update Oracle ERP Sales Order Address TO iPaaS.com (Child)
Description: Captures the billing and shipping addresses of a sales order from Oracle ERP and creates or updates the matching Transaction Address records in iPaaS.com. For each address, the integration uses the Oracle ERP invoice-to values when the address is the primary billing address and the ship-to values otherwise. No address-level field is required by iPaaS.com for the transfer to succeed. Addresses are transferred as part of the parent order.
Field Mapping Table
Mapping Type | Source Field (Oracle ERP) | Destination Field (iPaaS.com) | Description |
Field | IsPrimaryBilling | IsPrimaryBilling | Recommended. Flags the primary billing address, and also selects which Oracle ERP values are used for the address fields below: when true, the invoice-to values are used; otherwise the ship-to values are used. |
Field | IsPrimaryShipping | IsPrimaryShipping | Recommended. Flags the primary shipping address; the transfer will not fail without it. |
Dynamic Formula | (Invoice-to first line when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | Address1 | Recommended. First address line: invoice-to first line when the address is the primary billing address, otherwise the ship-to first line. |
Dynamic Formula | (Invoice-to second line when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | Address2 | Optional. Second address line: invoice-to when the address is the primary billing address, otherwise ship-to. Improves completeness; the transfer will not fail if empty. |
Dynamic Formula | (Invoice-to third line when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | Address3 | Optional. Third address line: invoice-to when the address is the primary billing address, otherwise ship-to. Improves completeness; the transfer will not fail if empty. |
Dynamic Formula | (Invoice-to city when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | City | Recommended. City: invoice-to when the address is the primary billing address, otherwise ship-to. |
Dynamic Formula | (Invoice-to state when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | Region | Recommended. State or province: invoice-to when the address is the primary billing address, otherwise ship-to. |
Dynamic Formula | (Invoice-to postal code when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | PostalCode | Recommended. Postal code: invoice-to when the address is the primary billing address, otherwise ship-to. |
Dynamic Formula | (Invoice-to country when primary billing, otherwise ship-to — see Dynamic Formula Documentation below.) | Country | Recommended. Country: invoice-to when the address is the primary billing address, otherwise ship-to. |
Each of the address-line, city, region, postal-code, and country mappings uses the same pattern, varying only by the Oracle ERP field it selects: when the address is the primary billing address it returns the invoice-to value, otherwise it returns the ship-to value.
Dynamic Formula Documentation — Address1
if(IsPrimaryBilling == true){
return INVOICETOADDRESS1;
}
return SHIPTOADDRESS1;
Dynamic Formula Documentation — Address2
if(IsPrimaryBilling == true){
return INVOICETOADDRESS2;
}
return SHIPTOADDRESS2;
Dynamic Formula Documentation — Address3
if(IsPrimaryBilling == true){
return INVOICETOADDRESS3;
}
return SHIPTOADDRESS3;
Dynamic Formula Documentation — City
if(IsPrimaryBilling == true){
return INVOICETOCITY;
}
return SHIPTOCITY;
Dynamic Formula Documentation — Region
if(IsPrimaryBilling == true){
return INVOICETOSTATE;
}
return SHIPTOSTATE;
Dynamic Formula Documentation — PostalCode
if(IsPrimaryBilling == true){
return INVOICETOZIP;
}
return SHIPTOZIP;
Dynamic Formula Documentation — Country
if(IsPrimaryBilling == true){
return INVOICETOCOUNTRY;
}
return SHIPTOCOUNTRY;
Add/Update Oracle ERP Sales Order Tracking TO iPaaS.com (Child)
Description: Captures shipment tracking information for a sales order from Oracle ERP and creates or updates the matching Transaction Tracking records in iPaaS.com. Maps the carrier name to the iPaaS.com shipping method and the tracking number to the tracking record. Tracking is transferred as part of the parent order and can also be picked up by the tracking poll.
Field Mapping Table
Mapping Type | Source Field (Oracle ERP) | Destination Field (iPaaS.com) | Description |
Field | CARRIERNAME | ShippingMethod | Required. Maps the Oracle ERP carrier name to the tracking record's shipping method. The value must match the name of a Shipping Method configured in iPaaS.com; ensure each Oracle ERP carrier name corresponds to a configured iPaaS.com Shipping Method so tracking associates with the correct method. |
Field | TRACKINGNUMBER | TrackingNumber | Recommended. Carries the shipment's tracking number so downstream processes and customers can follow the delivery; the transfer will not fail if the source value is empty. |
Add/Update Oracle ERP Sales Order Tracking Standalone TO iPaaS.com
Description: Captures shipment tracking information from Oracle ERP and creates or updates the matching Transaction Tracking records in iPaaS.com independently of the parent order transfer. Maps the carrier name to the iPaaS.com shipping method and the tracking number to the tracking record, and links each tracking record to an existing iPaaS.com transaction resolved from the Oracle ERP order number.
Field Mapping Table
Mapping Type | Source Field (Oracle ERP) | Destination Field (iPaaS.com) | Description |
Field | CARRIERNAME | ShippingMethod | Required. Maps the Oracle ERP carrier name to the tracking record's shipping method. The value must match the name of a Shipping Method configured in iPaaS.com; ensure each Oracle ERP carrier name corresponds to a configured iPaaS.com Shipping Method. |
Field | TRACKINGNUMBER | TrackingNumber | Recommended. Carries the shipment's tracking number; the transfer will not fail if the source value is empty. |
Dynamic Formula | Dynamic Formula | ParentId | Required in practice. Links the standalone tracking record to its parent transaction in iPaaS.com by resolving the transaction's identifier from the Oracle ERP order number. The parent transaction must already exist in iPaaS.com; if the order number does not resolve to a transaction, the tracking record cannot be attached. Transfer the sales order first so its transaction exists. Formula: return await GetSpaceportIdAsync(ORDERNUMBER, "Transaction", SpaceportSystemId); |
Error Handling
Errors from these mapping collections appear in the iPaaS.com Dashboard under Integration Monitoring / Error Logs. For the full catalog of error messages, their descriptions, and resolution steps, see the Error Messages article. Common failure conditions include:
The order's company cannot be resolved to an iPaaS.com company by customer account number, which blocks the order transfer until the company prerequisite succeeds.
A line's SKU cannot be resolved to an Oracle ERP item or an iPaaS.com product, which prevents the line from linking.
A tracking record's carrier name does not match the name of a Shipping Method configured in iPaaS.com.
A line's ordered quantity is fractional, which causes the extended-price calculation to fail.
Oracle ERP is temporarily unavailable when a transfer is triggered; the record can be retried through Manual Sync or on the next scheduled poll.
Testing & Validation
Test Scenarios
Manually sync an order by its Oracle ERP order number and verify that an iPaaS.com transaction is created with the correct transaction number, type (Order), status (Pending), company link, order date, and last-update date, and that its line items, addresses, and tracking are transferred with it.
Sync an order whose company does not yet exist in iPaaS.com and verify that the company is transferred automatically as a prerequisite before the order.
Sync an order whose line references a product not yet in iPaaS.com and verify that the product is transferred automatically before the line is linked.
Re-sync a previously transferred order and verify that the existing transaction is updated rather than duplicated.
Verify that an order line's extended price equals the unit selling price multiplied by the ordered quantity, and confirm behavior when the quantity is fractional.
Transfer standalone tracking for an order already present in iPaaS.com and verify it attaches to the correct transaction; then confirm that standalone tracking for an order not yet in iPaaS.com does not attach.
Confirm that each Oracle ERP carrier name matches a configured iPaaS.com Shipping Method so tracking associates with the correct method.
Validation Checklist
The integration's connection settings are configured, including the poll-days settings that control how far back the initial sales-order and tracking polls reach.
A Shipping Method exists in iPaaS.com for each Oracle ERP carrier whose tracking will be transferred, with a matching name.
Mapping filters and Add/Update settings on the child tracking collection and the standalone tracking collection are configured so the same tracking is not processed by conflicting configurations.
If the opposite-direction write-back collections are also enabled, the source of truth for order data has been decided to prevent changes from being copied back and forth.
Additional Notes
Static defaults: Order type and status, and line type and status, are set to fixed values in the default mappings. Subscribers or their MiSP who need these to reflect each record's real state in Oracle ERP should replace the relevant Static mappings before relying on that data.
Bulk transfer: These collections do not provide a bulk initial-sync mode. To load a large set of existing orders, use the supported bulk sync using Postman workflow.
Custom integration scope: At the time this documentation was written, this integration is built for a specific client's Oracle ERP configuration. Behavior with other Oracle ERP configurations has not been validated; subscribers should validate order transfers in a staging environment before relying on them in production.