Month: August 2026

How to Create Sales Orders with Kit Items in Acumatica

How to Create Sales Orders with Kit Items in Acumatica

Creating a sales order with kit items in Acumatica means adding one kit line, answering a short options prompt, and letting Acumatica explode that line into a placeholder item plus every component the customer will actually receive. This article walks that task as a user performs it in the Biz-Tech Services Kit Processing product for Acumatica ERP: adding the kit line, working the Options popup and the Component Details window, exploding the kit, and reading the result.

The point of the product is that kit components are visible and editable on the Acumatica sales order line itself. Users do not open a separate maintenance screen or print a pick list to see what is inside a kit. That convenience comes with rules, and most support questions trace back to a handful of settings configured long before the order was opened. Those settings appear below only where they change order entry.

Before You Start: What Must Be Configured

A kit line behaves according to its kit specification. If any of the following is missing, order entry will not go the way users expect.

1. The item is flagged as a kit. A kit specification can only be created for an item marked as a kit on the General tab of the Stock Items (IN202500) or Non-Stock Items (IN202000) form.

2. The Kit Assembly feature is enabled. The Kit Specifications form appears only if it is turned on for the tenant on the Enable/Disable Features (CS100000) form in Acumatica.

3. The specification is Active and has a current revision. A current revision must be enabled for the kit to explode on the Acumatica Sales Orders screen. If the kit already has one and you check another, Acumatica warns that saving will uncheck the previous revision.

4. Explode Kit is selected. Selecting it activates the three fields that drive order entry: Kit Placeholder Item, Explode Option, and Price Calculation.

5. The placeholder item exists and its unit of measure matches. The Kit Placeholder Item is a non-stock item that replaces the kit item after explosion, and its Unit of Measure, or UOM, must match the UOM of the kit item.

6. Preferences are set. In the Biz-Tech Services Kit Processing Settings section of Sales Orders Preferences, Price Calculation for Kits, Kit Placeholder Item, and Explode Option apply to all kits. Where the same settings are configured for a specific kit on the Kit Specifications screen, Acumatica gives priority to the per-kit setting.

That last point matters. When two users see different behavior from the same Acumatica kit, the usual cause is that the kit carries its own Explode Option or placeholder item and is ignoring the tenant-wide preference.

Creating a Sales Order with a Kit Item, Step by Step

Each sub-step below matches something the user clicks on the Acumatica Sales Orders screen.

Step 1: Add the Kit Item to the Order Line

Create the sales order as usual and add the kit inventory ID on a document detail line. The line is still a single kit line, not a set of components, and nothing is committed yet. That is exactly why this is the moment to make changes.

Step 2: Answer the Options Popup

If the specification has Kit has options selected, an Options popup opens automatically as soon as the kit item is entered. It lists each Option Category defined for the kit; the user selects an Option Code for each and presses OK. Where a category is marked Required, an option code must be chosen before the user can proceed with the kit order.

The order in which categories appear in the Acumatica drop-down is not random. The Sort Order setting on the kit specification sorts option categories ascending or descending, and that is what users see. If the sequence confuses order-entry staff, that is the setting to change.

Some option codes arrive without being chosen. A code flagged as Default Code is included automatically, which covers the cases where no human answers the popup: the API, import scenarios, processing screens, and sales quotes.

Step 3: Open the Component Details Window

With the kit line selected, open the Component Details popup. This window holds all information related to the kit. From here, and only before explosion, a user can add or delete components, exchange a component for a substitute item, and change the options selected in Step 2.

To revise options already answered, click Change Options. All previous Option Category and Option Code configurations stay intact unless manually changed, so reopening the window to adjust one category will not silently reset the others.

What the window shows about stock is configurable. The Component Availability section of Sales Orders Preferences decides whether Component Details displays Qty. Available, Qty. Avail. for Shipping, and Qty. on Hand, and whether it shows next-receive information drawn from receipts, transfers, and open purchase orders. For a user deciding whether to promise a date, that is the difference between guessing and knowing.

Step 4: Substitute a Component or Add One

Substitution is available when Allow Component Substitution is enabled and substitute items are defined. Double-click the component in Component Details, then use the search icon beside it to pick the substitute. This is how a kit ships with an equivalent part without redefining the kit in Acumatica.

Adding a component that was never part of the kit requires Allow Component Addition, which activates the Add Row option in Component Details. If it is off, new components cannot be added, but existing ones can still be deleted.

Step 5: Explode the Kit

There are two ways to trigger kit explosion on an Acumatica sales order: click Load Components in Component Details, or assign a quantity to the new kit line. Both produce the same result, and users tend to discover the second by accident, which is why a kit sometimes appears to explode on its own.

Whether explosion happens without being asked depends on the Explode Option. Prompt asks the user whether to explode the kit. Automatically explodes it with no user intervention. Do Not Explode prevents explosion entirely.

Step 6: Read the Order After Explosion

After explosion the kit item is replaced by the Kit Placeholder Item, and the components become their own Acumatica order lines with prices, quantities, and costs. The placeholder is a non-stock item that behaves like the kit item but contains no actual items. It keeps the financials clean: with the components on the order in their own right, carrying the kit item too would double-count costs.

One field on the placeholder row deserves attention. Total Cost of Components is the component unit cost at the time the sales order was created, which does not change afterward, multiplied by quantity. It carries forward to the invoice.

Document Triggers: What Each Action Creates

Four actions on the kit line create or change documents in Acumatica. Knowing which produces what is the fastest way to trace where a number came from.

Kit Explosion Creates the Placeholder and Component Lines

Explosion creates no separate document. It rewrites the sales order, swapping the kit line for a placeholder line and inserting one line per component. If Use Kit Posting Group is selected, Acumatica also puts the kit item Account and Subaccount values on the placeholder row, and if Apply to the Components is selected too, on the component rows as well. That is a trigger with accounting consequences, so confirm it before switching it on mid-year.

Mark for PO and Create PO Produce a Purchase Order

A purchase order can be raised for one component directly from the sales order, before the kit is exploded. Add the kit, open Component Details, select Mark for PO for the component, and click Create PO. Acumatica creates the purchase order and shows its number under the PO number column in the popup.

Three rules govern grouping and maintenance. The purchase order is created according to the Default Vendor ID of the component. If several components share a vendor, one purchase order covers them all. And if the purchase order is later deleted, or its lines removed, the number disappears from Component Details, so the sales order does not point at a missing document.

Mark for Kit Assembly and Generate Kit Assembly Produce an Assembly

A kit assembly document can be generated from the order without exploding the kit, provided Allow Kit Assembly Generation is selected on Sales Order Preferences. Enter the kit, select Mark for Kit Assembly on the Details tab, then click Generate Kit Assembly from the Actions list and Save. The same action sits behind the Mark/Unmark for Kit Assembly button in Component Details.

The generated number lands in the Kit Assembly field on the Details tab, and that link opens the Kit Assembly form, whose Orders tab shows the originating sales order number. Assemblies generated this way use the current revision on the Kit Specifications screen. Components can still be added or removed in Component Details beforehand.

Opportunities and Sales Quotes Produce the Order Upstream

Kit lines can begin before the Acumatica sales order exists. On the Details tab of Opportunities, add the kit item and press Create Quote. The kit will not explode on Opportunities itself. On the resulting Sales Quotes screen it explodes the same two ways as on an order. After Save, the exploded kit appears on the Opportunities Details tab too, and later changes are reflected on both screens.

Mapping Rules That Decide What Appears on the Order

What lands on the order is not simply the component list from the specification. Four mechanisms decide the final content and total.

Option Categories and Option Codes

When Kit has options is enabled, two tabs appear on the Kit Specifications screen: Option Category and Option Codes. Each option code belongs to a category, carries its own Option Price, and has stock or non-stock items attached, which may include other kit items. Those items are what Acumatica adds to the order when a user picks that code. This is how one inventory ID serves a family of configurations.

Option Rules That Exclude Combinations

Enabling Allow Option Rules adds an Option Rule tab. A rule pairs a Source Option Category and Source Option Code with a Target Option Category and Target Option Code, and the effect on the Sales Orders screen is exclusion: selecting the source combination removes the target code from the target category.

The documented example: with Size as source category and 8x10 as source code, and Color as target category and Black as target code, choosing 8x10 for Size removes Black from Color. Change Size to 8x12, which is not configured under Option Rules, and Black becomes available again. If staff report that a color has vanished in Acumatica, an option rule is almost always why.

Component Substitution

Substitution changes which item appears on the line without changing the kit specification. Enabling Allow Component Substitution adds a Substitution tab and a matching column on the Stock Components tab. Selecting that check box for a component publishes it to the Substitution tab, where the Sub Item section holds the items that may replace it. It applies to specified components and option code components alike.

The Three Price Calculation Methods

Price Calculation determines how the kit contributes to the order total, and the three methods give materially different numbers.

1. Use Kit Default Price. The kit default price is used, plus any manually added price for the options associated with the kit.

2. Use Component Default Price. The calculation is based on each component default price, and the kit item price is set to zero.

3. Use Combined Default Price. Both the kit default price and the default prices of each component are combined.

A separate setting skips explosion entirely for pricing. Unexploded Kit Price Calculation by Components prevents the kit from exploding and prices only the components for the order total, with a warning that it runs only for kit items whose Explode Kit check box is not enabled. One more preference changes quantities: with Not Calculate Component Quantities enabled on Sales Order Preferences screen, quantity calculation in Acumatica sales orders is based on the quantity specified for the kit itself.

Validation and Common Exceptions

These are the blocks and errors users actually hit on an Acumatica kit order, and what each is telling you.

The Placeholder Unit of Measure Does Not Match the Kit

The UOM of the Kit Placeholder Item must match the UOM of the kit item. If they do not, a warning error message appears. This is a configuration fault that only surfaces during order entry, which is why it feels like an order problem. Fix the placeholder or kit item, then re-enter the line.

The Kit Refuses to Explode

Several independent settings suppress kit explosion, each working regardless of the others. Work through them in this order.

1. The kit specification is not Active, or has no current revision enabled.

2. The Explode Kit check box is not selected on the kit specification.

3. The Explode Option is set to Do Not Explode.

4. Block Kit Items Explosion is selected on the Customers or Vendors screen for this customer.

5. Block Kit Items Explosion is selected in the Biz-Tech Kit Processing Settings on the Order Types screen for this order type.

6. Unexploded Kit Price Calculation by Components is selected, which by design prevents explosion and prices the components instead.

The last three catch people out: the kit specification looks perfectly correct while the block comes from the customer record, the order type, or a pricing preference.

Editing Is Restricted After Explosion

Once the kit has exploded, Component Details stops being an editing surface. Users can no longer delete or add components there, and only Quantity and Warehouse remain editable. Components can still be deleted or added with the [X] and [+] buttons on the Document Details tab.

Editing component quantities on an exploded kit is itself gated. Allow Edit Exploded Kit Component lets users edit individual component quantities and delete kit components on the Sales Orders screen; if it is off, expect quantities to be read-only. The same setting exists in Purchase Orders Preferences for Acumatica purchase orders.

Component Quantities Block the Shipment

Shipping is governed by Components Qty. Is Required for Kit Item Ship in Sales Orders Preferences. Selecting it reveals a drop-down with three options, and the one chosen decides whether a shipment can be created at all.

1. Ship Available Qty. sets the kit or placeholder line to back order allowed, so a shipment can be created for the minimum component quantity without all components being available based on the kit quantity.

2. Ship Ordered Qty. requires all components to be available based on the quantity specified for the kit. Nothing ships until every component is allocated and available.

3. The third option sets the line to back order allowed without requiring component quantities to be available for shipping.

If Acumatica will not create a shipment for an order that looks fully stocked, check which of the three is in force before investigating allocations. Separately, Invoice After Full Shipment allows partial shipment and holds the placeholder to be invoiced after all components have shipped.

A Component Has Zero Quantity

If any kit component has a quantity of zero and the kit item is not set to back order allowed, an error message appears when the check box is selected. A zero-quantity component and a line that cannot be back-ordered are unshippable, and Acumatica stops you at selection rather than at the shipment.

Non-Stock Kit Rules

Non-stock kits carry two constraints, both about the Explode Option. If a non-stock kit has a stock option item, its explode option should be Automatically so the stock option is allocated during shipment. If a non-stock kit is a component or option inside another kit, the Explode Option for both parent and child kit must be Automatically. Nested Acumatica kits that appear to lose stock components almost always violate one of these rules.

Kit Assembly Is Unavailable

For non-stock kit items the Mark for assembly button is disabled by design: there is nothing physical to assemble. Generating an assembly from the order also requires Allow Kit Assembly Generation, and the Kit Assembly form requires the Kit Assembly feature to be enabled in Acumatica.

A Purchase Order Will Not Be Created

Create PO needs a required quantity with a value on the component before Acumatica will create a purchase order. It also depends on the component having a Default Vendor ID, because that is what the order is created against.

Where to Check Your Work

Before releasing a kit order into the Acumatica fulfillment cycle, confirm these fields on the finished document. Most kit disputes come down to one of them being wrong when the order was saved.

1. Kit Placeholder Item. The placeholder line, not the original kit item, should be on the order after explosion.

2. Unit of Measure on the placeholder line. It must match the UOM of the kit item.

3. Component lines. Every expected component present, with its own price, quantity, and cost.

4. Total Cost of Components on the placeholder row. Unit cost at order creation multiplied by quantity, carried to the invoice.

5. Option Category and Option Code selections. Reopen Change Options and confirm they match what the customer asked for.

6. Order total against the price calculation method: Use Kit Default Price, Use Component Default Price, or Use Combined Default Price.

7. Account and Subaccount on the placeholder row, and on the component rows if Apply to the Components is in use.

8. PO number column in Component Details. Any component marked for purchase should show a live number.

9. Back order allowed on the kit or placeholder line, consistent with the shipping option selected.

10. Quantities on component lines, particularly where Not Calculate Component Quantities is enabled.

Creating Sales Orders with Kit Items: Frequently Asked Questions

Why will my kit not explode on the sales order?

Check the specification first: Active, current revision enabled, Explode Kit selected, Explode Option not Do Not Explode. If that is all correct, the block is outside the specification. Block Kit Items Explosion on the Customers or Vendors screen, the same check box on the Order Types screen, and Unexploded Kit Price Calculation by Components each prevent Acumatica kit explosion on their own.

How do I explode a kit without entering a quantity?

Open Component Details for the kit line and click Load Components, which explodes the kit directly. Assigning a quantity does the same thing and is the more common route in Acumatica, but it is easy to trigger before you meant to.

Can I change the options after I have answered the Options popup?

Yes, as long as the kit has not been exploded. Click Change Options in Component Details and adjust the option codes. Every previous Option Category and Option Code configuration stays intact unless you change it.

Why can I not add or delete components anymore?

Two rules produce that symptom. Before explosion, adding components requires Allow Component Addition, although existing ones can still be deleted without it. After explosion, Component Details allows no adding or deleting, and only Quantity and Warehouse can be edited there. Use the [X] and [+] buttons on the Document Details tab instead.

Why does an option code keep appearing even though nobody selected it?

That code is almost certainly flagged as a Default Code on the kit specification. Default codes are included automatically so kits still configure correctly when no user answers the Options popup: the API, import scenarios, processing screens, and sales quotes.

Why does my second invoice for a kit show a price of zero?

That is expected for a partial shipment when Use Kit Default Price is the price calculation option. The invoice for the first shipment carries the total kit price, and the price for the remaining items is zero. Acumatica charges the kit price once, not once per shipment.

Why is Mark for Kit Assembly greyed out on my order?

For non-stock kit items the button is disabled by design. If the kit is a stock item and it is still unavailable, confirm that Allow Kit Assembly Generation is selected in the Biz-Tech Kit Processing Settings and that the Kit Assembly feature is enabled on the Enable/Disable Features (CS100000) form.

Do kit lines work the same way on quotes and purchase orders?

Largely, yes. On the Sales Quotes screen a kit explodes by quantity or by Load Components exactly as on an order, and changes flow back to the linked opportunity, although the kit will not explode on Opportunities itself. Acumatica purchase orders use the same Component Details window and the same two explosion triggers, with their settings in Purchase Orders Preferences.

Work With the Biz-Tech Services Kit Processing Product

Creating a sales order with kit items rests on a few decisions: whether the kit explodes, which options and substitutions apply, how the price is calculated, and what must be available before the order can ship. Once your business settles those in the kit specification and in Sales Orders Preferences, order entry is a matter of adding a line, answering the Options popup, and confirming the placeholder and component rows. The Biz-Tech Services Kit Processing product keeps that loop on the Acumatica Sales Orders screen, where the order-entry user already is.

To learn more about the Biz-Tech Services Kit Processing product for Acumatica ERP, or to discuss how kit orders should be configured for your business, visit https://biz-techservices.com to learn more and get in touch with the Biz-Tech Services team.

Check also related articles

How to Set Up Kit Processing in Acumatica

Kit Processing Configuration Checklist for Acumatica

How Kit Processing Works in Acumatica from Order Entry to Fulfillment

Watch YouTube training video.

---

by Gary

How ServiceTitan Operational Data Flows into Acumatica ERP

How ServiceTitan Operational Data Flows into Acumatica ERP

The ServiceTitan data flow into Acumatica moves field service records in one direction: ServiceTitan creates the operational documents - purchase orders, receipts, bills, invoices, payments, inventory transactions and journal entries - and the Biz-Tech Services ServiceTitan Acumatica Connector retrieves them and creates them as native documents on standard Acumatica ERP screens. Each document type has its own processing screen, its own retrieval rule, and its own place in Acumatica where the result becomes visible.

This article follows that path record by record. It is not a setup checklist. It assumes the store is already configured and answers the question that comes next: what actually happens to a ServiceTitan purchase order, receipt, bill, invoice, payment or journal entry as it lands in Acumatica? It names the screens, tabs, checkboxes and fields that carry the values, because those are the places your users will look to confirm a record arrived or work out why it did not.

What the ServiceTitan Connector for Acumatica Does

The Biz-Tech Services Acumatica ServiceTitan Connector is an ERP integration that imports records from ServiceTitan, a field service management platform, into Acumatica. It connects to a ServiceTitan store through an API, using the credentials entered on the Connection Settings tab, and then brings ServiceTitan documents into Acumatica as purchase orders, purchase receipts, bills, invoices, payments, inventory transactions and journal entries. Imports run from dedicated processing screens, either manually or automatically on a scheduler.

Everything the Biz-Tech Services Acumatica ServiceTitan integrator does is governed by the ServiceTitan Stores screen. It controls invoice import rules, import behavior, customer creation rules, inventory and item handling, warehouse and branch mapping, vendor and business unit mapping, transaction processing logic, purchase orders and receipts, and bills. The store record is the rulebook the data flow reads at every step: it decides which documents are eligible, which master records they attach to, and whether they arrive released or open. If the store is not set up correctly, no data can be imported.

The ServiceTitan Data Flow at a Glance

Before looking at each document type in detail, here is the whole path a record travels on its way into Acumatica ERP:

1. Connection: the Biz-Tech Services ServiceTitan Acumatica connector authenticates against the ServiceTitan store using the credentials on the Connection Settings tab; the Test Credentials action confirms it works before any import runs.

2. Eligibility: the ServiceTitan Store record decides what is in scope - the Import with the following statuses setting, the Begin Invoice Date and Last Invoice Date fields, and the equivalent Begin Journal Entry Date and Last Journal Entry Date fields.

3. Retrieval: every processing screen pulls ServiceTitan records based on their updated date, so a record that changes in ServiceTitan becomes eligible again.

4. ServiceTitan purchase orders first: they are imported on the Import ServiceTitan Purchase Orders screen and created in Acumatica as purchase orders. Any receipt or bill that already exists at that moment comes across in the same run.

5. Receipts and bills next: anything created after the purchase order was imported comes in separately through the Import ServiceTitan Receipts and Import ServiceTitan Bills screens, and attaches to the PO History tab of the Purchase Orders screen.

6. Invoices and payments: the Import SO Invoices screen creates sales invoices in the Invoices and Memos screen, and the Import Invoice Payments screen creates payments that are applied on the Applications tab of the invoice.

7. Inventory and items: ServiceTitan materials, equipment and services become Acumatica stock and non-stock items, and receipts, transfers, adjustments and returns become inventory transactions, released on import when the matching release checkbox is selected.

8. General Ledger: when the Journal Entry option is active, ServiceTitan journal entries are imported against the mapped General Ledger, or GL, accounts and the mapped branches.

Where the ServiceTitan Data Flow Starts: The Store Record

Every import begins at the ServiceTitan Stores screen. The Store Code field is a lookup that identifies the corresponding ServiceTitan store, and the Description field labels it for users. The Default Store checkbox matters to the data flow more than it looks: when it is selected, the system automatically sets and displays that store code on the processing screens, so users do not have to pick a store before they can retrieve anything. The Test Credentials action tests the connection through the API using the information on the Connection Settings tab, and is worth running before a scheduled import window, because a failed connection makes the processing screens return nothing rather than naming the credentials as the cause.

The Purchase Order Path: Why ServiceTitan Purchase Orders Must Come First

The purchase order sequence is the single most important rule in the ServiceTitan data flow, and it is where most import errors originate. The purchase order module workflow was updated so that ServiceTitan purchase receipts and bills cannot be imported into Acumatica unless the related ServiceTitan purchase order has already been imported. The purchase order is the anchor document; receipts and bills are attachments to it, not standalone records.

Step 1: Import ServiceTitan Purchase Orders

Purchase orders are imported from the Import ServiceTitan Purchase Orders screen and created in Acumatica as purchase orders, retrieved based on their updated date. Before this screen returns anything, the required preferences must be configured on the ServiceTitan Stores screen - in particular the PO Types mapping, which maps ServiceTitan purchase receipt PO order type names to Acumatica PO types, and the Return Types mapping, which maps ServiceTitan return types to Acumatica PO types. Without those mappings the Biz-Tech Services ServiceTitan Acumatica integrator cannot decide what kind of purchase order to create.

The purchase order import is also opportunistic. If a ServiceTitan purchase receipt or bill already exists at the moment the purchase order is imported, it is imported as part of the same process; if it does not exist yet, it is simply not imported. That is why one purchase order import can produce three linked documents in Acumatica and another produces only one.

Step 2: Import ServiceTitan Receipts

The Import Purchase Receipts screen retrieves purchase order receipts based on the selected date and status defined in the Receipt Options settings of the ServiceTitan Store. Receipts are retrieved based on their updated date, and the synchronization can be run manually or automatically using the scheduler.

When the related purchase order has already been imported, the Biz-Tech Services Acumatica ServiceTitan integrator system locates it during the receipt import and attaches the receipt document to the PO History tab of the Purchase Orders screen. That tab is where your users should look to confirm a receipt landed against the right purchase order.

The status the receipt arrives in is decided by the ServiceTitan Store setup, not by the processing screen. If the Release checkbox is selected there, the receipt is imported with a Released status; if it is not selected, the receipt arrives with a balanced status and waits for someone to release it. Select it when your business wants ServiceTitan to be the point of control, and leave it clear when you want an Acumatica reviewer in the loop. Receipts can also pull a bill along with them: if the receipt includes a bill, the system imports the bill during the same process and attaches it to the same PO History tab. That behavior is enabled by the Activate Bill checkbox.

