Turn SAP Business One Offline Sales Pick Lists into Shopify Orders

An offline sale may begin as one order in SAP Business One but leave the warehouse in several picks. APPSeCONNECT represents that split in Shopify by creating one Shopify order for each eligible SAP Business One pick list. The design preserves the original sales order relationship while moving the picked products, customer and address details, charges, and approved transaction context into each child order.

Business Requirement

The client creates offline sales orders in SAP Business One. Inventory availability may prevent the warehouse from picking every line and quantity at once. One sales order can therefore produce several pick lists, each representing a distinct set of products and quantities that operations can fulfill.

The Shopify side needs to show those fulfillment units as separate orders. Each order must contain the correct picked lines, customer context, destination, commercial values, and references back to SAP Business One. The integration connects the systems and turns the one-to-many SAP document relationship into a controlled sequence of Shopify order creations.

The Challenge

Copying the SAP sales order as a single Shopify order would hide the actual warehouse split. Copying every pick list without a durable parent reference would create the opposite problem: Shopify would show several orders, but operations and finance could not reliably connect them to the original sale.

The commercial values create another risk. A source order can contain line discounts, document discounts, freight, tax, and payment information. If an integration repeats the complete order-level amount on every child, the children overstate the sale. If it drops those values, Shopify no longer represents the commercial context required for support and reconciliation.

The design therefore has to answer five questions before any order is posted:

• Eligibility: Define the pick-list status and synchronization state that permit creation.
• Quantity Basis: Choose whether the Shopify order represents released quantity, picked quantity, or another approved quantity.
• Commercial Allocation: Define how discounts, freight, tax, and rounding are divided across child orders.
• Destination Routing: Identify the SAP customer and address fields that control direct-address and drop-ship orders.
• Replay Behavior: Prevent a retry, timeout, or rerun from creating a duplicate Shopify order.

The Approach

The SAP Business One sales order and pick-list relationship provides the source structure. The configured flow retrieves candidate pick lists, validates the eligibility criteria, splits the source packet into one processing unit per pick list, maps each unit into a Shopify order request, and writes the resulting Shopify identifiers back to the approved integration reference fields.

APPSeCONNECT intentionally maps one pick list to one Shopify order. A design that keeps one Shopify order and creates multiple fulfillments would use a different destination model, state machine, and error-recovery path.

From Offline Sales Order to Shopify

The workflow starts with the commercial order in SAP Business One and follows the warehouse documents that fulfill it. The source sales order remains the parent even when Shopify receives several child orders.

Sales Order Creation in SAP Business One

The offline order contains the customer, products, ordered quantities, pricing, discounts, tax treatment, freight, and address snapshot needed for the sale. Its document entry and line numbers provide the stable source coordinates that later pick-list rows can reference.

Inventory Release and Physical Picking

SAP Business One separates the quantity released for picking from the quantity physically picked. The SAP Business One pick-list row model stores RelQtty and PickQtty separately and links each row to its source OrderEntry and OrderLine.

That distinction matters when stock is partial. A released quantity is permission or allocation for warehouse work. A picked quantity records what the picker completed. The illustrated flow uses the values shown in the Picked column to form the Shopify line quantities. The mapping must reject zero, negative, cancelled, or otherwise ineligible quantities under the approved business rule.

SAP Business One also exposes several pick states, including released, picked, partially picked, partially delivered, and closed. The exact trigger for the APPSeCONNECT integration must be configured rather than inferred. A common acceptance test is to confirm that an unfinished pick list cannot create a final child order unless the business explicitly allows partial synchronization.

Pick-List Selection in the Integration

The selection query must return only records that belong to the intended company and meet the status, date, and synchronization filters. SAP Business One maintains the connection from a pick-list row to its source order entry and line, while its document-line link table provides additional pick-list linkage for managed items and bins.

The selection layer should return enough context to build a complete child order in one pass:

• Pick-List Identity: Include the absolute entry, displayed pick number, status, and relevant dates.
• Parent Identity: Include the sales order document entry, displayed number, and source line number.
• Line Data: Include the item code, quantity basis, unit of measure, warehouse, bin, batch, or serial details when the destination process needs them.
• Commercial Data: Include the currency, price, discount, tax, freight, and any approved transaction fields.
• Party Data: Include the customer code, contact data, bill-to address, ship-to address, and the field that classifies direct-address or drop-ship handling.
• Synchronization Data: Include existing Shopify identifiers, source flags, and the last known processing result.

One Shopify Order for Each Pick List

