Order Aggregation Engine

What it does

• Combines up to a defined capacity of orders (up to 5,000 per batch) into one aggregated order.
• Aggregates SKU quantities, payments, discounts, and taxes.
• Creates a single shipping request (SR) with per-location fulfillments that mirror the locations in the original orders.

Why it matters

• Fewer API calls and objects to process.
• Faster throughput during high-volume periods.
• Lower costs where pricing is volume-based.

How It Works

• Per aggregation configuration

For each rule you configure (source filter, payment consolidation, capacity, window), the engine maintains one or more aggregation orders that collect matching source orders.

• Creation (Draft)

As soon as the first eligible order for a rule arrives, the engine creates an Aggregation Order in Draft status and starts adding line items, payments, discounts, taxes, and fulfillment locations.

• Segmentation by settings

Aggregation orders are segmented by custom payment method only. The engine uses the custom payment method value on each order, not the standard payment method, to determine how orders are grouped.

• Aggregate payment method enabled: a single aggregation order collects orders regardless of custom payment method.
• Aggregate payment method disabled: the engine creates separate aggregation orders per custom payment method.

Grouping by fulfillment location is not supported. Splitting a single order's payment transaction across multiple locations is not reliable, so the engine does not split payments before posting to your ERP.

Example of why location-based grouping is not supported:

• An order contains 3 items.
• The order is paid in full with a single payment method.
• The items are fulfilled at 2 locations.

If grouping by location were enabled, the order's single payment transaction would have to be divided between the two locations. This cannot be done safely before posting to the ERP, so the engine keeps the payment intact on a single aggregated order.

• Fulfillment location handling within an aggregated order

When an individual order is split across multiple fulfillment locations, the engine groups by custom payment method as usual and splits the SKU lines per location within the same aggregated order.

Example:

• An order contains 3 units of sku123, paid in full with a single payment method.
• Fulfillment is split across 2 locations:
  • 2 units of sku123 fulfilled at locationA
  • 1 unit of sku123 fulfilled at locationB

Instead of posting a single consolidated line to NetSuite (sku123, 3 units), the app posts two lines on the same aggregated order:

This preserves per-location fulfillment detail without splitting the payment transaction.

• Finalization trigger A - capacity reached

When an aggregation order reaches the configured capacity, the engine:

• Creates the shipping request and fulfillments for that order.
• Marks the aggregation order Fulfilled.
• Immediately opens a new Draft aggregation order to continue collecting any additional eligible orders in the same timeline.
• Finalization trigger B - timeline end

When the aggregation timeline closes within the specified time (for example, 12 or 24 hours), the engine finalizes all Draft aggregation orders even if they have not reached capacity:

• Creates the shipping request and fulfillments.
• Transitions the order to Fulfilled after a short 5–10 minute buffer to complete processing.
• What you should expect
  • In a single timeline, you may see multiple aggregation orders per configuration if volume exceeds capacity or if settings split by custom payment method.
  • Draft aggregation orders include a note indicating aggregation is in progress. They move to Fulfilled when the capacity or timeline trigger occurs.

NetSuite Integration

Aggregated orders can be exported to NetSuite as Sales Orders. Use the aggregation order source type to route these orders through your NetSuite flow as needed.

Eligibility and Limitations

• Stage 1 scope: Only fulfilled orders with fulfillments are aggregated.
• Excluded: Orders without fulfillments (for example, some FBA flows) are not aggregated.
• Channels: Multiple sources are supported (for example, Shopify). Aggregated orders use a distinct aggregation order source type in the app.
• Grouping: Segmentation is available by custom payment method only. Fulfillment location is not a supported grouping attribute.

Configuring the Engine in the App

Go to Integrations → Order Aggregation Engine, then select Edit to view or change settings. The examples below show a Shopify configuration, but the fields work the same for any source. Depending on your rollout stage, settings may be editable by Pipe17 only. If you do not see the integration, contact support to enable it.

Order Aggregation Settings

Apply rules only to orders with matching Pipe17 order sources

Choose which order sources this rule applies to (required).