Step 3: Import ServiceTitan Bills

The Import Receipt Bills screen imports ServiceTitan bills into Acumatica, retrieved by their updated date. A bill cannot be imported separately without its corresponding purchase order; attempting it produces an error message. When the purchase order has already been imported, importing the bill later automatically locates that purchase order and attaches the bill to it. The net effect is that bills are always correctly linked to their related purchase orders, whether the bill arrived with the purchase order, with the receipt, or on its own afterwards.

One field is specific to this path: the Branch field used in the bills import process. It applies only when bills are imported and Bills and Adjustments documents are created, so it determines which branch those documents post to. That is why the ServiceTitan Business Units mapping has to be right before bills start flowing.

What Happens When the Purchase Order Has Not Been Imported Yet

If a purchase order receipt is imported before its purchase order, the system displays an error naming the receipt, in the form "POOrder document for Receipt 433272225 has not been created yet". The number is the ServiceTitan receipt identifier, which makes the error straightforward to resolve: take that number, find the corresponding purchase order, import it on the Import ServiceTitan Purchase Orders screen, then re-run the receipt import. The same rule and the same class of error apply to bills.

The Invoice and Payment Path: Three Matching Scenarios

Invoices are imported on the Import SO Invoices screen of Biz-Tech Services ServiceTitan Acumatica integration, which brings ServiceTitan sales invoices into Acumatica. They are retrieved based on their updated date and selected status, with the eligible statuses set by the Import with the following statuses option and the window bounded by the Begin Invoice Date and Last Invoice Date fields. ServiceTitan payments are imported on the Import Invoice Payments screen. Because an invoice and its payment can become available at different times, the Biz-Tech Services Acumatica ServiceTitan connector handles three scenarios, and in all of them the payment ends up matched to the correct invoice.

Scenario 1: The Invoice Arrives With Its Payment

If the invoice includes a payment at the time it is retrieved, both are imported together. The invoice is created in the Invoices and Memos screen, and the payment is created and applied on the Applications tab of that invoice. At the same time the corresponding payment identifier is removed from the Import Invoice Payments screen, because it was already processed as part of the invoice import. If a ServiceTitan payment vanishes from that processing screen without anyone running a payment import, this is why.

Scenario 2: The Invoice Is Already in Acumatica and the Payment Follows

If the invoice has already been imported but the payment is still sitting on the processing screen, the system locates the corresponding invoice during the payment import and applies the payment to it automatically. Users do not have to identify or apply the invoice manually.

Scenario 3: The Payment Lands First and the Invoice Follows

If the payment has already been made and the invoice is imported afterwards, the system automatically matches the payment with the corresponding invoice. This is the case that matters for businesses collecting in the field, where money is captured on the job before the invoice is finalized in ServiceTitan.

How the Import Invoice Payments Screen Behaves on Its Own

The Import Invoice Payments screen retrieves all payments from ServiceTitan and displays the associated Invoice ID next to each one, which is the field users should read when checking what a pending payment will attach to. If an invoice and its payment are both available, they are imported together. Payments can also be imported separately, either as a deposit or after the invoice has already been imported.

Two ServiceTitan Store settings govern how those payments are created. Payment Type determines whether payments imported from ServiceTitan are created with the payment or prepayment type in Acumatica. The Release Payment After Import checkbox determines whether they are released on arrival, which removes a manual step but also removes the review point.

What Rides Along With an Imported ServiceTitan Invoice

An invoice does not arrive alone. The Activate Invoice checkbox is the master switch: the interface changes based on the selected checkboxes, enabling import of invoices, taxes, payment methods, customer data and GL accounts. The Invoice Type field displays the type of invoice created in Acumatica for ServiceTitan invoices. Customer handling has two modes - if the Import Customer checkbox is not selected, invoices are imported with the default customer; if it is selected, the customer is created when missing, using the default customer class field. The Override Bill Address Information from Invoice and Override Ship Address Information from Invoice checkboxes decide whether the billing and shipping addresses travel with the invoice.

Tax Options enables Biz-Tech Services ServiceTitan Acumatica integrator to import invoices with taxes. Term Options maps ServiceTitan term values to their Acumatica equivalents, and Account Options maps the GL accounts, so imported documents post where your accounting team expects. Country names are imported in ISO country code format, defined by the International Organization for Standardization; note that the Country options become invisible when the Activate Payment checkbox is selected.

How ServiceTitan Inventory Transactions Reach Acumatica

Inventory has two halves in the ServiceTitan data flow: the items themselves, and the transactions that move them. Items come first, because a transaction has nowhere to land without them.

When the Import Item checkbox is selected, the Generate Item from ServiceTitan action method becomes available. It generates non-stock and stock items based on the Stock Item Class, Non-Stock Item Class and Unit of Measure, or UOM, values on the store record. The Load Materials, Equipment, Services action loads and displays the corresponding ServiceTitan items on the Inventory tab in Acumatica. The split is defined by the ServiceTitan category: stock items are created from Materials and Equipment, and non-stock items are created from Service. ServiceTitan items can also be mapped to existing Acumatica items manually instead of being created, which is the right choice when your item master is already the system of record. But make sure the Activate Invoice checkbox on Import Options tab is added to have Inventory tab available.

Transactions are configured on the Inventory Transactions tab, which holds setup options for Receipts, Transfers, Adjustments and Returns. Each type has its own release checkbox - Releasing Receipt After Import, Releasing Transfer After Import, Releasing Adjustment After Import and Releasing Return After Import. When those are selected, the Biz-Tech Services ServiceTitan Acumatica connector imports the documents into Acumatica and releases them. Selecting a release checkbox is the difference between a transaction that immediately affects your inventory balances and one that sits unreleased until a user acts on it.

Where those transactions land is decided by the Warehouses mapping, which maps Acumatica warehouses to ServiceTitan Warehouse and Truck IDs, and the Load Warehouses action retrieves those values for manual mapping. Truck IDs are the reason this mapping deserves attention: stock sitting on a truck in ServiceTitan has to correspond to a real Acumatica warehouse for the transaction to post correctly.

How ServiceTitan Journal Entries Flow into Acumatica

Journal entries are the alternative to the invoice path rather than an addition to it. The Journal Entry checkbox on the Import Options tab becomes available when the Activate Invoice checkbox is disabled, so a store is set up to import either detailed ServiceTitan invoices or summarized ServiceTitan journal entries.

The journal entry flow is bounded by its own date fields. Begin Journal Entry Date displays the date from which the first entry should be imported, and it is not set automatically the first time - a user has to set it manually. If your first journal entry import returns nothing, this is the field to check. Last Journal Entry Date displays the date of the last imported entry. Eligible statuses are set by the Import with the following statuses option for journal entries.

The Mapping Tables Every ServiceTitan Document Passes Through

Several mapping tables on the ServiceTitan Stores screen is not import steps in itself, but every imported document passes through them. Business Units maps ServiceTitan Business Unit IDs to Acumatica branches, and Load Business Units retrieves those values for manual mapping - this determines the branch on imported documents, including the Bills and Adjustments documents created by the bills import. Vendors work the same way on the purchasing side: when the Import Vendor checkbox is selected, ServiceTitan vendors are created in Acumatica, and Load Vendors retrieves all of them so they can also be mapped manually to existing Acumatica vendors. Because purchase orders, receipts and bills all carry a vendor, an unmapped vendor is a common reason a purchase document does not arrive as expected.

Where to Monitor ServiceTitan Results in Acumatica

Once imports are running, results show up in predictable places. These are the screens, tabs and fields your users should check as these are custom entites provided by Biz-Tech Services Acumatica ServiceTitan integration:

1. Purchase Orders screen, PO History tab - the most important place to look for purchase documents. Imported ServiceTitan receipts and bills are attached here against the purchase order they belong to.

2. Import ServiceTitan Purchase Orders screen - the purchase orders currently eligible for import based on their updated date.

3. Import ServiceTitan Receipts screen - receipts retrieved according to the date and status in the Receipt Options settings, and the place the "POOrder document for Receipt ... has not been created yet" error appears.

4. Import ServiceTitan Bills screen - bills waiting to be imported. A bill leaving this list without a separate bill import means it came across with its purchase order.

5. Invoices and Memos screen - where every imported ServiceTitan invoice is created in Acumatica.

6. Applications tab of the Invoice - where the imported ServiceTitan payment is applied, and the place to confirm a payment matched the right invoice.

7. Import Invoice Payments screen, Invoice ID field - all payments retrieved from ServiceTitan and the invoice each one is associated with.

8. Import SO Invoices screen - the invoices eligible under the current status filter and date window.

9. Last Invoice Date field on the ServiceTitan Stores screen - the date the last order was imported, and the reference point other invoice import processes count from.

10. Last Journal Entry Date field - the date of the last imported entry, and the quickest confirmation the journal entry flow is still running.

11. Inventory tab on the ServiceTitan Stores screen - the ServiceTitan materials, equipment and services loaded into Acumatica and how they map to stock and non-stock items.

12. Business Units, Warehouses, PO Types, Return Types and Vendors tabs - check these first when a document imports but posts to the wrong branch, warehouse, PO type or vendor.

ServiceTitan Acumatica Integration: Frequently Asked Questions

Why do I get "POOrder document for Receipt has not been created yet" when importing ServiceTitan receipts?

This error means the purchase order related to that receipt has not been imported into Acumatica yet. A purchase order receipt cannot be imported before its purchase order exists in Acumatica. Use the receipt number shown in the message to identify the purchase order, import it on the Import ServiceTitan Purchase Orders screen, then re-run the receipt import.

Why did my ServiceTitan bill disappear from the Import ServiceTitan Bills screen?

That is expected when the related purchase order was imported while the bill was sitting on the processing screen. In that case the bill is imported together with the purchase order and removed from the list. Check the PO History tab of the corresponding purchase order - the bill will be attached there.

In what order should ServiceTitan purchase documents be imported into Acumatica?

Purchase orders first, then receipts, then bills. ServiceTitan purchase receipts and bills cannot be imported unless the related ServiceTitan purchase order has already been imported. If the receipt or bill already exists when the purchase order is imported, the Biz-Tech Services Acumatica ServiceTitan integrator brings all of them across in a single run.

How does the ServiceTitan connector decide which records to import?

Every processing screen provided by Biz-Tech Services ServiceTitan Acumatica integration, retrieves ServiceTitan records based on their updated date. Invoices are additionally filtered by their selected status and by the Begin Invoice Date and Last Invoice Date fields, receipts by the date and status in the Receipt Options settings, and journal entries by the Begin Journal Entry Date, Last Journal Entry Date and their own status filter.

What happens if a ServiceTitan payment is imported before the invoice?

The Biz-Tech Services ServiceTitan Acumatica integrator handles it automatically. If the payment has already been made and the invoice is imported afterwards, the system matches the payment to the corresponding invoice on import. The same applies in reverse: if the invoice is already in Acumatica and the payment arrives later, the payment import locates the invoice and applies the payment on its Applications tab.

Why are ServiceTitan receipts arriving unreleased in Acumatica?

Release status is controlled by the Release checkbox in the ServiceTitan Store setup, not by the processing screen. When it is selected, receipts are imported with a Released status; when it is not, they arrive with a balanced status and must be released in Acumatica. The same pattern applies to inventory transfers, adjustments and returns through their own release checkboxes, and to payments through Release Payment After Import.

Which ServiceTitan items become stock items in Acumatica?

Stock items are created from ServiceTitan Materials and Equipment, and non-stock items are created from Service. They are generated using the Stock Item Class, Non-Stock Item Class and Unit of Measure values when the Import Item checkbox and the Generate Item option are used. You can also map ServiceTitan items to existing Acumatica items manually instead of generating new ones.

Can ServiceTitan imports run automatically in Acumatica?

Yes. The synchronization process can be performed manually from the processing screens or automatically using the scheduler. Because records are retrieved by updated date, a scheduled run picks up both new ServiceTitan records and existing ones that changed since the last import.

Work With the Biz-Tech Services ServiceTitan Connector

The ServiceTitan data flow into Acumatica is orderly once you know its rules: the store record defines what is eligible and how it arrives, every screen retrieves by updated date, purchase orders anchor their receipts and bills on the PO History tab, invoices and payments find each other in any order, and inventory transactions and journal entries land against the mapped warehouses, branches and GL accounts. Knowing which screen creates each document and which field shows the result turns most support questions into a two-minute check.

If your business runs field service operations in ServiceTitan and accounting in Acumatica, the Biz-Tech Services Acumatica ServiceTitan Connector is built to move those records between them reliably. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary

How Salesforce CRM Data Flows into Acumatica ERP

How Salesforce CRM Data Flows into Acumatica ERP

Salesforce orders flow into Acumatica as sales orders through a connected store record, and updated order data flows back out to the CRM on demand. Salesforce is a Customer Relationship Management platform, or CRM, and Acumatica is an Enterprise Resource Planning system, or ERP. The Biz-Tech Services Salesforce Acumatica Connector is the bridge between them, moving orders, customers, contacts, items, price books and discounts across the gap so that sales, finance and inventory all work from the same numbers.

This article follows that path end to end: how the connection is established, how a Salesforce order becomes an Acumatica sales order, how customers and items are resolved along the way, how pricing and discounts are kept aligned, and how changes made in the ERP are pushed back out. Configuration is covered here only where a specific setting decides what happens at a handoff, because the settings are what make the flow behave one way rather than another.

What the Salesforce Connector for Acumatica Does

The Biz-Tech Services Salesforce Acumatica Connector is an integration product from Biz-Tech Services, Inc. that connects a Salesforce CRM org to an Acumatica ERP instance. It defines data synchronization, automates the workflows that move records between the two platforms, and keeps data flowing in both directions. On the ERP side it adds a Salesforce Store screen that holds the credentials and the rules for the integration, processing screens for importing orders and exporting customers, price books and discounts, and inquiry screens where the results of each transfer can be reviewed. The product must be installed on an Acumatica system carrying a PCSR PERP or SAAS license.

The Salesforce Data Flow at a Glance

Every record that crosses between the two systems follows the same broad path. These are the stages, in the order they occur:

1. The Salesforce Store screen holds the store code, its description, and the API credentials on the General Info tab that link the two systems.

2. The Test Credentials button under Actions in the screen header confirms the connection is valid before any data moves.

3. The Get Orders button on the Import Salesforce Orders screen retrieves orders dated after the value set in the Order Settings tab of the store.

4. Import or Import All turns the selected orders, or all displayed orders, into Acumatica sales orders of the configured Order Type.

5. During that import the connector resolves the customer and the items on the order, creating them in Acumatica or matching them to existing records, and applies the tax, payment and discount rules.

6. The resulting document can be opened from the Salesforce Orders Inquiry screen, which shows the original CRM detail alongside the SO number and SO status.

7. Customers, price books and discounts flow outbound through the Export Salesforce Customers screen and its counterparts for price books and discounts.

8. Order changes made in Acumatica flow back through the Sync Orders To Salesforce screen, updating the matching CRM order at both line and document level.

Stage One: Connecting Salesforce to Acumatica

Everything downstream depends on the Salesforce Store screen. The store code carries all the configuration and setup for the integration between the two systems, and the description field holds notes about what that store code represents. Underneath the code and description sit the tabs that govern the flow.

The General Info tab is where the API credentials that link the CRM with the ERP are entered. Once they are in place, the Test Credentials button in the header under Actions reports whether the credentials are correct. The Order Settings tab then defines how imported records behave: the order import process, order calculation, order type, import destination, order discount settings, payment methods and more. Because these settings are read at import time rather than at setup time, they are the switches that decide what each incoming Salesforce record turns into.

Inbound: How Salesforce Orders Become Acumatica Sales Orders

The Import Salesforce Orders screen is the transfer point for order data moving from the CRM platform into the ERP system. Pressing Get Orders retrieves the Salesforce orders related to the date set in the Order Settings tab of the store. The Import button brings in only the orders selected in the grid, while Import All brings in every order currently displayed.

Which Default Import Options Shape the Result

Several fields in Default Import Options determine the shape of the resulting document. Order Type indicates the document type the order should be imported into and placed as in Acumatica. Warehouse ID sets the default warehouse for the order. Last Imported Order Date displays the date of the last imported order, and that date is used the next time orders are fetched to decide which orders count as new, so it is the field that keeps repeat pulls from re-importing history. Last Imported Price Book Date works the same way for price books.

Enable File Import Process controls whether attachments travel with the order. When the checkbox is selected, the file is retrieved from the Salesforce order and copied into the workspace on the Sales Orders screen at import time. When it is cleared, the file is not retrieved with the order at all.

How Tax Is Calculated on an Imported Order

Tax options allow for alternative tax calculations based on how the tax option is set up. Selecting Use External enables the calculation of alternative taxes such as Avalara tax. Setting up the Customer Tax Zone, Tax ID and Tax Category instead allows for the import of similar taxes, such as those coming from Salesforce. The choice determines whether the tax figure on the imported order is calculated locally or carried over.

How Customers and Items Are Resolved During Import

An incoming Salesforce order is only useful if it lands on the right customer and the right inventory items. The connector resolves both during the import process.

Customer Creation and Address Handling

When the Import Customer checkbox is selected, a new customer is created in Acumatica during the order import process, using the email, the contact information and the selected customer class. When the checkbox is cleared, the system uses the default customer for every imported order instead, which keeps the customer list from growing with every CRM transaction.

The Override Billing Address Information and Override Shipping Address Information checkboxes decide which address ends up on the sales order. When they are selected, the import process overrides the customer addresses and sets the Salesforce order address on the sales order.

Item Matching and Product Creation

Item Settings governs how products are resolved. When the Import Item checkbox is selected, new items are created in Acumatica based on the configured settings as items are imported from Salesforce. When it is not selected, the program prohibits the import and creation of items unless the corresponding items already exist there. In that case the system searches for the Inventory CD using the Salesforce Product SKU: if it is found, that item is retrieved; if it is not, the error message "The item {0} does not exist in the system" is displayed and the record stops there. Add Items in Inventory Sync enables item synchronization, and Use Numbering Sequence for Product ID Generation makes the system automatically generate a unique product ID for each new product from a predefined numbering sequence.

How Payments Ride Along With the Order

Default Payment Options controls the payment side of the import. Skip Salesforce Payment imports the order without a payment when selected. Payment Method sets the payment method applied during the order import process, and Payment Type determines the payment type of the imported order. Release Payment during Order Import releases the payment as part of that same import. Selecting the Use Cross Ref for Payment checkbox on the Order Settings tab enables payments through cross-reference, and when cross-reference is used for payment the payment must not be skipped. Cross-reference options more generally let your business link and map Acumatica and Salesforce values such as Payment, Country or Ship Via, with each option enabled by its checkbox and mapped on the Cross-Reference tab.

How Pricing and Discounts Stay Aligned

Prices reach the ERP through price books. Selecting the Last Imported Price Book Date on the Order Settings tab lets you load Salesforce price books into the Price Book Details tab based on that date. Each ID listed in that tab is a hyperlink to the Salesforce Price Books inquiry screen, where the list price can be changed and item lines added or deleted.

The Salesforce Price Books screen is also where synced products are added to a price book and the list price is defined manually. Selecting a preferred price book ID and clicking Get All Products in the Actions menu retrieves and displays every item in that price book. Two ordering rules matter here: items must be included in the standard price book before they are added to another price book, and if an item already exists in a price book it must be brought into Acumatica by importing an order, during which the item is automatically added to the corresponding price book.

Discounts follow their own path. When the Salesforce Synced checkbox is cleared on the Acumatica Discounts screen, the setup discount code appears on the Export Salesforce Discounts screen, where it can be created or updated and then used during order creation. Both line and document discount types are supported.

Outbound: Sending Acumatica Data Back to Salesforce

The flow does not end when an order lands in the ERP. Four screens move data in the other direction.

Exporting Customers and Contacts

The Export Salesforce Customers screen creates and updates Acumatica customers in Salesforce. Load Acumatica Customers loads and displays all of them, and the Export or Export All button creates or updates the selected customers or all of them in the CRM. If a customer has a primary contact, that primary contact is also created as a Contact during the customer creation process. Note that the export creates the primary contact only once and does not update it afterward, so later contact corrections do not travel.

Exporting Price Books

The Export Salesforce Price Books screen displays all the price books that have been loaded and are shown in the Price Book Details tab of the store screen. Process or Process All adds or updates products in the selected price books or in all of them. Only items that have been updated or changed are exported; unmodified items are not sent, which keeps each run small.

Syncing Order Changes Back to the CRM

The Sync Orders To Salesforce screen is where an order that came in from the CRM, was updated in Acumatica, and now needs to be pushed back gets processed. Updates are supported at both the order line level and the order document level. At the line level it updates the line description, discount code and discounted amount, and lines can be added and deleted. At the document level it updates the shipping and billing addresses, plus country, order date, order description, order total, freight amount, discount amount and tax amount. After changing that data, selecting the order and syncing it updates the CRM record to match. The screen also retrieves internal notes from Salesforce and displays them in the sales order Notes workspace, where they are read-only.

One filter governs what appears here: only modified orders with a status of On Hold or Open are displayed on this screen. An order that has moved past those statuses will not be listed, which is the first thing to check when an expected order is missing.

Where to Monitor Salesforce Results in Acumatica

Every stage of the flow leaves a visible trace. These are the exact places to look when you need to confirm that a record moved:

1. Import Salesforce Orders screen: the grid of orders retrieved by Get Orders, before and after Import or Import All is pressed.

2. Salesforce Orders Inquiry screen: reached by clicking the Order ID hyperlink on the import screen, showing the initial order details.

3. SO number and SO status on that inquiry screen: proof that the CRM order became an Acumatica sales order, and where that order now stands.

4. The workspace on the Sales Orders screen: holds the file copied from the Salesforce order when Enable File Import Process is selected.

5. The Notes workspace on the sales order: holds the internal notes retrieved from the CRM, which are uneditable.

6. Salesforce Info tab on the Customers screen: a generated ID plus a selected Salesforce customer checkbox means the record is a synced customer.

7. The Contacts screen: the same ID and checkbox logic applies to the primary contact.

8. The Export Salesforce Customers processing page: displays the Account ID and the last sync date for records already synced.

9. Item Details tab of the store screen: the synced item Salesforce ID, product code, product name, price and weight, populated by Load Acumatica Items, Sync to Salesforce and Sync all from Salesforce.

10. Price Book Details tab of the store screen: the price books loaded from the CRM, each ID linking through to the Salesforce Price Books inquiry screen.

11. Last Imported Order Date and Last Imported Price Book Date on the Order Settings tab: the watermark that decides what the next fetch pulls.

12. Salesforce Synced checkbox on the Discounts screen: cleared means the code is still waiting on the Export Salesforce Discounts screen.

Salesforce Acumatica Integration: Frequently Asked Questions

How do Salesforce orders get into Acumatica?

Press Get Orders on the Import Salesforce Orders screen. The connector retrieves the orders related to the date set in the Order Settings tab of the store and lists them in the grid. Then use Import to bring in only the orders you selected, or Import All to bring in every order displayed.

Does the connector create customers in Acumatica automatically?