The ProcessFlow splits the retrieved data at the pick-list boundary. The ProcessFlow Splitter breaks a packet into smaller units before mapping and destination posting. In this ProcessFlow, every unit contains exactly one pick list plus the parent and commercial data required to create its Shopify order.

In this illustrative example, one sales order produces three eligible pick lists and three Shopify orders:

Production processing should use system identifiers for matching and retain human-readable document numbers for support and search.

Keeping Every Order Detail in Place

Creating the Shopify order is one API operation, but the payload has several independent mapping decisions. Each decision needs a source field, transformation rule, destination field, validation, and failure response.

Line Items and Quantities

The Shopify order should contain only the items represented by the current pick list. In this example, the four pick-list quantities are 1, 1, 4, and 3, and the Shopify order shows the same four product quantities.

The current Shopify order creation input accepts a variant ID, SKU, title, quantity, price set, tax fields, shipping requirement, and other line data. A production mapping should resolve the SAP item code to the correct Shopify variant ID before posting. If no unique variant exists, the process should fail or enter an approved exception route. Silently creating a custom line can break inventory, fulfillment, and reporting expectations.

The destination call also needs an offline access token with the write_orders scope. Keep that credential in the configured connection rather than in mappings, logs, or order fields. The Shopify order creation options default inventoryBehaviour to BYPASS and both receipt settings to false. Those defaults do not decide the business policy. When SAP Business One owns stock for this offline flow, choose and test the Shopify inventory behavior so the import does not deduct the same units twice. Decide separately whether an imported order or its fulfillment should send a customer notification.

Discounts, Shipping, Tax, and Rounding

Split orders need a conservation rule: the sum of the child orders should match the amounts the business intends to represent from the parent. The rule must also define what happens when only some pick lists have been created.

• Line Discounts: Preserve the effective price or approved line discount for the picked quantity. Do not reapply the parent order's full discount to every child.
• Document Discounts: Allocate the amount once using a documented basis such as extended line value. Use deterministic rounding and assign any remainder to one defined child.
• Shipping: Choose one policy, such as charging the first shipment, prorating by weight or value, using actual shipment cost, or keeping shipping outside this order flow. Repeating the full freight amount on every child is incorrect.
• Tax: Preserve the approved tax basis and rounding behavior. Shopify allows tax lines at the order or line level, but its API does not allow both in the same created order.
• Reconciliation: Compare parent totals, posted child totals, allocated amounts, and any unapplied remainder before the workflow is considered complete.

Shopify's orderCreate mutation supports one discount code and does not apply multiple line-item discounts automatically. A mapping that needs richer discount behavior must calculate and represent the commercial result through a tested policy rather than assuming Shopify will reproduce the SAP pricing engine.

Customer and Address Handling

Customer identity and delivery destination are separate mapping concerns. An existing Shopify customer may be linked to the imported order, while the order's shipping and billing addresses still need to reflect the SAP sales order snapshot.

The Shopify order input accepts customer, email, shipping address, and billing address data. The shipping address can take precedence when Shopify derives customer details. The mapping should therefore test customer-master effects instead of assuming an order-level address is isolated from the customer record.

Direct-address and drop-ship flows also need explicit precedence rules:

• Direct Address: Use the approved customer and order ship-to snapshot. Validate the postal fields before creating the order.
• Drop Ship: Use the destination held for that transaction, even when it differs from the customer's normal address. The implementation must identify the actual SAP classification field before deployment.
• Missing Address: Stop or route the order for review when a shippable item lacks the minimum destination data required by the Shopify store.
• Privacy: Transfer only the contact and address fields needed for the order. Do not place credentials, internal notes, or unrelated personal data in Shopify notes or custom attributes.

Transaction and Financial Status

Shopify can accept transaction records during order creation, including amount, gateway, kind, status, and processing time. The integration should create such a record only when it represents a real source transaction and the accounting rule has been approved.

Financial status must agree with the imported transaction. Shopify can derive financial status from transaction data and may recalculate an inconsistent status after later operations. An imported record must never imply that Shopify captured a payment when settlement occurred elsewhere.

A Clear Reference from SAP Business One to Shopify

Traceability depends on identifiers that survive retries, user renaming, and later document updates. The SAP Business One view includes synchronization and web-order fields beside the pick list, demonstrating the reference layer used by APPSeCONNECT.

Each successful creation should preserve at least these relationships:

• Source Company and Pick List: Use the SAP company or database identity with the pick-list absolute entry as the source key.
• Parent Sales Order: Store the source sales order entry and readable document number for reconciliation.
• Shopify Identity: Keep the Shopify GraphQL order ID and readable order name as different values.
• Processing State: Record whether creation has started, succeeded, failed, or requires reconciliation, together with a timestamp or execution reference.

