Parent Only Tables
Parent Only tables address data structure differences between systems. They enable you to map parent record fields as if they were child table records, thereby resolving compatibility issues that arise when data is stored differently across platforms.
The Problem
Different systems store related data in different ways:
System A: Stores data in separate fields within the main table (e.g., ALT_1_UNIT, ALT_2_UNIT).
System B: Stores the same data in separate, dedicated tables.
This creates mapping challenges when integrating between systems.
The Solution: Parent Only Tables
Parent Only tables are fieldless objects that bridge this gap. They enable you to:
Access parent record fields using child table syntax.
Create consistent mapping patterns across different system architectures.
Maintain clean, predictable formulas regardless of underlying data structure.
Example
Scenario: Mapping alternate units between Counterpoint and another system.
Counterpoint: Stores alternate units as fields in the item table (
ALT_1_UNIT,ALT_2_UNIT, etc.).
Other system: Stores alternate units in a separate table.
Solution: Use Parent Only Tables with the formula Parent.ALT_1_UNIT to access the parent field as if it were a child record.
Parent and Child Formulas
When working with Parent Only Tables, you can reference parent fields directly using dot notation (Parent.ALT_1_UNIT), creating a unified approach to data mapping regardless of the source system's structure.
Special Fields
System ID
Knowing the subscription ID is crucial in specific scenarios, particularly when performing lookups against external IDs. You can access this identifier through the SpaceportSystemId variable.
SourceTypeName
To enable conditional logic or different mapping behaviors based on the type of data object you're currently processing, use SourceTypeName. For example, you might want to apply a Parent Only mapping for billing addresses, but handle shipping addresses as a separate collection. SourceTypeName allows you to filter and apply the correct mapping logic. This variable provides the source data type.
Custom Fields
iPaaS.com manages custom fields within a collection named CustomFields. To streamline the process of locating and retrieving specific custom fields, we offer the GetCustomFieldValue function. This function takes two arguments: the CustomFields collection itself and a string representing the exact name of the custom field you wish to retrieve from the current data type you are mapping. For example: GetCustomFieldValue(CustomFields, "Meta Keywords").
Additional Collections
Special Collections for Reference in iPaaS.com
Product
When working with the standard ProductResponse class from iPaaS.com, you'll find the following additional collections available for reference:
Variants: Sub-items representing different versions of the product.
Inventory: Real-time stock information for the product.
Categories: A list of integer IDs representing the categories the product is assigned to.
Custom Fields: A dictionary where keys are custom field names and values are their corresponding data.
Options: Definitions for customizable aspects of the product (e.g., color choices, size ranges).
Units: Data related to different units of measure for the product (e.g., each, case).
Product Variant
For the ProductVariant class, these additional collections are available:
Inventory: Stock Information specifically for this product variant.
Options: The specific option selections for this product variant.