Only if you tell it to. With the Import Customer checkbox selected, a new customer is created during the order import process with email, contact information and the selected customer class. With the checkbox cleared, every imported Salesforce order is placed on the default customer instead.

Can changes made in Acumatica be sent back to Salesforce?

Yes, through the Sync Orders To Salesforce screen. It updates the order at both line and document level, covering line description, discount code and discounted amount, added and deleted lines, shipping and billing addresses, country, order date, order description, order total, freight amount, discount amount and tax amount.

Why do I get "The item does not exist in the system" when importing a Salesforce order?

That message appears when the Import Item checkbox is not selected and the product on the order has no match in Acumatica. The system searches for the Inventory CD using the Salesforce Product SKU, and when nothing is found it cannot create the item on its own. Either create the item in Acumatica first, or select Import Item so new items are created from the configured settings during import.

Why is my modified order missing from the Sync Orders To Salesforce screen?

That screen only displays modified orders with a status of On Hold or Open. If the sales order has moved to another status, it will not appear in the list regardless of the changes made to it. Check the SO status on the Salesforce Orders Inquiry screen first.

Why does my imported order have no payment on it?

Check Skip Salesforce Payment in Default Payment Options, because when that checkbox is selected the order is imported without payment. Also check whether Use Cross Ref for Payment is selected on the Order Settings tab: when payments run through cross-reference, the payment must not be skipped, so the two settings have to agree.

Why can I not add a product to a Salesforce price book?

Items must be included in the standard price book before they can be added to another price book. If the item already exists in a price book, it has to be brought into Acumatica by importing an order first, and during that import the item is automatically added to the corresponding price book.

How do I confirm a customer is already synced?

Open the Customers screen and look at the Salesforce Info tab. When the Salesforce customer checkbox is selected and an ID has been generated there, the record is synced. The export processing page also shows the Account ID and the last sync date for customers that have already been sent across.

Work With the Biz-Tech Services Salesforce Connector

The data flow into Acumatica is a single continuous path: credentials on the Salesforce Store screen, orders pulled by Get Orders, customers and items resolved during import, tax and payment applied from the store settings, results visible on the Salesforce Orders Inquiry screen and on the sales order itself, and updates pushed back out through the Sync Orders To Salesforce and export screens. Knowing which screen owns which stage is what makes the integration straightforward to run day to day.

If your business runs Salesforce alongside Acumatica and wants that flow set up, tuned and monitored properly, the Biz-Tech Services Salesforce Acumatica Connector is built for exactly that. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary

How PayPal Payment Data Flows into Acumatica ERP

How PayPal Payment Data Flows into Acumatica ERP

The Biz-Tech Services Acumatica PayPal Integration for ERP moves payment data along one clear path: an Accounts Receivable (AR) Payment created in Acumatica sends a live invoice to your customer through PayPal, and every status check pulls that invoice state back onto the same payment record to release it, void it, or update the amount collected. Nothing is guessed and nothing is duplicated -- the Acumatica payment is the anchor, and the provider is the source of truth for whether money actually arrived.

Understanding that round trip is what makes the product easy to run day to day. This article traces the flow in the order records actually travel: credentials go in first, a payment request goes out, the resulting status comes back into Acumatica, and the outcome lands on fields your accounting team can filter, report on, and reconcile. The product described here is the Biz-Tech Services PayPal Acumatica Integrator for Acumatica ERP, built by Biz-Tech Services, Inc.

What the PayPal Integration for Acumatica Does

The Biz-Tech Services Acumatica PayPal connector is an Acumatica ERP customization that lets your business send payment invoices directly to customers from inside Acumatica, monitor payment status, and update payment records automatically when money is received, refunded, or cancelled. Invoices are created and sent through the PayPal invoicing Application Programming Interface, or API. Status updates are pulled on demand or processed in bulk, and the resulting accounting entries -- release, void, partial collection -- are handled by the customization rather than by hand.

Because the Biz-Tech Services PayPal Acumatica connector lives inside Acumatica, your team never has to leave the system to manage this billing. The Accounts Receivable and Sales Orders modules are both required, and on the provider side you need a PayPal Business account, since Personal accounts do not support the invoicing API. The Acumatica server must also be able to reach api-m.paypal.com, or the sandbox endpoint, over HTTPS on port 443. The package itself is published like any other customization from the Customization Projects screen (SM204505).

The PayPal Data Flow at a Glance

Before looking at individual screens, it helps to see the whole path a record takes. Every transaction handled by the Biz-Tech Services Acumatica PayPall integrator follows the same sequence, no matter which screen starts it:

1. Credentials in: a Payment Method in Acumatica (CA205000) stores the Client ID, Client Secret, and Base URL, on a PayPal Settings tab.

2. Customer routing: a Customer Payment Method (AR303010) stores the email address the invoice notification is delivered to.

3. Request out: a user clicks Request PayPal Payment or Send PayPal Request from a Sales Order, an Invoice, or the Payments and Applications screen.

4. Invoice created: the Biz-Tech Services PayPal Acumatica integration calls the PayPal API, emails the invoice to the customer, and writes the PayPal Invoice ID, Invoice URL, and Invoice Number back onto the Acumatica payment.

5. Payment parked: the AR Payment sits on Hold with a PayPal Invoice Status of "Sent" until the provider reports otherwise.

6. Status pulled back: a status check -- either the Remove Hold button on a single payment or the Check PayPal Payment Status processing screen in bulk -- asks for the current invoice state.

7. Action applied: PAID releases the payment and stores the Transaction ID, PARTIALLY_PAID updates the Paid Amount and leaves the payment on Hold, REFUNDED voids the payment and stores the Refund Number, and CANCELLED deletes the AR Payment record.

8. Monitoring: the processing screen, filtered by PayPal Invoice Status, becomes the daily worklist for everything still awaiting collection.

Step 1: Where PayPal Credentials Enter Acumatica

Configuring the PayPal Payment Method (CA205000)

Nothing can flow until a dedicated Payment Method exists. On the Payment Methods screen (CA205000), click the plus sign to create a record, set the Payment Method ID and Description (for example, ID PAYPAL), and select PayPal in the Means of Payment field. That selection is what makes the new PayPal Settings tab appear -- if you do not see the tab, the Means of Payment value is the first thing to check.

On that tab, paste the Client ID and Client Secret from your developer application, enter https://api-m.sandbox.paypal.com/ in Sandbox Base URL for testing and https://api-m.paypal.com/ in Live Base URL for production, and select the Is PayPal Payment checkbox to enable the Biz-Tech Services PayPal Acumatica integration behaviour. One detail matters more than it looks: the system uses the Sandbox URL whenever it is populated and ignores the Live URL, so switching to production means clearing the Sandbox Base URL field. Both fields can stay populated for reference, but a leftover sandbox value will quietly keep you in test mode.

Click Test Connection to confirm the credentials are accepted before you save, then open the Allowed Cash Accounts tab and add the cash or bank account these payments should post to. That cash account is what ties the incoming money to your general ledger, so it is a required part of setup rather than an optional refinement.

Configuring the Customer Payment Method (AR303010)

Each customer who will pay this way needs a Customer Payment Method configured with their PayPal email address, set up on the Customer Payment Methods screen (AR303010) or from the Payment Methods tab of the Customer record. This address is where the invoice notification is delivered, and it is pre-filled automatically on every new payment created for that customer -- though it can be edited per payment when a one-off override is required. Customers do not need an account of their own to pay, because PayPal supports guest checkout directly from the emailed invoice.

Step 2: How a PayPal Payment Request Leaves Acumatica

There are three entry points for creating a payment request, and all three end in the same place: an AR Payment record in Acumatica on Hold, and a live PayPal invoice in the customer inbox.

From a Sales Order (SO301000)

This is the most common workflow for businesses collecting payment before or upon shipment. Open the order on the Sales Orders screen (SO301000) and click Create Payment on the PAYMENTS tab; the system reads the order total, currency, and customer details automatically. Add the Cash Account and Payment Reference, and the Request PayPal Payment button appears. Clicking it creates an AR Payment linked to the order, emails the invoice to the customer, stores the PayPal Invoice ID, Invoice URL, and Invoice Number on the payment, and sets the payment on Hold with status "Sent". The resulting payment stays accessible from the Payments tab of the Sales Order.

From an Invoice (SO303000)

When billing has already been posted -- after shipment or service delivery, for example -- open the document on the Invoices screen (SO303000) and click Request PayPal Payment. The system creates a payment pre-applied to the invoice, sends it to the customer, and puts the payment on Hold. The invoice amount matches the outstanding balance on the AR invoice, so the two documents cannot drift apart.

From Payments and Applications (AR302000)

Use this route for a standalone payment, such as a deposit not tied to a specific document. On the Payments and Applications screen (AR302000), click the plus sign, select the customer, and choose the PayPal payment method. The PayPal Customer Email field auto-fills from the Customer Payment Method and can be adjusted if needed. Enter the amount and an optional description, optionally apply the payment on the Orders to Apply or Documents to Apply tabs, then click Send PayPal Request in the toolbar. The payment goes on Hold with status "Sent".

One guardrail applies across all three routes: a payment must not have been sent to PayPal previously before you click Send PayPal Request, and the Payment Method ID field is locked once an invoice has been sent, which prevents accidental changes to a request that is already live with the customer.

Step 3: How PayPal Status Data Returns to Acumatica

This is the direction most teams need to understand clearly. Acumatica polls PayPal on demand -- status does not update automatically in the background. A payment will sit at "Sent" indefinitely, even after the customer has paid, until someone triggers a check. There are two ways to trigger one.

Manual Check: The Remove Hold Button

To check a single payment and act on it immediately, open the record on Payments and Applications (AR302000), confirm it is on Hold with status "Sent" or "Partially Paid", and click Remove Hold in the header toolbar. The Biz-Tech Services Acumatica PayPal integration calls the PayPal API for the latest invoice status and applies the matching action. If the invoice is PAID, the payment is released automatically and a success message appears. If it is PARTIALLY_PAID, a message reports how much has been received and how much remains outstanding, and the payment stays on Hold. If it is CANCELLED, the AR Payment record is deleted. If the invoice is still SENT, the system explains that the payment cannot be released because it has not been paid, and makes no changes.

Bulk Check: The Check PayPal Payment Status Screen

When several payments are outstanding, use the Check PayPal Payment Status processing screen, registered in the Acumatica menu under the Sales Orders Processes module. It gives a centralized view of every AR Payment that has been sent to the provider and is the primary tool for bulk status management. A filter panel at the top narrows the list by PayPal Invoice Status -- pick Sent or Partially Paid to isolate one state, or leave it blank to show every linked payment. Select rows and click Process, or click Process All to run every row currently visible in the grid. Each payment is processed in sequence with the same logic as a manual check, and both successes and errors appear in the processing log.

What Each PayPal Status Does to the Acumatica Payment

The AR Payment moves through a lifecycle that mirrors the invoice held by the provider. SENT means the payment sits on Hold with no action taken and the customer has the invoice by email. PARTIALLY_PAID stores the collected amount in the PayPal Paid Amount field while the payment stays on Hold at the original amount. PAID and MARKED_AS_PAID confirm the amount, release the payment, set the status to Paid, and store the Transaction ID. REFUNDED and MARKED_AS_REFUNDED void the payment in Acumatica and store the Refund ID. PARTIALLY_REFUNDED updates the status only -- there is no automatic void, and a Credit Memo must be created manually. CANCELLED deletes the AR Payment record from Acumatica.

How Partial Payments Are Tracked in Acumatica

PayPal lets a customer pay less than the full invoice amount in a single transaction, and the invoice stays open so they can return and pay the remainder against the same document -- no new invoice is needed. Suppose a $100 invoice is sent from Acumatica and the customer pays $40. The invoice status becomes PARTIALLY_PAID. On the next status check, the PayPal Paid Amount field updates to $40, the PayPal Invoice Status is set to "Partially Paid", the Acumatica payment amount stays at $100, the payment remains on Hold, and a message reports the amount received and the balance remaining.

The design point behind this matters: Acumatica does not release partial amounts. The payment record always reflects the original agreed amount, and only when the invoice is confirmed fully PAID does the Acumatica payment get released. That is what keeps your accounts receivable accurate rather than showing a half-collected document as settled. Multiple partial payments against the same invoice are supported, and each status check refreshes the Paid Amount. Nothing special is required while you wait -- simply re-check the status at a later time.

Cancelling a PayPal Invoice from Acumatica

To pull back a payment request that has been sent but not yet paid, open the AR Payment on AR302000 -- it must be in "Sent" status and on Hold, since paid or released payments cannot be cancelled -- and click Cancel PayPal Invoice in the toolbar. The Biz-Tech Services Acumatica PayPal connector calls the API to cancel the invoice, the customer is emailed a cancellation notification, and the AR Payment record is deleted from Acumatica. Cancellation is irreversible: if you still want to collect from that customer, a new payment request has to be created from scratch.

How Refunds Flow Back Through Acumatica

For a full refund on a payment already collected and released, open the released AR Payment and click Void Check or Refund -- the standard Acumatica actions, enhanced by the Biz-Tech Services Acumatica PayPal integration. The Biz-Tech Services Acumatica PayPal integrator then calls the PayPal API to issue the full refund, voids the payment using the standard Acumatica void workflow, stores the Refund ID on the payment record, and sets the PayPal Invoice Status to "Refunded". The customer receives a refund notification.

Partial refunds work differently because they originate outside the system. If a partial refund is issued directly in the PayPal portal, the Biz-Tech Services Acumatica PayPal integration detects it on the next status check: the invoice reports PARTIALLY_REFUNDED, Acumatica updates the payment status to "Partially Refunded" and records the Refund ID, but the payment is not voided automatically, because Acumatica does not support partial voids on payment records. You must create a Credit Memo manually for the refunded amount to keep the AR balance accurate. The documented best practice is to issue all refunds from within Acumatica using the Void/Refund button so records stay in sync, and to use the provider portal only when absolutely necessary.

The PayPal Fields Added to Acumatica Records

The Biz-Tech Services PayPal Acumatica integrator adds a set of custom fields to the AR Payment screen, visible when the payment uses a PayPal payment method. Each one is populated at a specific point in the flow, which is useful to know when you are diagnosing a record that looks incomplete. PayPal Invoice ID holds the internal identifier used for API calls and is written after the invoice is created. PayPal Customer Email is populated when the payment method is set, auto-filled from the Customer Payment Method. PayPal Invoice Status appears after Send PayPal Request is clicked. PayPal Invoice Number, the human-readable number the customer sees, is written after the invoice is sent, as is the PayPal Invoice URL used by the Open in PayPal button. Transaction ID and Refund Number are filled once payment or refund is confirmed, and PayPal Paid Amount is maintained while the status is Partially Paid.

These fields are also available on ARAdjust, the applied-to lines, and SOAdjust, the sales order application lines. That is what keeps status information consistent across all related records rather than stranded on the payment header, and it is why you can read the current state from the documents a payment was applied to.

Where to Monitor PayPal Results in Acumatica

Monitoring comes down to a handful of screens and fields. These are the places where the results of the data flow actually surface:

1. Check PayPal Payment Status processing screen -- the centralized view of every AR Payment sent to the provider, registered under the Sales Orders Processes module.

2. The PayPal Invoice Status filter on that screen -- set it to "Partially Paid" for the recommended daily reconciliation list of invoices awaiting full collection.

3. The processing grid columns: Selected, Payment Ref, Customer, Customer Email, Currency / Amount, Sales Order, Invoice Nbr, PayPal Invoice Nbr, PayPal Status, and Transaction ID.

4. The Payment Ref, Sales Order, and Invoice Nbr columns are clickable, so you can jump straight from the worklist to the underlying Acumatica document.

5. The processing log after Process or Process All -- it reports both successes and errors for every row that was checked.

6. PayPal Invoice Status on the AR Payment (AR302000) -- Sent, Partially Paid, Paid, Cancelled, Refunded, or Partially Refunded.

7. PayPal Paid Amount on the AR Payment -- the cumulative amount actually collected, visible when the status is Partially Paid.

8. Transaction ID on the AR Payment -- the payment transaction identifier for paid invoices, or the refund transaction identifier for refunds.

9. Refund Number on the AR Payment -- the refund transaction identifier, populated after a refund is processed.

10. PayPal Invoice URL and the Open in PayPal button -- the direct link to inspect the invoice in the provider interface when the two systems appear to disagree.

11. The Payments tab of the Sales Order (SO301000) -- where the payment created from an order remains accessible.

12. ARAdjust and SOAdjust application lines -- status information carried onto applied-to and sales order application records.

PayPal Acumatica Integration: Frequently Asked Questions

Does Acumatica update PayPal payment status automatically?

No. Acumatica polls the provider on demand, so status does not refresh in the background. You must trigger a check either by clicking Remove Hold on an individual payment or by running the Check PayPal Payment Status processing screen. This is by design, and it is the single most important thing to know about how the data flow works.

Why is my PayPal payment status stuck at "Sent" even though the customer paid?

This is almost always the on-demand polling behaviour rather than a fault. Trigger a status check manually with Remove Hold, or run the payment through the processing screen in bulk. If the status still does not move, verify that the invoice is actually marked as PAID inside your PayPal account.

Why does the connection test fail when I save the PayPal Payment Method?

Three causes are documented. The Client ID or Client Secret may be incorrect, so copy them directly from the developer dashboard. The base URL may be wrong -- use https://api-m.sandbox.paypal.com for sandbox and https://api-m.paypal.com for live, including the trailing slash. Or the Acumatica server simply cannot reach the endpoint, in which case check firewall and proxy settings for outbound HTTPS on port 443.

What causes the "Customer email not configured" error when sending a request?

The customer does not have a Customer Payment Method set up with a PayPal email address. Open the Customer record, go to the Payment Methods tab, add a row for the PayPal payment method, and enter the email. The request will then send normally, since that address is where the invoice notification is delivered.

Why does PayPal Paid Amount show a value while the payment is still not released?

That is correct behaviour for a PARTIALLY_PAID invoice. Acumatica does not release partial amounts, so the payment stays on Hold at the original amount until the invoice is confirmed fully PAID. The Paid Amount field simply tracks the running total collected so far.

Why does the Refund button return a PayPal error?

Refunds can only be issued for payments that are in a PAID state with the provider, and the invoice must be fully released in Acumatica before a refund can be processed. If the refund was already issued in the PayPal portal, run a status check first to synchronize the record, then work from the updated status.

How do I switch the PayPal Integration from sandbox to production?

Clear the Sandbox Base URL field on the PayPal Settings tab of the Payment Method, or leave it blank. The system uses the Sandbox URL whenever it is populated and ignores the Live URL, so production traffic only begins once the sandbox value is gone. Both fields can be populated at the same time for reference, but live calls are made only with the sandbox field cleared.

Can I cancel a PayPal invoice after the customer has paid it?

No. The payment must be in "Sent" status and on Hold for the Cancel PayPal Invoice button to work, and paid or released payments cannot be cancelled. If money has already been collected, the refund path -- Void Check or Refund -- is the correct route instead.

Work With the Biz-Tech Services PayPal Integration

Traced end to end, the flow is straightforward: credentials configured once on the Payment Method, a payment request sent from a Sales Order, an Invoice, or Payments and Applications, an AR Payment held at status "Sent", and a deliberate status check that brings the result back to release, void, or update the record. Knowing where each field is written and which screen to monitor turns PayPal collections into a routine your team runs from one worklist inside Acumatica.

The Biz-Tech Services PayPal Acumatica Connector is built and supported by Biz-Tech Services, Inc. for Acumatica ERP. Visit https://biz-techservices.com to learn more about the Biz-Tech Services PayPal Acumatica integration, licensing requirements, and how to get it configured for your business.

---

by Gary

How CommerceHub Files Flow Through Acumatica ERP

How CommerceHub Files Flow Through Acumatica ERP

The CommerceHub Acumatica integration is unusual among connectors, and the difference shapes everything about how you troubleshoot it. CommerceHub exchanges data using SFTP, or Secure File Transfer Protocol, rather than direct API requests. Information is not transmitted straight to CommerceHub; it is written into text files that pass through an FTP client such as FileZilla before reaching the CommerceHub platform. Data coming back follows the same route in reverse, travelling from CommerceHub to the file server and only then into Acumatica. Knowing that every record is a file in transit is what makes this Biz-Tech Services Acumatica CommerceHub connector predictable.

The Biz-Tech Services CommerceHub Acumatica Connector adds a dedicated CommerceHub workspace to Acumatica once the customization is published, with a separate screen for each stage of the process. This article follows a record through the full data flow, from the mappings that define connector behavior, through purchase order import and acknowledgement, out to shipment, invoice, and inventory export, and finally to the screens where failures surface. Along the way it identifies the fields that matter and where to check results.

What the CommerceHub Connector for Acumatica Does

CommerceHub is a platform that facilitates e-commerce operations by connecting retailers, brands, and suppliers. The Biz-Tech Services Acumatica CommerceHub Connector for Acumatica ERP links that platform to your back office so that purchase orders placed through CommerceHub arrive as Acumatica sales orders, and so that acknowledgements, shipments, invoices, and inventory quantities flow back out to CommerceHub from Acumatica. Because the exchange is file-based rather than API-based, each of those movements is a file written to or read from an SFTP location rather than a live request and response.

Once the package is published in Acumatica, the CommerceHub workspace becomes available along with its related screens. Each screen is dedicated to one specific process, which is what makes the data flow easy to trace: if you know which stage a record is at, you know which screen to open.

Why CommerceHub Uses Files Instead of an API

Most connectors talk to their platform through direct API interactions. CommerceHub does not, and this is its standout characteristic. Information is written into files and then read for transmission, which introduces an intermediate hop that simply does not exist in API-driven integrations.

The practical consequence is that the file transfer layer is part of your Biz-Tech Services Acumatica CommerceHub integration. When a record does not appear where it should, the cause may be in Acumatica, in CommerceHub, or in the file transfer between them. That third possibility is unique to this Biz-Tech Services Acumatica CommerceHub connector and is worth building into your troubleshooting habits from the start. It also means timing is batch-like rather than instantaneous: records move when files move.

The CommerceHub Data Flow at a Glance

Before looking at individual screens, here is the path records travel through the Biz-Tech Services CommerceHub Acumatica integration:

1. The Mappings screen defines Biz-Tech Services CommerceHub Acumatica connector behavior, including store codes, item cross-references, warehouse and quantity settings, and the inventory template.

2. Import Purchase Orders pulls CommerceHub purchase orders in by store code, creating Acumatica sales orders with a default customer and the real customer address.

3. Two acknowledgement fields on the sales order start as Open, exposing the order on the two acknowledgement export screens until it is processed and both fields turn to Closed.

4. Export CommerceHub Shipment sends out orders that have reached Confirmed Shipment status.

5. Export CommerceHub Invoices sends out orders that have been invoiced, or invoiced and released.

6. Export CommerceHub Inventory synchronizes quantities for the items chosen in the inventory template.

7. Import Failed Purchase Orders and the CommerceHub Errors screen catch anything that did not complete, alongside the Error Log tab on the Mappings screen.

Every field discussed below sits at one of those handoffs.

The Mappings Screen: Where CommerceHub Connector Behavior Is Defined