Shopify provides sourceIdentifier, custom attributes, metafields, notes, and purchase-order fields that may carry approved references. These fields improve search and traceability, but they should not be assumed to enforce uniqueness.

The order-creation flow therefore needs application-level duplicate prevention:

1. Build a stable source key from the SAP company and pick-list identity.
2. Check the integration reference store and SAP synchronization fields before posting.
3. Create the Shopify order only when no completed mapping exists.
4. Persist both the Shopify ID and readable name immediately after a successful response.
5. If the response is lost or times out, search by the approved source reference and reconcile before retrying.
6. Allow a replay only when the same source key and payload fingerprint represent the same intended order.

This duplicate-control sequence is an implementation requirement. Shopify's idempotency mechanism applies only to mutations that expose its idempotency directive, and orderCreate does not currently expose that directive. APPSeCONNECT must prove its own duplicate-control behavior in testing.

ProcessFlow Architecture

The ProcessFlow shows SAP Business One, a Splitter, a Mapper, Shopify, a second Mapper, and a return node to SAP Business One. Treat the node layout as the workflow structure and verify every field mapping separately.

The nodes have distinct jobs:

• SAP Business One Source: Retrieve candidate pick lists and their parent order context through the configured action and filters.
• Splitter: Produce one processing packet per pick list. The split boundary must not separate a pick-list header from its lines.
• Outbound Mapper: Resolve products and transform quantities, prices, discounts, shipping, tax, customer, addresses, references, and approved transaction fields into the Shopify order input.
• Shopify Destination: Call the supported order-creation API and evaluate both transport errors and Shopify userErrors before treating the post as successful.
• Return Mapper: Transform the Shopify response into the SAP synchronization update, including the destination identifiers and state.
• SAP Business One Update: Persist the cross-reference only after the Shopify result has been validated.

ProcessFlows can be deployed with application credentials, mapped lookups, schedules, and retry settings. The Sync Info and Retry controls expose successful, failed, and unprocessed records for resynchronization. Begin each retry with duplicate reconciliation because a lost response can leave a real Shopify order even when the source side did not receive the identifier.

What Happens After the Shopify Order

The created Shopify order can supply data to the next configured business stage. That may include delivery confirmation, transaction reconciliation, or SAP invoicing. It does not make invoice posting automatic.

Before invoicing, the downstream process should verify the source pick list, Shopify order, commercial allocation, transaction state, and any required delivery condition. If several pick lists came from one SAP sales order, finance also needs a policy for one invoice per child, one consolidated invoice, or another approved document structure.

The same caution applies to payment data. A Shopify transaction record can represent an imported payment event, but the accounting process must still decide which system owns settlement, capture, refund, and reconciliation. APPSeCONNECT should never create a second financial event simply because an order is replayed.

Online and Offline Sales Orders Working Together

An organization may run two different directions through the same integration landscape. Online orders can begin in Shopify and create sales orders in SAP Business One. Offline orders can begin in SAP Business One and create Shopify orders through the pick-list-based flow described here.

The online and offline flows need separate selection filters and source identifiers so an order created by one direction is not collected by the reverse direction. The DataSource and synchronization fields shown in the pick-list view can support that separation when their values and update rules are formally defined.

Business Benefits

The integration gives each team a record that matches the unit it actually manages while preserving the original commercial relationship.

• Less Manual Recreation: Operations do not have to re-enter each SAP Business One pick in Shopify.
• Inventory-Aware Order Creation: Each child order contains the lines and quantities from its eligible pick list.
• Commercial Control: Explicit allocation rules prevent discounts, freight, tax, or payment context from being duplicated across child orders.
• Clear Customer Handling: Order-level addresses and direct-address or drop-ship rules keep the destination attached to the correct child.
• End-to-End Traceability: SAP sales order, pick list, Shopify order, and downstream invoice references can be reconciled as one transaction family.
• Recoverable Processing: Source keys, destination IDs, snapshots, and retries give support teams a defined path for failed or ambiguous executions.

Conclusion

Turning one SAP Business One pick list into one Shopify order works when APPSeCONNECT treats each pick as a complete, traceable child transaction. Define the quantity basis, allocate shared charges once, preserve source references, and reconcile ambiguous responses before retrying. APPSeCONNECT can coordinate those controls across SAP Business One and Shopify for a representative split order with discounts, freight, payment, and address variants.

Book a split-order integration assessment

Frequently Asked Questions