• Enter one or more exact source names (for example, Shopify) to scope the rule.
• Use * to include all sources for aggregating all orders.
• Use separate rules when behavior must differ by channel.

The order source of the aggregation order

Sets the Order Source value written on aggregated orders created by the engine.

• Purpose: makes aggregated orders easy to identify, filter, and route.
• Recommendation: use "<Source> Aggregated" (for example, Shopify Aggregated).
• Downstream mapping: this value is available to integrations such as NetSuite.

Aggregate payment method checkbox

Controls whether orders with different custom payment methods are combined into the same aggregated order.

• Enabled: consolidate across custom payment methods into one aggregated order.
• Disabled: create separate aggregated orders per custom payment method (for example, one for credit card, one for PayPal).

Use Disabled when your ERP or accounting requires separate handling by payment type.

If orders include multiple payment methods, what to do?

Policy when an aggregated order would contain mixed payment methods:

• Create an exception; order will not be aggregated.
• Fallback to highest-value payment method.
• Fallback to first payment method.

Choose the option that matches your reconciliation and ERP posting rules.

Aggregated order capacity

Maximum number of orders to include in a single aggregated order.

• When the count exceeds this number, the engine starts a new aggregated order.
• Maximum supported value: 5,000.
• Larger batches reduce API calls. Smaller batches simplify audit and validation.

Aggregation window

Time window during which the engine collects eligible orders for aggregation (for example, 3 hours or 24 hours).

• Aggregated orders are created when capacity is reached or after the window closes (with a 5–10 minute buffer).
• Choose a window that fits your operational cutoffs and downstream posting cadence.

Add aggregation settings

Create additional rule blocks with different filters and parameters (for example, one rule for Shopify, another for TikTok).

• Each rule has its own source filter, payment settings, capacity, and window.
• Use multiple rules to tailor behavior by channel or business unit.

Save/Restore defaults

• Save applies your changes.
• Restore defaults resets the fields in the current rule block to the default values.

Viewing Aggregated Orders in the App

All orders list

1. Go to Orders → All Orders.
2. Use the Order Source Type filter and select aggregation to show only aggregation-generated orders.

Draft aggregated orders indicate that aggregation is in progress and will finalize when the window closes or capacity is reached.

Aggregated order detail page

1. Go to Orders → All Orders. Open any aggregated order from the list.
2. On the Order Details tab, you can see the aggregated SKU lines with total quantities and values. When an original order was split across locations, the SKU lines appear per location on the same aggregated order.
3. In the Orders in This Aggregate section, select View all related orders to navigate to the list of the original source orders that make up this aggregate.

Steps to Get Started

1. Request enablement. Ask Pipe17 to enable the Order Aggregation Engine for your account.
2. Provide requirements:
   • Channels and sources to include.
   • Preference for Aggregate payment method (enabled vs. disabled).
   • Multi-payment policy selection.
   • Aggregation capacity (up to 5,000) and window duration.
3. Validate in a lower environment (recommended). Review draft aggregated orders, shipping requests, and fulfillments. Confirm inventory and dashboard behavior.
4. Promote to production. Apply the configuration and monitor the initial runs.

Troubleshooting

• Aggregated order stays in Draft

The window may not have closed yet, or capacity was not reached. Allow the 5–10 minute buffer after the window ends.

• Expected orders missing

Confirm the orders were fulfilled and have fulfillments. Verify the orders came from included sources during the active window.

• Unexpected split across multiple aggregated orders

Check whether Aggregate payment method is Disabled. When disabled, orders with different custom payment methods are placed in separate aggregated orders.

• Error on multi-payment aggregated order

Review the configured multi-payment handling policy. If set to create an exception, the run will skip that aggregated order.

• Inventory totals look off

The app excludes aggregated orders, SRs, and fulfillments from inventory and dashboard totals to avoid double-counting. Confirm you are not manually re-including them in views or exports.

Need Help?

If you need additional assistance:

• Use Ask Pippen, our AI agent, located at the top of the app page.
• Submit a support request with as much relevant detail as possible. Learn how to submit a request.
• For urgent issues, email us directly at support@pipe17.com.

We're here to help you succeed with your operations.