The Mappings screen is the main configuration screen of the Biz-Tech Services Acumatica CommerceHub integrator. It is used to configure Biz-Tech Services CommerceHub Acumatica integrator settings and define the connector's behavior, and it is where users set up and manage the various parameters required for the import, export, and synchronization processes. Nearly every question about why the Biz-Tech Services Acumatica CommerceHub connector behaved a certain way is answered somewhere on this screen.

Store codes and per-process configuration

Store codes play a pivotal role in managing distinct configurations and functionalities for specific import and export operations. Each store can be set up individually with its own parameters, including Transaction Type, Description, Default Customer, and Document Type. This is what allows tailored setups per process, so that inventory, item, and shipment operations can each carry their own configuration and accommodate different requirements.

Store code is also the selection field on nearly every processing screen in the Biz-Tech Services CommerceHub Acumatica integrator. Import and export screens filter by it, so choosing the wrong store code is a common reason for a screen to appear empty when records were expected.

Cross-Reference tab: matching CommerceHub item IDs to Acumatica items

The Cross-Reference tab enables the mapping of Acumatica items to their respective item IDs contained within the file during the order import process. Because the incoming file identifies products by CommerceHub's item ID rather than by your inventory ID, this mapping is what lets an imported order line resolve to the correct Acumatica item. An unmapped item ID is a predictable cause of import failure.

Warehouse Details and the quantity basis for export

On the Warehouse Details tab, the warehouses that need to be exported are added. Alongside them, the Quantity field determines which inventory quantity should be exported to CommerceHub, and there are three available options: On Hand Quantity, Available Quantity, and Available for Shipment Quantity.

This is a decision worth making deliberately rather than accepting a default. On Hand Quantity reports everything physically in the warehouse, Available Quantity accounts for existing commitments, and Available for Shipment Quantity is the most conservative basis. The option you choose directly determines what CommerceHub believes you can sell, so it drives both oversell risk and lost sales.

Inventory Template: choosing which items synchronize

When inventory IDs are selected and saved within the Inventory Template tab, the associated items are displayed on the Export CommerceHub Inventory screen. This functionality is what enables the synchronization of item quantities. In effect the template is the subscription list: an item that is not in the template will not appear for export, no matter what its quantity does.

Error Log and Purge Logs

During the import and export processes for orders, any errors encountered relating to orders are shown and detailed within the Error Log tab, where the messages can be reviewed and resolved. A Purge Logs button enables the deletion of all error messages within the tab at once. Because purging is all-or-nothing, it is worth resolving or recording outstanding messages before using it.

Inbound: Importing CommerceHub Purchase Orders into Acumatica

The Import Purchase Orders screen facilitates the importation of purchase orders from CommerceHub by selecting a preferred store code. After an order is imported, it appears on the Sales Orders screen as a standard Acumatica sales order. Users can either select specific orders and press the Process button to import just those, or use Process All to import every available order at once.

One behavior surprises people the first time they see it, so it is worth explaining before users encounter it. Customers are not imported from CommerceHub. Instead, a default customer is assigned to the sales order. The real customer information is not lost, however: on the Addresses tab of the sales order, the default address information is overridden with the actual customer address received from the imported order. So the order posts against a default customer record while shipping to the genuine end recipient, which is the normal pattern for drop-ship style marketplace fulfillment.

Acknowledgements: The Two Fields That Confirm Receipt

Acknowledgement is the stage that tells CommerceHub you have accepted the order, and Acumatica tracks it with two fields on the Sales Orders screen: Acknowledgement and PO Acknowledgement. The initial status for both fields is Open.

While orders have been generated and their acknowledgements remain at Open status, those orders are visible on both the Export CommerceHub PO Acknowledgment screen and the Export CommerceHub Acknowledgment screen. After the acknowledgements have been processed from both screens, the orders are no longer visible there, and the acknowledgement statuses on the Sales Orders screen transition to Closed.

Two points follow from this that are worth teaching. First, both screens must be processed, not just one, before the order is fully acknowledged. Second, the disappearance of an order from an acknowledgement screen is the expected sign of success rather than a sign that something went missing, and the acknowledgement fields on the sales order are where that success is confirmed.

Outbound: Exporting Shipments to CommerceHub

The Export CommerceHub Shipment screen displays all orders with a Confirmed Shipment status according to the selected store code, and provides the functionality to export those order shipments from Acumatica to CommerceHub. The gating condition is the important part: an order will not appear here until its shipment has actually been confirmed in Acumatica. If a shipment is missing from this screen, the first thing to verify is the shipment status on the order rather than anything in the Biz-Tech Services Acumatica CommerceHub connector.

Outbound: Exporting Invoices to CommerceHub

The Export CommerceHub Invoices screen displays orders that are either invoiced or released when a store code is selected. It offers the capability to export orders that have been invoiced, as well as those that both have an invoice and have already been released. As with shipments, the document state in Acumatica determines visibility on the screen, so the invoice must exist before the export can happen.

Outbound: Exporting Inventory Quantities to CommerceHub

The Export CommerceHub Inventory screen shows the items that were selected and saved in the Inventory Template tab of the Mappings screen, and it is the mechanism that synchronizes item quantities to CommerceHub. The quantity actually sent depends on the Quantity option configured in Warehouse Details, and the warehouses included depend on which ones were added there. Inventory export therefore draws on three separate pieces of configuration at once, which is worth remembering when the exported numbers do not look right.

Handling Failures: Failed Purchase Orders and the CommerceHub Errors Screen

Two screens exist specifically for things that did not go to plan. The Import Failed Purchase Orders screen enables the import of orders that encountered failures during the import process on the Import Purchase Orders screen, and it works the same way, by selecting a store code for the failed orders. This means a failed order is not lost. Once the underlying cause is fixed, commonly a missing item cross-reference, the order can be retried from this screen.

The CommerceHub Errors screen displays all errors received from CommerceHub relating to various processes. Read alongside the Error Log tab on the Mappings screen, which captures errors encountered during Acumatica's own import and export processing, these two views cover both sides of the exchange. Errors reported by CommerceHub appear on the Errors screen; errors raised while Acumatica processed a file appear in the Error Log.

Where to Monitor CommerceHub Results in Acumatica

When configuring the Biz-Tech Services Acumatica CommerceHub integrator, training users, or investigating a record that has not arrived, these are the fields and screens that reveal what actually happened:

1. Store code on every import and export screen, since each screen filters by it and the wrong selection makes a screen look empty.

2. The Cross-Reference tab on the Mappings screen, which resolves CommerceHub item IDs to Acumatica items during order import.

3. The Quantity option in Warehouse Details, which decides whether On Hand, Available, or Available for Shipment quantity is what CommerceHub sees.

4. The Inventory Template tab, which controls which items appear on the Export CommerceHub Inventory screen at all.

5. The Acknowledgement and PO Acknowledgement fields on the Sales Orders screen, which move from Open to Closed once both acknowledgement screens have been processed.

6. The Addresses tab of an imported sales order, which should carry the real customer address even though the order itself is assigned to the default customer.

7. Shipment status on the order, which governs whether it appears on the Export CommerceHub Shipment screen.

8. Invoice and release status, which govern visibility on the Export CommerceHub Invoices screen.

9. The Error Log tab on the Mappings screen for errors raised during Acumatica processing, remembering that Purge Logs clears every message at once.

10. The CommerceHub Errors screen for errors reported back by CommerceHub itself.

11. The Import Failed Purchase Orders screen, which is where orders that failed to import wait to be retried.

CommerceHub Acumatica Integration: Frequently Asked Questions

What is the CommerceHub connector for Acumatica?

It is a Biz-Tech Services customization that connects the CommerceHub e-commerce platform to Acumatica ERP. Once published, it adds a CommerceHub workspace with dedicated screens for importing purchase orders, exporting acknowledgements, shipments, invoices, and inventory quantities, and reviewing errors. Each screen handles one stage of the process.

Does CommerceHub connect to Acumatica through an API or through files?

Through files. CommerceHub operates using SFTP, or Secure File Transfer Protocol, rather than API requests. Data is not transmitted directly: it is written into text files that pass through an FTP client such as FileZilla before reaching CommerceHub, and data coming back travels the same path in reverse. This file-based approach is the Biz-Tech Services Acumatica CommerceHub connector's main distinguishing feature compared with the direct API interactions used by other platforms.

Why do imported CommerceHub orders show a default customer?

This is by design. Customers are not imported from CommerceHub, so a default customer is assigned to the sales order instead. The actual customer information still arrives: on the Addresses tab of the sales order, the default address is overridden with the real customer address received from the imported order.

What do the Acknowledgement and PO Acknowledgement fields mean?

They track whether an imported order has been acknowledged back to CommerceHub. Both start at Open, which makes the order visible on the Export CommerceHub PO Acknowledgment and Export CommerceHub Acknowledgment screens. Once the acknowledgements have been processed from both screens, the order disappears from them and both fields change to Closed.

Which inventory quantity is exported to CommerceHub?

Whichever one you select in the Quantity field of Warehouse Details. The three options are On Hand Quantity, Available Quantity, and Available for Shipment Quantity. Only the warehouses added on that screen are exported, and only the items saved in the Inventory Template tab appear on the Export CommerceHub Inventory screen.

What happens when a CommerceHub purchase order fails to import?

It is not lost. The Import Failed Purchase Orders screen allows orders that encountered failures during import to be brought in, by selecting the store code for those failed orders. Check the Error Log tab on the Mappings screen for the reason first, resolve it, then retry the import from the failed orders screen.

Why is an order missing from an export screen?

Each export screen filters on both a store code and a document state. Confirm the correct store code is selected, then check the order's status: shipments appear on the Export CommerceHub Shipment screen only once the shipment is confirmed, and orders appear on the Export CommerceHub Invoices screen only once they are invoiced or invoiced and released. For acknowledgements, an order disappearing is the expected result of successful processing.

Work With the Biz-Tech Services CommerceHub Connector

The Biz-Tech Services CommerceHub Acumatica integration becomes straightforward once you think in files. The Mappings screen defines how the Biz-Tech Services CommerceHub Acumatica connector behaves, store codes separate one process from another, purchase orders arrive as sales orders under a default customer with the real shipping address, acknowledgements close the loop back to CommerceHub, and shipments, invoices, and inventory quantities flow outward as their supporting documents reach the right state. When something does not arrive, the Error Log, the CommerceHub Errors screen, and the Import Failed Purchase Orders screen tell you where it stopped.

If your business sells through CommerceHub and wants orders, acknowledgements, shipments, invoices, and inventory synchronized with Acumatica without manual re-keying, we are glad to help you scope, configure, and roll out the Biz-Tech Services Acumatica CommerceHub integration. Visit https://biz-techservices.com to learn more about our Acumatica integration expertise or to schedule a personalized demonstration of the Biz-Tech Services Acumatica CommerceHub Connector.

---

by Gary

How DSCO Data Flows Through Acumatica Order-to-Cash Automation

How DSCO Data Flows Through Acumatica Order-to-Cash Automation

The DSCO data flow in Acumatica moves a retailer order through five documented stages: DSCO orders are pulled into Acumatica ERP and turned into sales orders or invoices, the purchase order is acknowledged back to DSCO, inventory quantities are pushed out, shipment confirmation and tracking numbers are exported when the invoice is prepared, and the invoice is exported when it is released, which moves the order to Shipped. Each stage is a separate screen in Acumatica, and each one writes a status value you can read back on the order.

That separation matters more than it first appears. Because every leg of the flow is its own processing screen with its own selection grid, your business can see exactly where a record is sitting at any moment, and a failure in one leg does not silently poison the rest. This article walks the whole path in sequence, from installing the customization package and testing credentials through to exporting invoices and cancellations, and names the screens, tabs, checkboxes and fields that control each hop. Where the product documentation is silent on a step, this article says so rather than guessing.

What the DSCO Connector for Acumatica Does

The Biz-Tech Services DSCO Acumatica Connector is a customization package for Acumatica Enterprise Resource Planning (ERP) that connects an Acumatica instance to a DSCO store. DSCO is a drop-ship and retailer-supplier network, so the connector sits between the retailer-facing platform and the supplier-side Acumatica system that actually picks, ships and bills the goods.

Communication runs over the DSCO API. The Bzi-Tech Services Acumatica DSCO connector authenticates with an Access Token and a Base URL that you store on the DSCO Store screen in Acumatica, and every subsequent action - retrieving orders, acknowledging them, updating quantities, setting tracking numbers, sending invoice numbers, canceling orders and canceling individual lines - is an API request issued from a specific Acumatica screen.

The product must be installed on an Acumatica system carrying one of the specified licenses: PCSR, PERP or SAAS. If your instance is on a different license type, confirm eligibility with Biz-Tech Services before planning an implementation, because this is a prerequisite rather than a configuration option.

It is worth being precise about scope. The Bzi-Tech Services Acumatica DSCO connector automates the DSCO-facing legs of the order-to-cash cycle - order intake, acknowledgment, inventory availability, shipment confirmation and invoice export. The documentation does not describe payment application or cash receipt handling; the connector's documented responsibility ends when the invoice number has been sent to DSCO and the order reaches Shipped.

The DSCO Data Flow at a Glance

Before looking at individual screens, it helps to see the whole path in order. Each of the following steps corresponds to a real screen or button in Acumatica, and each one hands a record to the next step:

1. Install the DSCO Connector customization package on the Customization Projects form (SM204505) and publish it to the tenant.

2. Configure the DSCO Store screen: enter the Partner Code, Access Token and Base URL, then use Test Credentials to confirm the connection works before anything is imported.

3. Map the supporting data - default Customer, warehouse cross-references, inventory item cross-references and cancel codes - on the DSCO Store tabs, so imported records can resolve to real Acumatica records.

4. Pull orders inbound on the Import DSCO Orders screen using GET ORDERS, then IMPORT or IMPORT ALL to create sales orders or invoices in Acumatica.

5. Acknowledge the purchase order back to DSCO, either automatically through the Set Order as Acknowledged checkbox on the store, or manually from the Export DSCO PO Acknowledgment screen.

6. Push inventory availability outbound from the Export DSCO Inventory Quantities screen so DSCO sees current quantities for the mapped items and warehouses.

7. Confirm the shipment outbound on the Export DSCO Shipments screen, which sets the tracking number on the order and moves it to Pending Shipment.

8. Export the invoice on the Export DSCO Invoices screen, which sets the invoice number in DSCO and moves the order to Shipped, with the invoice status set to Closed.

Setting Up the DSCO Connector in Acumatica

How do you install the DSCO Connector package?

The Biz-Tech Services Acumatica DSCO connector is delivered as a deployment package and installed through the standard Acumatica Customization Projects form, form ID SM204505. This is the same form your business already uses to add a customization project, open a project in the Customization Project Editor, validate one or several projects, publish projects to one or more tenants, cancel a publication, view the published project XML, export a project as a deployment package, import a project from an existing package, and delete a project.

The relevant operation here is import followed by publish. When you upload the package, the platform uploads the selected package, creates the corresponding customization project, and saves the project in the database. Publishing that project is what makes the DSCO screens appear in your Acumatica instance. Because the Bzi-Tech Services DSCO Acumatica connector arrives through the ordinary customization pipeline, it is also validated and republished the ordinary way after an Acumatica upgrade.

What goes on the General Settings tab of the DSCO Store screen?

The DSCO Store screen is the control panel for the entire Bzi-Tech Services Acumatica DSCO integration. Once the connection has been established, you use this form to specify the store settings, select the entities that need to be synchronized, define the default settings for customer synchronization, inventory items and order synchronization, and map shipping rules between Acumatica ERP and the store.

On the General Settings tab, Partner Code is a lookup field that indicates the corresponding DSCO store, and Description is a free-text field used to describe that store. These two fields identify which trading relationship the record belongs to, which matters as soon as your business runs more than one store.

Two credential fields drive the API connection. Access Token is a digital credential used to authorize and authenticate a user or application, granting specific permissions to access resources or perform actions within a system or service. Base URL is the fundamental web address, or Uniform Resource Locator, that serves as the starting point for all relative URLs within a website or web application - in other words, the root endpoint that every API call is built on top of.

Why should you use Test Credentials before importing anything?

Test Credentials is a button that allows you to test the ability to connect to the DSCO store via the API by using the information specified on the General Settings tab. Running it is not a formality. Every downstream screen in the flow - order import, acknowledgment, inventory sync, shipment export, invoice export, cancellation export - depends on this one connection. If the Access Token or Base URL is wrong, each of those screens will fail individually and the failures will look like separate problems. Testing the credentials once, at setup time, turns a scattered set of symptoms into a single answer.

Order Settings: How DSCO Orders Enter Acumatica

The Order Settings tab of the DSCO Store screen decides what an imported order actually becomes in Acumatica and which orders are eligible to come in at all. These settings are read at import time, so changing them changes the behaviour of every subsequent import.

What document type do DSCO orders become in Acumatica?

The Import DSCO Orders To field specifies the document type into which the orders will be imported. A DSCO order can be imported to Acumatica as a Sales Order or as an SO Invoice. This is a structural decision rather than a cosmetic one: importing as a sales order gives your business the full pick, pack, ship and invoice sequence, while importing directly as an SO invoice shortens the path. Choose based on whether shipments are actually processed inside Acumatica.

Order Type sets the default type of orders to be created by the Bzi-Tech Services DSCO Acumatica integration. Together with the document type, it determines which Acumatica order processing rules apply to everything DSCO sends you, so it is worth aligning with how your business already segments drop-ship volume from ordinary sales.

What does the DSCO Status setting control?

DSCO Status is the status of the corresponding order that will be imported to Acumatica, presented as a set of checkboxes. The documentation is explicit on this point: the corresponding order status checkbox must be selected for the order to be retrieved and imported. If an expected order never appears in the import grid, this is the first setting to check, because an unchecked status silently filters the order out at the source rather than reporting an error.

When should Set Order as Acknowledged be checked?

When the Set Order as Acknowledged checkbox is selected, sending back a separate acknowledgment for the order is unnecessary - the Bzi-Tech Services Acumatica DCO integrator treats the order as acknowledged as part of the import. With the checkbox enabled and the order imported with the corresponding settings, the Acknowledged Status in DSCO field on the Sales Orders screen is set to Closed.

If the checkbox is not selected in a store, acknowledgment becomes a deliberate manual step: you send the acknowledgment for the corresponding order from the Export DSCO PO Acknowledgment screen in Acumatica. Neither approach is inherently better. Leaving the checkbox clear gives your business a review gate before the retailer is told the order is accepted; selecting it removes a step for high-volume, low-touch drop-ship traffic.

How do Begin Order Date and Last Imported Order Date limit what is retrieved?

Begin Order Date allows you to filter data retrieval, and Last Imported Order Date records the date when the last order was imported. The pair works as a window on the retailer side of the conversation. Begin Order Date is particularly important on a new installation, because without it a first retrieval can reach back further than your business intends and pull historical orders that were already handled elsewhere.

What do the two export checkboxes on Order Settings do?

Two checkboxes on the Order Settings tab wire the outbound half of the order-to-cash flow to ordinary Acumatica document processing, and they are the most consequential settings on the screen.

1. Export Shipment During Prepare Invoice: if this checkbox is selected, the system sends shipment information to DSCO and marks the order as shipment pending. If it is not selected, no API request is sent and no update is made in the Bzi-Tech Services Acumatica DSCO connector.

2. Export Invoice During Release Invoice: if this checkbox is selected, the system sends invoice information to DSCO and the order gets the Shipped status.

The design intent is that shipment confirmation and invoice transmission ride along with the Acumatica actions your team already performs. Preparing the invoice is what tells DSCO the goods are going out; releasing the invoice is what tells it the transaction is billed. If either checkbox is clear, the corresponding export screen stays empty and the DSCO order status never advances, which is the single most common reason an Bzi-Tech Services Acumatica DSCO integration appears to have stopped working.

Mapping Customers, Warehouses and Items Before the First Import

An incoming order arrives with the retailer's own identifiers. Before it can become an Acumatica document, those identifiers have to resolve to real Acumatica records - a customer, a warehouse, an inventory ID. The DSCO Store screen provides a dedicated tab for each of these mappings, and skipping them is the most reliable way to make imports fail.

What does the Customer Information tab set?

The Customer field on this tab allows you to select a default customer, which is then set on DSCO orders during the import process. Because drop-ship traffic from a single retailer partner typically bills to one account, a default customer keeps the import from needing to resolve a customer per order.

The Cross-Reference options on the same tab allow you to select the entities that should be matched in DSCO and Acumatica during the transition. This is a gate as well as a selection: only the checked entities of Cross-Reference Options will show up in the drop-down field on the Cross-Reference tab. If an entity you expect to map is missing from that drop-down, the cause is almost always an unchecked box here.

Why does the Use Cross Ref for Warehouse checkbox matter?

If the Use Cross Ref for Warehouse checkbox is selected, the values of the DSCO item's warehouse must be mapped to Acumatica warehouse values from the Cross-Reference tab. The documentation carries an explicit warning about the consequence of skipping this: if the warehouse values are not mapped, the order import process produces the error message "Warehouse does not have value."

That error is worth memorizing, because it is a configuration failure dressed up as a data failure. Nothing is wrong with the order itself; the Bzi-Tech Services DSCO Acumatica connector simply has no Acumatica warehouse to put the line against.

What is the Cross-Reference tab for?

The Cross-Reference tab holds the mappings that let the Bzi-Tech Services DSCO Acumatica integrator translate data elements between the Acumatica system and the DSCO system. The documentation is emphatic that setup accuracy here is a prerequisite for the outbound half of the flow as well as the inbound half: it is important to ensure the setup is correct before sending an API request to update order status and set tracking numbers in DSCO, and the accuracy of the data on this tab is crucial to the success of that request. If the mapping is incorrect or incomplete, the result is a failure to update order status and set tracking numbers correctly.

In practice this means a broken cross-reference does not only block imports. It can also let an order in and then break shipment confirmation days later, at the point where the retailer is waiting for a tracking number.

How does the Inventory Items tab map DSCO items to Acumatica inventory IDs?

The drop-down fields in the cross-reference section of the Inventory Item tab let you choose how to search for the item within the Bzi-Tech Services Acumatica DSCO connector and map it to the Acumatica Inventory ID. In the documented example, the drop-down value is set to SKU, meaning Stock Keeping Unit. With that setting, the system searches for an item with the corresponding SKU number and then associates it with the Acumatica inventory ID.

The same warning applies as with warehouses: if the item values are not mapped, an error message appears during the order import process. Choosing the matching key is therefore a decision about which identifier your business can guarantee is identical on both sides, not just a preference.

What goes on the Inventory Availability tab?

On the Inventory Availability screen you add the warehouses that need to be in sync with DSCO. Two behaviours follow from that list. First, if warehouses are selected on this screen, the exported item quantity displays the sum of quantities from those selected warehouses. Second, the item quantity synced from Acumatica to DSCO depends on the chosen drop-down value: On Hand, Available, or Available for Shipment.

That drop-down deserves a real decision rather than a default. On Hand reports physical stock regardless of commitments; Available and Available for Shipment reflect narrower, more conservative numbers. For drop-ship traffic, over-reporting availability to a retail partner produces oversell and cancellations downstream, which is precisely the failure the cancellation screens later in this article exist to clean up.

What are Cancel Codes used for?

Order cancel reasons are added to the Cancel Codes tab. When canceling orders, a cancellation reason must be selected, and the values offered are the reason codes that have already been set up on this tab. The list of cancellation reasons can be imported or exported as an Excel file, which makes it practical to keep the code list aligned with whatever the retailer partner expects without retyping it.

Setting these up early is a small task with an outsized payoff. Because a cancel code is mandatory at cancellation time, an empty Cancel Codes tab blocks a cancellation at exactly the moment your business is under time pressure to send it.

Inbound: Importing DSCO Orders into Acumatica

With the store configured, the inbound leg runs from the Import DSCO Orders screen. This screen allows you to get and import all orders from DSCO into Acumatica, and it splits the work into two deliberately separate actions - retrieval and import.

What does the GET ORDERS button do?

Pressing the GET ORDERS button retrieves the orders from DSCO. After clicking the button, a timer indicates the elapsed time until the process is complete. The documentation flags an important behaviour here: after clicking GET ORDERS, the screen gets and displays at once all orders for the selected period. On a first run, or after a long gap, that can be a large set, which is why Begin Order Date on the store settings is worth configuring deliberately.

Retrieval is not the same as import. At this stage the orders are staged on the screen for review, and nothing has been created in Acumatica yet. You can click an Order Number to view the corresponding order in a pop-up window, with the most important information shown on the DSCO Orders screen.

How do you import selected DSCO orders?

By selecting the order or orders that need to be imported and clicking the IMPORT button, you begin the import process. Alternatively, you can click the IMPORT ALL button to import every order in the grid. After pressing IMPORT, the selected orders get filtered off the screen - which doubles as your progress indicator, since what remains in the grid is what has not yet been imported.

A long-running import is not a trap. Users can cancel the process of importing orders by clicking Cancel Processing, so a batch that was started against the wrong selection can be stopped rather than waited out.

What happens when an order fails to import?

If an error occurs while processing, an error message is displayed in the line corresponding to that order in the grid. Users can hover the cursor over the red cross to view additional information about the error. For deeper diagnosis, the documentation directs you to click TOOLS then Trace to access additional information about an error.

This per-line error model is why import is worth running in reviewable batches. A failure is attributed to the specific order that caused it, the rest of the batch is unaffected, and the failed order stays visible in the grid so it can be retried after the underlying mapping is corrected.

What does the DSCO Orders screen show after import?

This screen is the record of what the Bzi-Tech Services Acumatica DSCO integrator knows about each order. Its DSCO Order Status section initially displays the status held in DSCO. Once the order is marked as shipped there, you can update that status inside Acumatica by opening the Actions menu and clicking the Refresh Order button - a manual pull that reconciles Acumatica's copy of the status with the DSCO platform.

After an order has been imported and an invoice created, this screen also shows the sales order number and the invoice number associated with that order. That makes DSCO Orders the natural place to answer the question "what did this order actually become in Acumatica?" without hunting through the Sales Orders screen.

Acknowledging DSCO Purchase Orders

Acknowledgment is the first thing the retailer hears back after sending an order, and it is controlled entirely by the Set Order as Acknowledged checkbox described earlier.

If that checkbox is not selected on the store, then after importing an order into Acumatica it appears on the Export DSCO PO Acknowledgment screen, which gives you the opportunity to send the acknowledgment from there. After sending the acknowledgment for the corresponding order from that page, the order disappears from the screen, and the Acknowledged Status in DSCO field on the Sales Orders screen is updated to Closed.

The disappear-when-done pattern repeats across every outbound screen in this Bzi-Tech Services Acumatica DSCO connector, and it is the most useful monitoring habit to build. Each export screen is effectively a work queue: if a document is still listed, the corresponding message has not reached DSCO yet.

Keeping DSCO Inventory Quantities in Sync

The Export DSCO Inventory Quantities screen is used for syncing Acumatica and DSCO inventory quantities. Beforehand, you choose the required items from the Inventory Items tab of the DSCO Store screen and press Save, which is what puts those items in scope for the sync.

There are two documented ways to update an inventory quantity from this screen:

1. Select the checkbox for the item and click the SYNC button. The Quantity field is pushed to DSCO and the inventory quantity there is updated. Quantity is a read-only field that indicates the inventory quantity of the item in the Acumatica system.

2. Change the DSCO Quantity field, select the checkbox, then click SYNC. The inventory quantity in DSCO is updated based on the DSCO Quantity value rather than the Acumatica figure.

The second option exists for good reason. There are legitimate cases where the number a retailer should see is not the raw Acumatica figure - stock reserved for another channel, for example - and the editable DSCO Quantity field lets your business publish a deliberate number. Because Quantity is read-only, the two paths cannot be confused: whatever you type goes in DSCO Quantity, and whatever Acumatica calculates stays in Quantity.

Outbound: Confirming Shipments Back to DSCO

Shipment confirmation is where the order-to-cash flow turns outbound, and it is the leg the retailer is usually watching most closely.

When the relevant checkbox - Export Shipment During Prepare Invoice - is chosen within the store, the Export DSCO Shipments screen presents the count of shipments that have been confirmed. Upon selecting and processing these shipments, the order status in the Bzi-Tech Services DSCO Acumatica integrator is updated to Pending Shipment, and the tracking number is set on the DSCO order.

Two behaviours are worth holding onto. First, if the Export Shipment During Prepare Invoice checkbox is not selected, no API request is sent and no updates are made by the Bzi-Tech Services Acumatica DSCO integrator - the screen simply has nothing to do. Second, once the shipment is dispatched, the Shipment Status in DSCO field shows the value Closed and the shipment number no longer appears on the Export DSCO Shipments screen.

That second point is the practical monitoring rule for this stage. A shipment number that is still sitting on the Export DSCO Shipments screen has not been confirmed, no matter what the Acumatica shipment itself says.

Outbound: Exporting Invoices to Close the DSCO Order

The invoice is the last documented outbound message in the flow, and it is what moves the DSCO order to its final state.

If the Export Invoice During Release Invoice checkbox is chosen in the store settings, processing invoices from the Export DSCO Invoices screen updates the DSCO order status to Shipped and sets the corresponding invoice number there. The invoice status in DSCO is then set to Closed, and the invoice number is removed from the Export DSCO Invoices screen.

This is the endpoint of the connector's documented responsibility. From the retailer's side of the network, the order is now shipped, carries a tracking number and carries an invoice number; from your side, the Acumatica invoice is released and enters your normal accounts receivable process. The product documentation does not describe payment application, cash receipts or remittance handling, so anything beyond the released invoice sits outside what the Bzi-Tech Services DSCO Acumatica connector is documented to do.

Cancellations: Exporting Canceled DSCO Orders and Line Items

Not every order completes, and the Bzi-Tech Services Acumatica DSCO connector treats a cancellation as an outbound message that has to reach DSCO explicitly. Two screens handle it, one for whole orders and one for individual lines.

How do you cancel a whole DSCO order?

The Export DSCO Canceled Orders screen allows you to export all orders that have been canceled from the Sales Orders screen. To cancel a DSCO order from the Sales Orders screen, open Actions and select the Cancel Order button. A pop-up window appears where you fill in the Canceling a Line and DSCO Cancel Code fields - the latter offering the reason codes already set up on the Cancel Codes tab of the DSCO Store screen. After pressing Yes, the order is canceled and appears on the Export DSCO Canceled Orders screen. Upon selecting the order and processing it, the system sends an API request to update the order status to Canceled in DSCO.

How do you cancel a single line on a DSCO order?

The Export DSCO Order Item Canceled screen allows you to cancel the line item of a DSCO order while the order is on the Sales Orders screen. For item cancellation you can change the quantity to zero or delete the line, after which a pop-up window appears where you fill in the Canceling a Line and DSCO Cancel Code fields. After pressing Yes, the cancellation is recorded and appears on the Export DSCO Order Item Canceled screen. Upon selecting the order and processing it, the system sends an API request to update the item status to Canceled in DSCO.

The important discipline here is that canceling in Acumatica is only half the transaction. Until the record is selected and processed on the matching export screen, DSCO still believes the order or the line is live, and the retailer is still expecting it.

Where to Monitor DSCO Results in Acumatica

Because each leg of the flow has its own screen and its own status field, monitoring the Bzi-Tech Services DSCO Acumatica integration is a matter of knowing which field answers which question. These are the exact places to look:

1. DSCO Store, General Settings tab - use Test Credentials to confirm the Access Token and Base URL still authenticate against the API.

2. DSCO Store, Order Settings tab - check Last Imported Order Date to see when the last successful order import ran, and Begin Order Date to see how far back retrieval reaches.

3. DSCO Store, Order Settings tab - confirm the DSCO Status checkboxes, since an unchecked status prevents matching orders from being retrieved at all.

4. Import DSCO Orders screen - anything still listed in the grid after a GET ORDERS run has been retrieved but not yet imported.

5. Import DSCO Orders screen - hover over the red cross on a grid line to read the error message for that specific order, then use TOOLS then Trace for the fuller detail.

6. DSCO Orders screen, DSCO Order Status section - the current DSCO-side status of the order, refreshable through Actions then Refresh Order.

7. DSCO Orders screen - the sales order number and invoice number created in Acumatica for that order.

8. Sales Orders screen, Acknowledged Status in DSCO field - Closed means the purchase order acknowledgment has been sent.

9. Export DSCO PO Acknowledgment screen - any order still listed has not been acknowledged yet.

10. Export DSCO Shipments screen and the Shipment Status in DSCO field - a shipment number that has disappeared from the screen and shows Closed has been confirmed with its tracking number.

11. Export DSCO Invoices screen - an invoice number that has been removed from the screen has been sent, with the order moved to Shipped and the invoice status in DSCO set to Closed.

12. Export DSCO Canceled Orders and Export DSCO Order Item Canceled screens - anything still listed is a cancellation that has not been sent.

DSCO Acumatica Integration: Frequently Asked Questions

Why is a DSCO order not importing into Acumatica?

Work through the settings in the order the Bzi-Tech Services DSCO Acumatica connector reads them. First confirm the corresponding order status checkbox is selected under DSCO Status on the Order Settings tab, because the documentation states the order will not be retrieved and imported otherwise. Then check Begin Order Date, which filters data retrieval and can exclude older orders entirely. If the order is retrieved but fails at import, hover over the red cross on its line in the Import DSCO Orders grid and use TOOLS then Trace for the detail.

What does the error "Warehouse does not have value" mean?

This error appears during the order import process when the DSCO item's warehouse values have not been mapped to Acumatica warehouse values. It occurs when the Use Cross Ref for Warehouse checkbox is selected on the Customer Information tab but the corresponding mapping is missing from the Cross-Reference tab. Add the warehouse mapping on the Cross-Reference tab and import the order again - nothing needs to change on the DSCO side.

Why did DSCO shipment confirmation fail or never happen?

The first thing to check is the Export Shipment During Prepare Invoice checkbox on the Order Settings tab of the store; if it is not selected, no API request is sent and no updates are made in the Bzi-Tech Services Acumatica DSCO integrator at all. If the checkbox is selected and the shipment is still listed on the Export DSCO Shipments screen, the shipment has not been selected and processed yet. If processing is failing, review the Cross-Reference tab, since the documentation states that incorrect or incomplete mapping there causes failures to update order status and set tracking numbers.

Can a DSCO order be imported as an invoice instead of a sales order?

Yes. The Import DSCO Orders To field on the Order Settings tab specifies the document type into which DSCO orders will be imported, and the documented options are Sales Order and SO Invoice. Choose SO Invoice when your business does not process the shipment inside Acumatica, and Sales Order when you need the full order, shipment and invoice sequence - including the shipment confirmation leg back to DSCO.

How do I send a purchase order acknowledgment to DSCO manually?

Leave the Set Order as Acknowledged checkbox clear on the DSCO Store. Imported orders then appear on the Export DSCO PO Acknowledgment screen, where you select and send the acknowledgment. Once sent, the order disappears from that screen and the Acknowledged Status in DSCO field on the Sales Orders screen changes to Closed.

Which quantity does Acumatica send to DSCO?

It depends on two settings on the Inventory Availability tab. The warehouses you add there determine the scope, and if warehouses are selected the exported item quantity is the sum of the quantities from those warehouses. The drop-down value then determines the basis: On Hand, Available, or Available for Shipment. You can also override the figure at send time by editing the DSCO Quantity field on the Export DSCO Inventory Quantities screen before clicking SYNC.

Why is a canceled Acumatica order still open in DSCO?

Canceling the order on the Acumatica Sales Orders screen through Actions then Cancel Order only stages the cancellation. The order then appears on the Export DSCO Canceled Orders screen, and the API request that updates the order status to Canceled in DSCO is sent only when you select that record and process it. The same two-step pattern applies to line-level cancellations on the Export DSCO Order Item Canceled screen.

How do I update a DSCO order status inside Acumatica after it ships?

Open the DSCO Orders screen for that order, open the Actions menu and click Refresh Order. The DSCO Order Status section initially shows the status captured at import time; Refresh Order pulls the current status from DSCO once the order has been marked as shipped there, so Acumatica reflects reality rather than a stale value.

Work With the Biz-Tech Services DSCO Connector

The DSCO data flow through Acumatica is a sequence of clearly separated hops: configure and test the connection on the DSCO Store screen, map customers, warehouses, items and cancel codes so incoming identifiers resolve to Acumatica records, import orders on the Import DSCO Orders screen, acknowledge them, keep inventory quantities current, then let the Export Shipment During Prepare Invoice and Export Invoice During Release Invoice checkboxes carry shipment confirmation and invoice numbers back out as your team prepares and releases invoices in the normal way. Every stage leaves a status you can read, and every outbound screen behaves as a queue that empties when the message has landed. Getting the cross-reference mapping right up front is what keeps that queue moving.

The DSCO Connector for Acumatica ERP is built and supported by Biz-Tech Services, Inc. If your business is planning a Bzi-Tech Services Acumatica DSCO integration, or wants a review of an existing configuration, visit https://biz-techservices.com to learn more about the connector and the rest of the Biz-Tech Services product range for Acumatica.

---

by Gary

How ShipStation Data Flows Between Shipping and Acumatica ERP

How ShipStation Data Flows Between Shipping and Acumatica ERP

ShipStation data moves through Acumatica ERP as a round trip: a sales order is exported to a connected store on the shipping platform, the label and shipment are produced there, and the shipment number and tracking number come back to update the order and move it to Prepare Invoice. The Biz-Tech Services ShipStation Acumatica Connector is what carries records across that loop. It adds a store record to Acumatica, a set of processing screens for pushing orders out and pulling shipments back, and dedicated fields on the Sales Orders and Shipments screens so users can see exactly what happened to each document.

The Biz-Tech Services Acumatica ShipStation connector is not a one-directional feed. It supports two integration directions, and the direction you choose changes which tabs appear on the store record, which processing screens become usable, and which way orders, shipments, customers, and items travel. This article follows the records themselves rather than the chapter order of the documentation: first the credentials and store setup that make any transfer possible, then orders moving out for fulfillment, then shipment and tracking data coming back, then the alternative flow driven by the Confirm Shipment process, then the reverse direction where the shipping platform is the system of record for the order, then item synchronization, and finally where to look when something does not arrive.

What the ShipStation Connector for Acumatica Does

ShipStation is a web-based shipping solution built to optimize order fulfillment for online businesses. It consolidates orders from more than 70 ecommerce channels, generates shipping labels, packing slips, and pick lists in batch mode, communicates tracking information to customers, and provides automation, filtering and viewing options, wireless printing, and a dedicated mobile app. The Biz-Tech Services Shipstation Acumatica connector links that platform to Acumatica ERP so that fulfillment and shipping run as one connected process instead of two separate systems that someone has to reconcile by hand.

In practical terms it does two things. First, order syncing: orders move between the two systems so that documents originating in diverse sales channels can be viewed and managed centrally in the shipping interface. Second, shipping and fulfillment: users generate labels, produce packing slips, and manage shipments directly in that interface, using the carrier options and shipping methods available there, and the result is written back against the correct order in the ERP. The Biz-Tech ShipStation product must be installed on a system carrying one of the specified licenses: PCSR, PERP, or SAAS.

The ShipStation Data Flow at a Glance

Before looking at individual screens, it helps to see the whole round trip in order. The sequence below describes the primary Acumatica to ShipStation direction, where the sales order starts in the ERP and the shipment is created on the shipping side:

• Setup: the package is published on the Customization Projects (SM204505) form, and a ShipStation Store record is created with Connection Settings holding the Consumer Key, Consumer Secret, and Base URL that authenticate every call.
• Direction: the Integration Option on the store record is set to Acumatica to ShipStation, and the Process Flow is set to Shipment in ShipStation, which enables the export and import processing screens for this path.
• Reference data: the Get Stores, Get Carriers, and Get Packages buttons, plus the ShipStation Warehouses tab, pull connected stores, carrier codes, package types, and warehouses into Acumatica so exported orders carry values the shipping platform recognizes.
• Orders out: a sales order is exported from the Create Orders in ShipStation screen, or from the Actions menu of the Sales Orders screen, and the order is created under the configured Store Code and ShipStation Store ID.
• Acknowledgement: the platform returns an identifier that is written into the ShipStation Order ID field on the Sales Orders screen. That field is the proof the order left Acumatica.
• Fulfillment: warehouse staff work the order on the shipping side, choose the carrier and service, and generate the label. Acumatica takes no part in this stage.
• Shipment and tracking back in: the Import Shipment from ShipStation screen, or the Get Shipstation Shipments action on the Sales Orders screen, pulls the shipment across and adds the shipment number and tracking number to the corresponding order.
• Handover to billing: once that information lands, the order status is updated to Prepare Invoice, so the record continues through the standard order-to-invoice process.

Setup and Credentials: What Has to Exist Before Any Data Moves

Nothing crosses between the two systems until the package is published and a store record exists. This stage is worth doing carefully, because almost every failure users report later traces back to a setting chosen here.

Installing the package

The package is installed through the Customization Projects (SM204505) form. This is the standard form used to add a new customization project, open a project for editing in the Customization Project Editor, validate one or more projects, publish a project for one or multiple tenants, cancel a publication, view the XML of a published project, export a project as a deployment package, import a project from an existing deployment package, and delete a project. On import, the platform uploads the selected package, creates the corresponding customization project, and saves that project in the database. Publishing it is what makes the new Acumatica screens and fields appear.

Connection Settings: the credentials behind every transfer

The ShipStation Store screen is where all configuration lives, including Connection Settings, the Integration Option, and the setup relevant to the selected integration. The Store Code field is a lookup field that corresponds to the specific store, which ensures the right one is selected for the integration, and the Description field holds a short description of it.

Connection Settings is where users enter the Consumer Key, Consumer Secret, and Base URL credentials. These three values establish the link between the two platforms and are used to authenticate and enable communication between them. Because every subsequent button on every screen depends on them, they are the single highest-value thing to verify. That is what the Test Credentials button is for: it verifies the ability to connect through the Application Programming Interface, or API, using the information supplied on the Connection Settings tab. If a value has to change later, the Edit Credentials option lets users modify what is stored.

Integration Option: the setting that decides which way records travel

The Integration Option defines the direction of the data flow. Users choose whether the integration runs from ShipStation to Acumatica or from Acumatica to ShipStation. This is not a cosmetic preference. It determines which tabs the store record displays and which processing screens will accept the store code at all, so setting it incorrectly makes entire screens refuse to work.

Configured as ShipStation to Acumatica, the system allows orders to be imported with or without their shipments, and the store record shows the General Info, Import Info, Ship Via Cross Reference, Warehouse Cross Reference, and Inventory Details tabs. Configured as Acumatica to ShipStation, the visible tabs are General Info, Carriers and Services, Packages, and ShipStation Warehouses. The General Info tab stays consistent and unchanged regardless of direction, which keeps the core connection and store management settings the same on both sides.

Selecting the Acumatica to ShipStation option also reveals an additional field called Process Flow, with two drop-down values. Shipment in ShipStation retrieves all shipments from the shipping platform. Shipment in Acumatica generates those shipments from within the ERP. These are two genuinely different data flows, and both are described below.

General Info: selecting the store that records belong to

On the General Info tab, the Get Stores button retrieves and displays all the stores currently connected on the shipping side. They are then shown in the ERP, which makes it easier for users to manage and interact with connected stores without leaving the system. The Selected checkbox next to each one determines which store is used for importing orders and shipments. If nothing is selected, there is no source or destination for the records to attach to.

Outbound: How Acumatica Orders Are Exported to ShipStation

With the Integration Option set to Acumatica to ShipStation and Process Flow set to Shipment in ShipStation, the sales order begins its life in Acumatica and is pushed out for fulfillment.

Populating the carrier, package, and warehouse tabs first

This direction exposes three reference tabs that must be filled before exports make sense. To set up each one, users open the corresponding tab and press the relevant button. Clicking Get Carriers retrieves and displays all carrier codes. Pressing Get Packages retrieves all available package types, and selecting the corresponding checkbox chooses the package to be used for the order. The ShipStation Warehouses tab operates on the same logic: press the button, review what comes back, and select what applies.

This matters because those values originate on the shipping side, not in Acumatica. Pulling them across means the exported order already carries a carrier code, a package, and a warehouse that the receiving system recognizes, rather than internal values it has never seen.

Exporting orders from the Create Orders in ShipStation screen

The Export Acu Orders screen is the bulk export point. To use it, the Integration Option of the store setup must be Acumatica to ShipStation and the Process Flow must be Shipment in ShipStation. The screen displays all orders created in Acumatica that can be exported, and the export runs against the configured Store Code and ShipStation Store ID.

Exporting a single order from the Sales Orders screen

Order export and creation can also be performed directly from the Sales Orders screen by clicking the Create ShipStation Order button under the ShipStation option in the Actions menu. This is the same operation applied to one document. It is the natural choice when a single order has to reach the warehouse immediately rather than waiting for the next bulk run.

What the ERP records when the export succeeds

When the order is exported, it is generated on the shipping side and the resulting identifier is displayed in the ShipStation Order ID field of the Sales Orders screen. That single field is the confirmation that the outbound half of the round trip completed. An order with no value there has not been created downstream, whatever else the screen shows.

Inbound: How Shipment, Tracking, and Carrier Data Return to Acumatica

Once the order is out, fulfillment happens on the shipping side. Staff pick, pack, choose a carrier and service, and generate the label using the carrier options and methods available there. The ERP is not involved in that stage, which is the point of the Biz-Tech Services ShipStation Acumatica integration: the shipping platform does shipping work, and the ERP receives the result.

Shipment confirmation and the handover to invoicing

The import does more than copy numbers. Once the shipment information is applied, the order status is updated to Prepare Invoice. That status change is the hinge between fulfillment and billing: the order leaves the shipping stage and re-enters the normal document flow, where it is invoiced through standard order processing. If an order is still sitting in its pre-shipment status, the data has not been imported yet, no matter what the shipping platform shows.

The documented workflow can be performed from the Sales Orders screen as well as from the Create Orders in ShipStation and Import Shipment from ShipStation processing screens. Both routes produce the same result, so your business can standardize on whichever fits the volume being shipped.

The Alternative Flow: Creating the Order and Shipment During Confirm Shipment

The second Process Flow option, Shipment in Acumatica, describes a different and shorter round trip. Here both the order and its shipment are created downstream from the ERP during the Confirm Shipment process, rather than the shipment being built by hand on the shipping side and then retrieved.

To create an order together with its shipment this way, users first create a Sales Order and then create a Shipment. After the shipment creation process, they manually fill in the ShipStation Information option on the Shipping tab of the Shipments screen and proceed with the Confirm Shipment process. That manual step matters, because Confirm Shipment is what triggers the transfer and it can only send what has been filled in beforehand.

After confirmation, the order and its corresponding shipment are created downstream. The returned information, including Store Code, ShipStation Store ID, ShipStation Order ID, and ShipStation Order Number, is populated in the ShipStation Information option on the Shipping tab of the Shipments screen, along with the tracking information on the Packages tab. This is the flow to choose when your business wants shipments packed and confirmed in Acumatica and only wants the shipping platform to handle carrier labels and tracking.

The Reverse Direction: Importing ShipStation Orders into Acumatica

When the store record is configured as ShipStation to Acumatica, the flow runs the other way. Orders originate downstream, typically because they came from one of the ecommerce channels the platform consolidates, and Acumatica receives them as sales orders. Based on this setup, two processing screens are enabled for retrieving and importing orders and shipments created externally: Import ShipStation Orders and Import ShipStation Shipment Orders.

Import Info: which orders are eligible to come across

The Import Info tab holds the Default Import Options, which include two key fields, Status Key and Status. These map external order statuses to corresponding statuses in Acumatica, and the mapping defines which statuses are eligible for import. If no specific status is selected, the default is to retrieve orders that have the Shipped status. The statuses eligible for mapping and import are Awaiting Shipment, Awaiting Payment, Pending Fulfillment, Shipped, On Hold, and Cancelled.

Three further fields control what the imported document becomes. Import ShipStation Orders To specifies the document type the orders will be imported into, which is how they get classified once inside. Order Type specifies the corresponding order type used for the import. Begin Order Date displays the starting date for importing orders, and only orders placed on or after that date are imported, which is what keeps a first run from reaching back through the entire history.

Bringing shipments across with the order

Two checkboxes govern shipment data on this side. When the ShipStation Shipment checkbox is selected, then during the get process on the Import ShipStation Orders screen, any shipment associated with the order is also imported and displayed under the Shipment tab on the ShipStation Orders screen. The Generate Shipment When Importing Orders checkbox enables the import of existing shipment data along with the order details, so the related shipment information arrives with the order rather than being fetched separately.

Customer and address handling on import

When the Import Customer checkbox is selected, the Biz-Tech Services ShipStation Acumatica integration imports the customer information and creates a new customer record, so details such as name, address, and contact information are accurately reflected in Acumatica. If it is not selected, orders are imported with the default customer settings from the source system instead. This choice decides whether your customer list grows with every new ecommerce buyer or stays curated.

Two override checkboxes handle addresses. Override Ship Address Information allows the incoming shipping address to override the address held in Acumatica, which ensures the order is shipped to the correct location. Override Bill Address Information imports the billing address, which may differ from the default billing information already on file. These are the settings to check first when an imported order ships or bills to an unexpected address.

Item information and SKU creation

When the Import Item checkbox is selected, the system checks whether the item exists and, if it does not, creates a new item record during the order import process. Selecting Import Item also reveals additional options: Imported Item Type, Item Class, UOM (Unit of Measure), and Warehouse ID. These define the default values used when new items are created, so they are effectively the template for every item the Biz-Tech Services Acumatica ShipStation integrator invents.

If Import Item is not selected and a new item is found during the import, the system automatically assigns default values, using Replace Missing Products for the item name and the Warehouse ID from the setup for the warehouse. Two supporting options round this out. Use Numbering Sequence for SKU Generation means that if no existing SKU (Stock Keeping Unit) number is found during item creation, a new one is generated using the numbering sequence already set up, which keeps SKUs consistent and unique. Import Images, when selected, imports and creates images for the stock item; when it is not selected, image data is not retrieved.

Tax options on imported orders

The Tax Options group controls how tax arrives with an order. When the Import Tax checkbox is selected, the system imports and displays the associated taxes, which keeps tax information synchronized between the two systems. Customer Tax Zone refers to the combined taxes that apply based on the tax zone, which is defined according to the locations of customers or vendors and determines tax rates by geographical zone. Tax ID represents the customer tax identification number, which may be required for tax reporting or compliance. Taxable Category is used to create new tax categories or edit existing ones, and those categories are applied to the products being sold so the correct taxes are applied during order processing.

Cross-references for warehouses and shipping methods

The Cross-Reference options let users select specific entities that should be matched between the two systems during the integration process. Use Cross Ref for Warehouse enables cross-referencing between warehouses on each side, so inventory is correctly mapped and synchronized. Use Cross Ref for Ship Via allows cross-referencing between shipping methods, which ensures the appropriate method is used when processing orders. Selecting these fields reveals additional tabs, Warehouse Cross Reference and Ship Via Cross Reference, where the mappings are configured.

Cross-references are the quiet fix for a whole class of data problems. Two systems rarely name the same warehouse or the same carrier service identically, and without a mapping the imported order carries a value the receiving system cannot resolve.

The Import ShipStation Orders and Import ShipStation Shipment Orders screens

The Import ShipStation Orders screen retrieves and imports all orders from the selected store ID. Pressing Get Orders retrieves and displays them. Pressing Import brings the selected orders into the Sales Orders screen. Pressing Import All brings in every order currently displayed regardless of its selection status, which is the fast path when a full batch needs to come across.

The Import ShipStation Shipment Orders screen retrieves and processes all orders that have shipments, and it does so regardless of the ShipStation Shipment checkbox setting on the store record. That exception is worth remembering: this screen ignores the checkbox that governs the other import screen.

Both screens carry the same restriction. They are functional and allow a store code to be selected only if the Integration Option of that store is configured as ShipStation to Acumatica. If it is not, the system displays an error message indicating that the corresponding store is not used to import orders.

Item and Inventory Synchronization Between Acumatica and ShipStation

Orders and shipments are only half the traffic. The Inventory Details tab on the store record, available in the ShipStation to Acumatica configuration, handles product data moving in both directions so the two catalogs describe the same goods.

1. Load Acumatica Items retrieves all Stock and Non-Stock items and displays them in a table, making the relevant inventory accessible for viewing or further processing within the Biz-Tech Services Acumatica ShipStation integration.

2. Update ShipStation Items from Acumatica exports the listed items outward, so product data downstream is updated with the latest information from the ERP.

3. Load ShipStation Items retrieves items from the shipping platform and displays them, bringing the available products into view for any necessary updates or Biz-Tech Services ShipStation Acumatica integrator processes.

4. Generate Items in Acumatica from ShipStation imports items inward. If an item exists downstream but not in the ERP, this option creates it so Acumatica reflects the products available there.

5. Load ShipStation Item by SKU retrieves one specific item using its SKU. Entering the SKU pulls the exact item across, which is the targeted option when only one product is out of step.

Keeping this catalog aligned is what prevents item-level failures further down the flow. An order that references a SKU one system does not recognize is an order that cannot be created cleanly on the other side.

What Can Go Wrong in the ShipStation Data Flow

Most problems here are configuration problems rather than transfer problems, and the documentation points at a specific set of them.

The clearest documented error is the direction mismatch. If a user opens Import ShipStation Orders or Import ShipStation Shipment Orders and tries to select a store whose Integration Option is not ShipStation to Acumatica, the system displays an error message indicating that the corresponding store is not used to import orders. The mirror image applies to the export side: Create Orders in ShipStation and Import Shipment from ShipStation both require the Integration Option to be Acumatica to ShipStation with Process Flow set to Shipment in ShipStation, so a store configured any other way will not drive them.

The second common cause is scope rather than error. Begin Order Date excludes anything placed before the configured date. The Status Key and Status mapping excludes any order whose status was never mapped, and with nothing selected the default is to retrieve only Shipped orders. The Selected checkbox on General Info excludes any store that was not chosen. In each case the Biz-Tech Services Acumatica ShipStation integrator is working exactly as configured and simply has no reason to move the record.

The third is credentials. Because the Consumer Key, Consumer Secret, and Base URL authenticate every API call, an expired or mistyped value stops all traffic in both directions at once. The Test Credentials button on the Connection Settings tab is the fastest way to rule this in or out before investigating anything else.

Where to Monitor ShipStation Results in Acumatica

The Biz-Tech Services Acumatica ShipStation connector writes its results into specific, checkable places. When a user asks what happened to an order, these are the fields and screens that answer the question:

• ShipStation Order ID on the Sales Orders screen: populated once the order has been exported and created downstream. Empty means the export did not complete.
• The order status on the Sales Orders screen: updated to Prepare Invoice once shipment information has been imported.
• The Import Shipment from ShipStation screen: it displays all orders that have already been exported, so it doubles as a list of what made it across.
• The Create Orders in ShipStation screen: it displays all orders that can still be exported and created, which is effectively the outbound backlog.
• The shipment number and tracking number added to the corresponding order after the shipment is imported.
• The ShipStation Information option on the Shipping tab of the Shipments screen: after Confirm Shipment in the Shipment in Acumatica flow, it holds the Store Code, ShipStation Store ID, ShipStation Order ID, and ShipStation Order Number.
• The Packages tab of the Shipments screen: it carries the tracking information written back after the order and shipment are created from Acumatica.
• The Shipment tab on the ShipStation Orders screen: when the ShipStation Shipment checkbox is selected, any shipment associated with an imported order appears here.
• The ShipStation Orders generic inquiry: it displays the initial conditions of the imported orders.
• The ShipStation Shipments generic inquiry: it displays all initial information about the shipment orders.
• The General Info tab of the store record: the list returned by Get Stores and the Selected checkbox confirm which store the Biz-Tech Services Acumatica ShipStation integration is actually using.
• The Connection Settings tab: the Test Credentials button confirms whether Acumatica can still reach the shipping platform through the API at all.

ShipStation Acumatica Integration: Frequently Asked Questions

How do orders get from Acumatica to ShipStation?

Orders are exported either in bulk from the Create Orders in ShipStation screen or one at a time from the Sales Orders screen, using the Create ShipStation Order button under the ShipStation option in the Actions menu. The export uses the configured Store Code and ShipStation Store ID to decide which store receives the order. Both routes require the store record to have Integration Option set to Acumatica to ShipStation and Process Flow set to Shipment in ShipStation.

Why did an order not export to ShipStation?

Start with the ShipStation Order ID field on the Sales Orders screen: if it is empty, the order was never created downstream. The most common reason is that the store record is not configured for that direction, because Create Orders in ShipStation only works when the Integration Option is Acumatica to ShipStation and the Process Flow is Shipment in ShipStation. Also confirm the credentials still pass the Test Credentials check on the Connection Settings tab, since a failed connection stops every export.

Why is the tracking number missing on my Acumatica order?

The tracking number arrives only when the shipment is imported back, either from the Import Shipment from ShipStation screen or through the Get Shipstation Shipments button in the Actions menu of the Sales Orders screen. If that import has not run, or if no shipment exists yet for that order, there is nothing to write back. A reliable secondary check is the order status: if it has not moved to Prepare Invoice, the shipment information was not applied.

What is the difference between Shipment in ShipStation and Shipment in Acumatica?

These are the two Process Flow options available when the Integration Option is Acumatica to ShipStation. Shipment in ShipStation retrieves all shipments from the shipping platform, so the shipment is built there and imported afterwards. Shipment in Acumatica generates those shipments from within Acumatica, so the order and its shipment are both created during the Confirm Shipment process.

How do I import ShipStation orders into Acumatica?

Set the store record Integration Option to ShipStation to Acumatica, then use the Import ShipStation Orders screen. Press Get Orders to retrieve and display everything available, then Import to bring the selected orders into the Sales Orders screen, or Import All to bring in every order currently displayed regardless of selection. If you specifically need orders that already have shipments, use the Import ShipStation Shipment Orders screen instead.

Which order statuses can be imported into Acumatica?

The statuses eligible for mapping and import are Awaiting Shipment, Awaiting Payment, Pending Fulfillment, Shipped, On Hold, and Cancelled. The mapping is done with the Status Key and Status fields under Default Import Options on the Import Info tab. If no specific status is selected, the default is to retrieve orders with the Shipped status, which is why a store that was never mapped appears to import almost nothing.

Why does the store code field not accept my store on the import screens?

Import ShipStation Orders and Import ShipStation Shipment Orders are functional and allow a store code to be selected only if the Integration Option of that store is configured as ShipStation to Acumatica. If it is configured the other way, the system displays an error message indicating that the corresponding store is not used to import orders. Either switch to a store set up for imports, or reconsider which direction that store is meant to serve.

Does the connector keep item data in sync?

Yes, through the Inventory Details tab on the store record. Load Acumatica Items and Update ShipStation Items from Acumatica push product data outward, while Load ShipStation Items, Generate Items in Acumatica from ShipStation, and Load ShipStation Item by SKU bring product data back in. Generate Items in Acumatica from ShipStation is the option that creates an item in Acumatica when it exists downstream but not here.

Work With the Biz-Tech Services ShipStation Connector

This data flow is a loop with clear checkpoints. Credentials and the Integration Option decide what is possible, the export writes an order identifier onto the sales order, the shipping platform does the picking, carrier selection, and label generation, and the import writes the shipment number and tracking number back and moves the order to Prepare Invoice. In the reverse direction, orders, customers, addresses, taxes, and items flow inward through the Import ShipStation Orders and Import ShipStation Shipment Orders screens. Knowing which field to check at each checkpoint turns most support questions into a ten-second answer.

If your business runs fulfillment through ShipStation and accounting through Acumatica ERP, the Biz-Tech Services Acumatica ShipStation connector can carry orders, shipments, tracking data, and items across that gap without manual re-entry. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary

How ShipHero Data Flows Between WMS and Acumatica ERP

How ShipHero Data Flows Between WMS and Acumatica ERP

ShipHero data flows into Acumatica ERP as a round trip: orders, purchase orders and return orders travel out of Acumatica to ShipHero, the Warehouse Management System (WMS) picks, packs and ships them, and shipments, tracking numbers, labels, receipts, bin transfers and return receipts travel back into Acumatica to close the documents out. The Biz-Tech Services ShipHero Acumatica Connector is the customization that carries records in both directions, and it is built around one central configuration screen - the ShipHero Store - that decides which way each record is allowed to move.

Understanding that round trip is what makes the Biz-Tech Services Acumatica ShipHero connector predictable. Most of the questions users raise after go-live are not really integration questions; they are questions about which checkbox on the ShipHero Store told a record to move, which cross-reference translated a value from one system to the other, and which inquiry screen shows what the WMS sent back. This article walks the whole path in the order records actually travel: package installation and credentials first, then outbound documents, then inbound fulfillment, then item and inventory sync, and finally the screens and fields your business checks to confirm that each hop worked.

What the ShipHero Connector for Acumatica Does

ShipHero is a warehouse management and order fulfillment platform built to streamline logistics and supply chain processes for eCommerce businesses. Acumatica is a cloud-based enterprise resource planning (ERP) system that manages finance, inventory and customer relationships. The Biz-Tech Services ShipHero Acumatica integrator is the software integration that sits between them and handles communication and data exchange, so that the fulfillment side and the ERP side stay on the same set of records instead of two teams keying the same order twice.

The Biz-Tech Services Acumatica ShipHero integrator is delivered as an Acumatica customization package and published through the Customization Projects screen (SM204505). That screen is where you add the customization project, validate it, and publish it for a tenant or several tenants; the platform uploads the selected package, creates the corresponding customization project and saves it in the database. Once the project is published, the ShipHero screens - the ShipHero Store, the processing screens, and the ShipHero Order, Shipment, Item, Vendor and Purchase Order inquiries - become available inside your ERP.

What the Biz-Tech Services ShipHero Acumatica connector does not do is guess. Every document type, warehouse, carrier, box and reason code that crosses the boundary has to be either explicitly enabled or explicitly mapped on the ShipHero Store first. That is deliberate: it means a misconfigured record fails to appear on a processing screen rather than silently creating the wrong document in Acumatica.

The ShipHero Data Flow at a Glance

Here is the full round trip between Acumatica and the ShipHero WMS, in the order the records move:

1. Install and publish the ShipHero customization package on the Customization Projects (SM204505) screen, then open the ShipHero Store screen and enter the ShipHero Username, ShipHero Password and Base URL on the Connection Settings area of the General Info tab. Use Test Credentials to confirm the API connection before anything else.

2. Choose the Integration Option on the ShipHero Store header - either ShipHero to Acumatica or Acumatica to ShipHero. This single field determines the direction of travel and which tabs the store displays.

3. Map the values that differ between the two systems: Ship Via Cross-Reference for carriers, Warehouse Cross-Reference for warehouses, Box Mapping for the Acumatica Box ID against the ShipHero box name, and Reason Code Mapping for returns.

4. Sync master data both ways from the Inventory Details, Locations and Vendors tabs - Load Acumatica Items and Sync Acumatica Items push outward; Load ShipHero Items and Sync ShipHero Items pull inward.

5. Send documents out to the warehouse: Sales Orders through the Export ShipHero Order screen, purchase orders through Export Purchase Orders to ShipHero, and RC return orders through Export Return Orders To ShipHero.

6. ShipHero fulfills the work - it picks and ships the order, generates the shipping label and tracking number, receives the purchase order, moves stock between bins, and receives returns.

7. Bring the results back: Import Shipments from ShipHero confirms the Acumatica shipment, Import Receipts from ShipHero creates the purchase receipt, Import Bin Transfers from ShipHero creates the transfer, and Import Return Order Receipt from ShipHero creates the return document.

8. Optionally switch the whole inbound side to real time by enabling Use Webhook on the ShipHero Store header and registering shipment, PO receipt, return receipt and transfer webhooks on the Webhook Settings tab.

9. Monitor everything on the ShipHero Order, ShipHero Shipment, ShipHero Item, ShipHero Vendor and ShipHero Purchase Order inquiry screens, and on the Shipments tab of the related Sales Order.

Setup: Installing the Package and Configuring the ShipHero Store

Nothing moves until the customization is published and the store is configured. This is the part of the flow your business only does once, but every later behaviour traces back to a decision made here.

How do you install the ShipHero package in Acumatica?

The Biz-Tech Services ShipHero Acumatica connector is installed through the Customization Projects screen, Form ID SM204505. From that form you can add a new customization project - a set of changes and additional files that modify the Acumatica ERP application - open the project in the Customization Project Editor, validate one or several projects, publish a project for one tenant or multiple tenants, cancel a publication, view the XML of a published project, export the project as a deployment package, import a project from an existing deployment package, or delete a project. When you upload the ShipHero package, the platform creates the corresponding customization project and saves it in the database; publishing it is what makes the screens live.

Where do ShipHero credentials go?

Credentials live on the Ship Hero Store Credentials screen. The Connection Settings area of the General Info tab holds the ShipHero Username, ShipHero Password and Base URL - the ShipHero system credentials used during integration. Two buttons govern them: Test Credentials checks that Acumatica can reach ShipHero over the API using exactly what is on the Connection Settings tab, and Edit Credentials unlocks the fields so they can be changed. Run Test Credentials before you touch any processing screen, because a store whose credentials never validated will simply return nothing when you press Get Orders or Get Shipments, with no document to inspect afterwards.

The header of the store also carries the identifying fields. ShipHero Store Code is a lookup field that points at the corresponding store in the WMS, and Description labels it for your users. The Default Store checkbox matters more than it looks: when it is selected, that store code is the one displayed during all sync processes initiated from Acumatica, which is what keeps a multi-store setup from making users pick a store on every single action.

What does the Integration Option actually change?

The Integration Option field determines the workflow direction, and it changes which tabs the ShipHero Store even displays. Set to ShipHero to Acumatica, the system brings data from the WMS into the ERP: it retrieves and imports all shipped orders together with the labels and tracking numbers already generated in ShipHero. In that mode the store shows the General Info, Import Info, Ship Via Cross Reference, Warehouse Cross Reference, Inventory Details, Sync Info and Locations tabs.

Set to Acumatica to ShipHero, the flow reverses: orders are created in the ERP and exported to ShipHero, you ship them in the WMS, and the shipments come back into Acumatica. That mode adds tabs the other direction does not need, including Box Mapping, Vendors, Order Types To Export and - once a receipt order type exists - Reason Code Mapping. If a tab you expect is missing, the Integration Option is almost always the reason.

Which import defaults should you set first?

The Import Info tab carries the Default Import Options, which populate automatically once credentials are set. Import ShipHero Orders To specifies the document type that ShipHero orders land in and is a drop-down offering Sales Order or Invoice. Order Type shows the document type the order should be imported into. Import Freight controls whether the order freight comes across at all - clear it and freight is not imported. Last Imported Order Date sets the date boundary for the first order to be imported, which is how you keep a first sync from dragging in years of history.

Two checkboxes on the same tab control mapping: Use Cross Ref for Ship Via and Use Cross Ref for Warehouse. Selecting either makes the corresponding cross-reference tab appear on the store so ShipHero values can be matched to Acumatica values. Tax behaviour sits alongside them - selecting Import Tax brings ShipHero order taxes across and exposes the Customer Tax Zone (the combined effective tax for a zone, defined by the vendor or customer locations), Tax ID (the customer tax ID) and Taxable Category, which is used to create or edit the tax categories applied to products.

How does the connector decide which customer an imported order belongs to?

Customer resolution happens in two places, and knowing the order of precedence saves a lot of confusion. On the General Info tab, the Stores to Get grid has a Customer column that sets an individual default customer per store, plus a Last Import Date showing when the last order was imported and a Selected checkbox that tells the system which stores orders and shipments should be imported from. If the Customer field on that grid is null, the system falls back to the Customer Information setup during order importation.

On the Customer Information tab, selecting Import Customer makes the Biz-Tech Services Acumatica ShipHero integrator create a new customer record from the ShipHero customer data, and exposes a Customer Class field for the default class assigned to those new customers. Leave Import Customer cleared and orders import against the single default customer named in the Customer field instead. Two override checkboxes sit here as well: Override Ship Address Information from ShipHero Order imports the address the order ships to, and Override Bill Address Information from ShipHero Order imports the billing address of whoever pays the order.

What handles packaging?

On the Packaging tab, clearing the Automatic Packaging checkbox reveals a Default Box ID field. Choose the box there, then select Automatic Packaging so that the default package is used with the order. In the Acumatica to ShipHero direction there is also a Box Mapping tab, where users map the Acumatica Box ID value to the ShipHero box name so a package created on one side is recognisable on the other.

Cross-References: Translating Values Between Acumatica and ShipHero

Cross-references are the quiet backbone of the whole data flow. They exist because the same real-world thing - a carrier, a warehouse, a return reason - carries different identifiers in each system, and a record that cannot be translated is a record that stops.

Ship Via Cross-Reference

The Ship Via Cross-Reference tab lets you select the entities that should be set up and matched in ShipHero and Acumatica during the transition. This mapping is what turns a carrier and service returned by the WMS into a Ship Via that Acumatica recognises, and it is also called out as a prerequisite for exporting returns.

Warehouse Cross-Reference

The Warehouse Cross-Reference tab is used by two separate processes: the item sync process and the order import process. Based on this setup, the Biz-Tech Services ShipHero Acumatica integrator imports orders and assigns the mapped warehouse to the sales order screen. The same mapping applies to items - when items sync from ShipHero, the warehouse is created for the item according to this setup. It also constrains the Locations tab, because locations are only loaded for warehouses that have been set up on Warehouse Cross-Reference.

Order Types To Export and Reason Code Mapping

In the Acumatica to ShipHero direction, the Order Types To Export grid defines which Acumatica order types are allowed to leave for the WMS. Each row has an Active checkbox, and only when Active is selected can orders of that type be exported. You can also set up a receipt order type such as RC here. As soon as at least one receipt order type exists, a new Reason Code Mapping tab appears, whose grid contains Active and Is Default checkboxes; when a return order is exported, this grid maps the reason code onto the order lines.

Outbound: How Acumatica Documents Reach the ShipHero WMS

With the store configured, records begin moving. Each outbound document type has its own processing screen, and each has its own admission rule about which records are eligible to appear there.

How do sales orders get exported to ShipHero?

The Export ShipHero Order screen exports Acumatica orders to the WMS, provided the corresponding setup exists in the ShipHero Store. Two conditions decide whether an order is even listed: the order must have an Open status in Acumatica, and its order type must have been set up in the selected store. An order that fails either test does not appear on the screen at all - it does not appear with an error. Pressing Export creates the order in ShipHero.

How do purchase orders reach ShipHero?

The Export Purchase Orders to ShipHero screen exports purchase orders so the warehouse knows what inbound stock to expect. Only purchase orders with an Open status appear on this screen. There is no special store setup required for it. An Export to ShipHero button has also been added and can be added manually, which lets users determine all the purchase orders that should be exported.

How do return orders get exported?

The Export Return Orders To ShipHero screen handles returns going out. If the RC order type is configured in the ShipHero Store under the Order Types to Export tab, RC orders appear on this processing screen and can be exported. Clicking Load Return Orders loads and displays all orders with the RC order type; Export sends a selected order and Export All sends all of them at once. The screen also supports an automatic scheduler, so return exports can run unattended, and the export can equally be performed from the Sales Order actions.

The return round trip has a strict sequence, and the Customer Order Number field is the key that holds it together. First create a Sales Order and set a value in Customer Order Number. Create the shipment for that order in ShipHero and import the shipment back into Acumatica; once the shipment is imported, the order status in Acumatica updates to Completed. Only then create a new order with the RC (Return for Credit) order type, for the same customer, containing the same item or items, and with a Customer Order Number that matches the original sales order. During the return process the system uses the Customer Order Number value to identify and match the correct customer associated with the returned order. After the export, the system generates and displays the ShipHero returned order ID and number. Reason Code and Ship Via mappings must exist between the two systems for return exports to work.

Inbound: How Fulfillment, Tracking and Shipments Come Back to Acumatica

The inbound leg is where the warehouse tells the ERP what actually happened. Each inbound screen follows the same two-button pattern - a Get action that pulls raw records from the WMS onto a staging inquiry, and an Import action that turns them into real Acumatica documents. That separation is useful: it lets users inspect what ShipHero sent before it becomes an accounting document.

How do you import orders created in ShipHero?

The Import ShipHero Orders screen retrieves orders from the WMS. Select the ShipHero Store Code to specify which store orders should be retrieved from. Get Orders pulls the orders across and adds them to the ShipHero Order screen, and Import then creates the Sales Order based on the setup in the store - the document type, freight, tax, customer and warehouse decisions you made on the Import Info, Customer Information and Warehouse Cross-Reference tabs.

How do shipments and tracking numbers come back?

The Import Shipments from ShipHero screen gets and imports all shipments from the WMS. ShipHero orders with an Open status or Sales Order status are displayed here. Notably, both store directions can be shown on the ShipHero Store Code field of this screen - both ShipHero to Acumatica and Acumatica to ShipHero stores - because both flows eventually need shipments back. Get Shipments retrieves the shipments, which are then displayed on the Shipments tab of the ShipHero Order screen, and Import imports the shipment into Acumatica and confirms it.

That confirmation is the point of the whole outbound leg. In the ShipHero to Acumatica direction, the Biz-Tech Services Acumatica ShipHero integration retrieves and imports shipped orders along with the labels and tracking numbers already generated in the WMS, so your business is not rekeying carrier data. The label and package information for each shipment can be found on the Packages tab of the ShipHero Shipment screen.

How do purchase receipts come back?

The Import Receipts from ShipHero screen imports purchase receipts for purchase orders that were previously exported. Get Receipts pulls receipts from the WMS and displays the ones that need to be imported; Import creates the receipt for the purchase order. Whether that receipt is released automatically is governed by the Release PO Receipt During Import Process checkbox on the Sync Info tab of the store: selected, receipts are released automatically on import; cleared, receipts are imported unreleased. If a receipt is imported partially, the last imported receipt is released.

How do bin transfers come back?

The Import Bin Transfers from ShipHero screen imports transfer bins based on the dates selected on the Sync Info tab of the ShipHero Store screen. It imports the transfers and displays them on the Transfers screen, and each line shows which location an inventory ID was transferred from and which location it went to, within the same warehouse. The Release Transfer During Import Process checkbox controls whether those transfers are released automatically on import. One hard prerequisite applies: this screen only works when the Multiple Warehouse Locations checkbox is selected.

How do return receipts come back?

The Import Return Order Receipt from ShipHero processing screen imports all returns from the WMS into Acumatica. After returns are exported and return records exist in ShipHero, you can set the tracking number and generate a return label there. Once the return is ready, it can be retrieved and imported into Acumatica and assigned to the corresponding RC order type. Import handles a selected order and Import All handles them all, an automatic scheduler can be configured for the process, and returns can also be imported directly from the Sales Order actions. When a return is imported, the system creates a return document in Acumatica and adds it to the Shipments tab of the related Sales Order, including the tracking number.

Item, Location and Vendor Sync Between Acumatica and ShipHero

Documents only flow cleanly when the master data underneath them matches. The ShipHero Store carries three sync surfaces - Inventory Details for items, Locations for bins, and Vendors - plus a Sync Info tab that defines what happens when the Biz-Tech Services Acumatica ShipHero integration meets something it has never seen before.

How does item sync work in both directions?

The Inventory Details tab loads and displays both Acumatica and ShipHero items. Load Acumatica Items loads and displays all items in Acumatica, and Sync Acumatica Items exports them to the WMS. Load ShipHero Items loads and displays all items in ShipHero, and Sync ShipHero Items imports them into Acumatica; during that import, if a stock item has a vendor or vendors already synced to ShipHero, the vendor information is synced with the item as well. Purge deletes everything currently displayed on the Inventory Details table, and Select All selects every item, with a second press clearing the selection.

What happens when an item does not exist in Acumatica?

This is what the Import Item checkbox on the Sync Info tab decides, and it is one of the highest-impact settings in the Biz-Tech Services ShipHero Acumatica connector. Selected, the system is allowed to create a new item when it does not exist during the sync and order import processes, and it exposes Imported Item Type, Item Class, UOM and Warehouse ID fields that define the defaults for that new item. Cleared, the system does not create new items at all: when a new item arrives, it sets the default value of Replace Missing Products as the item name and takes the warehouse from the Warehouse ID field, assigning that same default item to every new item it meets.

The same tab controls what values are pushed outward. Export Price Type selects whether the default item price or the MSRP is exported, and Export Price Quantity selects whether the On Hand, Available, or Available for Shipment quantity is sent. That second field deserves thought - exporting On Hand when your business allocates stock heavily will tell the warehouse it has inventory that is already committed elsewhere.

How do warehouse locations sync?

The Locations tab is gated by the Multiple Warehouse Locations checkbox, which becomes selected when the button is activated from the Enable/Disable screen. With it selected, the Sellable Location, Non-Sellable Location, Release Transfer During Import Process and Begin Bin Transfers Date fields become available. Use Location Mapping then decides the granularity: select it and a grid appears for mapping locations one by one; leave it cleared and two locations should be set up instead.

Sellable Location and Non-Sellable Location determine the default values for sellable and non-sellable quantities in Acumatica when a purchase order is exported and a receipt is created in the WMS. There is an important exception to remember: when you create a sales order in Acumatica, export it to ShipHero and import the shipment back, the Sellable location on the lines is always set. The Locations grid itself works like Inventory Details - Load Acumatica Locations loads all Acumatica locations, Sync Acumatica Locations exports them to the WMS, Load ShipHero Locations loads all locations in ShipHero, Purge clears the grid, and Select All toggles the whole selection. Locations are only loaded for warehouses that have been set up on the Warehouse Cross-Reference tab.

How do vendors sync?

The Vendors tab loads and displays both Acumatica and ShipHero vendors and syncs them between the two systems, with Purge to clear the displayed table and Select All to toggle the selection. Before running the Sync Acumatica Vendors action, the Default Vendor Class ID must be selected on the Sync Info tab - that field also drives the Sync ShipHero Vendors button, which generates ShipHero vendors in Acumatica under the chosen class. This vendor information is used by the shipment import process from ShipHero to Acumatica.

Real-Time Flow: ShipHero Webhook Settings

Everything described so far is pull-based - a user or a scheduler presses Get and then Import. The Webhook Settings tab replaces that rhythm with real-time synchronization, so the WMS pushes events into Acumatica as they happen.

How do you set up ShipHero webhooks?

Enabling Use Webhook in the ShipHero Store header makes the Webhook Settings tab available; that tab defines which events are received from ShipHero and how they are processed. On the Webhooks screen, the Webhook Name must be selected and must match the value set as Webhook Type in the Webhook Settings tab of the store - if Webhook Name and Webhook Type do not match, the webhook will not work. Once the URL is generated on the Webhooks screen, set it in the Webhook Settings tab and press Create Webhook, which creates the webhook URL and sends it to ShipHero for POST requests. The same URL can be created for only one webhook and set only once; attempting to reuse it produces an error stating that the URL already exists.

A Branch for Webhooks must also be selected. All incoming webhook data - shipments, PO receipts, transfers and returns - is processed under that branch, and if no branch is selected, webhooks will not work at all.

Which events can ShipHero push into Acumatica?

Shipment webhooks cover the core fulfillment loop: Get Shipment listens for shipment events from ShipHero in real time, and Import Shipment automatically imports the received shipment data into Acumatica and matches the shipment to the corresponding Sales Order. This also supports a WMS-first pattern - a sales order can be created in ShipHero and exported to Acumatica, and once a shipment is created in ShipHero the webhook retrieves and imports it and automatically matches it with the corresponding Sales Order.

Get PO Receipt listens for PO receipt events and Import PO Receipt automatically creates PO receipts and updates received quantities for purchase orders, so receipts are reflected immediately in inventory. Get Return Receipt listens for return receipt events so returned items captured in the WMS can be processed according to your return workflows. Get Transfer listens to inventory transfer events and Import Transfer automatically imports them, updating stock movement between warehouses and locations in real time.

What do the webhook grid fields mean?

Each row in the webhook grid at the bottom of the tab is one webhook registration. Webhook Type defines the event type, such as Inventory Change, Shipment or PO Receipt. Webhook URL is the URL generated and registered for that webhook. Registered indicates the webhook was successfully registered with ShipHero, and Enabled indicates it is active and processing events. Create Webhook registers the webhook and sends its URL to ShipHero for POST requests, Enable Webhook activates the selected webhook and starts real-time synchronization, and Disable Webhook deactivates it and stops incoming events while the configuration remains saved.

Where to Monitor ShipHero Results in Acumatica

When users ask what happened to an order, these are the exact screens, tabs and fields to check, roughly in the order you would walk the flow:

• ShipHero Store, General Info tab - Test Credentials confirms the API connection, and the Last Import Date column in the Stores to Get grid shows when the last order was imported for each store.
• ShipHero Store, Import Info tab - Last Imported Order Date shows the date boundary the Biz-Tech Services ShipHero Acumatica connector is working from, which explains most cases of "older orders never arrived".
• Export ShipHero Order screen - if an Acumatica order is missing here, its status is not Open or its order type is not set up in the selected store.
• ShipHero Order screen - the header shows the order ID, Store Code, the order status in Acumatica and the ShipHero order number, plus the order status in ShipHero, the financial part of the order, the ship via and customer addresses.
• ShipHero Order, Details tab - the products that were ordered, as ShipHero has them.
• ShipHero Order, Addresses tab - the customer addresses that came across, which is where you verify the Override Ship Address and Override Bill Address behaviour.
• ShipHero Order, Shipments tab - the shipment ID for the order, rendered as a hyperlink that takes you straight to the ShipHero Shipment screen.
• ShipHero Shipment screen - the shipment detail, with the Packages tab holding the label and package information, and the Processed checkbox, which is selected automatically when the shipment is processed from the processing screens.
• ShipHero Item inquiry - the Warehouse Details tab shows item availability, the Vendors tab shows the vendor the item is connected to in ShipHero, and the Bin Transfers tab shows transfers for the item. Update Item displays all changes made to the ShipHero item, Sync ShipHero Item syncs the item into Acumatica, and Update Warehouse In ShipHero syncs and updates the item quantity in the WMS.
• ShipHero Purchase Order inquiry - synced purchase order data from Acumatica to ShipHero, where Update Order brings back to Acumatica all changes made to the synced purchase order in the WMS.
• ShipHero Vendor inquiry - ShipHero vendor information, useful when the shipment import process is not resolving a vendor.
• Transfers screen in Acumatica - bin transfers imported from ShipHero appear here, with the from and to locations on each line.
• Shipments tab of the related Sales Order - after a return is imported, the return document is added here including the tracking number, and after a shipment is imported the sales order status moves to Completed.
• Webhook Settings tab grid - the Registered and Enabled columns tell you whether a webhook is actually live, which is the first thing to check when real-time events stop arriving.

ShipHero Acumatica Integration: Frequently Asked Questions

Which direction does the ShipHero Connector move data?

Both, and the Biz-Tech Services ShipHero Acumatica Integration Option field on the ShipHero Store decides which one a given store handles. ShipHero to Acumatica retrieves and imports shipped orders with the labels and tracking numbers already generated in the WMS. Acumatica to ShipHero lets you create orders in Acumatica, export them, ship them in ShipHero and bring the shipments back. Your business can configure separate stores for each direction, and the Import Shipments from ShipHero screen shows both types.

Why did an order not reach ShipHero?

Start with the Export ShipHero Order screen. Only Acumatica orders with an Open status appear there, and the order type must have been set up in the selected ShipHero Store under Order Types To Export with the Active checkbox selected. If either condition fails, the order is simply not listed rather than flagged, so check status and order type setup before looking anywhere else. For returns specifically, the RC order type must be configured under Order Types to Export or RC orders will not appear on the Export Return Orders To ShipHero screen.

Why is tracking not coming back from ShipHero?

Tracking numbers arrive with the shipment, so the question is really why the shipment has not been imported. Check that Get Shipments was run on the Import Shipments from ShipHero screen and that the shipment is listed on the Shipments tab of the ShipHero Order screen, then that Import was run - it is the Import action that brings the shipment into Acumatica and confirms it. If you are relying on webhooks instead, confirm that the shipment webhook shows Registered and Enabled, that the Branch for Webhooks is selected, and that Webhook Name on the Webhooks screen matches Webhook Type in the Webhook Settings tab.

Why are my webhooks not working?

There are three documented causes. The Webhook Name selected on the Webhooks screen must match the Webhook Type value in the Webhook Settings tab of the ShipHero Store, or the webhook will not work. A Branch for Webhooks must be selected, because all incoming shipment, PO receipt, transfer and return data is processed under that branch. And the same URL can only be created for one webhook and set once - reusing it raises an error stating the URL already exists.

Why is the Import Bin Transfers screen not returning anything?

The Import Bin Transfers from ShipHero screen only works when the Multiple Warehouse Locations checkbox is selected. That checkbox becomes selected when the button is activated from the Enable/Disable screen. Also check the Begin Bin Transfers Date on the Locations tab and the dates on the Sync Info tab, because the screen imports transfers based on the dates selected there.

Why did an imported order come in with the wrong item?

That is the Import Item checkbox on the Sync Info tab. When it is cleared, the Biz-Tech Services Acumatica ShipHero connector does not create new items in Acumatica; instead it sets the default value of Replace Missing Products as the item name and takes the warehouse from the Warehouse ID field, assigning that default to every unrecognised item. If your business wants real items created automatically, select Import Item and set the Imported Item Type, Item Class, UOM and Warehouse ID defaults that appear.

Do purchase receipts and transfers release automatically?

Only if you tell them to. Release PO Receipt During Import Process on the Sync Info tab releases receipts automatically on import; when it is cleared, receipts are imported as not released, and if a receipt is imported partially, the last imported receipt is released. Release Transfer During Import Process does the same for transfers imported from ShipHero.

How does the connector match a return to the original order?

Through the Customer Order Number field. The original Sales Order must carry a value in Customer Order Number, and the RC (Return for Credit) order must be created for the same customer, contain the same items, and use the same Customer Order Number. The system uses that value during the return process to identify and match the correct customer associated with the returned order. Reason Code and Ship Via mappings must also exist between Acumatica and ShipHero values for return exports to work.

Work With the Biz-Tech Services ShipHero Connector

The ShipHero data flow is a loop, not a one-way feed. Documents leave Acumatica through the export screens, the WMS does the physical work and generates labels, tracking numbers, receipts and transfers, and the import screens - or the webhooks, if you run in real time - bring that reality back so sales orders, purchase orders and returns close out correctly. The ShipHero Store is where every one of those hops is authorised, from the Integration Option that sets direction, through the cross-references that translate carriers, warehouses, boxes and reason codes, to the Sync Info defaults that decide what happens when the two systems disagree. Get the store right and the monitoring screens become a formality; get it wrong and records quietly stop appearing on the processing screens.

If your business is running Acumatica alongside a ShipHero warehouse and wants the round trip configured properly the first time, the Biz-Tech Services ShipHero Connector team can help scope the store setup, the cross-references and the webhook configuration around how you actually fulfill. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary

How Magento Data Flows into Acumatica ERP

How Magento Data Flows into Acumatica ERP

Magento data flows into Acumatica ERP through a connector that retrieves orders from your Magento store, imports the selected orders as Acumatica documents, and then generates fulfillment events back in Magento once the resulting shipments are confirmed. Everything else the Biz-Tech Services Magento Acumatica integration does, customer creation, payment handling, tax defaults, item creation, inventory quantity updates, and refund processing, hangs off that same inbound-then-outbound path. Understanding the order in which records move is the fastest way to know which setting to change when something does not arrive where you expect it.

The product described here is the Biz-Tech Services Magento Connector for Acumatica ERP, built by Biz-Tech Services, Inc. It links Magento, the e-commerce platform, with Acumatica, the enterprise resource planning system, using connection settings entered in Acumatica and an Application Programming Interface, or API, connection to your store. This article walks the data flow in the order records actually travel: setup and credentials first, then inbound orders, then the customer, payment and tax decisions made during import, then outbound fulfillment, then item and inventory synchronization, and finally where errors surface and what a user checks to confirm the result.

What the Magento Connector for Acumatica Does

The Biz-Tech Services Acumatica Magento Connector is an Acumatica ERP customization that connects a Magento e-commerce store to the back office so that the two systems share orders, customers, and item data. The Biz-Tech Services Acumatica Magento integration requires connection settings on the Magento Store screen. Based on those settings, the Biz-Tech Services Magento Acumatica connector reaches the corresponding store and retrieves orders, and imports the selected orders into Acumatica ERP. When a user confirms the shipments created from those imported orders, fulfillment events are generated in the store for each corresponding order. The Biz-Tech Services Acumatica Magento Integrator also requires default options and the required values for the order import process, which is why the configuration screens matter as much as the processing screens.

The Biz-Tech Services Acumatica Magento integrator is delivered as an Acumatica customization project and is installed from the Customization Projects form, screen ID SM204505. That form is where you add the project, validate it, and publish it for a tenant, and it is also where the publication can later be cancelled or the project exported as a deployment package. The Biz-Tech Services Magento Acumatica integrator must be installed on an Acumatica system carrying one of the following licenses: PCSR, PERP, or SAAS.

The Magento Data Flow at a Glance

Before looking at individual fields, here is the whole path a record travels between the two systems:

• Credentials are entered and tested on the Magento Credentials screen, where Store Code, Description, Default Store, Username, Password, and Base URL define the connection, and Test Credentials confirms that Acumatica can reach the store through the API.
• The Magento Store screen holds the configuration that determines the overall functionality of the Biz-Tech Services Acumatica Magento integrator: order import, item import and creation, payment processing, customer management, shipping options, and warehouse settings.
• Get Orders on the Import Magento Orders screen retrieves the orders, and the processing grid lists only those that hold a qualifying status in the store.
• Import or Import All creates the Acumatica document defined by Import Magento Orders To and Order Type, applying the customer, payment, tax, discount, item, and warehouse defaults configured on the store screen.
• The Magento Orders screen records the imported order and links it forward through the Sales Order Number and Invoice Number fields, so a user can trace an order into the Acumatica document chain.
• Fulfillment runs in Acumatica, and confirming the shipment generates the fulfillment event in Magento, with the Prepare Invoice and Release Invoice steps governed by their own skip and quantity-check settings.
• Outbound item processes push items, product images, inventory quantities, multi-prices, categories, and publication status from Acumatica to Magento, while the matching import processes pull items and multi-prices back the other way.
• Refunded orders are retrieved separately on the Import Magento Refunded Orders screen and processed into Customer Refund payments or credit memos depending on how far the original order has progressed.

Each setting discussed below sits at one of those handoffs, which is why a change on the Magento Store screen can alter the outcome of a process run several screens later.

Stage One: Magento Credentials and the Connection to Your Store

Setup begins on the Magento Credentials screen, which is where users set up the credentials that connect the two platforms and make the Biz-Tech Services Magento Acumatica integration between them possible. Store Code functions as a lookup field that identifies the corresponding store, and Description is used to provide a description of that store. Because the connector supports more than one store record, the Store Code is the value that every downstream processing screen uses to decide which store it is talking to.

Selecting the Default Store checkbox marks the store as the default store. This matters more than it looks: on processing screens where a Store Code has to be chosen before anything is retrieved, a default store removes a repeated selection step and reduces the chance of running a process against the wrong store.

What the Connection Settings tab controls

Username, Password, and Base URL are the Magento system credentials used to configure the connection settings. The information specified on the Connection Settings tab is used to test the ability of the system to connect to the store through the API. Test Credentials tests that connection using the credentials from the Connection Settings tab, so it is the correct first check whenever nothing is being retrieved at all. Edit Credentials allows editing of the store credentials, and Redirect to Store Settings opens the Magento Store screen, which is the natural next step once the connection is proven.

Stage Two: The Magento Store Screen Governs the Whole Flow

The configuration defined on the Magento Store screen determines the overall functionality of the Biz-Tech Services Acumatica Magento Connector. It controls the order import process, item import and creation, payment processing, customer management, shipping options, warehouse settings, and other related operations. Users who treat this screen as a one-time setup task tend to misdiagnose later problems, because most unexpected import results trace back to a checkbox or default value here rather than to the processing screen where the problem was noticed.

Default Import Options: what is retrieved and from when

Get Magento selects which Magento entities to retrieve into the Acumatica system. Import Magento Orders To specifies where the orders are imported in Acumatica, and Order Type is the default type of orders to be created by the Biz-Tech Services Acumatica Magento integration. Together those two fields decide what kind of Acumatica document an order turns into, so they should be settled before the first production import rather than after.

Begin Order Date allows the data retrieval to be filtered, which is how your business avoids pulling the entire order history of the store on the first run. Two read-only companions record what has already happened: Last Imported Order Date is the date when the last order was imported, and Last Refunded Order Date is the date when the last refunded order was imported. Get Refunded Data when Receiving Orders retrieves refunded orders during the Get Order process, so refunds can be collected in the same pass rather than as a separate exercise.

Error notifications during order import

Send Email Notifications for Errors informs the user about any errors encountered during the process. An email notification feature exists for failed orders during the order import process, which ensures that users are promptly alerted if an order import encounters issues or failures. Notifications go to the email address added on the order settings tab. They are sent during batch imports and during process updates for the same order, because the system checks all orders again for the selected period during that process. For a store that imports on a schedule, this notification is the practical difference between finding a failed order the same day and finding it at month end.

Inbound: How Magento Orders Become Acumatica Documents

The Import Magento Orders screen allows users to retrieve and import all orders from the store into Acumatica. It is the main inbound entry point, and it is deliberately a two-step screen: retrieval and import are separate actions, so nothing is created in Acumatica simply because it was fetched.

Retrieving orders with Get Orders

The Get Orders button retrieves orders from Magento. After the button is clicked, a timer indicates the elapsed time until the process is complete, and a user can cancel the process of getting orders by clicking the loading icon next to the timer. The processing page shows only orders that hold the statuses Partially Shipped, on hold, Pending, and Processing in the Magento shop. That status filter is the single most common reason an order that exists in Magento never appears in the Acumatica grid.

The Import button enables the import of selected orders into Acumatica. Alternatively, the Import All button imports all orders displayed on the grid. Selective import is worth using during the first weeks of a go-live, because it lets your business validate the resulting documents order by order before switching to bulk runs.

Reading the Magento Orders screen

When orders are retrieved and displayed on the Import Magento Orders screen, each order carries a hyperlink, and clicking the order number navigates to the corresponding Magento Orders screen. That screen presents the initial status of the order and is the record your business returns to when tracing what happened to a given order.

The screen consists of several tabs. Document Details provides information about the items of the order. Addresses provides details about the customer address. Refund Info becomes visible only if the order has been refunded, displaying the relevant refund information. CC Payment provides information about the credit card payment method.

The header fields are where results are read. Order Number displays the Magento order ID. The Magento order status reflects the initial state of the order upon import. Status displays the Magento order status inside Acumatica. Payment Method displays the payment method used for the order, and Ship Via indicates the shipping method used. Sales Order Number displays the sales order number of the order once it is imported, and Invoice Number displays the invoice number once the order is invoiced. Those two fields are the link between the e-commerce record and the Acumatica document chain.

The amount fields complete the picture: Total Lines Amount displays the total sum of item lines, Discount Total displays the discount total for the order, Shipping Total displays the total amount of shipping, Total Tax displays the tax total, and Total shows the order total including taxes and other charges.

The three actions on the Magento Orders screen

Refresh Order updates the Magento order status in Acumatica. This matters because the status stored at import time is the initial state; if the order is later fulfilled in Magento, opening the actions menu and clicking Refresh Order updates the status of the order to match the store. Receive Orders enables the retrieval of individual orders into Acumatica by choosing the store code and setting the order ID, which is the targeted alternative to a full Get Orders run. Import Order, when selected on the corresponding Magento Orders screen, displays a confirmation popup asking whether you want to create a sales order for that order in Acumatica.

Customers, Payments, Taxes, and Discounts During Magento Order Import

The decisions the Biz-Tech Services Acumatica Magento integrator makes while an order is being imported are all configured on the Magento Store screen. These are the settings that determine whether a customer record is created, whether a payment document is produced, which tax defaults are applied, and how discounts land on the resulting Acumatica document.

Customer Information options

Import Customer means the Biz-Tech Services Magento Acumatica integration imports the customer information from Magento into a new customer record in Acumatica. Customer Class is the default customer class set on new customers that do not exist in Acumatica and are created by the Biz-Tech Services Acumatica Magento integration, so it is the field that decides which account and terms defaults a new web customer inherits.

Override Ship Address Information imports the address information of the location the order is going to be shipped to from Magento, and Override Bill Address Information imports the address information of the party who will pay the bill of the order from the store. Notify Customer for Shipment Confirmation means the Biz-Tech Services Magento Acumatica integrator notifies the customer when the order is shipped, if the checkbox is selected. Use Default Group ID allows a default group ID to be selected for the customer sync process, and Default Password for Customers allows a default password to be selected for the new customers being created in Magento.

Payment Options

Skip Magento Payment, when selected, means the order is imported from Magento without payment. That is the right choice when payment capture is handled entirely outside Acumatica. Payment Method is the payment method set on the payment during the order import process, and Payment Type is the type of payment that determines the payment type of the imported order. Release Payment during Order Import releases the payment during the Magento order import process, which removes a manual step but also commits the payment document immediately, so it should be enabled only once the mapping is proven.

Use Credit Card Payment, when selected, displays the CC Payment Mapping tab on the Magento Store screen, allowing the user to configure the corresponding mapping for the credit card payment method used for the order imported into Acumatica. The result of that mapping is what a user later reads on the CC Payment tab of the Magento Orders screen.

Tax Options

Tax ID is the default tax ID set on the orders. Customer Tax Zone is the combined tax of the effective taxes for a particular zone, defined according to the locations of the vendors or customers. Taxable Category is used to create tax categories, or edit existing tax categories, that are applied to products. Is Freight Included In Magento indicates that freight is being taxed in Magento, which is the setting that keeps the two systems from disagreeing about the tax on shipping.

Discount Option

Calculate Discount On Order Lines determines where discounts appear on the resulting document. When it is selected, the system calculates discounts per line, populating the Discount Amount and Discount Code fields in the Sales Orders Document Details table. Alternatively, the system calculates discounts for the entire order and provides the details in the Discount section. The choice affects reporting as much as data entry, because line-level discount data is what makes margin analysis by item possible.

Outbound: Fulfillment Events Sent Back to Magento

Once a Magento order has become an Acumatica document, fulfillment proceeds in Acumatica and the Biz-Tech Services Magento Acumatica integration reports the result back. When a user confirms the shipments created from the imported orders, fulfillment events are generated in the store for each corresponding order. If Notify Customer for Shipment Confirmation is selected on the Magento Store screen, the Biz-Tech Services Acumatica Magento Integration notifies the customer when the order is shipped.

Two Export Default Options on the Magento Store screen control what leaves Acumatica during invoicing. Skip Magento Shipment while Prepare Invoice means the Biz-Tech Services Acumatica Magento connector does not send a shipment creation request to Magento during the Prepare Invoice process in Acumatica. Skip API Request While Release Invoice means the Biz-Tech Services Magento Acumatica integrator sends no API request at all during the invoice release process. Both are useful when a business deliberately handles shipment records on the store side, and both are worth checking first when an expected update never reaches the store.

Two related item settings guard stock at the same points in the flow. Check Magento Qty While Prepare Invoice validates the product quantities in the store during the invoice preparation process, confirming that the required stock is available before the invoice is created. Check Magento Qty While Release Invoice validates the same quantities during the invoice release process to ensure sufficient stock is available. These checks put the quantity validation at the moment the financial document is created rather than after the fact.

Refunds: How Magento Refunded Orders Are Processed in Acumatica

Import Magento Refunded Orders allows users to import refunded orders from the store into Acumatica. The Get Orders button loads the refunded orders onto the screen, after which they can be imported. The system then manages the refunded order import based on how far the original order has already progressed in Acumatica, which is why the same Process button produces different documents in different situations.

• Case 1, when the refunded order is a sales order in Acumatica that has not progressed with any fulfillments and consists of a single item: pressing Process generates a payment with a Customer Refund type, attaches it to the Payments tab, sets the refunded amount, and closes the order. The sales order status changes to Canceled and all lines are deleted.
• Case 1, when the order consists of several items and is refunded: the refunded quantity is reduced from the order quantity, and the system creates a payment document and attaches it on the Payments tab for the refunded items, while the order status remains Open.
• Case 2, when an order shipment has been created but not confirmed: clicking Process triggers the system to find the created shipment, delete it, and then proceed with the actions of Case 1.
• Case 3, when an order shipment has been confirmed: clicking Process results in the system creating a credit memo and attaching a reference number with Customer Refund type to the Applications.
• Case 4, when the invoice is prepared but not released: the system creates a credit memo and attaches a reference number with Customer Refund type to Applications after the refunded order is processed.
• Case 5, when the invoice is released: the system reverses the invoice and generates a credit memo with a Customer Refund type in the reference number attached to Applications.

After those actions, the Processed checkbox on the Refunds tab is automatically checked on the Magento Orders screen for the corresponding order, which means the process is over and the order is Closed. To verify the financial side, follow the Reference number to view the Customer Refund type payment and the refunded amount on the Application History tab.

Customer Export: Sending Acumatica Customers to Magento

The customer export process can be run from the Customers screen as well as from the Export Magento Customer processing screen. On the Customers screen, the Sync Magento Customer button in the Actions command toolbar performs the customer export. Selecting that action from the Actions command menu is what sends the customer to the store.

The Biz-Tech Services Acumatica Magento connector syncs a customer only if three conditions are met, and each one is a common cause of a customer that silently fails to appear in the store. First, the Customer Price Class, which corresponds to Magento customer groups, must exist in both systems. Second, the customer must have a contact. Third, that contact must have a First Name, a Last Name, an Email, and a Magento Customer Password, and the password must be a mixture of letters, numbers, and special characters.

After the customer export process completes, the Magento Customer checkbox becomes checked on the Customers screen and the Magento Customer ID is added under the Magento Customers tab of the Customers screen. Those two indicators are the confirmation a user should look for rather than assuming the export worked. Customer groups themselves are handled on the Customer Groups tab of the Magento Store screen, where customer groups are synced to the Acumatica Customer Price Class.

Item and Inventory Synchronization Between Acumatica and Magento

Item data moves in both directions, and the Magento Store screen carries the settings that decide what is created, what is matched, and which quantity number is sent.

Item Information settings that govern item creation

If the Import Item checkbox is selected, new items are created in Acumatica during the synchronization of orders from Magento, based on the configured settings. If the checkbox is not selected, the program prohibits the import and creation of items unless the corresponding items have already been created in Acumatica. The system searches for the Inventory CD using the Magento Product SKU. If it is found, the system retrieves that item; if it is not found, an error message is displayed stating that the item does not exist in the system.

Import Item Type specifies the item type that should be created, and Item Class selects the item class for imported items, which groups stock or non-stock items with similar properties and provides default settings for new items. Warehouse ID is the default warehouse set on the orders imported from Magento, and UOM, the unit of measure, is used to quantify the inventory items. Replace Missing Products replaces Magento items that do not exist in Acumatica with a selected item during the order import process, if the Import Item checkbox is disabled, which keeps an order importable rather than blocking it on one unrecognized SKU.

Several further options tune the item side of the flow. Use Bulk Sync Items Functionality syncs one hundred items at once, but only if the RabbitMQ module is set up in the Magento system. Import Items on Inventory Details Tab retrieves items to the Inventory Details tab of the Magento Store screen while orders are being imported. Import Product Images allows images to be synced during synchronization if the item has one attached. Date Last Received Item indicates the last date used for retrieving products, which is the item-side equivalent of the order date trackers.

The Inventory Details tab

On the Inventory Details tab of the Magento Store screen, a user can load the items held in both systems and then sync, publish, or unpublish them in the store. Load Acumatica Items retrieves all Acumatica stock and non-stock items and displays them in the table, and the Load Magento Items button retrieves the store catalog the same way. Sync to Magento exports Acumatica items outward, and Sync from Magento brings items back into the Acumatica system.

The supporting buttons make bulk work practical. Check All selects all the items displayed in the table, and clicking it a second time unchecks them. Get Item retrieves a specified item by item SKU or name. Purge deletes all the items displayed in the table. Publish Items in Magento enables the publication of selected items in the store, setting their status to Enabled, and Unpublish Items in Magento removes the Enabled status from the selected items, making them unavailable for purchase. The item details list can be exported and imported as an Excel document.

When items are synced from Acumatica to Magento, a new item is created there and a unique ID for the item is generated. That unique ID is displayed in the Acumatica Magento store record and on the Magento Inventory tab of the stock item. The processes of item synchronization, item publishing, and item unpublishing can also be carried out on the Stock Items and Non-Stock Items screens, so a user working on a single item does not have to return to the store screen.

Warehouse Details and which quantity is sent

The Warehouse Details tab is where the warehouses whose quantities need to be in sync with Magento are added. If one or more warehouses are selected there, the exported item quantity displays the sum of quantities across the selected warehouses. The quantity that is synced from Acumatica to Magento depends on the selected drop-down value: On hand, Available, or Available for Shipment. That choice is worth deliberating over, because it decides whether your store advertises physical stock or committed-adjusted stock.

The outbound item processing screens

Export Magento Inventory Quantities is the screen for syncing Acumatica inventory quantities to Magento. Beforehand, the required items must be chosen on the Inventory Details tab of the Magento Store screen by checking the checkboxes and pressing Save, and the Magento Product SKU and Acumatica Inventory ID fields must also be set on that tab. Only after those actions do items appear on the Export Magento Inventory Quantities processing screen. To sync a quantity, enter the corresponding quantity in the Magento Quantity field for the item, check the checkbox, and click Sync; the item quantity in the store is updated based on that value. Sync All syncs the quantities of all items displayed on the screen.

Export Magento Items allows the export of Acumatica items outward. Items appear on that screen if the Magento Product SKU is set on the item tab of the Magento Store screen. Select the items and export them by pressing Sync or Sync All. After the synchronization process, the Price, Description, Weight, Length, Height, Width, and Category of the item are updated in the Magento shop. If the Biz-Tech Services Magento Acumatica connector does not find some items in the store during synchronization, it creates them automatically. Once the item has been synced, the Magento Item checkbox is checked and the Magento Product ID is added under the Magento Inventory tab of the Items screen.

Export Magento Product Images handles images: if an item has an attached image, the system exports it to the store from this screen. Select the corresponding items and export them by pressing Sync or Sync All.

Multi-price export and import

Item prices can differ based on clients, expiration date, and other factors, and the Export Item Multi-Prices screen exports item multi-prices from Acumatica to Magento. Items appear on that screen only if three conditions are met: the items must be selected and saved on the Magento Store screen, the items must have the Magento Product SKU field set on the Inventory Details tab of that same screen, and they must be added on the Sales Prices screen with their corresponding sales prices. Select the Store Code, check the items whose prices should be exported, and click Export or Export All. After synchronization, the sales price of the item is updated in the Magento store as its sales price.

Import Item Multi-Prices moves the same data the other way, importing item multi-prices from Magento to Acumatica. The same conditions must be met for the required items to appear on the screen. Select the Store Code, check the items whose prices should be imported, and click Import or Import All.

Importing Magento items into Acumatica

The Import Magento Items screen allows you to import Magento items along with their corresponding price, weight, and image into Acumatica. Run the Get Items process, after which the items are displayed on the screen, then select the corresponding items and click Import or Import All to import them into Acumatica. This is the catalog-first path for businesses whose product data is maintained in Magento rather than in the ERP.

Mapping: Cross-References, Attributes, and Categories

Mapping is what keeps the two systems agreeing on the meaning of a value, and it is configured on the Magento Store screen. Cross-Reference options select the entities that should be matched in Magento and Acumatica during the transition. The entities checked in Cross-Reference Options then appear in the drop-down field on the Cross-Reference tab, where Field selects the entity whose values should be matched and the Magento Value and Ship Via columns specify the values that correspond to each other. Separately, the Export Fields to Magento tab is where a user chooses which fields should be updated in the store during the item sync process.

The Inventory Mappings tab organizes the mapping that makes the sync of Acumatica attributes and user defined fields to Magento attributes possible. On that tab you add the properties of the particular attribute that you should choose on the Attributes tab of the Item Class screen. If the Magento property attribute does not exist in the shop, the sync process is not possible, so the store side has to be prepared first.

The Attribute Details tab loads the active options of a particular attribute. Retrieving them requires that the attribute properties have been added on the Inventory Mappings tab. Once the mappings are configured correctly, the active options for the attribute can be retrieved on the Attribute Details tab by pressing the Load Active Attribute Options button. The active options cannot be retrieved if the Acumatica attribute control type and the Magento attribute control type do not match, which is the first thing to check when the button returns nothing.

The Category Details tab exports and imports product categories. To retrieve product categories from Magento, click Get Magento Categories, or create a new category in Acumatica, choose it, and save; then press Sync Magento Categories to generate the new category in the store as well. The product categories list can be exported and imported as an Excel document. Attribute Sets is where a user gets Magento attribute sets.

Where to Monitor Magento Results in Acumatica

The Biz-Tech Services Acumatica Magento connector writes its results into specific fields, checkboxes, and tabs rather than into a single log, so knowing where to look is part of running it. These are the places a user checks to see what actually happened:

• The Import Magento Orders grid after Get Orders, including the timer that indicates elapsed time until the retrieval process is complete.
• The Status field on the Magento Orders screen, which displays the Magento order status in Acumatica, refreshed with the Refresh Order action when the order has since been fulfilled in the store.
• The Sales Order Number field on the Magento Orders screen, which displays the sales order number of the order once it is imported.
• The Invoice Number field on the same screen, which displays the invoice number once the order is invoiced.
• The amount fields on the Magento Orders screen: Total Lines Amount, Discount Total, Shipping Total, Total Tax, and Total.
• The Document Details tab for the items of the order, the Addresses tab for the customer address, and the CC Payment tab for the credit card payment method.
• The Refund Info tab, which becomes visible only if the order has been refunded, and the Processed checkbox on the Refunds tab, which is checked automatically once refund processing is complete and the order is Closed.
• The Payments tab of the sales order for the Customer Refund payment, and the Application History tab reached through the Reference number to confirm the refunded amount.
• The Magento Customer checkbox on the Customers screen and the Magento Customer ID under the Magento Customers tab, which together confirm a successful customer export.
• The Magento Item checkbox and the Magento Product ID under the Magento Inventory tab of the Items screen, plus the unique ID shown on that same tab of the stock item after a sync to Magento.
• The Last Imported Order Date, Last Refunded Order Date, and Date Last Received Item fields on the Magento Store screen, which show how far each retrieval process has progressed.
• The error email sent to the address on the order settings tab when Send Email Notifications for Errors is selected, which reports failed orders during batch imports and process updates.

Magento Acumatica Integration: Frequently Asked Questions

How do I connect Magento to Acumatica?

Connection settings are entered on the Magento Credentials screen, where you supply the Store Code, Description, Username, Password, and Base URL, and optionally mark the record as the Default Store. The information on the Connection Settings tab is used to test whether the system can connect to the store through the API, and the Test Credentials button runs that test. Once the credentials are valid, Redirect to Store Settings opens the Magento Store screen, where the rest of the configuration is defined.

Why is a Magento order not appearing on the Import Magento Orders screen?

The processing page shows only orders that hold the statuses Partially Shipped, on hold, Pending, and Processing in the Magento shop, so an order in any other status will not be listed. The Begin Order Date field on the Magento Store screen also filters data retrieval, which means orders older than that date are excluded. If nothing at all is retrieved, run Test Credentials on the Magento Credentials screen to confirm that Acumatica can still reach the store through the API. For a single known order, the Receive Orders action on the Magento Orders screen retrieves it directly by store code and order ID.

Why was a customer not created in Magento during the export?

The Biz-Tech Services Magento Acumatica connector syncs a customer only when three conditions are met. The Customer Price Class, which corresponds to customer groups, must exist in both systems; the customer must have a contact; and that contact must have a First Name, a Last Name, an Email, and a Magento Customer Password made up of a mixture of letters, numbers, and special characters. If the export appeared to run but nothing arrived, check whether the Magento Customer checkbox was set and whether a Magento Customer ID appears under the Magento Customers tab of the Customers screen.

Why does an order import fail saying the item does not exist in the system?

During order import the system searches for the Inventory CD using the Magento Product SKU. If the SKU is not found and the Import Item checkbox is not selected, the program prohibits the import and creation of the item and displays that error, because it will only use items that already exist in Acumatica. Selecting Import Item lets new items be created during order synchronization based on the configured settings, and Replace Missing Products offers the alternative of substituting a selected item for Magento items that do not exist in Acumatica while Import Item remains disabled.

Can I import Magento orders without payment information?

Yes. Selecting Skip Magento Payment on the Magento Store screen means the order is imported without payment. When payment is imported, Payment Method sets the payment method used during the Magento order import process and Payment Type determines the payment type of the imported order, while Release Payment during Order Import releases the payment as part of the import. Use Credit Card Payment adds the CC Payment Mapping tab so that credit card methods can be mapped explicitly.

What happens in Acumatica when a Magento order is refunded?

Refunded orders are loaded on the Import Magento Refunded Orders screen with Get Orders and then handled by the Process button, and the outcome depends on the stage of the original order. An unfulfilled single-item order produces a Customer Refund payment, the order closes, and the sales order status changes to Canceled with its lines deleted. A multi-item refund reduces the refunded quantity and attaches a payment while the order remains Open. Once a shipment has been confirmed, or an invoice prepared or released, the system produces a credit memo instead, reversing the invoice first in the released case.

How do I publish or unpublish Magento items from Acumatica?

Use the Inventory Details tab of the Magento Store screen. Publish Items in Magento enables the publication of the selected items in the store and sets their status to Enabled, while Unpublish Items in Magento removes the Enabled status and makes those items unavailable for purchase. The same item synchronization, publishing, and unpublishing processes can also be carried out from the Stock Items and Non-Stock Items screens.

Which Acumatica license does the Magento Connector require?

The Biz-Tech Services Acumatica Magento Connector must be installed on an Acumatica system with one of the following licenses: PCSR, PERP, or SAAS. Installation itself is performed on the Customization Projects form, screen ID SM204505, which is used to add the customization project, validate it, and publish it for one or more tenants.

Work With the Biz-Tech Services Magento Connector

The Magento data flow into Acumatica ERP is a single path with configurable branches. Credentials on the Magento Credentials screen open the connection; the Magento Store screen sets the defaults that govern order import, customer creation, payments, taxes, discounts, items, and warehouses; Get Orders and Import move the orders in; fulfillment in Acumatica sends events back out; the item, image, quantity, and multi-price processes keep the catalog aligned in both directions; and refunds are reconciled according to how far the original order had already travelled. Once your business knows which screen owns which decision, tracing any individual record through Acumatica becomes a short exercise rather than an investigation.

If your business runs a Magento store alongside Acumatica ERP and wants order, customer, and inventory data to move between them without manual re-entry, the Biz-Tech Services Magento Acumatica Connector is built for exactly that. Visit https://biz-techservices.com to learn more about our Acumatica expertise or to schedule a personalized demonstration.

---

by Gary