Estimated reading time: approximately 58 minutes.

Available-to-Promise in Acumatica 2026 R2 helps a distributor answer a practical question during sales-order entry: when can the full open quantity of this stock item be covered and shipped from the selected warehouse? The calculation looks beyond current on-hand inventory. It processes configured supply and demand in date order, applies the order type's ATP horizon and safety-stock policy, and returns an ATP date for an eligible line. It can also calculate the date on which the entire order can ship in full.

That answer is useful only when the inputs reflect the company's fulfillment policy. An ATP date is not a guarantee from a supplier, a warehouse reservation, or a substitute for allocation and shipment processing. It is a calculated commitment signal based on the documents, dates, warehouses, item classes, order types, and quantities that the configuration tells Acumatica to consider. A sound rollout therefore combines setup, data review, worked scenarios, reconciliation, user guidance, and post-launch monitoring.

This guide explains the 2026 R2 feature, the distinction between ATP and familiar inventory quantities, the configuration sequence, sales-order behavior, a detailed example, testing, governance, integrations, and common failure patterns. Product behavior and field names are based on the Acumatica 2026 R2 form reference and release materials available on 21 October 2026. Validate the process in the organization's exact build before using ATP dates in customer commitments.

Table of Contents

1. What Available-to-Promise means in Acumatica 2026 R2
2. Why distributors need a date-based promise
3. ATP compared with on hand available and available for shipping
4. ATP compared with capable to promise and inventory planning
5. The four configuration layers behind an ATP date
6. Enable the Available-to-Promise feature deliberately
7. Create ATP calculation rules that match fulfillment policy
8. Assign ATP rules through item classes
9. Configure order types for cumulative look-ahead
10. Choose an ATP horizon that covers relevant supply
11. Decide whether ATP should protect safety stock
12. Understand the dates used on a sales order
13. How the cumulative look-ahead calculation works
14. How line-level and order-level ATP differ
15. Worked ATP example with supply demand and safety stock
16. How warehouse selection changes the promise
17. Which sales-order lines are eligible for ATP
18. How order status and unconfirmed shipments affect the action
19. How shipping rules and back orders interact with ATP
20. Allocation is different from an ATP calculation
21. Purchase orders transfers and replenishment in the ATP timeline
22. Special cases that need separate testing
23. ATP behavior for imported and integrated sales orders
24. Data quality controls before implementation
25. A practical ATP test plan
26. Reconcile an ATP date to its source documents
27. Design permissions ownership and exception handling
28. Roll out ATP without disrupting order entry
29. Monitor promise quality after go-live
30. Common ATP pitfalls and how to diagnose them
31. Available-to-Promise implementation checklist
32. Frequently Asked Questions
33. Sources

What Available-to-Promise means in Acumatica 2026 R2

Acumatica defines the Available-to-Promise feature as the ability to determine when a sales-order line, or the sales order as a whole, can be shipped to a customer in full. The feature lets an organization create multiple ATP calculation rules, assign them to item classes, select which order types use ATP, and configure the calculation settings for those order types. The 2026 R2 Enable/Disable Features reference describes that scope directly.

The result is a date. For a qualifying sales-order line, Acumatica determines the earliest date on which its full open quantity can be covered. For the order, the system can calculate the date on which all eligible lines can be shipped in full. The Sales Orders form reference documents both calculations and the conditions under which the commands appear.

The phrase can be covered is important. ATP considers a time-phased series of quantities. It starts with the applicable available quantity at the beginning of the horizon, then adds supply and subtracts demand in chronological order according to the ATP rule. When the running balance can cover the quantity being evaluated, the system has a candidate coverage date. If the order type requires shipment, lead time to the customer's location is part of the displayed ATP result.

ATP is therefore more informative than reading one quantity from an inventory inquiry, but it remains dependent on recorded facts. A purchase order with an optimistic promised date can pull the calculation forward even when the vendor is habitually late. A sales order missing from the included demand categories can make supply look freer than it is. A warehouse with stale transfer dates can produce a technically consistent answer that operations cannot deliver.

Acumatica announced general availability of 2026 R2 on 1 October 2026 and identified Available-to-Promise as a new Distribution capability. The official release announcement says the distribution enhancements are intended to support more reliable customer commitments; the practical control is still the tenant's own configuration and data. See the Acumatica 2026 R2 release announcement and 2026 R2 release overview.

Back to TOC

Why distributors need a date-based promise

Sales teams often receive a simple question: can we deliver the requested quantity by the customer's date? Inventory systems commonly show several quantities, but none necessarily answers the date question alone.

On-hand quantity describes what the system records physically. Available quantity applies an availability calculation rule to on-hand inventory and selected additions and deductions. Available for shipping removes quantities that are already shipped, allocated, in unavailable locations, or tied to certain unreleased transactions. These numbers describe a current state. They do not, by themselves, show how future receipts and future demand unfold across a sequence of dates.

A date-based calculation matters when the answer changes over time. Consider an item with 20 units available for shipping today, customer demand for 15 units tomorrow, a purchase receipt for 50 units next Tuesday, and another demand document for 30 units on Wednesday. The business cannot safely tell a customer asking for 40 units that “50 are coming next week” without evaluating what consumes those units and when.

ATP gives order-entry users a documented timeline behind the result. In the line-level calculation dialog, Acumatica lists the supply and demand documents considered, their dates, reference numbers, positive or negative quantities, and the running Available-to-Promise quantity. That transparency makes the answer reviewable. A user can see whether the date depends on a specific purchase order, transfer, return, production supply, or competing demand document.

The business benefit does not come from displaying another date field. It comes from replacing informal promise logic with a shared rule. Customer service, sales, purchasing, inventory planning, and warehouse operations can discuss the same documents instead of relying on different spreadsheets or memory. The rule also exposes disagreements that need policy decisions: whether on-hold orders consume supply, whether safety stock is protected, which inbound documents count, and how far forward the system should look.

The Biz-Tech Acumatica Distribution ERP guide provides broader context for sales orders, availability, allocation, replenishment, purchasing, receiving, and warehouse fulfillment. ATP sits between these processes. It reads their recorded supply and demand to support a promise; it does not execute the downstream work.

Back to TOC

ATP compared with on hand available and available for shipping

The safest ATP rollout begins with a shared vocabulary. Users should not use on hand, available, available for shipping, and available to promise as if they were interchangeable.

On hand is the recorded physical quantity. It is useful for inventory control, but a portion may already be allocated, shipped, stored in a location excluded from availability, expired, or otherwise unsuitable for a new order.

Available is a configurable quantity. The Inventory Allocation Details reference describes it as on hand plus total additions minus total deductions. The selected availability calculation rule determines which plan types are additions and deductions. Two item classes can therefore show different available behavior when their rules differ.

Available for Shipping focuses on what can support shipping from the warehouse. Acumatica calculates it from on hand after deducting shipped quantities, quantities allocated for sales, production, and service orders, quantities in warehouse locations excluded from availability, unreleased issues, certain kit-assembly component demand, and certain kit-disassembly quantities. This value can be lower than on hand for valid operational reasons.

Available to Promise produces an earliest coverage date based on future supply and demand, the quantity to promise, the selected warehouse, the ATP rule assigned to the item's class, the order type's horizon, and the safety-stock choice. It uses Available for Shipping as a visible starting context in the calculation dialog, but it answers a different question.

This distinction should appear in training, order-entry procedures, and test scripts. If a salesperson expects ATP to reserve inventory, the process will fail even if the calculated date is correct. If a planner expects the current available quantity to account for future receipts, the planner may reject a valid ATP result because the measures answer different questions.

The same distinction matters for integrations. A commerce connector may publish On Hand, Available, or Available for Shipment, while ATP is evaluated during sales-order work. Biz-Tech's DSCO inventory synchronization guide shows why the exported quantity basis and selected warehouses must match the fulfillment policy. Publishing a current quantity to a channel and calculating a future promise date are related but separate controls.

Back to TOC

ATP compared with capable to promise and inventory planning

Available-to-Promise should also be separated from Capable-to-Promise and from Distribution Requirements Planning.

Acumatica's manufacturing Capable-to-Promise, or CTP, evaluates when manufactured items can be completed by considering production capacity and manufacturing constraints. The official Capable-to-Promise general information describes finite scheduling, resource availability, raw-material lead times, subassemblies, and planning or production orders. CTP is a manufacturing scheduling workflow. The new Distribution ATP feature is a supply-and-demand coverage calculation for sales-order lines and orders.

The two terms can sound similar because both support customer commitments. Their models are not equivalent. ATP does not automatically prove that a production work center has capacity, that engineering is complete, or that a configurable item can be produced on the candidate date. The Sales Orders reference explicitly excludes configurable lines from the ATP calculation. A manufacturer should continue to use the documented CTP workflow where production capacity is central.

Distribution Requirements Planning, or DRP, has another purpose. DRP creates time-phased planning recommendations and exceptions so the organization can procure or transfer inventory when it is needed. ATP reads configured supply and demand to answer a commitment question. DRP helps decide what supply actions should be taken. One can reveal that a quantity is not coverable within the ATP horizon; the other may guide the planner toward a purchase or transfer response.

This boundary prevents overclaiming. ATP can make existing supply-and-demand information more useful at order entry. It does not repair inaccurate lead times, create vendor capacity, reserve transport, authorize procurement, or schedule production. Those responsibilities remain in the appropriate purchasing, transfer, warehouse, planning, and manufacturing processes.

Back to TOC

The four configuration layers behind an ATP date

An ATP date becomes available only when four layers align.

1. Feature layer. The Available-to-Promise feature must be enabled on Enable/Disable Features (CS100000).
2. Rule layer. An availability calculation rule with the Available-to-Promise rule type must define the supply and demand categories to consider.
3. Item layer. The ATP calculation rule must be assigned to the relevant item class on Item Classes (IN201000), so qualifying stock items inherit the rule.
4. Order layer. The sales-order type must use Cumulative with Look-Ahead in the ATP Calculation field, with an ATP horizon and an explicit safety-stock decision.

The sales-order line then has to meet the documented eligibility conditions. It must contain a stock item, use the Issue operation, remain incomplete, not be configurable, and not have a related unconfirmed shipment. The order must be in a status that permits the ATP command.

This layered design is valuable because it prevents one global rule from being forced onto every item and transaction. A distributor can define different ATP rules for item families that have different supply reliability or demand behavior. It can enable ATP for order types used in customer commitments while leaving other types on the default Do Not Calculate setting.

The flexibility also creates a diagnostic requirement. When Calculate ATP is absent or an ATP Date remains blank, the cause may be at any layer. Troubleshooting should begin with the configuration chain rather than with a code assumption.

Back to TOC

Enable the Available-to-Promise feature deliberately

Enable the feature first in a nonproduction environment. The feature makes ATP controls available on the related forms, but the implementation work begins after the checkbox is enabled.

Before activation, define the business owner and the desired scope. The owner should be able to answer these questions:

• Which sales-order types create customer-facing commitments?
• Which stock-item classes should receive an ATP rule?
• Which supply documents are reliable enough to count?
• Which demand statuses should reduce promise capacity?
• Should safety stock be protected from promises?
• How far into the future are inbound dates considered credible?
• Who can accept or override the resulting date?

Enabling a feature without these decisions can produce inconsistent use. One item class may be configured quickly while another is missed. A test order may show the ATP command, leading users to assume the feature is complete, even though only a subset of items has rules.

Record the configuration baseline before changing it. Export or document the relevant item classes, availability rules, order types, warehouses, locations, safety-stock values, lead times, and representative open documents. This evidence supports testing and rollback. It also helps distinguish a new ATP issue from a pre-existing availability or data-quality problem.

Treat activation as a governed configuration change. Use a sandbox or copy of production data, schedule representative tests, document expected results, and obtain functional approval before deploying. The feature's purpose is operational, so a technically successful enablement is not enough.

Back to TOC

Create ATP calculation rules that match fulfillment policy

Use Availability Calculation Rules (IN201500) to create a rule whose Rule Type is Available-to-Promise. The 2026 R2 Availability Calculation Rules reference distinguishes this rule type from the standard Available type. The ATP rule is used to calculate dates for stock items in sales-order lines and for the order, based on future supply and demand.

The rule's checkboxes decide which recorded events affect the timeline. Demand options include issues, prepared sales, open sales orders, shipped quantities, allocations, back orders, service-order demand, production demand, kit demand, transfer demand, and project-material demand where the related features apply. Supply options can include purchase orders, prepared purchases, purchase receipts, transfers, sales returns, kit assembly supply, production supply, and material supply.

Do not select every checkbox because it exists. Each inclusion needs a business interpretation. A prepared purchase order may represent credible supply in one organization and an unapproved draft in another. An on-hold sales order may represent real customer demand or an unqualified quote-like request. The rule should reflect the meaning of statuses in the organization's process.

Use a decision worksheet with four columns:

Some items need different policies. Fast-moving stocked goods may rely on purchase orders and transfers. Special-order items may be tied to purchase-to-order documents. Repair parts may receive unpredictable returns. Segmenting item classes can be safer than constructing one permissive rule for the entire catalog.

Document the rationale beside the technical setup. When a result is questioned months later, the team needs to know why a plan type was selected, not merely that the checkbox is selected.

Back to TOC

Assign ATP rules through item classes

The ATP rule is assigned in the ATP Calculation Rule field on Item Classes (IN201000). The Item Classes reference states that only an availability calculation rule with the Available-to-Promise type can be selected.

This assignment is a major control point. An eligible sales-order line must contain a stock item whose item class has an ATP rule. If the rule is missing, the line will not qualify even when the feature and order type are configured.

Review item-class design before mass assignment. Item classes often group records for financial, replenishment, tax, or reporting reasons, not solely for promise behavior. One class may contain items with very different lead-time reliability. If a single rule would be misleading, consider whether item-class restructuring is appropriate or whether the ATP rollout should begin with a narrower set.

Do not assume that new items will always inherit the intended rule without review. Add the ATP rule to the new-item governance checklist. When a stock item is created or moved between classes, validate its promise behavior with the same care applied to availability, replenishment, and accounting defaults.

For existing catalogs, produce an exception report that shows active stock items with their item class, assigned ATP rule, default warehouse, and relevant planning attributes. Flag items in customer-facing order flows that have no ATP rule. Also flag discontinued, obsolete, non-stock, configurable, or special-process items so the project does not spend time testing lines that are outside the intended scope.

Back to TOC

Configure order types for cumulative look-ahead

On Order Types (SO201000), the Available-to-Promise Settings section appears when the feature is enabled and the order type uses an eligible automation behavior. The Order Types reference lists Invoice, Sales Order, RMA Order, and Mixed Order automation behaviors for this section.

ATP Calculation has two choices:

• Do Not Calculate, the default, leaves ATP dates inactive for orders of that type.
• Cumulative with Look-Ahead processes supply and demand in chronological order within the horizon and can consider supply expected after the requested date.

Select Cumulative with Look-Ahead only for order types where a promise calculation belongs in the workflow. Review custom order types separately. A copied order type may have different operations, automation behavior, shipping expectations, or integration dependencies even when its code resembles the standard SO type.

An order type is also a contract with integrations. E-commerce, EDI, customer portals, PDF-order automation, and custom connectors frequently choose the destination order type during import. Changing ATP settings on that type can alter what users see on imported orders and what downstream processes might read. The underlying order creation does not automatically calculate or publish an ATP date unless the workflow invokes the appropriate action, but the configuration becomes part of the transaction's behavior.

Capture the old and new settings for every affected type. Confirm the automation behavior, default operation, shipping requirement, shipping rule, back-order behavior, quick-process settings, and integration mappings. ATP should be added to the established process, not treated as an isolated checkbox.

Back to TOC

Choose an ATP horizon that covers relevant supply

ATP Horizon (Days) defines the number of calendar days from the current business date within which Acumatica searches for supply and demand transactions. The system excludes transactions dated beyond the horizon. The Order Types reference states that the default is 90 days when Cumulative with Look-Ahead is selected.

The default is a starting point, not a universal answer. A horizon should be long enough to include supply that the company genuinely uses for promises and short enough to avoid false precision.

A distributor that replenishes domestic stock weekly may not need to consider documents six months out. An importer with ocean freight and seasonal buys may need a longer period. A service-parts business may receive supply sporadically and prefer a conservative horizon because distant purchase dates are less reliable.

Evaluate the horizon with transaction evidence:

1. Measure actual supplier lead-time distribution by item family or vendor.
2. Identify how far ahead customers normally request delivery.
3. Review the date quality of purchase orders, transfers, and returns at different ages.
4. Test whether a longer horizon merely finds uncertain supply instead of improving commitment quality.
5. Define what users should say when ATP is blank because the quantity cannot be covered within the horizon.

A blank ATP Date does not necessarily mean the item can never be supplied. The Sales Orders reference says the field is empty when the quantity cannot be covered within the ATP horizon. The distinction should be explicit in training. The correct next step may be to review purchasing, alternate warehouses, substitutions, transfers, or a manual customer negotiation rather than extending the horizon to make a date appear.

Do not change the horizon casually after go-live. A longer horizon can make more orders appear coverable, while a shorter horizon can remove dates that users previously saw. Treat a horizon change as a policy change and rerun the approved scenarios.

Back to TOC

Decide whether ATP should protect safety stock

Order Types includes Include Safety Stock in ATP Calculation. When selected, Acumatica subtracts the safety-stock quantity from the available quantity before calculating ATP so the calculation does not promise inventory below that level. The setting is cleared by default.

The choice is operational. Safety stock may exist to protect service levels during demand variability, supplier delay, or other uncertainty. If ATP ignores it, the promise calculation can consume the buffer in its mathematical coverage. If ATP protects it, an order may receive a later date even though physical units appear to be present.

Neither choice is inherently correct for every order type. Some companies treat safety stock as a firm floor. Others permit selected customer orders to use it with approval. A single checkbox cannot model an informal exception policy by itself.

Use these questions to decide:

• Is safety stock maintained accurately by item and warehouse?
• Does the current process already protect it during allocation and shipment?
• Can sales override the buffer, and if so, who approves the exception?
• Are strategic customers handled through a separate order type or workflow?
• Will users understand why ATP is later than the current physical quantity suggests?
• How often is the buffer recalculated, and what evidence supports the quantity?

Test both states with the same documents. For example, begin with 25 units available for shipping, safety stock of 10, and a request for 20. With safety stock excluded from the promise calculation, current supply may cover the request. With safety stock protected, only 15 units are promiseable at that point, so ATP should move to a later supply event or remain blank within the horizon.

The test demonstrates why the policy belongs in training and customer-service scripts. The system is not “wrong” when it gives different dates under the two settings. It is applying two different promise policies.

Back to TOC

Understand the dates used on a sales order

ATP depends on dates, but sales orders contain several date concepts. Users should know which one they are viewing and who owns its accuracy.

Requested On is when the customer wants to receive the item. The line can have its own requested date, particularly when the order-level shipping rule allows back orders. This is a customer requirement, not proof that supply exists.

Ship On is when the item should be shipped. Acumatica normally derives it from Requested On minus the lead days. If that result is earlier than the current business date, the current date is used. The line's Ship On date can be editable when Back Order Allowed applies.

ATP Date on the line is the earliest date on which the full open quantity can be covered under the configured calculation. The calculation dialog also shows Lead Time (Days). When the order type requires shipment, Acumatica adds lead time to the date on which the quantity can be covered to determine the ATP date.

ATP Date on the Shipping tab is the date on which the sales order can be shipped in full after order-level calculation. It is not necessarily the same as the earliest line date because the order cannot ship in full until its limiting line is ready.

Supply and demand dates come from the documents included by the ATP rule. A purchase order line's expected date, a transfer's date, a sales order's demand date, or a return's date can move the running balance. These dates must be maintained by their process owners.

Use a date dictionary in the rollout documentation. List the source field, business meaning, owner, update trigger, and whether it influences ATP. This small artifact prevents a recurring misunderstanding: users may read an ATP result as a requested delivery date, or may update Requested On without realizing that the calculation relies on different supply dates.

Back to TOC

How the cumulative look-ahead calculation works

The line-level Available-to-Promise Calculation dialog gives the clearest explanation of the method. Acumatica shows the item's warehouse context, quantity to promise, on-hand quantity, available-for-shipping quantity, safety stock, lead time, requested date, and calculated ATP date. Beneath the summary, it lists the supply and demand documents used in the calculation.

Each timeline row has:

• the date on which the document is expected to increase or decrease availability;
• the document type;
• a reference number linked to the source document;
• a positive quantity for supply or a negative quantity for demand; and
• the running Available-to-Promise quantity as of that row.

The running balance begins with the available quantity at the start of the ATP horizon. Acumatica then adds each document quantity in chronological order. The quantity to promise is evaluated against this progression. The candidate date is the earliest point at which the applicable balance can cover the full quantity, subject to safety stock and other settings.

This method is called cumulative because earlier supply and demand affect later availability. It uses look-ahead because supply after the requested date can still produce a future ATP result. That does not mean the customer request is met. It means the system has found the earliest later point, within the horizon, at which the full quantity can be covered under the rule.

The calculation is deterministic with respect to its inputs, but the inputs change. A newly entered order, rescheduled purchase, canceled transfer, partial receipt, return, allocation, or warehouse change can alter the result. Users should recalculate before communicating a date when material documents have changed.

Do not create an external simplified formula and assume it will reproduce every tenant result. The selected plan types, statuses, features, warehouse rules, safety stock, and line eligibility all matter. Use the calculation dialog as the primary reconciliation surface because it shows the actual documents Acumatica used.

Back to TOC

How line-level and order-level ATP differ

The Details tab provides a Calculate ATP action for one selected line. The result can be reviewed in the calculation dialog before it is saved to the line. Users can also change the warehouse or quantity to promise in the dialog; when saved, those changes update the line along with the ATP date.

The More menu provides Calculate ATP Date for the entire order. Acumatica evaluates all eligible lines, inserts their line dates, and calculates the date on which the order can ship in full. The order-level ATP Date appears on the Shipping tab.

The distinction matters when an order has several items:

• Line A may be coverable today.
• Line B may depend on a purchase receipt next Friday.
• Line C may be coverable in another warehouse on Wednesday.
• The complete order date must reflect the set of eligible lines and the chosen fulfillment behavior.

If a customer accepts split shipments, line dates may guide a staged commitment. If the customer requires Ship Complete, the latest constraining line controls the meaningful complete-order promise. The order-level calculation provides a shared reference, but the shipping rule and customer agreement still determine how operations should act.

Line-level review is also useful for diagnostics. A user can change the warehouse or test a smaller quantity without editing several order fields blindly. The dialog should not become an undocumented override mechanism. If warehouse or quantity changes affect the commercial agreement, require the same approval and audit controls used for ordinary order changes.

Back to TOC

Worked ATP example with supply demand and safety stock

The following example illustrates the logic without claiming to reproduce every tenant's plan configuration. It assumes one stock item, one warehouse, a 30-day horizon, an ATP rule that includes the listed documents, and zero delivery lead time unless stated otherwise.

Scenario setup

The customer wants 40 units of item A100. The selected warehouse is MAIN.

• Available for Shipping at the start of the horizon: 20 units
• Safety stock: 5 units
• 23 October: existing open sales-order demand of 8 units
• 24 October: purchase-order supply of 25 units
• 25 October: transfer-out demand of 10 units
• 28 October: purchase-order supply of 30 units
• 30 October: existing back-order demand of 12 units

The new line itself is the quantity being tested, so the example does not subtract it as a separate competing demand row.

Timeline without safety-stock protection

The running quantity first reaches 40 on 28 October. It remains above 40 after the 30 October demand, so 28 October is the candidate coverage date in this simplified timeline.

Timeline with safety-stock protection

If the order type protects 5 units of safety stock, begin from an effective promiseable quantity of 15 rather than 20.

The balance reaches 40 on 28 October, but later included demand reduces it to exactly 40. Depending on how the product evaluates coverage against later dated commitments within the configured method, the calculation dialog is the authoritative result. The example's purpose is to show that safety stock changes the running balance and can change the date or eliminate coverage near the horizon boundary.

Add customer delivery lead time

Assume the stock is covered on 28 October and the customer location has two lead days. When the order type requires shipment, the documented calculation adds the lead time to determine the ATP date shown to the user. The operational interpretation should distinguish the warehouse coverage date from the customer-facing date.

Change the warehouse

Suppose warehouse EAST has 45 available-for-shipping units and no earlier included demand. The line-level dialog lets the user change the warehouse and recalculate. EAST may produce an earlier date, but that result is not a command to move the order automatically. The user must consider fulfillment cost, warehouse policy, branch access, shipping zone, customer expectation, and whether the organization uses order orchestration.

What to validate in the real system

Build the scenario with actual documents and record:

1. Every document that appears in the calculation dialog.
2. Every expected document that does not appear.
3. The sign and date of each quantity.
4. The starting available-for-shipping value.
5. The safety-stock behavior.
6. The coverage date before lead time.
7. The saved line ATP date and order ATP date.
8. The result after changing one input at a time.

This approach tests both configuration and user interpretation. A screenshot of a final date without the document timeline is not enough evidence.

Back to TOC

How warehouse selection changes the promise

ATP is evaluated for the warehouse selected on the line. In the calculation dialog, changing the warehouse recalculates the date. This is useful when the company can fulfill from multiple sites, but it makes warehouse data part of the promise.

Warehouses may differ in:

• current available-for-shipping quantity;
• inbound purchase schedules;
• transfer supply and demand;
• safety-stock values;
• excluded locations;
• customer delivery lead time;
• shipping zones and carrier services;
• item-specific warehouse settings; and
• operational cutoffs or capacity not represented in ATP.

The earliest mathematical date is not always the best fulfillment choice. Shipping from a distant site may increase freight cost, split an order, complicate tax or branch handling, or consume supply reserved operationally for another region. Define when users may change the warehouse and whether approval is required.

If Order Orchestration is enabled, do not assume ATP and orchestration make the same decision. Order orchestration chooses fulfillment according to configured strategies and plans; ATP calculates coverage for the selected warehouse and quantity. Test the combined workflow using the actual order type, orchestration strategy, shipping zone, and warehouse priorities.

Unavailable warehouse locations also matter to the starting quantity. Inventory Allocation Details states that Available for Shipping excludes quantities in locations where Include in Qty. Available is cleared. Validate receiving, quarantine, inspection, damaged-goods, and staging locations so physical stock that cannot ship is not mistaken for promiseable stock.

Back to TOC

Which sales-order lines are eligible for ATP

According to the Sales Orders reference, a line qualifies for ATP calculation only when all of these conditions are met:

• It contains a stock item.
• The item's item class has an ATP calculation rule.
• The line is not completed.
• The operation is Issue.
• The line is not configurable.
• The line does not have a related unconfirmed shipment.

The conditions explain several common cases before troubleshooting begins.

A non-stock service or charge line does not represent warehouse stock and therefore does not receive this ATP calculation. A receipt operation adds inventory rather than issuing it to the customer. A completed line no longer needs a new coverage date. A configurable item may require configuration and manufacturing logic outside the distribution ATP model. A line already tied to an unconfirmed shipment has entered a different fulfillment state.

Create a negative test for each exclusion. The goal is not to force every line to display a date. The goal is to confirm that eligible lines calculate and ineligible lines remain outside the process for the documented reason.

Mixed orders, returns, replacements, kits, drop shipments, and custom line types deserve extra attention because one document can contain different operations and fulfillment paths. Review the line, not only the order header.

Back to TOC

How order status and unconfirmed shipments affect the action

The ATP commands are available only for sales orders in documented working statuses. The 2026 R2 Sales Orders reference lists On Hold, Awaiting Payment, Credit Hold, Open, and Back Order for the calculation actions.

These statuses cover orders that may still need a commitment decision. A canceled or completed order is outside that decision. A line with a related unconfirmed shipment is excluded because fulfillment processing has already created a shipment document whose quantities and status need to be resolved.

Users should calculate at defined checkpoints:

1. During order review, after item, quantity, warehouse, requested date, and shipping information are correct.
2. After credit or payment status changes when the order remained open long enough for supply and demand to move.
3. After a material purchasing, transfer, or back-order update.
4. Before sending a promise externally when the prior calculation is no longer recent.
5. After changing the warehouse or open quantity.

Avoid a rule that says “calculate once at order creation.” ATP is a snapshot of a changing document timeline. The saved date can become stale after other transactions change. The process should define when recalculation is mandatory and how users recognize an old result.

An unconfirmed shipment requires operational review rather than an ATP workaround. Confirm, correct, or delete the shipment according to normal controls. Do not detach or alter shipment records merely to make the ATP button available.

Back to TOC

How shipping rules and back orders interact with ATP

Shipping rules determine how an order may be fulfilled. Acumatica documents three familiar outcomes on sales orders: Ship Complete, Back Order Allowed, and Cancel Remainder. ATP does not replace these rules.

With Ship Complete, the practical commitment centers on the date when the order can ship in full. The order-level ATP date is especially relevant because the latest constraining eligible line controls the complete shipment.

With Back Order Allowed, lines can have different requested and ship dates. Line-level ATP can support staged commitments, but the business must explain each shipment and keep the remaining demand visible. Back-order demand should be included or excluded from the ATP rule according to a deliberate policy.

With Cancel Remainder, the first shipment can end the remaining obligation according to the order process. An ATP date for the full original open quantity may be less relevant if the customer accepts partial fulfillment and cancellation of the balance. The sales policy should decide whether ATP is used before that decision and how the communicated commitment is recorded.

Test partial availability explicitly. Enter an order larger than current stock, calculate ATP, create a partial shipment where allowed, confirm or leave the shipment unconfirmed, and recalculate the remaining order after the correct operational step. Observe line eligibility, open quantity, back-order status, and the updated timeline.

Back orders can consume future supply when the ATP rule deducts them. This is usually essential for fairness: a new order should not be promised against a receipt already needed for older demand. If back orders are excluded, document the reason and test the priority process that prevents overpromising.

Back to TOC

Allocation is different from an ATP calculation

Allocation reserves or associates inventory quantities with demand according to the order and inventory process. ATP estimates the earliest date on which the full open quantity can be covered under a rule. A calculated ATP date does not, by itself, hard-allocate the stock or prevent another transaction from consuming it.

This distinction is critical in high-volume order entry. Two users can calculate similar dates close together while supply and demand continue to change. If the business requires reservation, the allocation workflow must occur and be monitored separately.

Inventory Allocation Details is the main diagnostic surface for current availability and item plans. It shows on-hand, available, available-for-shipping, additions, deductions, and the source documents behind them. The ATP dialog provides the time-phased subset used for the promise calculation. Use both when a user reports that the promise date conflicts with the apparent inventory position.

Training should use precise verbs:

• “Calculate ATP” means determine an earliest coverage date.
• “Save ATP” means write the reviewed result to the line, and possibly save changed warehouse or quantity values from the dialog.
• “Allocate” means reserve or designate inventory through the applicable sales-order process.
• “Create shipment” moves the order into warehouse fulfillment.
• “Confirm shipment” records the completed shipment step according to the configured workflow.

Biz-Tech's guide to PDF order automation and inventory allocation explains a similar boundary: automation can create clean sales-order demand, while Acumatica still controls allocation, back orders, transfers, and shipment behavior. ATP adds a date calculation to that controlled process; it does not erase the boundary.

Back to TOC

Purchase orders transfers and replenishment in the ATP timeline

Future supply can make ATP valuable, but only when the underlying documents are credible.

Purchase orders. If the ATP rule includes open purchase orders, their quantities and expected dates can increase the running balance. Review approval status, vendor confirmation, partial receipts, overdue lines, and date-maintenance discipline. An open purchase order is not the same as a confirmed delivery.

Purchase receipts. Unreleased receipts may represent goods that have arrived but are not yet available under the ordinary inventory process. Test whether the selected plan category belongs in the ATP rule and whether inspection or quality holds create additional constraints.

Transfers. Transfer supply and demand should be paired by warehouse and date. A transfer into MAIN is potential supply for MAIN and demand against the source warehouse. Late transfer processing can make one warehouse appear short while another appears to have supply in motion.

Replenishment. A recommendation or planning exception is not necessarily an executable supply document. ATP uses the plan types included in the rule. Confirm which planning outputs become purchase orders, transfers, or other documents before counting them.

Purchase-to-order and drop shipment. Sales lines linked to purchasing follow specific fulfillment relationships. Test linked quantities, partial documents, vendor dates, and receipt or direct-ship behavior. Do not assume the general warehouse ATP date is the appropriate customer commitment for a drop shipment without validating the documented flow.

Build an exception report for inbound supply used by ATP. Useful conditions include promised dates in the past, lines with no promised date, partially received orders, transfers not released, purchase orders on hold, and vendors whose actual receipts frequently miss recorded dates. ATP quality depends on the owners correcting those records.

Back to TOC

Special cases that need separate testing

Some inventory and order patterns cannot be covered safely by one ordinary stocked-item scenario.

Kits

Stock kits and non-stock kits can depend on component availability, kit assembly, disassembly, or customized processing. The ATP line may represent the kit item while operational feasibility depends on components. Test the actual kit configuration and the plan types included in the ATP rule. The Biz-Tech kit component inventory guide explains why On Hand, Available, Available for Shipping, component demand, purchase supply, and assembly documents must be distinguished.

Lot and serial tracking

A total quantity can appear sufficient while the usable lots do not meet expiration, assignment, customer, project, or quality requirements. Inventory Allocation Details can exclude expired quantities and locations not included in availability, but the business should test its lot and serial workflow through allocation and shipment.

Configurable items

The documented sales-order ATP calculation excludes configurable lines. Use the applicable configuration and manufacturing process. Do not present a missing ATP date as a defect when the line is outside the feature's eligibility.

Project-specific inventory

Project inventory can restrict which quantity belongs to a customer or project. Test project and task dimensions, warehouse locations, allocations, and item plans. A company-wide quantity may not be available to the specific order.

Returns

An expected return is uncertain until the goods arrive and their condition is known. If the ATP rule includes sales returns, define when a return can be counted and whether inspection or disposition delays the item becoming ship-ready.

Expired or quarantined stock

The warehouse can physically contain units that should not be promised. Confirm location availability settings, lot expiration behavior, quality controls, and the starting Available for Shipping quantity.

Units of measure

ATP evaluates quantities in a system that may use different sales, purchase, and base units. Test conversion factors, rounding, divisible-unit settings, pack sizes, and vendor quantities. A conversion error can move the date even when document counts look reasonable.

Customizations and integrations

Custom code may set warehouse, requested date, order type, operation, status, plan type, or quantity. Review customizations that extend SO301000, IN201500, IN201000, purchase processing, transfer processing, or integrations. Retest after every upgrade or customization change.

Back to TOC

ATP behavior for imported and integrated sales orders

Imported orders use the same Acumatica order configuration after they are created. The source system does not bypass the need for a correct Acumatica item, warehouse, order type, quantity, unit of measure, requested date, operation, and status.

This point matters because integrations often apply defaults:

• A connector may choose one order type for all incoming orders.
• A store configuration may assign a default warehouse.
• A cross-reference may translate an external SKU or warehouse into Acumatica values.
• An import scenario may place orders on hold.
• EDI or commerce data may omit a requested delivery date or use a different date definition.
• A customization may create allocations, purchase links, or shipments soon after import.

Each default can affect ATP eligibility or the resulting timeline. A wrong warehouse can produce a valid date for the wrong supply pool. A wrong item can inherit a different ATP rule. A direct-to-invoice flow may not follow the sales-order process expected by customer service. An automatically created unconfirmed shipment can make the line ineligible for calculation.

Review the integration mapping as part of the ATP design. The Biz-Tech WooCommerce data-flow guide shows how a connector can set the destination document type, order type, and warehouse. The Salesforce inventory-allocation guide reinforces that imported demand affects inventory through the Acumatica sales order that is created, while allocation rules remain in Acumatica.

Create end-to-end tests for each order source:

1. Import a known item and quantity.
2. Confirm the resulting order type, warehouse, UOM, requested date, status, and line operation.
3. Calculate ATP and capture the document timeline.
4. Compare the result with a manually entered order using identical values.
5. Change one mapping, such as warehouse, and confirm the expected change.
6. Continue through allocation, shipment, confirmation, and invoice processing.
7. Verify what date, if any, is returned to the external channel.

Do not automatically publish the ATP date to a marketplace, portal, CRM, or EDI acknowledgment without a separate interface design. Define the outbound field, timezone, date semantics, recalculation trigger, error handling, and what happens when the date is blank or later changes.

Back to TOC

Data quality controls before implementation

ATP can expose weak data because it asks the system to connect many ordinary transactions on a timeline. Improve the data before judging the feature.

Item master data

Confirm that each in-scope stock item has the correct item class, base and sales UOMs, default warehouse, item-warehouse settings, safety stock, lead times, lot or serial settings, and active status. Identify duplicate or obsolete items that should not receive customer demand.

Warehouse and location data

Review warehouse access, defaulting, customer shipping zones, item availability by warehouse, and location flags. Quarantine, damaged, inspection, returns, staging, and consignment locations should reflect whether their stock is eligible for availability and shipping.

Supply dates

Measure overdue and missing promised dates on purchase orders and transfers. Ask buyers and warehouse planners how dates are updated after vendor acknowledgments, partial receipts, or delays. A daily ATP process needs a daily date-maintenance habit.

Demand status discipline

Review how long sales orders remain on hold, credit hold, open, or back order. Remove canceled or abandoned demand through the proper workflow. Decide which statuses the ATP rule treats as real demand.

Document quantities

Look for unusual UOM conversions, negative quantities, partially completed lines, incorrect open quantities, and duplicate integration records. Reconcile linked purchase-to-order and transfer documents.

Customer lead-time inputs

Confirm that the delivery lead time used in the result corresponds to the customer location and shipping process. Carrier transit time, warehouse cutoff, weekends, holidays, and route schedules may need operational controls beyond the base ATP calculation.

Ownership

Assign each data category to a role. Sales owns customer request details; purchasing owns expected vendor dates; inventory control owns location and quantity accuracy; warehouse operations owns shipment state; the ERP team owns configuration; process leadership owns exception policy.

Use measurable entry criteria for the pilot. Examples include no missing ATP rule on pilot item classes, no overdue inbound document without a reviewed date, no unexplained negative Available for Shipping quantity, and signed expected results for representative scenarios.

Back to TOC

A practical ATP test plan

A reliable test plan combines configuration coverage, business scenarios, negative cases, and reconciliation. Use a recent copy of production data where permitted, because synthetic master data often misses real item-class, warehouse, and document variation.

Establish the baseline

Before enabling ATP, record the current promise process. Identify which fields users read, which spreadsheets or inquiries they consult, who approves an exception, and how late promises are tracked. This baseline will show whether ATP reduces ambiguity or simply adds another date.

Build a scenario matrix

Test at least the following:

Change one variable at a time

Begin with a known document set. Calculate and capture the result. Then change one input: a PO date, quantity, warehouse, safety-stock setting, horizon, demand status, or rule checkbox. Recalculate and explain the difference. Multiple simultaneous changes make a failed expectation difficult to diagnose.

Verify both line and order calculations

Test Calculate ATP on a selected line and Calculate ATP Date for the order. Confirm saved values in the line and Shipping tab. Use orders with one line and several lines.

Test user roles

Run scenarios under the actual sales, customer-service, purchasing, warehouse, and administrator roles. Confirm that users can see the necessary source documents without receiving unnecessary access. A calculation result that links to documents the user cannot inspect needs an escalation path.

Test concurrency and change

Have one user calculate while another updates an included supply document in a controlled test. Recalculate and confirm the changed result. The purpose is to teach that ATP is time-sensitive, not to prove that a saved date is permanently reserved.

Record evidence

For each scenario retain the configuration version, build number, user role, starting values, source documents, screenshots of the timeline, expected result, actual result, and reviewer decision. This evidence supports training and future regression tests.

Back to TOC

Reconcile an ATP date to its source documents

Reconciliation should be a standard response to a questioned ATP date. Avoid debating the final date before reviewing the timeline.

1. Open the sales order and confirm its status, type, warehouse, item, quantity, operation, requested date, open quantity, and shipment state.
2. Confirm that the Available-to-Promise feature is enabled.
3. Open the order type and record ATP Calculation, ATP Horizon, and the safety-stock setting.
4. Open the item's item class and record the assigned ATP Calculation Rule.
5. Open the rule and record every selected supply and demand category.
6. Open Inventory Allocation Details for the item and warehouse. Reconcile On Hand, Available, Available for Shipping, locations, and item plans.
7. Open the line-level ATP dialog and export or transcribe the dated document rows.
8. Follow each reference number to its source document. Confirm date, status, warehouse, open quantity, and link relationships.
9. Rebuild the running balance in a simple worksheet.
10. Confirm safety-stock and lead-time effects.
11. Recalculate after correcting any source document through its normal workflow.

Do not edit a transaction merely to force the expected answer. If the calculation uses an unwanted document, determine whether the document is wrong, its status is wrong, its date is stale, or the rule includes a plan category the business does not trust.

The dialog's source links are an important control. They turn ATP from an opaque date into an auditable chain. Save that evidence when resolving a customer-impacting exception.

If a customization or build-specific issue is suspected, create the smallest reproducible scenario. Include exact build, enabled features, order type, rule settings, item class, document data, user role, and steps. Compare the result in a clean environment when practical before escalating.

Back to TOC

Design permissions ownership and exception handling

ATP crosses functional boundaries, so ownership must be explicit.

ERP administrator. Enables the feature, controls configuration changes, documents versions, and coordinates regression testing.

Distribution functional owner. Approves the ATP rule, horizon, safety-stock policy, order-type scope, and operational interpretation.

Sales and customer service. Enters accurate order data, calculates at defined checkpoints, communicates approved dates, and escalates exceptions.

Purchasing. Maintains credible inbound dates and resolves supplier changes that affect promises.

Inventory and warehouse teams. Maintain quantity accuracy, location availability, transfers, allocations, shipment status, and exception stock.

Integration owner. Validates order defaults and controls any outbound use of the ATP date.

Finance or commercial leadership. Defines which customers, order values, or margin conditions require approval before a later date, split shipment, expedited freight, or safety-stock exception is accepted.

Separate permissions for calculation, transaction editing, and configuration. A sales user may need to calculate and inspect the timeline without being allowed to edit ATP rules or purchase dates. A buyer may maintain purchase dates without changing the order's commercial terms.

Define exception categories:

• blank date within the horizon;
• date later than the customer request;
• source document with uncertain or overdue supply;
• safety-stock override request;
• alternate-warehouse request;
• split-shipment request;
• expedited purchase or freight request;
• strategic-customer prioritization;
• result that conflicts with a physical or supplier reality.

For each category, name the decision owner, required evidence, response time, allowed changes, and where the decision is recorded. ATP should make exceptions visible, not move them into private messages.

Back to TOC

Roll out ATP without disrupting order entry

Use a controlled sequence instead of enabling every order type and item class at once.

Phase 1: policy and design

Map the current promise process. Approve rule categories, horizon, safety stock, order types, item scope, roles, and exception handling. Identify integrations and customizations.

Phase 2: configuration prototype

Enable ATP in a sandbox. Create one ATP rule for a coherent item family, assign it to a pilot item class, and configure one order type. Use a small set of representative warehouses and customers.

Phase 3: data cleanup

Correct stale dates, class assignments, warehouse defaults, location flags, UOMs, safety stock, back orders, and incomplete supply documents for the pilot scope.

Phase 4: scenario testing

Execute the approved matrix and reconcile every result. Include integrations, permissions, negative cases, and multi-line orders.

Phase 5: user pilot

Select a small sales and customer-service group. Ask them to use ATP alongside the existing promise process without changing external commitments automatically. Collect discrepancies and classify their causes.

Phase 6: operational integration

Update procedures, customer communication templates, approvals, reports, dashboards, and any intended outbound interfaces. Train purchasing and warehouse users on how their dates and statuses influence promises.

Phase 7: production release

Deploy the signed configuration through the organization's change process. Verify it in production with non-disruptive test orders or carefully selected real orders. Confirm the exact build and enabled feature state.

Phase 8: expansion

Add item classes, order types, warehouses, and integrations only after the pilot metrics are stable. Reuse regression tests and document rule differences.

The rollout should include an explicit stop condition. Pause expansion if users cannot reconcile dates, overdue inbound records remain common, the integration publishes unreviewed dates, or late commitments increase.

The broader Acumatica 2026 R2 Upgrade Guide provides a framework for sandbox testing, customizations, integrations, training, and cutover. ATP should follow the same controlled upgrade discipline.

Back to TOC

Monitor promise quality after go-live

The goal is not to maximize the number of orders with an ATP date. The goal is to improve the reliability and explainability of customer commitments.

Track measures that connect the calculation to outcomes:

Promise adherence

Compare the communicated promise date with the actual shipment or delivery result. Segment by item class, warehouse, vendor-dependent supply, order type, and customer.

ATP date stability

Measure how often the saved date changes before shipment and the size of the change. Frequent movement may indicate stale supply dates, volatile demand, weak allocation, or a horizon that reaches too far.

Requested-date gap

Measure the difference between Requested On and ATP Date. This identifies item families and warehouses where demand regularly exceeds the planned supply position.

Blank ATP rate

Track eligible lines that remain uncovered within the horizon. Do not treat zero as the target. A blank result can be an honest signal. Investigate clusters by item, vendor, warehouse, or rule.

Manual override rate

Record warehouse, quantity, date, or safety-stock exceptions. High volume may mean the policy does not match real operations or users are bypassing it.

Source-document quality

Monitor overdue purchase lines, missing promised dates, late transfers, unconfirmed shipments, old back orders, and abandoned on-hold sales orders.

Customer-service handling time

Measure the time needed to answer a date inquiry and the number of handoffs. A transparent calculation may reduce manual investigation even before on-time performance changes.

Review results weekly during the pilot and monthly after stabilization. Separate configuration errors, data errors, process exceptions, and supplier or warehouse execution problems. ATP cannot solve every cause, but it can make the causal chain easier to inspect.

Back to TOC

Common ATP pitfalls and how to diagnose them

Calculate ATP is missing

Check the feature, order type's ATP Calculation setting, order status, item class rule, line operation, completed state, configurable status, and related unconfirmed shipment. Follow the four-layer configuration chain.

ATP Date is blank

Confirm that the quantity cannot be covered within the horizon. Review the timeline for missing or excluded supply, competing demand, safety stock, wrong warehouse, and dates beyond the horizon. A blank field can be the correct answer.

The date is much later than expected

Look for included demand before the anticipated supply, protected safety stock, lead time, back orders, transfer demand, overdue supply moved to a later date, or an item in the wrong class.

The date is earlier than operations believe

Investigate optimistic purchase dates, on-hold supply counted as credible, missing demand categories, stale canceled or duplicated data, returns counted before inspection, wrong UOM conversion, and stock in an operational state not represented by the rule.

On Hand is high but ATP is late

Reconcile Available for Shipping. The stock may already be allocated, shipped, located in an excluded location, expired, reserved for another purpose, or protected as safety stock.

Available for Shipping is low but future supply exists

Current ship-ready quantity and future promise are different. Confirm that the future document type is included, dated within the horizon, assigned to the same warehouse, and in an eligible status.

A purchase order does not appear

Check the rule's purchase categories, PO status, warehouse, item, UOM, open quantity, date, link type, and whether the transaction is beyond the horizon.

An old sales order consumes supply

Confirm whether its status and plan category are included. Resolve the order through the proper cancel, complete, close, or back-order process. Do not exclude valid demand merely to improve dates.

Alternate warehouse gives an attractive date that cannot be used

Review warehouse access, branch and shipping policy, customer lead time, freight, carrier service, tax implications, order orchestration, item restrictions, and operational capacity.

Imported orders calculate differently from manual orders

Compare order type, warehouse, status, UOM, requested date, operation, item mapping, quantity, and any automatic shipment or purchase link. Build a paired control test.

Users treat ATP as a reservation

Correct the procedure and training. Add an allocation checkpoint and a warning in the work instruction. Track cases where calculated dates change because inventory was not allocated.

Users extend the horizon until a date appears

Return to the data and policy. A farther date is not more reliable merely because the system can see it. Require approval for horizon changes and evaluate inbound-date accuracy.

Safety stock is bypassed informally

Choose a governed exception path. Consider a separate order type only if it matches the business process and is tested. Do not encourage users to change item master data temporarily.

The order date and line dates disagree

Review all eligible lines and the shipping rule. The order-level date reflects when the full order can ship, while individual lines can be ready earlier.

The result changed after a patch or upgrade

Run the saved regression scenarios. Compare build numbers, enabled features, rules, item classes, order types, customizations, plan types, and source documents. Reopen the current Acumatica documentation before escalating.

Back to TOC

Available-to-Promise implementation checklist

Scope and policy

• [ ] Name the ATP business owner and technical owner.
• [ ] Define which customers, item families, warehouses, and order types are in scope.
• [ ] Decide whether safety stock is protected.
• [ ] Approve the ATP horizon using lead-time and date-quality evidence.
• [ ] Define how blank, late, or changing dates are handled.
• [ ] Define when a calculated date may be communicated externally.

Configuration

• [ ] Enable Available-to-Promise in a sandbox.
• [ ] Create ATP-type calculation rules.
• [ ] Document every included supply and demand category.
• [ ] Assign ATP rules to the correct item classes.
• [ ] Set order types to Cumulative with Look-Ahead where appropriate.
• [ ] Record horizon and safety-stock settings for each order type.
• [ ] Review custom order types and automation behaviors.

Master data and transactions

• [ ] Validate item class, stock status, UOMs, and warehouse defaults.
• [ ] Validate item-warehouse safety stock and lead-time inputs.
• [ ] Review warehouse-location availability flags.
• [ ] Correct overdue or missing purchase and transfer dates.
• [ ] Resolve abandoned on-hold orders and invalid back orders.
• [ ] Reconcile linked purchase-to-order, drop-ship, kit, and transfer documents.

Testing

• [ ] Test current stock, future supply, competing demand, and no-supply cases.
• [ ] Test the horizon boundary and both safety-stock settings.
• [ ] Test line-level and order-level calculations.
• [ ] Test alternate warehouses and multi-line orders.
• [ ] Test shipping rules and partial fulfillment.
• [ ] Test every documented line exclusion.
• [ ] Test all user roles.
• [ ] Test each integration source against a manual control order.
• [ ] Reconcile results to the calculation dialog and source documents.
• [ ] Save evidence for future regression testing.

Rollout and operations

• [ ] Train sales, customer service, purchasing, and warehouse teams.
• [ ] Separate ATP calculation from allocation and shipment steps.
• [ ] Define recalculation checkpoints.
• [ ] Define exception ownership and approval evidence.
• [ ] Verify reports, dashboards, and integrations that use the date.
• [ ] Monitor promise adherence, date changes, blanks, and overrides.
• [ ] Review supplier and warehouse data quality regularly.
• [ ] Revalidate after patches, upgrades, or configuration changes.

Back to TOC

Frequently Asked Questions

What is Available-to-Promise in Acumatica 2026 R2?

Available-to-Promise, or ATP, is a Distribution feature that calculates the earliest date on which the full open quantity of an eligible sales-order line can be covered in a selected warehouse. It can also calculate the date on which the complete order can ship in full. The result is based on a configured timeline of supply and demand within an ATP horizon.

Does ATP reserve inventory for the customer?

No. ATP calculates a date; it does not replace inventory allocation or shipment processing. If the business needs stock reserved, users must follow the applicable allocation workflow. A saved ATP date can change when other supply and demand documents change.

Why is Calculate ATP not visible on a sales order?

Confirm that the Available-to-Promise feature is enabled, the order type uses Cumulative with Look-Ahead, the order has an eligible status, and the line contains an eligible stock item whose item class has an ATP rule. The line must use the Issue operation, remain incomplete, not be configurable, and have no related unconfirmed shipment.

Why is the ATP Date blank?

The requested quantity may not be coverable within the configured ATP horizon. Review the line-level calculation, warehouse, quantity, safety stock, included supply and demand categories, document dates, and competing demand. A blank date can be a correct warning rather than a configuration error.

What is the difference between Available for Shipping and Available to Promise?

Available for Shipping is a current quantity after defined operational deductions, including shipped and allocated quantities and inventory in excluded locations. Available to Promise is a future date calculation. It processes configured supply and demand chronologically to find when the full quantity can be covered.

How does safety stock affect ATP?

When Include Safety Stock in ATP Calculation is selected for the order type, Acumatica subtracts safety stock from the available quantity before calculating the date. This protects the buffer from being promised through the ATP calculation and may move the result later or leave it blank inside the horizon.

What does the ATP horizon control?

The horizon is the number of calendar days from the current business date in which Acumatica searches for supply and demand transactions. Documents beyond the horizon are excluded. The Order Types form defaults the value to 90 days, but the organization should choose a horizon that matches credible lead times and date quality.

Can users calculate ATP for another warehouse?

Yes. The line-level calculation dialog lets a user change the warehouse and recalculate. Saving the dialog also updates the line's warehouse if it was changed. The organization should govern this choice because freight, branch, customer, tax, orchestration, and operational rules may make the earliest warehouse date unsuitable.

Does ATP work for configurable or non-stock items?

The documented sales-order ATP calculation applies to qualifying stock-item lines and excludes configurable lines. Non-stock items do not receive the inventory coverage calculation. Manufacturing organizations should evaluate the applicable Capable-to-Promise workflow for produced items where resource capacity matters.

Which documents are included in ATP?

The ATP calculation rule controls the plan categories. Depending on enabled features and selected checkboxes, the rule can include or deduct sales orders, back orders, allocations, issues, purchase orders, receipts, transfers, returns, kit documents, service demand, production supply and demand, and project-material plans. Review the actual rule and calculation dialog rather than assuming a fixed universal list.

How often should ATP be recalculated?

Recalculate after material changes to quantity, warehouse, order status, requested date, purchase or transfer timing, allocation, or other included supply and demand. At minimum, calculate during order review and again before communicating a customer commitment when the earlier result may be stale.

Can ATP dates be sent to an e-commerce or EDI system?

They can be integrated only through an intentional interface design. Define the outbound field, date meaning, timezone, recalculation trigger, blank-date handling, change notifications, error behavior, and approval policy. Do not assume that enabling ATP automatically publishes its result to an external channel.

Back to TOC

Sources

1. Acumatica 2026 R2 release announcement
2. Acumatica release news and 2026 R2 overview
3. Introducing Acumatica Cloud ERP 2026 R2
4. Sales Orders SO301000 form reference for 2026 R2
5. Order Types SO201000 form reference for 2026 R2
6. Item Classes IN201000 form reference for 2026 R2
7. Enable or Disable Features CS100000 form reference for 2026 R2
8. Availability Calculation Rules IN201500 form reference for 2026 R2
9. Inventory Allocation Details IN402000 form reference for 2026 R2
10. Capable-to-Promise general information
11. Biz-Tech Acumatica Distribution ERP guide
12. Biz-Tech guide to PDF order automation and inventory allocation

Available-to-Promise can improve order-date decisions when the calculation rule, item classes, order types, warehouses, safety stock, and document dates reflect real operating policy. The next practical step is to choose one item family and one order type, reproduce a small set of supply-and-demand scenarios in a sandbox, and reconcile every date before expanding the rollout. Biz-Tech Services can help with Acumatica 2026 R2 configuration, integration review, test design, and distribution-process optimization through the Biz-Tech support and consultation page.

Back to TOC

The post Available-to-Promise in Acumatica 2026 R2: Setup, Sales-Order Behavior, and Pitfalls appeared first on Biz-Tech Services.

The Biz-Tech Services ShipHero Acumatica Connector provides the controls needed to load and synchronize items and to decide what happens when a record is missing. This guide focuses on those documented item-level controls and marks the unsupported areas clearly.

What ShipHero Item Mapping in Acumatica Establishes

The Biz-Tech Services Acumatica ShipHero Connector uses the Inventory Details tab to load and display items from both systems. Load Acumatica Items displays the ERP items, Load Ship Hero Items displays the warehouse management system items, Sync Acumatica Items exports items to ShipHero, and Sync Ship Hero Items imports items into Acumatica.

When an imported ShipHero item does not exist in Acumatica, Import Item controls whether a new inventory record may be created. When that checkbox is selected, imported item type, item class, UOM, and warehouse ID become available as defaults. When it is not selected, the source says the connector does not create a new item and uses the configured Replace Missing Products default instead.

Warehouse Cross-Reference is part of the item synchronization path, but it maps warehouse values rather than item identifiers. The source says the connector creates or assigns the warehouse for an imported item according to this setup. It does not say that Warehouse Cross-Reference maps an SKU, Inventory ID, alias, or product code.

ShipHero Item Mapping at a Glance

Use this sequence to configure the documented item behavior without assuming an undocumented SKU rule.

1 Select the integration direction on Ship Hero Store because the available tabs and processing behavior change between Ship Hero to Acumatica and Acumatica to Ship Hero.

2 Configure Warehouse Cross-Reference for the warehouse values used during item synchronization and order import.

3 On Sync Info, decide whether Import Item should create a missing Acumatica item or whether the connector should use Replace Missing Products.

4 If Import Item is selected, set imported item type, item class, UOM, and warehouse ID as the defaults for a newly created item.

5 Open Inventory Details and use Load Ship Hero Items or Load Acumatica Items to review the records available for processing.

6 Run Sync Ship Hero Items to import selected ShipHero items or Sync Acumatica Items to export ERP items.

7 Open the Ship Hero Item inquiry to review item availability, connected vendors, bin transfers, and the result of Sync Ship Hero Item.

8 Treat the SKU, alias, duplicate, and precedence rules as unresolved until Biz-Tech Services supplies product-specific guidance because the manual does not define them.

Choose the Item Synchronization Direction

Ship Hero Store includes an Integration Option that determines the workflow direction. Ship Hero to Acumatica brings data from the warehouse management system into the ERP and exposes General Info, Import Info, Ship Via Cross Reference, Warehouse Cross Reference, Inventory Details, Sync Info, and Locations.

The Inventory Details actions show the documented item flow. Load Acumatica Items retrieves the ERP item list, and Load Ship Hero Items retrieves the ShipHero item list. Sync Acumatica Items sends ERP items to ShipHero. Sync Ship Hero Items brings ShipHero items into Acumatica. Purge deletes the items displayed on the Inventory Details table, while Sellect All, as written in the source, selects all displayed items.

The manual does not list Inventory Details grid columns or identify an SKU, product ID, inventory code, or line-level key on that tab. It also does not explain whether synchronization updates an existing record or creates a new one based on an SKU comparison. Confirm the visible fields in the installed customization before documenting a local matching procedure.

Configure Missing Item Creation and Item Class Defaults

Import Item is the documented switch for missing inventory records. Select it when the connector should allow a new item to be created during synchronization or order import. The following default fields then appear: imported item type, item class, UOM, and warehouse ID.

Item class is used as a default for new item creation. The source does not describe item class as a cross-reference, a match condition, or a way to resolve multiple records with the same external identifier. It also does not state whether any attributes or settings inherited from the class are required by the connector.

When Import Item is not selected, the manual says that the connector does not create a new item and sets a default item for each missing product. Replace Missing Products supplies that default item, and Warehouse ID supplies the warehouse value. The source also contains an awkward sentence saying it sets Replace Missing Products as the item name; it does not clarify whether this means the selected replacement item, the displayed line description, or another value.

These controls define how an unmapped or missing product can be handled during import, but they do not define the condition that makes a product missing. No rule is given for blank SKUs, unknown SKUs, duplicate SKUs, inactive items, stock versus non-stock items, or a ShipHero record whose code differs from the Acumatica Inventory ID.

Separate Warehouse Cross-References from Item Identity

Warehouse Cross-Reference is explicitly used by item synchronization and order import. Based on that setup, an imported order receives the mapped warehouse on the sales order, and an imported item receives or creates the warehouse associated with that mapping.

The Biz-Tech Services ShipHero Acumatica Integration also uses the mapped warehouses when locations are loaded. The Locations note states that locations are loaded for warehouses configured on Warehouse Cross-Reference. When Use Location Mapping is selected, a grid appears to map locations; otherwise, Sellable Location and Non-Sellable Location provide the documented defaults.

Ship Via Cross-Reference serves a different purpose. The Import Info settings expose Use Cross Ref for Ship Via and Use Cross Ref for Warehouse. Selecting these options shows the corresponding tabs so ShipHero values can be matched with Acumatica values. The manual does not provide an item cross-reference option or an SKU cross-reference tab.

Box Mapping and Reason Code Mapping are also named mapping features, but neither identifies an inventory item. Box Mapping pairs Acumatica Box ID with ShipHero Box name. Reason Code Mapping supports return orders. Keep these mappings separate from the unresolved item-identity question.

Validate Imported Items Vendor Data and Locations

When Sync Ship Hero Items imports an item, vendor information is also synchronized if the stock item has a vendor or vendors that have already been synchronized to ShipHero. The source does not state which vendor field is used for the connection or what happens when the vendor has not been synchronized.

The Ship Hero Item inquiry provides three review areas. Warehouse Details displays item availability. Vendors displays the vendor connected with the item in ShipHero. Bin Transfers displays transfers for the item. Update Item displays changes made to the ShipHero item, Sync Ship Hero Item synchronizes the item into Acumatica, and Update Warehouse In Ship Hero updates item quantity in ShipHero.

Location setup should be reviewed with the item. Load Acumatica Locations displays ERP locations, and Sync Acumatica Locations exports them to ShipHero. Load Ship Hero Locations displays warehouse-system locations. The documentation says only locations for warehouses configured on Warehouse Cross-Reference are loaded.

The manual supplies no screen IDs for Ship Hero Store, Inventory Details, Warehouse Cross-Reference, Locations, or Ship Hero Item. The only screen ID stated in the document is Customization Projects (SM204505), which is used for package installation and is not an item-mapping screen.

Apply the Documented Mapping Validation Rules

The source provides configuration dependencies rather than a formal SKU validation table.

1 Select a Ship Hero Store integration direction before expecting the related item and mapping tabs to appear.

2 Select Use Cross Ref for Warehouse before expecting Warehouse Cross-Reference to appear.

3 Configure the mapped warehouse because the setup is used for both item synchronization and order import.

4 Select Import Item before expecting imported item type, item class, UOM, and warehouse ID defaults to appear.

5 If Import Item is not selected, confirm Replace Missing Products and Warehouse ID before importing a product that may not exist.

6 Confirm that a vendor is already synchronized before expecting the vendor information of an imported stock item to synchronize with the item.

7 Configure Warehouse Cross-Reference before loading locations because the source limits loaded locations to configured warehouses.

The documentation does not provide error-message text, validation codes, duplicate handling, or a rejected-record inquiry for item synchronization. It does not say how a failed item appears on Inventory Details or whether Purge removes only the displayed staging records or affects data outside the table.

Document the SKU and Alias Rules the Manual Does Not Define

Despite the business need to map ShipHero SKUs, the source never names an SKU field. It does not say that ShipHero SKU equals Acumatica Inventory ID, Inventory CD, Alternate ID, or another field. It also does not show item-level mapping columns on Inventory Details or provide a sample product-to-item mapping.

No alias mechanism is documented. The manual does not identify customer part numbers, vendor part numbers, global trade item numbers, universal product codes, barcodes, alternate IDs, wildcard matching, or case-insensitive matching as valid connector keys. It does not define which identifier wins if multiple candidates exist.

Unmapped-record behavior is documented only through Import Item and Replace Missing Products. The source does not identify a holding queue, error log, notification, or correction screen for a product that cannot be matched or created. It also does not state whether a later successful match replaces an earlier replacement-product line.

A safe implementation record should therefore distinguish documented configuration from tested local behavior. Record the installed screen fields, the exact ShipHero value, the resulting Inventory ID, the Import Item state, the selected defaults, and the warehouse mapping observed in a controlled test. Do not present the observed key as a product guarantee unless it is confirmed by Biz-Tech Services.

Where to Check Your Work

The Biz-Tech Services ShipHero Acumatica Integrator exposes the documented item result in these locations.

1 Ship Hero Store: confirm Store Code, Integration Option, and the tabs displayed for the selected direction.

2 Import Info: confirm Use Cross Ref for Warehouse and Use Cross Ref for Ship Via when those mappings are required.

3 Warehouse Cross-Reference: compare the ShipHero warehouse value with the Acumatica warehouse value used during item synchronization and order import.

4 Sync Info: check Import Item, imported item type, item class, UOM, warehouse ID, Replace Missing Products, Export Price Type, and Export price Quantity.

5 Inventory Details: load both item lists, review the displayed records, and run only the synchronization direction intended for the test.

6 Ship Hero Item: review Warehouse Details, Vendors, and Bin Transfers, then use Update Item or Sync Ship Hero Item as documented.

7 Locations: confirm that the expected warehouses were mapped before loading locations, and review Use Location Mapping, Sellable Location, and Non-Sellable Location.

8 The resulting Acumatica inventory item and sales order line: compare the item, warehouse, UOM, and replacement-product outcome with the configured defaults. The manual does not provide a specific screen ID for this review.

ShipHero SKU and Inventory Item Mapping Frequently Asked Questions

Does the connector documentation say which Acumatica field matches a ShipHero SKU?

No. The manual documents item synchronization and missing-item settings but does not name a ShipHero SKU field or state that it matches Inventory ID, Inventory CD, Alternate ID, or another Acumatica field.

Can the connector create an inventory item that does not exist in Acumatica?

Yes, when Import Item is selected. The connector can create a new item using imported item type, item class, UOM, and warehouse ID as the documented defaults.

What happens when Import Item is not selected?

The source says the connector does not create the new item. It uses the default configured in Replace Missing Products and takes the warehouse from Warehouse ID.

Is item class used to match ShipHero products?

The manual only identifies item class as a default for new item creation. It does not define item class as an SKU match, alias, or cross-reference rule.

Does Warehouse Cross-Reference map ShipHero SKUs?

No SKU behavior is documented for that tab. It maps warehouse values used during item synchronization and order import, including the warehouse associated with an imported item.

Where can I review a synchronized ShipHero item?

Use Inventory Details to load and process item records, then use the Ship Hero Item inquiry to review Warehouse Details, Vendors, and Bin Transfers. The source provides no screen IDs for those locations.

Does the connector support aliases or alternate item identifiers?

The Biz-Tech Services Acumatica ShipHero Integration documentation does not define item aliases, alternate IDs, barcodes, customer part numbers, vendor part numbers, or wildcard matching. Obtain product-specific confirmation before building a mapping process around any of those identifiers.

How can I validate an SKU mapping when the manual does not define the key?

Run a controlled item synchronization and record the exact source value, resulting inventory item, Import Item setting, item defaults, replacement-product outcome, and warehouse mapping. Treat the result as environment-specific until the key is confirmed by Biz-Tech Services.

Work With the Biz-Tech Services ShipHero Connector

A reliable mapping design starts with the controls the manual actually documents: synchronization direction, missing-item handling, creation defaults, and warehouse mapping. The SKU key, aliases, matching precedence, and rejected-record workflow require product-specific confirmation.

If you need help confirming ShipHero item identifiers, testing missing-item behavior, or documenting a controlled SKU-mapping process, visit https://biz-techservices.com to work with the Biz-Tech Services Acumatica ShipHero Integrator.

The post How to Map ShipHero SKUs to Acumatica Inventory Items appeared first on Biz-Tech Services.

Slow Generic Inquiries in Acumatica are usually improved by reducing the work performed by the base inquiry before changing how the results look. Start with the business question, select only the required data sources and fields, join tables on the correct keys, filter early, limit unnecessary totals and rows, and test with representative data. Acumatica 2026 R2 grouped table views can make results easier to explore, but they use an existing Generic Inquiry as their data source and do not automatically correct an inefficient query.

This guide explains how to diagnose Acumatica Generic Inquiry performance without sacrificing the meaning of the report. It covers Generic Inquiry design, 2026 R2 grouped table views, dashboard refresh behavior, benchmarking, reconciliation, deployment controls, and the point at which a workload belongs in a different reporting architecture. The intended audience includes Acumatica administrators, functional consultants, report designers, developers, SQL specialists, finance leaders, operations managers, and quality assurance teams.

Table of Contents

Why Generic Inquiry performance is a business issue

How an Acumatica Generic Inquiry processes data

What changed with grouped table views in 2026 R2

Why grouped tables do not replace query optimization

Define the business question before editing the inquiry

Build a performance baseline that can be repeated

Recognize the main Generic Inquiry performance patterns

Choose the smallest correct set of data sources

Design table relations without multiplying records

Use conditions and parameters to reduce the working set

Control displayed rows and page size deliberately

Sort only when the result requires an order

Group and aggregate without changing the metric

Manage formulas and calculated fields carefully

Configure grouped table views for useful analysis

Improve dashboard performance at the consumption layer

Treat nested Generic Inquiries as dependencies

Prevent duplicate and missing results

Use a disciplined before and after test method

Worked test case for open sales orders

Worked test case for grouped accounts payable analysis

Worked test case for an executive dashboard

Reconcile performance changes with business totals

Deploy Generic Inquiry changes safely

Monitor performance after release

Know when a Generic Inquiry is the wrong tool

Generic Inquiry performance review checklist

Frequently Asked Questions

Sources

Why Generic Inquiry performance is a business issue

A slow inquiry is not merely an inconvenient screen. The same Generic Inquiry can feed a list, export, pivot table, dashboard widget, integration, OData request, AI feature, or user workflow. A design that performs adequately for one analyst can become expensive when it is placed on a dashboard opened by many users or refreshed throughout the day.

The business impact also depends on when the inquiry runs. A ten-second inquiry opened once during a monthly review may be tolerable. The same inquiry used by an order desk after every customer call can delay work. If several dashboard widgets rely on broad inquiries and refresh at short intervals, the cumulative load may affect users who are entering orders, releasing documents, or reviewing inventory.

Performance therefore needs an explicit service expectation. The team should identify who uses the inquiry, how often it runs, how current the data must be, how many rows users actually need, and what decision depends on the result. Without that context, optimization often removes useful detail or shifts work to another part of the system.

A sound performance review protects two outcomes at the same time:

1. The inquiry returns quickly enough for its operational purpose.
2. The result still represents the correct business population, grain, and calculation.

The second condition is essential. A fast inquiry that omits valid documents, duplicates amounts, or changes the definition of an open order is not optimized. It is wrong.

Back to TOC

How an Acumatica Generic Inquiry processes data

An Acumatica Generic Inquiry is a configurable data request built on data access classes, commonly called DACs. The designer selects data sources, defines relations, applies conditions and parameters, specifies grouping and sorting, and chooses fields for the result grid. Acumatica then generates the request needed to retrieve and present the data. The official Creation of a Generic Inquiry documentation describes this sequence and emphasizes that the design depends on the organization’s business needs.

It is useful to separate the work into four layers.

Business definition

This layer defines the question, population, grain, measures, and security. An inquiry may answer “Which sales orders are open” or “What is the total open order value by customer and week.” Those are different questions. They require different rows, fields, grouping, and validation.

Query definition

This layer includes DAC selection, relations, conditions, parameters, formulas, grouping, sorting, and limits. Most material performance problems begin here because these settings determine how much data must be joined, filtered, calculated, sorted, and returned.

Presentation definition

This layer controls how users see the result. In 2026 R2 it can be a table, pivot table, or grouped table view. Presentation can reduce visual clutter and help users reach the right level of detail, but it cannot make an overbroad or incorrectly joined base inquiry logically correct.

Consumption pattern

This layer covers dashboards, exports, OData consumers, automations, and repeated interactive use. The same query design creates different total load depending on refresh intervals, user count, filters, and concurrency.

The distinction prevents a common mistake: changing a widget or grouped view while leaving the expensive base request untouched. Diagnose each layer, then change the lowest layer that actually causes the problem.

Back to TOC

What changed with grouped table views in 2026 R2

Acumatica 2026 R2 adds grouped table views as a formal data representation for Generic Inquiry results. A grouped table organizes records into an expandable hierarchy and can show summarized information together with underlying detail. According to Acumatica’s Data Views General Information, the available representations are Table, Pivot Table, and Grouped Table.

The feature must be enabled through Grouped Table Views in Generic Inquiries on the Enable or Disable Features form, CS100000. Once enabled, users can create personal grouped views for inquiries they can access. Administrators can create shared views and can make an appropriate shared view the default for all users.

A grouped table can contain multiple group levels. Each level can have its own fields, sort order, aggregate values, and display settings. The details section can retain the underlying records, so a manager can start with a summary and expand a group when a total needs explanation. The official Grouped Table configuration guidance explains how to create and configure these views.

For example, an accounts payable inquiry can be grouped first by vendor and then by financial period. A group level can display total and average document amounts, while the details section retains individual bills and adjustments. Acumatica’s grouped table activity uses this pattern to demonstrate a shared default view.

Grouped views can improve usability in several ways:

• Users can begin with summaries instead of scanning a flat result set.
• Multiple analytical views can reuse one governed inquiry.
• The underlying details remain available for investigation.
• Administrators can standardize a shared view for a role or process.
• Personal views let individual users organize the same governed data without cloning the inquiry.

These are meaningful improvements, especially where teams previously created several near-duplicate inquiries to present the same facts at different levels.

Back to TOC

Why grouped tables do not replace query optimization

A grouped table is a view of one Generic Inquiry’s results. Acumatica states that each data view uses an existing Generic Inquiry as its data source and that the inquiry’s parameters and filters apply to every representation. That means the grouped table and the base inquiry must be evaluated together.

If the underlying inquiry joins unnecessary DACs, returns years of history, calculates expensive formulas for every row, or multiplies records through an incorrect relation, a grouped presentation does not remove that work by definition. It may make the output easier to read, but the query still needs to produce the source data required by the view.

The practical rule is simple:

Use grouped table views to improve how people explore a correct, appropriately scoped inquiry. Optimize the base Generic Inquiry to reduce unnecessary data work.

This distinction also protects the business meaning of the result. Moving a metric into a grouped view may change where aggregation occurs. A detail inquiry grouped for display is not always equivalent to an inquiry designed to return one row per business entity. If a dashboard needs only one total, it may be better to build a narrowly scoped source inquiry than to return a large detail population and aggregate it later.

Before adopting a grouped table as a performance change, answer four questions:

1. Does the base inquiry return fewer rows or perform fewer calculations after the change?
2. Does the grouped view merely collapse rows visually, or does it change the data request?
3. Are the same filters and parameters applied in both the baseline and revised tests?
4. Do totals and distinct business keys reconcile at every group level?

If the first answer is no, describe the grouped table as a usability improvement rather than a query optimization.

Back to TOC

Define the business question before editing the inquiry

The fastest useful Generic Inquiry is the smallest correct request for a defined decision. Performance work should therefore begin with a one-sentence business question, not with the Generic Inquiry screen.

Consider the difference between these requests:

• List all open sales order lines.
• Show open sales order value by customer.
• Show orders ready to ship today by warehouse.
• Count overdue shipments for an executive dashboard.

The first request needs line-level detail. The second needs a customer-level measure and may not need every line field. The third needs operational filters and warehouse data. The fourth may need only a narrow population and a count. Reusing one broad inquiry for all four tasks is convenient during prototyping but can be expensive and difficult to validate.

Document the following before changing the design:

• Population: Which records qualify and which must be excluded.
• Grain: What one result row represents.
• Measures: Which amounts, quantities, counts, dates, or statuses matter.
• Dimensions: Which fields users need for grouping, filtering, or explanation.
• Freshness: How current the result must be.
• Audience: Who can see the data and who owns its definition.
• Consumption: Screen, dashboard, export, OData, automation, or another use.
• Acceptance criteria: Required totals, sample records, and response-time target.

This brief is also the basis for reconciliation. If the grain is “one row per sales order,” the test must compare distinct orders, not only the number of result rows. If the measure is “open amount,” the team must define how holds, cancellations, partial shipments, tax, currency, and released documents affect the total.

Back to TOC

Build a performance baseline that can be repeated

An optimization claim is credible only when the baseline and revised inquiry are tested under comparable conditions. Capture the baseline before editing the inquiry, even when the problem appears obvious.

Use a test tenant or controlled nonproduction environment with representative data. Record the Acumatica version and build, enabled features, database or hosting context, inquiry identifier, filters, user role, and relevant customization packages. Performance observed on a small demonstration dataset cannot predict a production tenant with several years of transactions and concurrent users.

For each test scenario, record:

• Time from request to usable result.
• Number of rows returned.
• Distinct count of the primary business key.
• Key totals or aggregates.
• Selected parameter values and filters.
• Whether record counts and totals were enabled.
• Records per page and Select Top settings.
• Dashboard refresh or cache setting when applicable.
• First-run and repeated-run behavior.
• Any server, database, or application evidence available to the responsible technical team.

Run each scenario more than once. A single result may be influenced by caching, competing activity, or network conditions. For operational comparison, use the same sequence of tests and report the median together with a slower percentile such as the 95th percentile when the sample size is sufficient. These are measurement practices, not Acumatica performance guarantees.

The baseline should include at least one typical case and one legitimate heavy case. A date range covering the current week may represent daily work, while a full financial year may represent period-end analysis. Do not benchmark an artificially narrow filter and then claim that the inquiry is fast for all users.

Back to TOC

Recognize the main Generic Inquiry performance patterns

Most slow Generic Inquiries fall into one or more recurring patterns. Recognizing the pattern helps the team avoid random changes.

Broad population

The inquiry loads far more records than the user needs. Common signs include no required date parameter, an all-branches default, historical closed documents mixed with current exceptions, or a dashboard widget that queries the full table to show one number.

Row multiplication

The result contains duplicate business entities or unexpectedly high totals because a one-to-many relation is joined at the wrong grain. Adding another detail table can multiply existing detail rows. A cross join is especially dangerous because the result size is the number of rows in one source multiplied by the number in the other, as the Generic Inquiry form reference explains.

Expensive presentation work

The inquiry returns many columns, sorts a large population, calculates formulas, loads record counts and totals, or requests an excessive page size. Each operation may be reasonable alone but costly in combination.

Repeated consumption

An inquiry that is acceptable interactively becomes expensive when several widgets, users, or integrations run it repeatedly. Very short dashboard refresh intervals can turn a modest query into a continuous workload.

Incorrect aggregation

The inquiry groups at one level but includes fields or formulas that imply another. The system may need to calculate more than expected, and the output may be misleading even if it loads quickly.

Nested complexity

One Generic Inquiry uses another as a data source, which may itself depend on additional inquiries. Reuse can improve governance, but deep or broad dependency chains make the total work harder to see and test.

Environmental contention

The inquiry design may be sound, but performance changes during imports, releases, integrations, backups, or other heavy activity. Query optimization alone cannot resolve capacity or scheduling problems. The baseline must capture when the slowdown occurs.

Back to TOC

Choose the smallest correct set of data sources

Every data source should have a stated purpose. If the inquiry only needs fields from a sales order header, adding line, shipment, invoice, customer location, and inventory DACs creates work and changes the possible grain. Remove a data source only after confirming that it is not required for a condition, parameter, formula, security rule, navigation link, or result field.

Acumatica’s documentation recommends identifying the DACs and fields behind the relevant forms before creating an inquiry. The DAC Discovery guidance explains that users access database data through DACs and that the selected fields become result columns or inputs to the report design.

Use this review sequence:

1. Mark the parent business entity that defines one intended row.
2. List every output field and identify its source.
3. List every condition, parameter, formula, grouping field, and navigation field.
4. Remove fields that no consumer uses.
5. Identify data sources that remain only because of removed fields.
6. Retest the inquiry after each logically related change.

Selecting fewer result columns can improve network transfer and rendering, but the larger gain often comes from eliminating an unnecessary one-to-many source. If a field is needed only for drill-down, consider whether navigation to the source record can replace copying many descriptive columns into the result.

Do not select a base DAC solely because its name looks familiar. Inspect the form field, DAC schema, keys, and relationships. Acumatica documents that DAC key fields can be discovered through the schema browser and recommends key and foreign key fields for relations because they allow faster retrieval. See Discovery of Key Fields.

Back to TOC

Design table relations without multiplying records

Relations determine both performance and correctness. The designer must know the cardinality of each pair: one-to-one, one-to-many, or many-to-many. The order and type of joins also affect which records survive and how many rows the result contains.

Acumatica’s multiple data sources documentation explains that sources are paired as parent and child, and the sequence of pairs determines how the system builds the combined data. The Related Tables dialog can propose relationships, but the designer remains responsible for confirming that the relation matches the business question.

Verify complete keys

Many Acumatica documents use composite keys. Joining only on a reference number while ignoring document type, company, branch, or another key component can connect unrelated records. Use the full logical relationship required by the DACs and business process.

Choose the join type intentionally

An inner join keeps only records with a match in both sources. A left join keeps every parent record and adds matching child data when available. Changing an inner join to a left join can recover missing parents, but it can also introduce null child fields. Changing a left join to an inner join may reduce rows while silently excluding valid business records.

Count at the intended grain

Suppose 100 sales orders average five lines and each line has two related allocation records. A header-to-line-to-allocation result can contain approximately 1,000 rows before other relationships are added. Counting rows would not count orders. Summing a header amount across those rows could multiply the value. The correct design depends on whether the intended grain is order, line, or allocation.

Avoid cross joins unless the business case requires them

A cross join combines every row from one source with every row from another. Even small sources can create a large result. Cross joins should be treated as a deliberate analytical operation with a bounded dataset, not a shortcut for an unresolved relationship.

Validate optional relationships

When child data is optional, test parents with no child, one child, and multiple children. This reveals both missing rows and multiplication. Keep a small set of known business records for regression testing after every relation change.

Back to TOC

Use conditions and parameters to reduce the working set

Conditions and parameters are among the most effective ways to reduce unnecessary work, but they serve different purposes. A condition defines what the inquiry includes by default. A parameter lets the user supply a value in the selection area and can narrow the result for a particular task.

Acumatica’s condition configuration documentation shows how conditions combine fields, operators, values, parentheses, and And or Or logic. Treat the Boolean expression as code. A misplaced bracket or broad Or clause can change both performance and meaning.

Useful default conditions often include:

• Current or open status when the inquiry supports operational work.
• A bounded transaction date or financial period.
• A branch, company, warehouse, project, or customer scope appropriate to the audience.
• Exclusion of deleted, archived, voided, or completed records when those records do not serve the decision.
• A clear exception condition for dashboards designed for management by exception.

Parameters should reflect natural user decisions. A warehouse manager may choose warehouse and promised date. A controller may choose branch and financial period. Requiring a parameter can prevent accidental all-history requests, but it can also make an inquiry unusable for scheduled or integrated consumers. Confirm how every consumer supplies the parameter.

Avoid formulas around fields used for filtering when a direct comparison can express the same rule. A transformation applied to every candidate row may make the condition harder to evaluate efficiently. When date logic is needed, prefer bounded start and end values that preserve the intended time zone and business definition.

Test empty, default, typical, and extreme parameter values. A default that means “all” may defeat the performance objective. A default date based on the current day may be correct for one role and wrong for another. Record the default behavior in the inquiry’s documentation and test plan.

Back to TOC

Control displayed rows and page size deliberately

The Interface Options settings on the Generic Inquiry form include Select Top and Records per Page. They affect how many records the user receives and sees, but they should not be used to hide an undefined population.

Acumatica’s Number of Records Shown documentation states that Select Top limits the displayed result after the specified sort order is applied. It also warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance.

Use Select Top when the business question is genuinely about a ranked subset, such as the 50 oldest overdue shipments or the 25 largest open balances. Define an explicit sort that makes the subset deterministic. “Top 50” without a business order can return an unstable or meaningless selection.

Use Records per Page to support readable interaction. A larger page can reduce paging clicks but increases the amount rendered at once. Test the page size with the actual number and width of columns. A narrow inquiry with ten fields behaves differently from a result with dozens of wide calculated columns.

Acumatica 2026 R2 also exposes an option to disable record counts and totals. The form reference states that hiding the number of records or pages can make the associated inquiry load faster. This is appropriate when users do not need the count or footer totals for the decision. It is not appropriate when the count itself is the control being monitored.

Do not confuse display limits with data correctness. If a user exports data or a widget applies a separate aggregation, verify how the limit affects that consumer. Document any intentional truncation prominently enough that users do not treat a partial result as a complete population.

Back to TOC

Sort only when the result requires an order

Sorting is valuable when order conveys meaning, such as oldest first, largest variance first, or customer then document date. Sorting a large result by several fields also requires work, so each sort field should support a user task or a deterministic limit.

Acumatica’s Sorting and Grouping documentation explains that the Sort Order tab defines the default order and that user-defined sorting can override it. When no explicit sort is defined, Acumatica uses a default order and shows a warning in the tab.

Review sorting with these questions:

• Does the user need the order, or is it decorative?
• Does Select Top depend on this order?
• Can the same business order be expressed with fewer fields?
• Is a text formula being sorted where a native date or numeric field would be clearer?
• Does a dashboard widget apply its own order or display only an aggregate?

Remove redundant sorts, but keep the fields required to make a limited result stable. For example, sorting by requested date alone may leave many ties. Adding a document key as a final sort can make the result repeatable without changing the primary business order.

Back to TOC

Group and aggregate without changing the metric

Grouping can reduce a detail population to one row per business dimension, but only when the selected aggregate functions match the field types and the intended measure. Acumatica supports AVG, COUNT, MAX, MIN, SUM, and STRINGAGG in the Generic Inquiry grouping configuration. The official grouping guidance notes that numeric fields default to SUM and other fields default to MAX when no aggregate is selected, while calculated fields require deliberate aggregate choices.

Start by writing the metric in plain language. “Open order value by customer” requires a definition of open order value and one output group per customer. If header amounts repeat across joined lines, summing the header amount after the join is wrong. The correct source may be a line amount, an already aggregated source inquiry, or a design that preserves one header row.

Pay close attention to these cases:

• COUNT versus distinct business entities: A row count after a detail join may count lines or allocations rather than documents.
• SUM of repeated header fields: The same order total can repeat for each child row.
• AVG after uneven duplication: Customers with more detail rows may receive unintended weight.
• MAX used as a placeholder: MAX can select one value from a group without proving that all rows share that value.
• STRINGAGG growth: Concatenating many values can create large strings that are hard to use and expensive to render.
• Null behavior: Aggregate functions may ignore null values, which can affect counts and averages.

Create reconciliation totals at both the overall and group level. If the inquiry groups by branch and customer class, validate a few known branches, then compare the grand total to an independent source. Do not accept a grand total alone because errors in different groups can offset one another.

Back to TOC

Manage formulas and calculated fields carefully

Formulas make Generic Inquiries flexible, but they can add per-row work and create subtle differences between detail and grouped results. Every formula should have an owner, a business definition, a data type, and a test set.

Use native fields when they already represent the required value. Recalculating status labels, dates, or amounts through nested expressions can make the inquiry harder to maintain and may prevent straightforward filtering or grouping. When a formula is necessary, keep it as simple as the rule allows and avoid repeating the same expression across several result fields.

Test formula behavior for:

• Null values and empty strings.
• Zero denominators.
• Currency and unit conversions.
• Time zones and date boundaries.
• Negative values and credit documents.
• Rounding before and after aggregation.
• Text values stored differently from their displayed labels.
• Grouped results where the formula references a nonaggregated field.

Acumatica’s grouping documentation warns that the aggregate function must match the field type and that calculated columns need a manually selected aggregate because no single default works for every formula. A runtime error is visible; a logically wrong aggregate is more dangerous because it can look plausible.

If a formula is used only for display styling, determine whether the style is worth the cost on a large result. If it drives a condition or business decision, include it in the reconciliation evidence. Formula changes should be treated as calculation changes, not cosmetic edits.

Back to TOC

Configure grouped table views for useful analysis

A grouped table should reflect how users investigate a question. More hierarchy is not automatically better. Deep groups create extra navigation and can hide the level at which a total is defined.

Use this configuration sequence:

1. Select a base inquiry with a documented grain and validated totals.
2. Choose the first group that matches the user’s primary decision, such as vendor, customer, warehouse, project, or branch.
3. Add a second group only when it supports a common drill path, such as financial period within vendor.
4. Select aggregate fields that reconcile to the base inquiry.
5. Choose a meaningful sort within each group.
6. Decide which groups open expanded or collapsed based on typical result size.
7. Show only fields needed at each level.
8. Test personal, shared, and default behavior with appropriate roles.

The grouped view should not become a substitute for a clearly scoped base inquiry. If users always filter to the current month, put that requirement in a parameter or shared filter. If executives need only a total and an exception count, a dedicated summary inquiry may be more appropriate than a detailed grouped view.

When making a shared view the default for all users, consider whether every role interprets the groups the same way. A controller may start with branch and period, while an operations manager may start with warehouse and promised date. Separate views can reuse the same inquiry when the underlying data and security are genuinely shared.

Validate the view on the expected screen width and with long labels, empty groups, negative totals, and large groups. A technically correct hierarchy can still be slow to use if users must expand many nodes or scroll across unnecessary columns.

Back to TOC

Improve dashboard performance at the consumption layer

Dashboard performance depends on the source inquiry, the number of widgets, filters, parameters, refresh intervals, and user behavior. Acumatica’s Table Widgets documentation confirms that data table widgets display data collected by a Generic Inquiry. KPI widgets also select a source inquiry and aggregate a chosen field.

Start by inventorying every widget on the dashboard. Record its source inquiry, filter, parameters, displayed fields, record limit, aggregate function, and refresh setting. Two widgets that appear simple may each run a broad inquiry independently.

Match refresh intervals to business freshness

Acumatica allows widget caching and refresh intervals. The Widget Settings documentation explains that cached data is reused when it is newer than the configured interval. Selecting On Page Reload disables that reuse and updates data whenever the dashboard opens or refreshes.

Use the longest interval that still supports the decision. A weekly trend does not need a five-minute refresh. An order exception widget may need fresher data, but it should also use narrow conditions. Document the expected delay so users know whether the dashboard is current to five minutes, an hour, or a day.

Give each widget a bounded question

A scorecard should not rely on a detail inquiry that returns many unused columns. A table widget should have a reasonable record limit and should show only actionable rows. Shared filters and dashboard parameters can narrow data, but the source inquiry still needs a safe default.

Reduce simultaneous work

Remove duplicate widgets, consolidate overlapping metrics when the design remains understandable, and avoid placing every available chart on a home page. A dashboard used by hundreds of users creates a different workload from a specialist dashboard opened occasionally.

Test the dashboard as a dashboard

An inquiry tested alone may perform differently when several widgets load together. Measure the complete page, observe which widget finishes last, and test with the relevant user role. Include cache-expired and cache-valid scenarios.

For a broader view of how reporting, dashboards, and AI features fit into the current platform, see Biz-Tech’s Acumatica Agentic ERP 2026 guide. Treat each feature as a consumer of governed data, not as a reason to expose a broad inquiry without controls.

Back to TOC

Treat nested Generic Inquiries as dependencies

Acumatica 2026 R2 allows a Generic Inquiry to use another Generic Inquiry as a data source. The official Generic Inquiry as Data Source documentation states that multiple simple inquiries can be combined into a more complex request and that the system prevents circular parent relationships.

This reuse can improve governance. A validated base inquiry can define a shared fact set, and several parent inquiries can apply different presentation or business rules. It can also hide complexity if the dependency chain is not documented.

For every nested source, record:

• Source inquiry title and identifier.
• Intended grain and population.
• Parameters and defaults.
• Fields exposed to the parent.
• Parent inquiries and widgets that depend on it.
• Owner and last validation date.
• Expected performance range for representative inputs.

Avoid nesting merely to avoid understanding the underlying DACs. Each level should provide a stable, reusable contract. If a child inquiry returns more fields or rows than the parent needs, consider a narrower source. If several parents independently apply the same corrective filters, the shared source definition may be incomplete.

When changing a source inquiry, test every known parent. Acumatica can warn about deleted source fields, but it cannot determine whether a retained field now has a different business meaning. Dependency testing must cover totals, sample records, filters, navigation, exports, and performance.

Back to TOC

Prevent duplicate and missing results

Performance tuning often changes relations and filters, the same settings that determine which records appear. Build correctness tests before making those changes.

Use a controlled sample that includes:

• A parent with no child record.
• A parent with one child.
• A parent with several children.
• Two document types that share a reference number pattern.
• Records across branches or companies where relevant.
• A null optional value.
• A closed or voided record near the filter boundary.
• A record exactly on the start and end date.
• A negative or credit amount.
• A record the test user cannot access.

Then validate several dimensions of the output.

Population completeness

Confirm that qualifying business entities appear and excluded entities do not. Compare known document keys, not only row counts.

Grain integrity

Confirm what one row represents after each join. If the intended grain is order line, use a composite key that identifies the line. Check for duplicate keys.

Measure reconciliation

Compare counts, quantities, and amounts with a trusted form, report, or independently validated query. State whether the source uses document currency, base currency, signed amounts, or another convention.

Security behavior

Run the inquiry as representative roles. An administrator’s correct result does not prove that a restricted user sees the right population or that the inquiry avoids exposing sensitive fields.

Boundary behavior

Test dates, periods, statuses, and amounts exactly at the condition boundary. A greater-than condition and a greater-than-or-equal condition can produce different operational lists.

Do not accept a faster result until these tests pass. Performance and correctness are one release decision.

Back to TOC

Use a disciplined before and after test method

The purpose of before-and-after testing is to isolate the effect of a specific design change while preserving the business result. Use one change set at a time whenever practical.

Prepare the test

Copy the inquiry rather than overwriting the only working version. Freeze the test data or record the data snapshot time. Use the same user, role, parameters, browser path, and environment. Identify any integrations or batch processes that could distort the run.

Run the baseline

Execute the original inquiry several times for each scenario. Record usable response time, row count, distinct key count, totals, and errors. For dashboard cases, record complete dashboard load time and individual widget behavior where visible.

Apply one coherent change

Examples include correcting one relation, adding a required date parameter, removing an unused detail DAC, changing an excessive page size, disabling unused counts, or adjusting one widget refresh interval. Avoid combining many unrelated changes in the first comparison because the team will not know which change mattered.

Run the revised test

Repeat the same sequence. Compare the distribution of times, not only the fastest run. Confirm that the result has the same intended population and measures. If the change intentionally alters the population, document the new definition and validate it as a functional change.

Decide with evidence

Promote the change only when it improves the relevant user experience or resource use and passes reconciliation. A small speed difference may not justify added complexity. A major improvement that changes totals requires correction before release.

Maintain a compact evidence record containing the inquiry versions, settings changed, test cases, results, reconciliation, reviewer names, and approval. This makes later regression diagnosis much faster.

Back to TOC

Worked test case for open sales orders

This test case illustrates the method without claiming a universal performance result. Actual timing must come from the customer’s build, dataset, hosting model, customizations, security role, and workload.

Business question

Which open sales orders require attention for a selected warehouse and promised-date range, with one row per sales order line?

Common slow design

The inquiry defaults to all warehouses and all dates. It joins order header, order line, allocation, shipment, customer, address, and inventory sources even though the operational list needs only order, line, customer name, warehouse, promised date, quantity, and status. Several wide description fields are returned. The result is sorted by customer name, order date, inventory description, and reference number. Records per Page is set to a very large value.

Review plan

First, confirm the required grain is one order line. Then identify which joins create multiple rows per line. Make warehouse and date-range parameters part of the normal workflow. Remove sources and columns that do not support the list, filters, navigation, or security. Keep a deterministic sort based on promised date and document keys. Select a usable page size.

Correctness controls

Use known orders with no allocation, one allocation, and multiple allocations. Confirm that the line quantity is not multiplied. Reconcile distinct order and line keys. Check orders exactly on the date boundaries and orders with partial shipment activity. Compare the population to the source sales order form using the same definition of open.

Performance evidence

Run the original and revised inquiries with the same warehouse and date range. Record repeated response times, returned rows, distinct line keys, and totals. Then test the legitimate heavy case, such as a broader date range used during backlog review. The revised inquiry is accepted only if both cases remain correct and the operational case improves meaningfully.

Expected design lesson

The likely improvement comes from scoping the population and removing unnecessary relational work, not from hiding rows after retrieval. The exact benefit cannot be promised before testing.

Back to TOC

Worked test case for grouped accounts payable analysis

This scenario uses the 2026 R2 grouped table capability for its intended analytical purpose.

Business question

Show accounts payable documents by vendor and financial period, with total and average document amount at the period level and access to individual documents for explanation.

Base inquiry requirements

The base inquiry must return the correct AP document population with a documented grain. It should include the vendor, financial period, document key, document date, status, and amount fields required by the grouped view. Conditions should define whether released, open, voided, and adjustment documents are included.

Grouped view design

Create a grouped table view with vendor as the first level and financial period as the second. Add total amount and average amount at the period level. Keep document details available beneath the group. Choose whether groups open collapsed based on the typical vendor and period count. An administrator may create a shared default view if this hierarchy suits the audience.

Performance interpretation

The grouped view may help users reach summaries without scanning a flat list. Do not state that it makes the base query faster unless the measured request changes. Compare the base table and grouped view with the same parameters, and separately measure user task completion if usability is the objective.

Correctness controls

Reconcile each vendor-period total to the base inquiry and to an accepted AP source. Check vendors with credit adjustments, multiple currencies, null optional fields, and no activity in a period. Confirm that the average uses the intended document population and that null values are handled as expected.

Expected design lesson

Grouped table views can replace cloned presentation inquiries when one validated source supports several useful hierarchies. Their strongest benefit is governed exploration, while query efficiency still depends on the base inquiry.

Back to TOC

Worked test case for an executive dashboard

Executive dashboards often reveal consumption problems because several broad queries run together.

Business question

Show the count and value of overdue shipments, the value of open orders, and a short list of the oldest exceptions, with data fresh enough for daily management.

Common slow design

Three widgets use broad detail inquiries. Each loads on every page refresh. The scorecards aggregate columns from inquiries that return many unused fields. The exception table shows hundreds of rows even though leaders act on the oldest twenty. The dashboard is set as a home page for a large user group.

Review plan

Define a narrow source for each distinct metric or a carefully governed shared source when the population is identical. Apply default exception conditions. Use only the fields required for the widget. Give the table an intentional record limit and sort. Set refresh intervals according to business freshness rather than defaulting every widget to On Page Reload.

Correctness controls

Reconcile the scorecard counts and values to the underlying exception population. Verify that the table’s top records correspond to the defined order. Test with the roles that receive the dashboard. Confirm the timestamp and refresh expectation are understandable to users.

Performance evidence

Measure the dashboard after cached data has expired and again while the cache remains valid. Record full page readiness and identify any widget that lags. Test concurrent access appropriate to the user population when the environment and responsible technical team support it.

Expected design lesson

Dashboard performance is a system of query scope, widget count, caching, refresh intervals, and audience size. Improving only the visual layout does not address repeated database work.

Back to TOC

Reconcile performance changes with business totals

Reconciliation turns a technical optimization into an auditable business change. It should be designed before the test, not added after a discrepancy appears.

Use three levels of reconciliation.

Record reconciliation

Compare known business keys between original, revised, and trusted sources. Explain every missing or added key. For large populations, use counts and automated comparisons, then inspect a risk-based sample.

Aggregate reconciliation

Compare counts, quantities, and amounts overall and by meaningful groups. Useful groups include branch, warehouse, status, period, document type, customer class, and currency. Group-level comparison identifies offsetting errors that a grand total can hide.

Rule reconciliation

Verify that each condition implements the written business rule. A status label may combine several stored values. A date may represent order date, requested date, shipment date, or financial period. A balance may be in document or base currency. Document the rule beside the test evidence.

Set acceptance tolerances deliberately. Record counts and discrete document totals usually require exact agreement. Calculated currency amounts may require a defined rounding tolerance. Response times require a target range and sample size rather than one perfect run.

When totals differ, stop and classify the difference:

• The original inquiry was wrong and the revised result corrects it.
• The revised inquiry introduced a defect.
• The business definition changed.
• The test data changed between runs.
• Security or parameters differed.
• Rounding, null handling, or aggregation changed.

Do not average these causes into a vague explanation. Resolve and approve the specific difference.

Back to TOC

Deploy Generic Inquiry changes safely

Generic Inquiries can become infrastructure. They may support dashboards, exports, integration endpoints, automation, AI features, and user navigation. A change that looks local can affect several consumers.

Use a controlled deployment process:

1. Copy or export the current inquiry and dependent views before modification.
2. Record the inquiry identifier, site map location, access rights, and consumers.
3. Make and test the change in a nonproduction environment with representative data.
4. Run functional, reconciliation, performance, and security tests.
5. Review dependent dashboards, pivot tables, grouped views, OData consumers, and nested inquiries.
6. Schedule the release when rollback and observation are practical.
7. Recheck parameters, filters, roles, shared views, and default views after deployment.
8. Monitor response time, errors, totals, and user-reported differences.

Acumatica’s 2026 R2 release introduces wider platform changes beyond grouped tables. If the inquiry work is part of an upgrade, coordinate it with the broader readiness plan in Biz-Tech’s Acumatica 2026 R2 Upgrade Guide. Version, feature enablement, Modern UI behavior, customizations, and connected products can all affect the test scope.

Avoid editing a predefined inquiry directly when a copy is the safer governance choice. Use clear naming and descriptions so users can distinguish the supported version. Retire obsolete copies after confirming no consumer depends on them; otherwise, near-duplicate inquiries create confusion and inconsistent totals.

Back to TOC

Monitor performance after release

Performance changes as transaction volume, retention, user count, dashboards, and integrations grow. A passing implementation test is not permanent evidence.

Create a small monitoring record for important inquiries:

• Inquiry owner and business owner.
• Purpose and intended grain.
• Major consumers.
• Representative parameter scenarios.
• Expected row-count range.
• Expected response-time range.
• Key reconciliation totals.
• Last test date and Acumatica build.
• Known seasonal or period-end load.

Review the inquiry after upgrades, large data migrations, new customizations, dashboard changes, or material growth in transaction volume. Also review it when users compensate for slowness by exporting data, widening default filters, duplicating inquiries, or building spreadsheets. Those workarounds often signal that the existing design no longer supports the decision.

Track performance at the user task level. A query may become slightly faster while the user needs more manual filters or additional screens. Measure time to a usable answer, not only server response. For dashboards, include cache behavior and the number of widgets. For exports, include row volume and downstream processing.

Keep freshness honest. Update the article, inquiry documentation, and test evidence when behavior changes; do not change dates merely to imply current validation.

Back to TOC

Know when a Generic Inquiry is the wrong tool

Generic Inquiries are well suited to operational lists, governed exploration, dashboard sources, exports, navigation, and many integration or automation scenarios. They are not the best architecture for every analytical workload.

Consider another approach when the requirement involves:

• Very large historical datasets scanned repeatedly.
• Complex transformations across many fact tables.
• Heavy concurrency that competes with transactional processing.
• Long-running trend analysis with stable periodic snapshots.
• A semantic model shared across many external BI reports.
• Calculations that require extensive preprocessing.
• Regulatory reporting that needs a fixed, formally controlled output.
• A dashboard that needs data at a different refresh and storage pattern from live transactions.

Possible alternatives include a dedicated summary inquiry, a pivot table, an Acumatica report, Analytical Report Manager for the appropriate financial use, an external BI model, or a governed data warehouse. The correct choice depends on the required grain, latency, volume, auditability, and user interaction.

Do not move a workload merely because it is slow. First determine whether the inquiry is poorly scoped. Conversely, do not keep adding conditions and indexes to force an operational query tool to serve a warehouse-scale analytical problem.

Biz-Tech’s overview of Acumatica Cloud ERP reporting and dashboards provides broader context for selecting reporting surfaces. Where teams need help turning business questions into governed inquiries, Biz-Tech’s AI Analyst describes a review-first approach to creating and refining Generic Inquiries and related reporting assets. Product suitability, availability, licensing, and implementation scope should be confirmed for the customer’s environment.

Back to TOC

Generic Inquiry performance review checklist

Use this checklist before approving a new or revised inquiry.

Business definition

• The question, audience, decision, and freshness requirement are written.
• The intended population and one-row grain are explicit.
• Counts, amounts, quantities, and dates have documented meanings.
• The business owner approves the definition.

Data design

• Every DAC and result field has a purpose.
• Relations use the complete logical keys.
• Join types preserve the intended population.
• One-to-many relationships do not duplicate measures.
• Cross joins are absent unless explicitly required and bounded.
• Nested inquiry dependencies are documented.

Filtering and limits

• Default conditions match the operational population.
• Parameters prevent accidental broad requests where appropriate.
• Empty and extreme parameter values are tested.
• Select Top has a deterministic sort and a business reason.
• Records per Page is usable and not excessive.
• Record counts and totals are enabled only when needed.

Calculation and presentation

• Aggregate functions match field types and metric definitions.
• Formulas handle nulls, zero, dates, currency, units, and rounding.
• Grouped views reflect the user’s drill path.
• The grouped view is not described as a query improvement without evidence.
• Dashboard widgets use appropriate fields, filters, limits, and refresh intervals.

Testing

• The baseline and revised tests use the same environment and inputs.
• Typical and legitimate heavy scenarios are included.
• Repeated timings are recorded.
• Row counts, distinct keys, group totals, and grand totals reconcile.
• Representative user roles are tested.
• Dependent dashboards, exports, nested inquiries, and integrations are checked.

Release and monitoring

• The original design can be restored.
• Owners and dependent consumers are recorded.
• The deployment window allows observation and rollback.
• Post-release response time and totals are reviewed.
• The next review trigger is defined.

Back to TOC

Frequently Asked Questions

What is an Acumatica Generic Inquiry

An Acumatica Generic Inquiry is a configurable way to retrieve and display ERP data through data access classes without writing a conventional report for every question. Designers choose data sources, relations, conditions, parameters, grouping, sorting, and result fields on the Generic Inquiry form, SM208000. The inquiry can also serve dashboards, exports, navigation, integrations, and other governed consumers.

Why is my Acumatica Generic Inquiry slow

The most common causes are an overbroad population, unnecessary data sources, incomplete or multiplying joins, excessive formulas or sorting, very large page settings, record counts that are not needed, nested inquiry complexity, or repeated dashboard refreshes. Measure the inquiry with representative parameters and data before changing it because environmental contention can produce similar symptoms.

Do grouped table views make Generic Inquiries faster in 2026 R2

Not automatically. A grouped table organizes the results of an existing Generic Inquiry into a hierarchy with summaries and details. It can improve analysis and reduce the need for cloned presentation inquiries, but the underlying query still needs correct sources, joins, filters, calculations, and limits. Claim a speed improvement only after comparable testing.

How should I optimize joins in an Acumatica Generic Inquiry

Begin with the intended row grain, then use the complete key and foreign key fields that represent each relationship. Confirm whether each join is one-to-one or one-to-many and choose inner or outer behavior intentionally. Test parents with zero, one, and multiple children, then reconcile distinct business keys and totals to detect multiplication or missing records.

Should I use Select Top to improve Generic Inquiry performance

Use Select Top when the business question genuinely requires a ranked subset and define an explicit sort that makes the result deterministic. Do not use it to conceal an undefined or incorrect population. Verify how the limit affects exports, dashboard aggregations, and other consumers, and make any intentional truncation clear to users.

Can Records per Page be set very high

It can, but Acumatica warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance. Choose a page size that supports the user’s task and test it with the actual number and width of columns. A large page is not a substitute for useful filters or parameters.

How do dashboard refresh settings affect Generic Inquiry load

Dashboard widgets can cache results for a configured interval. If On Page Reload is selected, the widget updates whenever the dashboard opens or refreshes. Frequent refreshes across many users and widgets can repeatedly execute source inquiries. Match each interval to the business freshness requirement and test the complete dashboard after cached data expires.

How do I test a Generic Inquiry optimization

Copy the inquiry, record the environment and parameters, run the original several times, and capture response time, rows, distinct keys, and totals. Apply one coherent change, repeat the same tests, and reconcile the output. Include both typical and legitimate heavy cases. Do not publish a fixed improvement percentage from another tenant’s dataset.

How can I prevent duplicate totals in grouped results

Define the metric and row grain before grouping. Check whether header values repeat across joined detail rows, use the appropriate source field and aggregate, and compare distinct document keys. Reconcile totals by several business dimensions, not only at the grand-total level, because errors in separate groups can offset each other.

When should I replace a Generic Inquiry with another reporting tool

Consider another architecture when the workload repeatedly scans very large history, requires complex transformations, supports heavy analytical concurrency, or needs a governed semantic model and periodic snapshots. First correct any avoidable query-design problems. Then compare a summary inquiry, pivot, formal report, external BI model, or data warehouse against the required volume, latency, auditability, and user experience.

Back to TOC

Sources

1. Acumatica 2026 R2 Reporting Tools Guide
2. Creation of a Generic Inquiry General Information
3. Generic Inquiry Form Reference SM208000
4. Data Views General Information
5. Data Views Creating and Configuring Grouped Tables
6. Modification of Inquiry Results The Number of Records Shown
7. Data from Multiple Data Sources General Information
8. Data from Multiple Data Sources Discovery of Key Fields
9. Sorting and Grouping General Information
10. Widget Settings General Information
11. Specific Widgets Table Widgets
12. Specific Widgets KPI Widgets

Biz-Tech Services can help Acumatica teams review slow Generic Inquiries, validate joins and totals, tune dashboard consumption, and choose the appropriate reporting architecture. A reporting performance review should begin with representative data, documented business definitions, and measurable acceptance criteria rather than a promised universal speed increase.

Back to TOC

The post Faster Generic Inquiries in Acumatica 2026 R2: Grouped Tables, Query Design, and Dashboard Performance appeared first on Biz-Tech Services.

The Biz-Tech Services Amazon Acumatica Connector gives administrators a choice between mapping an Amazon item to an existing inventory record and allowing a new record to be created during import. This article focuses on those documented item and SKU controls, the behavior of unmapped items, the product lookup actions, and the limited error information available during order import.

What Amazon SKU Mapping Does in Acumatica

The Biz-Tech Services Acumatica Amazon Connector uses item mapping to associate an Amazon product identifier with an inventory record. The Amazon guide names two related work areas on the Amazon Store screen: Cross-Reference, which matches external and internal values for selected entities, and Inventory Details, where a new Amazon SKU is mapped and existing SKU assignments can be changed.

The guide also describes Import Item. When this checkbox is selected and an order contains a product that does not yet exist in the ERP, the connector imports the new product information and generates an Inventory ID based on the SKU. When Import Item is not selected, the documentation says an integration error occurs for a product that does not exist.

These controls establish the documented mapping boundary. The manual does not define a general alias engine, item-class default, or external-ID hierarchy. It describes Amazon Value, Acumatica Value, SKU, ASIN, SELLERSKU, and Inventory ID, but it does not specify matching precedence among them.

Map Amazon SKUs to Acumatica Inventory IDs Step by Step

Use the following documented controls to prepare item matching. The source does not supply one end-to-end numbered workflow, so each step below stays within the functions it explicitly assigns to the Amazon Store settings.

1 Open the Amazon Store record for the store whose Amazon products need to be matched

2 In Cross-Reference Options, select Items so the item entity is available in the Cross-Reference Field list

3 In Cross-Reference, select the item entity in Field and enter the Amazon Value and corresponding Acumatica Value

4 In Inventory Details, create the mapping required for a new Amazon SKU or review the SKU assigned to an existing Acumatica item

5 Decide whether Import Item should create product information for Amazon items that do not yet exist in Acumatica

6 If order imports should populate Inventory Details, select Insert Item in Inventory Details Tab

7 Use Get Product by ASIN or Get Product by SELLERSKU to retrieve and display the Amazon item in Inventory Details

8 For Fulfillment by Amazon products, use Load FBA Products to display store products and Sync From Amazon on a loaded item when an Acumatica item must be created from its SKU

9 Import a controlled Amazon order and review the order line or import error before applying the setup to a larger group of orders

How Import Item Handles an Unmapped Amazon Product

Import Item determines what the connector does when Amazon supplies product information that does not exist in the ERP. With the checkbox selected, the connector imports the new product information. The Inventory Details note adds that order import generates an Acumatica Inventory ID based on the SKU.

With Import Item cleared, the guide says an integration error occurs. It does not provide the exact error text, identify a separate queue for unmapped items, or state whether the order is partly imported. It also does not say whether the error can be resolved directly from the order grid or requires a new mapping on the Amazon Store screen.

Send Email Notifications for Errors can send notifications about Order IDs that have errors. On the Amazon Orders screen, an error message can be displayed for an order, and the import grid can show a red cross with more information on hover. The guide also points users to Tools and Trace for additional error details, but it does not tie a named message specifically to an unmapped SKU.

How Amazon and Acumatica Values Are Cross Referenced

The Biz-Tech Services Amazon Acumatica Integration includes cross-reference functionality for Items, Payments, and Ship Via. Cross-Reference Options selects which external and internal entities should be matched. Only selected entities appear in the Field drop-down on Cross-Reference.

For each selected entity, Field identifies what is being matched. Amazon Value specifies the external value, and Acumatica Value specifies the corresponding internal value. These are the exact field labels documented for general cross-references. The source does not show a completed item example or explicitly state whether the value displayed for Items is the Inventory ID.

The Cross-Reference settings and Inventory Details both participate in product setup, but the guide does not explain their precedence or whether they store the same relationship. Do not assume that an item entered in one area automatically appears in the other without confirming the result in the installed connector.

How Inventory Details Maintains Amazon SKUs

The Amazon Store Inventory Details tab is the documented location for creating a mapping for a new Amazon SKU. The guide also says that an existing item’s SKU can be changed in Inventory Details and imported without creating a new Acumatica item. This gives the setup a documented maintenance path as well as an initial creation path.

Insert Item in Inventory Details Tab controls whether items retrieved during order import are placed in the Amazon Store’s Inventory Details tab. The guide does not say whether this action creates a complete mapping, creates a pending record, or only displays the Amazon product for review.

When an item already exists on the Stock Item screen, Import Item does not update its description. Instead, the Sales Order line description is set to the Amazon item title. During order import, the connector also uses the Amazon item price rather than the mapped Acumatica item price. Description and price therefore do not establish or change the SKU-to-Inventory-ID relationship described here.

Amazon Product Lookup and FBA Item Creation

Inventory Details includes two documented lookup actions. Get Product by ASIN retrieves and displays an Amazon item by Amazon Standard Identification Number, or ASIN. Get Product by SELLERSKU retrieves and displays the product by its seller SKU. The guide does not state which identifier wins if the values identify different products.

For Fulfillment by Amazon, Load FBA Products loads and displays all Amazon products in the store. After a loaded FBA item is selected, Sync From Amazon creates the local item through the product SKU. The source also says FBA products are loaded through API requests and mapped with local inventory, but it does not provide the mapping fields used by that API process.

The manual does not state whether the FBA action applies the same Inventory Details mapping used for Fulfillment by Merchant orders. It also does not define duplicate detection when an Inventory ID already exists for a similar SKU.

Validation and Mapping Exceptions for Amazon Items

The documented validation evidence appears during order processing rather than as a dedicated item-mapping validation screen. Users can view an Amazon order before import. If an error appears, the Amazon Orders screen displays an error message intended to indicate what must be corrected and in which system.

During import, a line-level error appears on the corresponding order row. Hovering over the red cross shows additional information, and Tools and Trace provides another diagnostic location. These controls are documented for order errors in general. The guide does not identify an Inventory ID validation button, a mapping status field, or an item-specific error catalog.

Import Item provides the only explicit rule for a missing product: create the product information when selected, or encounter an integration error when it is not selected. No rule is supplied for blank SKUs, duplicate SKUs, different letter case, leading zeros, inactive Inventory IDs, or stock versus non-stock items.

Mapping Features Not Defined in the Amazon Guide

The guide does not describe item classes, item-class defaults, alternate SKU aliases, wildcard matching, SKU normalization, units of measure for SKU matching, or an unmapped-item inquiry. It does not show whether the generated Inventory ID is identical to the Amazon SKU or transformed to meet local numbering rules.

The source also does not explain how Inventory Details interacts with the general Cross-Reference table, what value uniquely identifies an existing item during an SKU change, or how conflicts are handled when Amazon Value, ASIN, and SELLERSKU point to different records. Those are implementation questions, not documented connector behaviors.

Where to Check Your Amazon SKU Mapping

The Biz-Tech Services Amazon Acumatica Integrator exposes the following documented places to review item setup and import results.

1 On Amazon Store, confirm the Store Code for the store whose products are being mapped

2 In Cross-Reference Options, confirm that Items is selected as an entity to be matched

3 In Cross-Reference, review Field, Amazon Value, and Acumatica Value

4 In Inventory Details, review the Amazon SKU and its existing Acumatica item assignment

5 In the Import Settings area, confirm the intended status of Import Item and Insert Item in Inventory Details Tab

6 Use Get Product by ASIN or Get Product by SELLERSKU to verify that the intended Amazon product is displayed

7 On Amazon Orders, view the order and inspect any displayed error message before import

8 In the import grid, hover over a red cross for additional error information and use Tools and Trace when more detail is needed

9 On the resulting Sales Order, confirm the Inventory ID, Amazon item title in the line description, and Amazon item price

Amazon SKU and Inventory ID Mapping Frequently Asked Questions

Where do I map a new Amazon SKU in Acumatica?

Create the mapping in the Inventory Details tab of the Amazon Store. The guide identifies this tab as the location required to upload a new Amazon item SKU.

What happens when an Amazon item does not exist in Acumatica?

When Import Item is selected, the connector imports the new product information and can generate an Inventory ID based on the SKU. If it is not selected, the guide says an integration error occurs.

Can an existing Amazon SKU be changed without creating a new item?

Yes. The documentation says the SKU can be changed for an existing item in Amazon Store Inventory Details and imported without creating a new Acumatica item.

How does the Amazon item cross reference work?

The Biz-Tech Services Acumatica Amazon Integration uses Cross-Reference Options to select entities and uses Field, Amazon Value, and Acumatica Value to define the match. The guide does not show a completed item record or explain its relationship to Inventory Details.

Can I find an Amazon item by ASIN or seller SKU?

Yes. Inventory Details provides Get Product by ASIN and Get Product by SELLERSKU. Both actions retrieve and display the Amazon product using the selected identifier.

Does item mapping use the Acumatica price or Amazon price?

The guide states that order import uses the Amazon item’s price rather than the mapped Acumatica item’s price.

Can Amazon SKUs be mapped by Acumatica item class?

The source does not document item-class mapping, item-class defaults, or alias rules. It documents Inventory Details and value-based cross-references.

Where can I see an Amazon item mapping error?

Review the Amazon Orders screen and the import grid. An error can appear for the order, a red cross can expose more information on hover, and Tools and Trace can provide additional details. No item-specific error list is included in the guide.

Work With Biz Tech Services on Amazon Item Mapping

Amazon item setup in Acumatica depends on a documented choice: match the Amazon value and SKU to an existing item, or enable Import Item so a missing product can be created from the SKU. Inventory Details, Cross-Reference, and the order-import error displays provide the available control points.

If your team needs help reviewing Amazon SKU mappings and Inventory ID behavior, the Biz-Tech Services Acumatica Amazon Integrator can support your connector implementation. Visit https://biz-techservices.com to contact Biz-Tech Services or schedule a personalized demonstration.

The post How to Map Amazon SKUs to Acumatica Inventory IDs appeared first on Biz-Tech Services.

A five-layer diagnostic sequence for measurable Acumatica Modern UI troubleshooting.

When Acumatica Modern UI feels slow after an upgrade, do not begin by tuning SQL, disabling customizations, or blaming the browser. First reproduce one business task, determine whether the slowdown affects one user, one screen, or the whole site, and compare browser timing with Acumatica Request Profiler data. That sequence separates client and network delay from application-server, Generic Inquiry, customization, and database causes.

The key is to diagnose a transaction rather than a feeling. “The system is slow” cannot be tested. “Opening Sales Orders as the warehouse supervisor takes 11 seconds on the first load and 8 seconds on a warm repeat, while other users complete it in 3 seconds” gives the team a screen, role, browser, data state, timing, and comparison point.

This guide provides a repeatable diagnostic sequence for Acumatica 2026 R1 and 2026 R2 environments. Test every conclusion against the exact build, database, customizations, roles, and data volumes used by your organization. Community reports can help identify questions to investigate, but they do not establish the cause in your tenant.

What counts as an Acumatica Modern UI performance problem?

An Acumatica Modern UI performance problem is a repeatable delay in a defined user task, request, inquiry, or process compared with an accepted baseline. The delay may come from the browser, network, application server, database, Generic Inquiry design, customization code, automation, or the number of interactions required to finish the task.

That last distinction matters. A page can return quickly while users still need more clicks or pointer movement than before. Conversely, a workflow can feel familiar while a server request, SQL statement, or integration call is taking too long. Measure both technical response time and task completion time when the complaint concerns productivity.

Acumatica’s official troubleshooting guide begins with the same scope distinction: either the whole site is slow or a particular process is slow. It then moves through basic causes, application-versus-database time, server configuration, database checks, additional evidence collection, and support escalation. [1]

Start with four classification questions

Before collecting a large trace, answer four questions:

1. What exact action is slow? Name the screen, action, record, filters, and expected result.

2. How wide is the impact? One user, one role, one location, one browser, one screen, or the whole site?

3. When does it happen? First load only, every repetition, certain data volumes, a scheduled period, or under concurrency?

4. What changed? Acumatica build, browser, customization package, Generic Inquiry, database, infrastructure, integration, role, or data volume?

Run the same transaction at least three times. Record the first result separately because cold browser assets, application caches, database caches, or freshly started services can make the first run different from warm repeats. Use the same record and filters where possible, and do not compare an administrator’s broad access with a production role unless role differences are part of the test.

The five-layer diagnostic sequence

1. Reproduce the user task and capture browser evidence

Open the browser’s developer tools before reproducing the issue. On the Network panel, preserve the log, capture the slow action, and note the request with the longest elapsed time. Record whether the wait is primarily before the request starts, during connection and transfer, or while waiting for the server response. Acumatica’s Modern UI uses web technologies and request-based communication that browser development tools can inspect. [2]

Repeat in another supported browser or a clean browser profile. If the problem occurs only in one profile, examine extensions, cached assets, local storage, security software, and browser policy. If it occurs only from one location, compare latency, VPN path, proxy, DNS, packet loss, and bandwidth. Acumatica’s official first-step guidance explicitly recommends comparing browsers and physical locations before moving deeper into the stack. [1]

Do not stop when clearing cache appears to help once. Retest the same task after the browser and server are warm. A cache reset can remove stale assets, but it can also create a slower first load and hide an intermittent problem.

2. Compare browser time with Acumatica Request Profiler

Use Request Profiler (SM205070) to determine whether Acumatica spent the time on the server. For a particular process, open Settings > Profiler, start logging, reproduce only the target transaction, stop logging, and export the profile. The exported ZIP can include URL requests, SQL activity, exceptions, warnings, errors, and stack details needed for analysis or support. [3]

Compare three values:

Request Profiler has default thresholds for automatic monitoring, including 20 seconds for certain screen, Generic Inquiry, and report requests and 60 seconds for other requests. Those values are logging defaults, not promises of acceptable performance. Your baseline must reflect the business task and environment. [3]

3. Isolate Generic Inquiry and customization cost

If the slow screen, selector, dashboard, AI data source, or export depends on a Generic Inquiry, reproduce it with the exact role, filters, parameters, sorting, and row volume. A GI that is quick for a narrow test may become expensive when a condition is removed, a calculated field is added, a join multiplies rows, or a user exports the complete result.

Capture the inquiry name, parameters, returned row count, total browser time, Request Profiler server time, and SQL time. Then test one controlled change at a time. Narrow the date range, remove a nonessential calculated field, simplify sorting, or replace a broad join only in a sandbox. Keep the result set logically equivalent before calling the change an optimization.

For a suspected customization, compare the same action before and after unpublishing the specific project in a safe environment. Acumatica’s troubleshooting guidance recommends profiling the action without the suspected project, publishing it again, repeating the same action, and comparing results. [1] A clean-system test does not prove that every customization is faulty; it identifies whether the measured cost changes when a defined package is present.

Check more than custom business logic. Modern UI customization problems can involve client-side code, generated files, build errors, stale assets, screen definitions, or API calls. Review browser console errors and the customization build output alongside server traces. If a customization calls an external service, time that dependency separately so a slow remote response is not mislabeled as database latency.

4. Investigate database and environment causes

When SQL consumes a material part of the slow request, capture the exact query context before changing indexes. Review blocking, long-running statements, execution plans, resource pressure, storage latency, database growth, statistics, and maintenance history. Acumatica’s official sequence includes SQL Server configuration and reports or the corresponding MySQL checks after application-server analysis. [1]

Also inspect the environment around the transaction:

• running processes and automation schedules;
• System Monitor activity and unusually long jobs;
• application-pool memory and recent recycling;
• CPU, memory, disk latency, and database-server pressure;
• antivirus or endpoint scanning on application paths;
• license or concurrency conditions where relevant;
• integrations or imports running during the same period.

Correlate timestamps. A request that slows at 10:00 every morning may coincide with automation, backups, reporting, virus scanning, or an integration batch. Evidence from different clocks is hard to compare, so record the time zone and ensure application, database, monitoring, and workstation clocks are aligned.

5. Decide whether to optimize, patch, or escalate

Optimize when the evidence identifies a repeatable design cost that your team owns: an overbroad GI, an inefficient customization, unnecessary external calls, a poorly scheduled process, or an environment bottleneck. Make one change, rerun the same test, and record both the performance difference and functional result.

Patch when the behavior matches a documented defect for the exact Acumatica build and the release guidance identifies a corrected build. Validate the patch in a production-like sandbox with the same workflow, role, data, and customizations. “A newer build exists” is not enough evidence by itself.

Escalate when the problem is reproducible but the available evidence does not isolate an owned component, or when the trace points to platform behavior that requires Acumatica Support. Submit a focused case with the build, deployment model, timestamps, screen ID, steps, role, browser, profile export, logs, data scope, business impact, recent changes, comparisons, and tests already completed. This follows Acumatica’s documented sequence: collect Request Profiler and log evidence before opening the support case. [1] [3]

The first five measurements to capture

If time is limited, collect these five measurements before changing anything:

1. Business-task duration: start-to-finish time for one named task, including the record and filters used.

2. Browser request duration: the slowest relevant request from the Network panel, plus a HAR file when permitted by security policy.

3. Request Profiler server and SQL time: captured during the same reproduction window.

4. Scope comparison: same task from another supported browser, user or role, and location.

5. Environment context: build number, customization packages, dataset size or row count, concurrent jobs, and timestamp.

Together, these measurements prevent three common mistakes: treating a local browser issue as a database problem, tuning SQL for time spent in application or external code, and escalating without a reproducible transaction.

Acumatica performance evidence worksheet

Use one row per controlled test. Attach the exported files separately rather than pasting sensitive data into the worksheet.

Sanitize customer names, personal data, credentials, tokens, and business-sensitive values before sharing evidence outside the authorized team. First-chance exception logging and other verbose diagnostics should be enabled only for the short period needed because the output can grow quickly. [1]

Build a reliable performance baseline before troubleshooting

A performance baseline is a documented range for a repeatable business task under known conditions. It is more useful than a single target such as “every screen must load in two seconds” because different Acumatica actions perform different amounts of work. Opening a maintained customer record, calculating a large inquiry, releasing a batch, and exporting thousands of rows should not be evaluated as if they were the same transaction.

Begin with ten to twenty tasks that represent the work people depend on most. Include the actions that affect cash, fulfillment, production, customer service, purchasing, project billing, and financial close. For each task, record the screen ID, role, data volume, record state, filter set, browser, location, build, and number of concurrent users or processes. A useful baseline is specific enough that another analyst can reproduce it without asking what the original tester meant.

Measure the full task from the user’s perspective and the important requests inside it. Total task time shows whether the employee can complete the work efficiently. Browser and Request Profiler timings show which technical layer contributed to the wait. Retain both because an improvement in one request may not reduce the number of steps, and a shorter task may hide an expensive background call.

Use a small series rather than one run. A practical starting point is one cold run followed by at least three warm runs. Record every value instead of keeping only the fastest result. The median warm time describes the typical experience better than a best-case number, while the slowest valid run helps reveal intermittent blocking, network variation, or competing jobs. Do not combine failed tests, different records, or changed filters into the same comparison.

Define the acceptable range with the process owner. The threshold should reflect the business consequence of the delay, the normal data volume, the frequency of the action, and the technical work involved. A two-second increase on an action performed hundreds of times per day can matter more than a longer delay on a monthly report. The baseline therefore connects technology measurements to operational cost.

Acumatica performance baseline: A useful baseline is a versioned record of how long a defined business task and its principal requests take under repeatable conditions. It must identify the build, role, data, client, environment, timing method, and acceptable range. Without those controls, a before-and-after comparison can describe different work rather than a real performance change.

Diagnose by scope before diagnosing by technology

Scope is the fastest way to reduce the number of plausible causes. Ask how many users, screens, processes, locations, and time periods are affected. The answers do not prove a cause, but they determine the next comparison that will produce the most information.

One user is affected

When one user is affected and peers with the same role can repeat the task normally, compare the endpoint first. Check the browser version and profile, extensions, cached assets, local storage, endpoint protection, device resource pressure, display or accessibility tools, VPN state, and network route. Then compare the user’s role, preferences, branch, company, and saved filters with a working peer.

Do not assume that “one user” means “one computer.” Have the user sign in on a known-good device when policy permits, and have a comparison user test the affected device. This two-way test separates user configuration from endpoint configuration more cleanly than reinstalling software or changing several settings at once.

One screen or action is affected

When the rest of the site performs normally, focus on the dependencies of that transaction. Identify its Generic Inquiries, selectors, dashboards, reports, customization code, external calls, attachments, automation steps, and database queries. Capture Request Profiler data for only that action so unrelated requests do not obscure the trace.

Use a neighboring transaction as a control. If Sales Orders is slow, compare another screen that uses the same customer and inventory data but not the same customization. If an inquiry is slow, compare a narrower filter and a known-simple inquiry under the same role. The control helps identify whether the issue follows the data, the screen design, or the environment.

One location is affected

When users in one office, warehouse, or remote network are affected, compare connection setup and request timing. Record round-trip latency, VPN or proxy use, packet loss, DNS behavior, and whether large static assets or API responses are delayed. A browser HAR file can show whether time accumulates before the server responds or during transfer.

Avoid treating a successful ping as proof that the application path is healthy. Acumatica traffic may pass through gateways, inspection services, load balancers, or identity components that a simple network test does not exercise. Compare the actual browser transaction from affected and unaffected locations.

The whole site is affected

When many users and unrelated screens slow at the same time, widen the evidence window. Review application-server resources, application-pool behavior, database pressure, blocking, storage latency, running processes, scheduled automation, integrations, backups, scanning, and license or concurrency conditions where applicable. Acumatica’s official troubleshooting sequence specifically separates overall-site performance from a slow individual process because the likely evidence and corrective actions differ. [1]

The problem appears only at certain times

Time-bound issues often correlate with other workloads. Map the slowdown against automation schedules, imports, exports, backups, maintenance, reporting, integration bursts, end-of-period activity, and user concurrency. Use a shared time zone and synchronized clocks. The strongest evidence is a repeated correlation between the slow transaction and a measured competing workload, followed by a controlled schedule or resource change that removes the effect.

Read browser evidence without misdiagnosing the server

The browser Network panel is most valuable when it is used to answer a precise question: where did the elapsed time accumulate for the request associated with the slow action? Preserve the log, reproduce one transaction, and identify the request or sequence that aligns with the user’s wait. Record the request name or URL pattern, method, status, start time, duration, response size, and timing phases.

A long wait before a request is sent can indicate browser queuing, client-side work, connection limits, or another blocking resource. A long connection phase can point toward DNS, proxy, TLS, VPN, routing, or network instability. A long wait for the first response byte is consistent with time spent beyond the browser, but it does not by itself distinguish application code, SQL, an external dependency, or server capacity. A long content download can reflect response size or transfer conditions.

Use the browser Console as supporting evidence. Repeated exceptions, failed resource loads, blocked requests, or customization errors may explain a stalled interface even when the backend request is reasonable. Capture the exact message, timestamp, source, and action that produced it. A console warning unrelated to the tested transaction is not automatically the cause.

HAR files can contain URLs, parameters, record identifiers, headers, cookies, or other sensitive information. Follow the organization’s data-handling policy before exporting or sharing them. Remove credentials and sensitive values, retain an unmodified copy only in an approved location when required, and tell the recipient what was sanitized.

Compare like with like. Use the same browser cache condition, record, role, and request sequence for the affected and control tests. If one test is the first visit after clearing cache and the other is a warm repeat, the comparison does not isolate the variable you intended to test.

Browser time versus Acumatica server time: Browser elapsed time includes work outside the Acumatica server, while Request Profiler server time measures processing recorded by Acumatica. When browser time is much higher than profiler time, investigate the client and delivery path. When profiler time explains most of the browser wait, inspect application, customization, external dependency, and SQL evidence inside the server trace.

Use Request Profiler as a controlled experiment

Request Profiler is not merely a place to collect a large log. It is a tool for connecting a user action to server time, SQL time, memory, exceptions, and trace details. The clearest profile contains the smallest practical set of activity that reproduces the issue.

Before starting logging, prepare the target screen and the exact record or filter. Note the local time and the tester. Start the profiler, perform the action once, stop logging promptly, and export the result. Avoid navigating through unrelated screens during the capture. If the slow behavior requires a sequence, document every step so the recipient can match the profile entries to the user’s actions.

Interpret totals in context. Server time that is high with little SQL time directs attention to application logic, customization code, serialization, external calls, or resource pressure. SQL time that closely tracks server time directs attention to the generated query, blocking, plan, data distribution, and database resources. Exceptions and warnings may reveal a repeated fallback or retry, but they still need to be matched to the transaction.

Memory figures can help compare two versions of the same action. A large difference does not establish a leak on its own; it identifies a transaction that deserves a longer observation or code review. Likewise, one expensive request does not explain a whole-site complaint unless its timing and concurrency align with the broader impact.

Acumatica documents automatic monitoring thresholds in Request Profiler, including defaults for certain screen, Generic Inquiry, report, and other requests. Use those thresholds to understand what the profiler records automatically, not as universal service-level targets. [3] A frequently repeated four-second action may be operationally significant even if it does not cross an automatic logging threshold.

Run A/B comparisons with only one intentional difference:

1. Capture the task on the current build and package set.

2. Change one variable in a sandbox, such as the suspected customization, GI revision, browser path, or schedule.

3. Repeat the same record, role, filters, cache condition, and repetition method.

4. Compare user time, browser time, server time, SQL time, memory, result correctness, and any exceptions.

5. Restore or retain the change according to the test plan, then document the conclusion and next owner.

If several variables change together, the test may show improvement without explaining it. That makes the result difficult to reproduce and risky to promote into production.

Troubleshoot Generic Inquiry performance methodically

Generic Inquiries are frequently reused across screens, dashboards, exports, integrations, AI tools, and operational reporting. A design that appears in one place can therefore influence several user experiences. Troubleshooting should protect the business meaning of the inquiry while reducing unnecessary work.

Start by documenting what the GI is supposed to return. Identify the business grain: one row per sales order, line, shipment, customer, inventory item, or another defined entity. If joins create more rows than the business grain allows, the inquiry may process and return duplicate combinations even when users see a familiar result after grouping.

Review joins and conditions together. A correct relationship with an incomplete join condition can multiply rows. A filter applied after a broad join can make the database assemble a much larger intermediate result than the final grid suggests. Calculated fields, subqueries, aggregation, grouping, and sorting can add work, especially when the result covers a long period or many branches.

Test the GI with the production role rather than only an administrator. Security scope and accessible companies, branches, customers, or records can change both the result and the generated work. Record parameters and saved filters because two users can appear to open the same inquiry while requesting different datasets.

Pay attention to selectors and dashboards. A selector may execute while a user enters data, so a moderate delay repeated many times becomes disruptive. A dashboard can issue several inquiries at once, making its total load a concurrency problem rather than a single-query problem. Isolate each component before optimizing the combined page.

For exports, distinguish grid display from full dataset retrieval. The visible page may load a limited result while an export requests far more rows, columns, formatting, or calculated values. Record both the displayed row count and the exported row count.

Use the following sequence in a sandbox:

1. Confirm the required business grain and columns.

2. Reproduce with the exact role, parameters, filters, sorting, and data range.

3. Record browser, server, and SQL time plus returned row count.

4. Check joins for unintended multiplication and filters for unnecessary breadth.

5. Remove one nonessential column, calculation, sort, group, or join at a time.

6. Compare timing and validate totals, distinct keys, and sample records.

7. Test every consumer that depends on the inquiry before publishing the revision.

Slow Generic Inquiry diagnosis: A slow GI should be evaluated by business grain, joins, conditions, calculations, sorting, security scope, parameters, and returned volume. The safe optimization is the smallest design change that reduces measured work while preserving record counts, totals, keys, navigation, security, and downstream consumers.

Isolate Modern UI customization and integration effects

Customization troubleshooting should identify a package, component, or call path rather than classify all custom code as the problem. Begin with the dependency map for the slow task: screen extension, graph extension, event handler, client-side code, API call, external service, custom inquiry, automation, and any overridden behavior.

Check publication and build evidence after the upgrade. A customization can publish successfully while still performing unnecessary work at runtime. Conversely, a client-side build error, stale generated asset, or browser exception can impair the interface before the server transaction begins. Review both the customization build output and the browser evidence.

When safe, compare the same task with the suspected project unpublished and republished in a sandbox. Keep every other relevant condition constant. Acumatica’s performance troubleshooting guidance describes this comparison as a way to identify customization involvement. [1] The result should be framed precisely: “server time decreased when package X was absent” is evidence; “all customization is slow” is not.

If several projects depend on one another, test a supported package set. Do not create an artificial environment that cannot execute the transaction correctly. Record dependencies, publication order, build output, and functional differences. A faster test that skips required business logic is not an acceptable optimization.

Time external dependencies independently. A customization may call a tax provider, carrier, commerce platform, document service, or internal API. Capture the start, finish, outcome, timeout, and retry behavior of that call. If Acumatica waits for a remote response, database tuning will not remove the delay. Consider whether the interaction must be synchronous, but treat architecture changes as a separate design decision with business and recovery implications.

Review repeated work. Code that queries or recalculates once per line, field event, or grid refresh can scale poorly as document size grows. Compare a small and large document while holding other variables constant. A sharply increasing curve is more informative than a single slow example.

Validate behavior after every performance change. Confirm field defaults, totals, taxes, discounts, inventory allocation, approvals, releases, notes, attachments, integrations, and audit expectations that the customization affects. Performance is one acceptance dimension; the transaction must remain correct and supportable.

Investigate SQL without jumping directly to indexes

SQL evidence should begin with the query and its operating context. Identify the Acumatica action, profiler entry, parameters, duration, reads where available, wait or blocking condition, execution plan, data scale, and competing activity. This prevents a database change from being based on an isolated statement copied without the application conditions that produced it.

Blocking and resource pressure can make a normally efficient query appear slow. Check whether the statement was waiting on another transaction, storage, memory, CPU, or a concurrent maintenance operation. Correlate the database timeline with the Acumatica and browser timestamps. A plan captured after the event may not reflect the plan or parameter values used during the slow execution.

Review data distribution and statistics. An upgrade can coincide with data growth, changed filters, new workflows, or maintenance differences even when the underlying query text is familiar. A plan that works for a narrow parameter may perform poorly for a broad one. Record the actual business parameters before testing an alternative.

Do not add an index solely because a tool suggests it. Evaluate write cost, storage, overlap with existing indexes, maintenance, upgrade support, and whether the query comes from a customization or a standard process. A targeted GI or code change may reduce more work with less long-term cost. Database changes should follow the organization’s Acumatica support and change-control practices.

For overall-site issues, examine server configuration and health in the order described by the official guide. Acumatica’s troubleshooting sequence includes the distinction between application-server and database-server time, followed by server and database checks and then additional evidence collection. [1] This order reduces the risk of tuning the database when most of the elapsed time occurs elsewhere.

Retest with the same workload after any change. Compare not only duration but also reads, CPU, blocking, result counts, and the effect on concurrent transactions. An improvement for one query that degrades order entry, imports, or release processing is not a successful system-level fix.

Account for post-upgrade conditions that distort results

The period immediately after an upgrade can produce measurements that do not represent steady-state operation. Application services may have restarted, caches may be cold, browser assets may have changed, database plans may be refreshed, and scheduled jobs may be catching up. Users may also be learning new navigation, which affects task time independently of server performance.

Separate stabilization observations into technical response and human execution. Measure the request sequence, and also watch a trained user complete the entire task. If requests are fast but the task takes longer, investigate layout, focus order, keyboard use, saved views, filters, and the number of interactions. If the same steps remain but requests are slower, continue with browser, profiler, customization, and database evidence.

Verify the exact build and package set. A statement about “2026 R1” or “2026 R2” is too broad for support or regression work because maintenance builds and customization revisions can differ. Record the complete Acumatica build, browser version, package versions, deployment topology, database version, and date of the test.

Warm the environment in a controlled way before accepting a baseline. Run the selected tasks once, then measure the defined warm series. Keep cold-start results as a separate operational measure if restarts or scale-out events matter to the business. Do not discard cold behavior; label it correctly.

Confirm background recovery. Integrations, automation schedules, search indexes, reporting extracts, or other processes may resume after an upgrade and compete for resources. Record queue depth and completion state. A slowdown caused by temporary backlog requires a different response from a repeatable screen defect.

Compare with the pre-upgrade environment only when the data and test method are comparable. A refreshed sandbox with a larger database, different integrations, fewer server resources, or different user concurrency cannot provide a clean version comparison. Document unavoidable differences and avoid claiming that the release caused the full measured gap.

The Acumatica 2026 R2 Upgrade Guide provides the broader readiness and stabilization framework. The Modern UI Migration Readiness guide helps teams identify complete role-based tasks so the performance test covers more than opening a screen.

Prepare an escalation package that support can use immediately

A strong escalation package allows another technical team to reproduce the issue, understand its business impact, and inspect the same evidence without beginning with basic discovery. Keep it focused enough to review and complete enough to act on.

Start with a one-paragraph summary. Name the environment, full build, affected task, scope, expected behavior, observed behavior, and business consequence. Include the first observed date and whether the issue began after a known change. Avoid conclusions that the evidence has not established.

Provide exact reproduction steps. State the screen ID, role, record or sanitized equivalent, filter values, buttons or actions, expected result, observed time, repetition count, and frequency. Explain whether the first run differs from warm repeats. If production data cannot be shared, describe the minimum data characteristics needed to reproduce the workload.

Attach a timeline using one time zone. Include the browser capture time, profiler session, application log interval, database observation, and any concurrent job. This lets support align events that were recorded by different systems.

Summarize comparisons already completed:

• affected and unaffected user;
• affected and unaffected location;
• supported browsers or clean profile;
• cold and warm run;
• customization present and absent in a sandbox;
• narrow and broad data range;
• normal and affected time window;
• current and comparison build when valid.

List the result of each comparison, including tests that rejected a hypothesis. This prevents repeated work and shows which variables are still open. Attach the Request Profiler export, sanitized HAR when allowed, relevant logs, screenshots, build and package inventory, monitoring graphs, and database evidence. Do not attach an entire unrestricted log archive when a focused interval will answer the question.

Close with the assistance requested. Ask whether support should confirm a known defect, interpret a trace, recommend a corrected build, review platform behavior, or advise on the next diagnostic step. A precise request is easier to route than “please fix performance.”

Minimum Acumatica support evidence: Provide the full build, deployment model, business impact, screen ID, exact steps, role, record and filters, timestamps, browser timing, Request Profiler export, relevant logs, package inventory, comparisons performed, and a clear request. Sanitize sensitive data while preserving the technical relationships needed for reproduction.

How to prevent performance regressions after the fix

Turn the confirmed transaction into a regression test. Store the screen, role, filters, representative record, row count, cold or warm condition, expected result, and acceptable range. Run it after Acumatica builds, browser changes, GI revisions, customization releases, and infrastructure work.

Include high-volume and exception paths, not only a blank screen or a small demo record. For the broader upgrade process, the Acumatica 2026 R2 Upgrade Guide explains how to build performance checks into sandbox validation and stabilization. If your organization is still moving custom screens and workflows, use the Modern UI Migration Readiness guide to inventory the role-based tasks that need coverage.

The goal is a small, trusted baseline rather than a single universal threshold. A sales-order screen, a 200,000-row inquiry export, and a batch release have different purposes. Each needs a business owner, representative data, and an agreed measurement.

Frequently asked questions

Why is Acumatica Modern UI slow only on the first load?

The first load may include browser assets, application initialization, and cold caches that later runs reuse. Record the cold result separately, then repeat the same action on a warm session. If only the first load is slow, inspect static-asset delivery, cache behavior, browser policy, and application startup rather than averaging the first and later runs together.

How do I tell whether Acumatica or the network is slow?

Compare the browser’s elapsed request time with Request Profiler server time for the same action. A long browser request with low server time points toward the client, network, proxy, or endpoint path. High server time means the delay is within application processing, SQL, customization code, an external dependency, or server capacity.

Can a Generic Inquiry make Modern UI feel slow?

Yes. Joins, calculated fields, filters, sorting, security scope, returned row volume, and exports can increase the work behind a Generic Inquiry. Test the exact role and parameters, capture row count and profiler timings, then change one element in a sandbox while verifying that the business result remains correct.

Should I clear the browser cache after an Acumatica upgrade?

Clearing stale browser assets can be a valid controlled test, especially after UI or customization changes, but it is not a complete diagnosis. Record the result, distinguish the next cold load from warm repeats, and confirm whether the improvement persists. If the issue returns, capture browser and server evidence instead of repeating cache clearing as the only remedy.

When should I open an Acumatica Support case?

Open a case when you can reproduce the issue but cannot isolate an owned component, when evidence points to platform behavior, or when a documented defect may apply. Include the exact build, steps, timestamps, screen ID, role, browser, profiler export, relevant logs, comparisons, and business impact so support can begin with evidence rather than request basic reproduction details.

Get a focused Acumatica performance diagnostic

Biz-Tech Services can help reproduce a slow Acumatica transaction, separate browser, network, application, customization, Generic Inquiry, and database causes, and prepare an evidence package for remediation or support. Explore Biz-Tech Services Acumatica consulting and support or contact the team to request a performance diagnostic for your exact build and workflow.

Sources

1. Acumatica 2026 R2 System Administration Guide: Troubleshooting Performance

2. Acumatica: A Modern User Interface for a New Technology Era, Part I

3. Acumatica 2026 R2 System Administration Guide: Request Profiler

4. Acumatica 2025 R1 Modern UI overview

5. Acumatica Community: How is 26R1 Modern UI performing for you? (directional user reports; verify in your own environment)

The post Acumatica Modern UI Performance Troubleshooting After an Upgrade appeared first on Biz-Tech Services.

The Biz-Tech Services Shopify Acumatica Connector also separates identity mapping from field mapping. The Shopify Inventory tab handles product and item synchronization, Inventory Mapping connects ERP properties to Shopify fields and metafields, and the template and matrix item workflow represents Shopify products and variants. This article stays focused on those product, variant, SKU, cross-reference, item-class, and validation decisions rather than repeating connection setup, order import, or quantity synchronization.

What Shopify Product and Variant Mapping Does

The Biz-Tech Services Acumatica Shopify Connector provides documented paths for resolving item identity and synchronizing product data. When Sync from Shopify runs on the Shopify Inventory tab, the connector takes the Shopify item SKU and creates an Acumatica Inventory ID. When an order import encounters an item that does not exist, the Import Item setting determines whether a new inventory item may be created.

Field mapping is configured separately on the Inventory Mapping tab. That tab connects Acumatica attributes, item currency settings, and user-defined fields with Shopify fields. It also supports Shopify metafields at the product or variant level. A product or variant can therefore have both an item identity, normally tied to SKU, and a set of mapped descriptive or custom properties.

The connector documents a third layer for catalog structure. An Acumatica Template Item represents the base product, while Matrix Items represent the sellable Shopify variants. Each Matrix Item is a unique attribute combination, such as a specific size and color, and is stocked, priced, and sold separately.

Shopify Product and Variant Mapping at a Glance

Use this sequence to separate item identity, missing-item behavior, field mapping, and variant structure.

1 Review Import Item on the Shopify store Import Settings before importing products or order lines that may not exist in the ERP.

2 If new items may be created, set the imported item type, item class, UOM, and warehouseID defaults that appear when Import Item is selected.

3 If Shopify may send an item without an SKU, decide whether Use Numbering Sequence for SKU Generation should generate a new value from the configured numbering sequence.

4 Load Shopify items on the Shopify Inventory tab, then use Sync from Shopify for the documented SKU-to-Inventory ID import path.

5 Use Inventory Mapping to pair ERP properties with Shopify properties and to configure product-level or variant-level metafield mappings.

6 For products with options, sync the Acumatica Template Item as the Shopify product and select the Matrix Items that should become Shopify variants.

7 Select the required import or export checkbox for each field mapping before processing mapped values.

8 Validate the resulting SKU, Inventory ID or Inventory CD, Shopify product identity, template identity, matrix-item selection, and required field checkboxes on the documented screens and tabs.

Resolve Shopify SKUs to Acumatica Inventory Items

The Shopify Inventory tab can load both Acumatica and Shopify items. Load Acumatica Items retrieves stock and non-stock records. Load Shopify Items retrieves Shopify items. Sync to Shopify exports ERP items, while Sync from Shopify imports Shopify items into the ERP. Get Item by ID retrieves a Shopify item by its ID, and Purge removes the items displayed in the table.

For Sync from Shopify, the manual gives a direct identity rule: the connector takes the Shopify item SKU and creates an Acumatica Inventory ID. That statement establishes SKU as the documented import identifier. The manual does not say whether the comparison is case-sensitive, whether spaces or punctuation are normalized, or how duplicate Shopify SKUs are resolved.

The export direction uses a different rule. The connector does not support item mapping when an ERP inventory item is exported to Shopify. Instead, it sets the item Inventory CD as the Shopify SKU. Before choosing an item-code design, account for that restriction because the manual does not document an export alias that substitutes a different Shopify SKU.

The manual alternates between Inventory ID for the imported item and Inventory CD for the value sent as the Shopify SKU. It does not explain whether those terms refer to the same visible item identifier in this connector context. Preserve the documented terms when testing each direction and verify the actual values displayed in the Shopify Inventory table and the inventory record.

Configure Missing Product Creation and Item Defaults

Import Item controls the connector behavior when a Shopify item is not found in the ERP during synchronization or order import. When the checkbox is selected, the system allows a new item to be created. The imported item type, item class, UOM, and warehouseID options then appear and supply the documented default values for that new item.

Item class is therefore documented as a new-item default, not as an alternate matching key. The source does not state that an item class decides which existing inventory record matches a Shopify SKU, nor does it document class-based product aliases or variant resolution. Use the item class to classify newly created items only to the extent shown by the setting.

When Import Item is not selected, the source says the new item import case uses Replace Missing Products as the item name and takes the warehouse from Warehouse ID. The wording is imprecise, but it clearly identifies Replace Missing Products as the documented fallback setting for a missing imported item rather than describing automatic creation of a normal inventory record.

Use Numbering Sequence for SKU Generation applies during item creation when the system does not find an SKU number. In that case, the connector generates a new value from the numbering sequence setup. The documentation also warns that an absent corresponding numbering sequence produces an error message, although it does not provide the exact message text.

Populate Items in Inventory Details adds the imported item to Inventory Details. Save Item Properties in Line Notes allows item properties from the order to be synchronized to line and header notes. These settings affect the created record or imported order context; the manual does not present them as matching or alias rules.

Use Cross-References Without Assuming an Item Alias Model

Cross-Reference options on Import Settings determine which entities may be set up and matched between Shopify and Acumatica. The Cross-Reference tab visibly supports values such as Ship Via. For customer imports that use tags and the Code type, the source specifically describes Shopify Value and Acumatica Value fields and explains how a Shopify tag can select a customer record.

The manual then states that the same logic works for items, but it does not provide the corresponding item example, item field names, or a complete matching sequence. It does not say whether the Shopify value is an SKU, tag, product ID, variant ID, title, or another property. It also does not explain the relationship between an item cross-reference and the SKU-based behavior on Shopify Inventory.

The Biz-Tech Services Shopify Acumatica Integration should therefore be configured only from the item choices actually exposed in Cross-Reference options. Do not infer a customer part-number, vendor part-number, alternate ID, wildcard, or alias table from the brief statement that item logic is similar. The documentation does not define those mechanisms.

For an unmapped record, the documented outcomes depend on the workflow and settings. Shopify Inventory import can create an Acumatica Inventory ID from the Shopify SKU. Order import can create a new item when Import Item is selected, or use Replace Missing Products when it is not. The manual does not state which behavior takes precedence if an item cross-reference exists but conflicts with the SKU, or if an item cross-reference is enabled but no row matches.

Map Product Variant and Metafield Properties

Inventory Mapping handles field-level data after the product or variant identity is established. The tab supports Acumatica attributes, item currency settings, user-defined fields, and Shopify fields. It also supports exporting and updating Shopify metafields at the product or variant level.

Use Get Metafields to retrieve existing Shopify metafields before organizing the mapping. Each mapping has checkboxes that specify whether it applies to import or export. Select the appropriate direction before processing; the source explicitly tells users to confirm that the corresponding checkbox is selected before importing or exporting mapped values.

The documentation defines Acumatica property as the Acumatica item category and Shopify property as the Shopify item category. It does not list the complete set of allowed categories, provide sample product-level and variant-level rows, or describe type conversion between the platforms. It also does not define what happens when a metafield type or mapped value is invalid.

Export Item Mappings is a related but separate tab. It determines which product-related fields are synchronized to Shopify, and its checkboxes can exclude fields that should not be updated. The source warns that if required fields are not selected for creation or update, corresponding data such as price, description, or weight will not be updated on Shopify processing screens.

Connect Template Items Matrix Items and Shopify Variants

An Acumatica Template Item is the base product used to create multiple Matrix Items and is not itself a sellable product. A Matrix Item is a child product generated from the template. Each Matrix Item represents one attribute combination and is stocked, priced, and sold separately. In Shopify terms, the template supplies the product structure and the matrix items supply the variants.

After the Template Item is synchronized, the Shopify-generated Template ID is displayed on the Shopify Product tab. Syncing can then include selected matrix items or all matrix items.

1 Select Sync Matrix Items.

2 Open the Matrix Items tab.

3 Select the desired items.

4 Select Include Item in Sync.

5 Confirm that the selected items appear on the Shopify Details tab, which the manual uses as confirmation that they are in the Shopify store and ready to synchronize.

Sync All Matrix Items sends all matrix items with the template product. After the template item exists in Shopify, Shopify Product Data becomes available on the Shopify Product tab. Selecting it exposes additional fields such as Custom URL, Meta Description, and Page Title. Export to Shopify is automatically selected when the product exists in Shopify.

The same selected-checkbox logic applies to stock items. When the template and matrix synchronization checkboxes are selected, the items synchronize as one template with its matrix items. When they are not selected, the manual says items export as ordinary individual products.

Understand Export Direction and Validation Limits

The export path must be reviewed separately from import. Because export item mapping is not supported, the Acumatica Inventory CD becomes the Shopify SKU. If the connector cannot find some items in the Shopify store during synchronization, the documentation says it creates them automatically. On sales order export, Create Product determines whether a missing Shopify product is created; when it is not selected, the default product under Replace Missing Products is used.

Track Quantity has a documented validation rule. If Track Quantity is not selected in either Shopify or Acumatica, an error message should appear during synchronization. If it is not selected in Shopify but is selected in the ERP, synchronization should update the quantity and automatically select the option in Shopify. The source does not provide the error text or describe the opposite mismatch.

Product-field synchronization also depends on selected checkboxes in Export Item Mappings. Price, description, weight, and other fields are not updated when their required creation or update fields are not selected. Image synchronization depends on Product Image, but the source separately warns that punctuation marks can duplicate an image without defining which punctuation, filename field, or comparison rule is involved.

The source does not provide screen IDs for Shopify Stores, Shopify Inventory, Inventory Mapping, Export Item Mappings, Export Shopify Inventory Items, Stock Items, or the template and matrix workflow. No screen ID should be inferred from a standard installation or from another connector.

Where to Check Your Work

The Biz-Tech Services Shopify Acumatica Integrator exposes the documented mapping result across these screens and tabs.

1 Shopify Stores Import Settings: check Import Item, imported item type, item class, UOM, warehouseID, Use Numbering Sequence for SKU Generation, Replace Missing Products, Warehouse ID, Populate Items in Inventory Details, and Save Item Properties in Line Notes.

2 Cross-Reference options and Cross-Reference tab: confirm that the item entity is selected before expecting its values to appear, then review the Shopify Value and Acumatica Value fields that the screen exposes.

3 Shopify Inventory: use Load Shopify Items or Get Item by ID, review the Shopify SKU, and confirm the result of Sync from Shopify in the Acumatica inventory record.

4 Inventory Mapping: confirm the Acumatica property, Shopify property, product-level or variant-level metafield selection, and the import or export checkbox for each mapping.

5 Export Item Mappings: confirm that every product field intended for synchronization is selected before running a related processing screen.

6 Shopify Product tab: after template synchronization, confirm the generated Template ID, Shopify Product Data, and Export to Shopify state.

7 Matrix Items and Shopify Details tabs: confirm which matrix items were selected with Include Item in Sync and which variants are ready to synchronize.

8 Export Shopify Inventory Items: confirm that the intended price, description, and weight checkboxes were enabled in Export Item Mappings before processing.

9 Import Shopify Orders or another importing workflow: when a line does not resolve to the expected item, compare the SKU, Import Item state, item creation defaults, Cross-Reference setup, Replace Missing Products, and Warehouse ID.

Shopify Product and Variant Mapping Frequently Asked Questions

Does the connector map a Shopify SKU to an Acumatica inventory item?

Yes, in the documented Shopify-to-Acumatica path. Sync from Shopify takes the Shopify item SKU and creates an Acumatica Inventory ID. The source does not describe normalization or duplicate-SKU handling.

Can I map a different Acumatica item code when exporting to Shopify?

The documentation says the connector does not support mapping during Acumatica item export. It sends the Acumatica Inventory CD as the Shopify SKU.

What happens when a Shopify item does not exist in Acumatica?

With Import Item selected, the connector can create a new item using the configured imported item type, item class, UOM, and warehouseID defaults. Without Import Item, the documented fallback uses Replace Missing Products and Warehouse ID, although the manual does not explain the fallback record in detail.

Can the connector generate an SKU when Shopify does not provide one?

Use Numbering Sequence for SKU Generation allows a value to be generated during item creation when the system does not find an SKU. The corresponding numbering sequence must be configured or an error message is displayed.

How are Shopify variants represented in Acumatica?

The documented model uses a Template Item as the base product and Matrix Items as the individual variants. Each matrix item represents one attribute combination and is stocked, priced, and sold separately.

Can product and variant metafields use different mappings?

Inventory Mapping supports Shopify metafields at the product or variant level. Retrieve existing fields with Get Metafields and select import or export for each mapping. The source does not provide examples of the allowed data types or conversion rules.

Does the connector support item aliases and alternate identifiers?

The Biz-Tech Services Acumatica Shopify Integration documents SKU-based identity, selected Cross-Reference entities, and property mapping. It does not define an alias table, alternate item ID, wildcard match, customer part number, or vendor part number for product and variant resolution.

Why did a product field fail to update in Shopify?

Check Export Item Mappings and the relevant Inventory Mapping direction. The manual warns that price, description, weight, or other data is not updated when the required creation or update checkbox is not selected.

Work With the Biz-Tech Services Shopify Connector

Reliable Shopify product mapping starts by treating item identity, field properties, and variant structure as separate controls. Validate the SKU and missing-item behavior first, then configure Inventory Mapping, and finally confirm how Template Items and Matrix Items appear as products and variants.

If you need help validating Shopify SKU resolution, item-creation defaults, metafield mappings, or template and matrix item synchronization, visit https://biz-techservices.com to work with the Biz-Tech Services Acumatica Shopify Integrator.

The post How to Map Shopify Products and Variants to Acumatica Inventory Items appeared first on Biz-Tech Services.

Acumatica AI agents can become controlled steps inside an ERP process: a user, business event, import scenario, schedule, or workflow invokes an agent action; the agent reads the current record and approved supporting data; it writes a bounded result; and the surrounding process decides what happens next. The practical opportunity in Acumatica 2026 R2 is therefore not unrestricted autonomous ERP. It is governed automation in which the target record, available tools, editable fields, trigger, review point, exception path, and audit evidence are designed before activation.

That distinction matters because an agent can change business records. A useful implementation does more than write a persuasive instruction. It limits the data the model can retrieve, exposes only the tools required for the task, constrains outputs to values that downstream rules can evaluate, tests both normal and adverse cases, and assigns a human owner. Acumatica provides relevant controls through the Agents form, endpoint-backed tools, published Generic Inquiries, field masking, result previews, processing logs, token statistics, AI Automation History, business events, workflows, and import scenarios. Those controls still require process design and operational discipline.

This playbook explains how finance, operations, IT, and process owners can select a suitable use case, design the agent boundary, protect sensitive data, build approval and exception paths, test changes, monitor cost and behavior, and scale only after evidence supports the decision. It focuses specifically on Acumatica AI Automation agents and agent actions. For the broader 2026 R2 program, see the Biz-Tech Acumatica 2026 R2 Upgrade Guide.

Executive Summary for Business and Technology Leaders

An Acumatica AI agent is most valuable when it applies judgment to a narrow record-level task that ordinary rules cannot express cleanly. Examples include classifying an incoming record, drafting a bounded description, comparing a current transaction with approved reference data, or assigning one of several defined review outcomes. Acumatica documentation describes agents that can retrieve the current record, update editable fields and detail lines, and retrieve supporting information through published Generic Inquiries. Once activated, an agent action can be invoked manually or by a configured business event, import scenario, or workflow.

The control model should begin outside the model. The process must specify which record exists before the agent runs, what data the agent may receive, what fields it may update, which output values are valid, what event or transition may follow, and who reviews exceptions. Acumatica notes that an agent works with the current record on its target form and cannot create a new record on that form. It also cannot invoke another target-form action from inside the agent. Record creation, releases, notifications, status transitions, and other actions should remain separate, visible process steps.

The safest first production use case usually has five characteristics:

• A clear owner can explain the business decision in plain language.
• The required data is available on one target form or through a small number of governed Generic Inquiries.
• The permitted output can be limited to a small set of fields or values.
• A person can verify correctness without recreating the entire analysis.
• An incorrect result can be contained, corrected, and traced without financial posting or irreversible downstream effects.

The rollout decision should be evidence based. A pilot should show that the agent selects the right scope, uses the intended tools, produces acceptable changes, routes uncertainty correctly, stays within a tolerable token and processing budget, and fails safely when data is missing or instructions conflict. If those conditions are not demonstrated, the next action is not broader deployment. It is a narrower boundary, better source data, clearer instructions, or a conventional deterministic rule.

Back to Table of Contents

What an Acumatica AI Agent and Agent Action Actually Do

In Acumatica 2026 R2, the Agents form ML202000 is used to configure and test AI Automation agents. Selecting a target data-entry form gives the agent a current-record context. Acumatica adds standard tools that retrieve the current record and apply updates to editable fields or detail lines. A configured endpoint defines which entity and fields those tools expose. Supporting data can be added through Generic Inquiry tools, with one published inquiry per tool.

After testing, activating most agents adds a generated command to the target form. A user can invoke that command from the More menu or add it as a favorite. The action can also participate in a process started by a record change, schedule, user action, import, business event, or automation workflow. Acumatica registers an internal action name that begins with LLMAction_ followed by the agent ID; workflow and import-scenario configurations use that name.

The agent is not the whole process. It is one step that retrieves information, applies the instructions, and returns a bounded result. A subsequent business event or workflow condition can evaluate the value written by the agent and decide whether to notify a reviewer, assign a task, run another step, or move the record. This separation is useful because it leaves deterministic routing and approvals in Acumatica configuration rather than asking the model to control every consequence.

The boundary also prevents common overstatements. An agent does not receive unrestricted database access merely because it operates inside the ERP. It receives what its tools, endpoints, Generic Inquiries, filters, and current-record context expose. It cannot update fields that are read-only through the configured endpoint, and it cannot update a detail line if the line cannot be edited manually on the target form. If a task requires a dialog, another form, or a target-form action, that task belongs in a separate workflow step or customization.

Back to Table of Contents

How AI Automation Differs from AI Assistant and Biz Tech AI Analyst

Acumatica AI Automation, Acumatica AI Assistant, and Biz-Tech AI Analyst solve different problems. Treating them as interchangeable leads to poor architecture and confusing expectations.

Acumatica AI Automation agents operate in a configured record context. They can retrieve current-record data, call approved supporting tools, and update fields that the configured endpoint permits. Their natural role is bounded execution within a business process. The governance question is which actions, data, fields, triggers, and outcomes are permitted.

Acumatica AI Assistant is oriented toward conversational analysis. The Assistant works with administrator-exposed Generic Inquiries so users can ask questions, examine source records, and create analytical outputs such as tables, charts, pivots, or dashboard widgets. It is suited to finding and explaining information, while AI Automation agents are designed to participate in defined process steps. Organizations planning both should maintain separate ownership, access reviews, use-case inventories, and acceptance tests. The Biz-Tech guide to Acumatica AI Assistant governance covers that analytical use case in more detail.

Biz-Tech AI Analyst is a separate Biz-Tech product for creating and refining Acumatica reports, Generic Inquiries, and Import Scenarios through a proposal-and-approval process. It can help turn business requirements into governed designs, including import mappings, but it does not replace Acumatica AI Automation or remove the need to govern an agent action. AI Analyst presents the proposed data sources, fields, filters, grouping, mapping, and limitations before building or changing a design. For imports, the user’s team retains control of Prepare and Import.

These products can complement one another. A team might use Biz-Tech AI Analyst to prepare a narrowly scoped Generic Inquiry or Import Scenario, use Acumatica AI Automation to apply judgment to each current record, and use Acumatica AI Assistant to analyze approved results. The architecture is sound only when each capability retains its own access boundary, review process, and operational owner.

Back to Table of Contents

Choose a Process That Benefits from Model Judgment

The first design decision is whether the task needs an LLM. Many ERP actions are better implemented with formulas, workflows, business events, approval maps, import mappings, validation rules, or code. Those mechanisms are deterministic, easier to test exhaustively, and usually cheaper to run. An agent earns its place when the input contains ambiguity, unstructured text, contextual comparison, or classification that would otherwise require brittle rules or repetitive human interpretation.

Good candidates often transform information rather than authorize a final transaction. Examples include drafting a standardized summary from an existing record, categorizing an activity into one of several review queues, comparing a record with reference data, identifying the reason a record requires attention, or proposing a value for a reviewer to accept. The sales-order pricing demonstration in Acumatica documentation follows this pattern: the agent compares actual line prices with expected values retrieved through a Generic Inquiry and prepares a description of the differences.

Weak candidates combine too many business decisions. An instruction such as “review the order, decide whether the customer is trustworthy, change prices if needed, release the order, and notify everyone” mixes data retrieval, subjective judgment, financial authority, a target-form action, and communication. It is difficult to test, difficult to explain, and inconsistent with the documented boundary that an agent cannot invoke another action on the target form. Split such a process into record preparation, agent evaluation, human or rule-based approval, and deterministic execution.

Use a short selection test before configuration:

1. State the input record and the business question in one sentence.
2. Identify the smallest output that makes the next step possible.
3. List the exact fields and reference data required.
4. Define an abstain or review outcome for insufficient evidence.
5. Name the person who can judge whether the output is correct.
6. Describe how the original state can be restored or corrected.

If the team cannot answer those questions, it is not ready to write agent instructions.

Back to Table of Contents

Define the Automation Boundary Before Writing Instructions

Agent governance begins with a process contract. The contract should identify the target form, current entity, trigger, inputs, tools, fields the agent may update, permitted result values, prohibited changes, review path, and evidence retained. This contract should be approved by the process owner and technical owner before anyone spends time refining prompts.

The target form anchors the agent to a current record. Confirm that the form is a data-entry form, that the required entity is available through an endpoint, and that the intended fields can be retrieved and updated. If the Default endpoint omits a required field, decide whether extending an endpoint is justified. Acumatica warns that after an endpoint changes, tool settings in every affected agent must be updated and saved so the tools are rebuilt against the current endpoint definition. Endpoint changes therefore belong in change control, not an informal prompt-editing exercise.

Limit write scope. If the agent only needs to assign a review category and add an explanation, do not expose unrelated writable fields. If it does not need line-level updates, do not design the instructions around them. If a downstream workflow needs a status-like value, use a dedicated field with a small controlled vocabulary rather than asking the model for free-form prose that another rule must interpret.

Define what the agent must not do. Examples include changing quantities, prices, tax data, payment information, customer credit settings, posting periods, ownership, or release status. Some prohibited actions may already be impossible through the selected tools, but documenting them helps reviewers confirm that the technical configuration matches the business policy.

Finally, describe the next step independently of the agent. A workflow or business event should evaluate the saved output and determine whether a person reviews it, a notification is sent, or the record advances. This makes the process observable and allows the organization to disable the agent action without redesigning every downstream rule.

Back to Table of Contents

Build a Minimum Data Contract

An agent should receive the least data required to answer its assigned question. More context can improve a demonstration while weakening production control. Extra columns increase the chance that sensitive information is transmitted, that irrelevant details distract the model, that token consumption grows, and that a future data change alters behavior unexpectedly.

For current-record tools, document each exposed field and why it is required. Separate fields needed for reasoning from fields needed only for identification or traceability. For Generic Inquiry tools, define the inquiry owner, published screen ID, filters, returned columns, row limit, business meaning, refresh assumptions, and access restrictions. A query that was designed for human exploration may be too broad for an agent tool.

Acumatica supports adding one or more Generic Inquiry tools, each retrieving data from a single published inquiry. The tool name and description help the model decide when to call it. Use names that describe the business data and descriptions that state both purpose and limits. Avoid a generic description such as “use this for more information.” A better description explains which records the inquiry returns, what filter should be applied, and which decision the data supports.

The data contract also needs volume limits. An inquiry that returns hundreds of rows may exceed the useful context for the task, increase response time, and raise provider costs. Add shared filters and query conditions that produce only the relevant comparison set. Test with records near the expected maximum, not only with a convenient example that returns two rows.

Review the contract whenever a source changes. New columns, renamed fields, modified joins, different filters, or expanded access can change what the agent sees without any edit to its business instructions. Treat a material Generic Inquiry or endpoint change as a reason to retest affected agents.

Back to Table of Contents

Protect Sensitive Data and Understand the Masking Boundary

Acumatica AI Automation can mask selected fields returned by the get_current tool before data is sent to the LLM. The system replaces values with placeholders, keeps the actual data in Acumatica, and restores recognized placeholders when the model returns them. This is useful when an agent needs to carry a value through a result without analyzing the value itself.

Masking has operational limitations. A model cannot calculate with or classify a value it cannot see. If a numeric amount is masked, the model cannot use the actual amount to compute a percentage or compare it with a threshold. Acumatica also documents that after patch_current is invoked, an agent with masked fields cannot call get_current again. Instructions and tool sequence must account for that boundary.

Most importantly, masking on get_current does not mask columns returned by Generic Inquiry tools. Acumatica documentation explicitly warns that GI results are sent to the LLM without that masking. A governed design must therefore remove sensitive columns from the inquiry itself, apply appropriate filters, and limit returned records. Do not assume that selecting masked fields on the current-record tool protects a broad supporting inquiry.

Perform a field-level data review before production:

• Identify personal, payroll, banking, payment, tax, credential, contract, pricing, health, and regulated information.
• Decide whether the model needs to see, carry, aggregate, or ignore each value.
• Remove unnecessary fields at the source rather than relying only on instructions.
• Confirm the LLM provider, deployment, retention, regional, and commercial terms with the organization’s security and legal owners.
• Review processing logs carefully because they can contain tool inputs, messages, returned data, errors, and model output.

The processing log is a governance asset and a sensitive record. Limit access to people who need it, define retention expectations, and avoid copying production logs into unsecured tickets or chat threads.

Back to Table of Contents

Write Instructions as an Executable Business Policy

Business instructions should describe purpose, required data, allowed tools, decision rules, output fields, valid values, exceptions, and stopping conditions. They should not depend on motivational language or broad requests to “use best judgment.” A reviewer should be able to compare the instructions with the process contract and identify any missing or conflicting rule.

Start with the goal and scope. Name the current record and the single decision the agent supports. Then define the tools and when to use them. Insert exact field and tool names from Acumatica rather than typing approximations. Acumatica provides an Insert Data Field command because the model must use names that match the configured tool schema.

State decision rules in observable terms. If the output is a review category, enumerate the allowed values and the evidence required for each one. Include an explicit value such as NEEDS_REVIEW when the data is incomplete, contradictory, outside policy, or unavailable. Downstream workflows should recognize that value and route it to a person instead of treating uncertainty as approval.

Separate analysis from writing. An agent that evaluates a record and generates explanatory text should first determine the controlled result, then produce a short explanation grounded in the retrieved fields. Limit length and prohibit unsupported claims. If the process needs a note for a customer or vendor, require human approval before external communication.

Add constraints that reflect actual business policy: fields that must remain unchanged, date or amount boundaries, valid currencies, permitted record statuses, maximum number of lines, and conditions that require no update. Avoid repeating constraints in contradictory ways. Acumatica notes that conflicts among system instructions, business instructions, and tool descriptions can cause processing errors.

Version the instructions. Record the approver, effective date, related agent ID, target form, endpoint version, GI versions, and test evidence. A prompt edit can change production behavior as materially as a workflow or code change.

Back to Table of Contents

Keep Human Approval at the Right Decision Point

Human review should protect the consequence, not merely observe the model. Placing a reviewer after an irreversible action provides little control. Place approval before release, payment, posting, external communication, compliance classification, account changes, or any transition that materially affects another party.

For a low-risk internal field, post-action review may be sufficient if changes are visible, reversible, and sampled regularly. For higher-risk records, the agent should write a proposal or review status rather than the final authoritative value. A workflow can assign the record to an authorized user, display the explanation, and require acceptance or correction.

Design the review screen around evidence. The reviewer needs the original value, proposed value, reason, relevant source data, and any missing or conflicting information. A bare “AI approved” flag is not enough. Acumatica’s test Result tab demonstrates the value of before-and-after differences; production review should follow the same principle when possible.

Define reviewer authority and service expectations. Specify who may approve, who handles exceptions, how quickly records must be reviewed, and what happens when no reviewer acts. Avoid silently allowing an agent-generated value to become authoritative because a queue aged past a deadline.

Measure human disagreement. Corrections reveal where instructions, source data, or use-case boundaries need improvement. Preserve a reason for overrides rather than recording only that the value changed. A rising override rate should trigger investigation and perhaps automatic suspension of the action for the affected scenario.

Back to Table of Contents

Use Agent Actions in Import Scenarios Carefully

Acumatica 2026 R2 allows an import scenario to invoke an AI Automation agent action for each record it creates or updates when the AI Automation feature is enabled. This can apply judgment during a controlled import, but it also multiplies execution volume and introduces ordering requirements.

The documented action sequence is Save, agent action, and Save again. The first save creates or updates the current record so the agent has something to process. The agent reads that record and writes its result. The second save persists the agent’s values. Each row uses Commit and executes for each record. The internal action name is entered manually in angle brackets because the dynamic agent action does not appear in the normal lookup.

Mapping conflicts deserve special attention. If the source file maps a value into a field that the agent also writes, the import can overwrite the model’s result. Acumatica advises leaving the corresponding source values empty when the agent is responsible for those fields. Document field ownership explicitly so a future spreadsheet template or mapping change does not reintroduce the conflict.

Every imported record causes a separate LLM request sequence, and the import waits for each result. Begin with a small record count, measure processing time and token use, and verify the AI Automation History before increasing volume. Do not launch a large production import based on a successful one-record test.

Create restart and reconciliation rules. Determine how to identify records that completed the first save but not the agent action, or the agent action but not the final save. Use an import batch identifier, status field, or other traceable marker. Define whether a failed record can be retried safely and whether the agent will produce the same result when the current record already contains a partial output.

Back to Table of Contents

Orchestrate with Business Events and Workflows

An agent action becomes more useful when Acumatica configuration controls when it runs and how its result is handled. A business event can respond to a record change, schedule, or user action. A workflow can expose the agent action only in appropriate states, run it automatically, or use it in a transition. These mechanisms should remain responsible for sequence and authorization.

Use stable output values for downstream logic. Acumatica recommends instructing an agent to write one of a fixed set of values when a business event or workflow condition depends on the result. Free-form text is suitable for explanation, but it is a poor control signal. A dedicated field with values such as NO_ISSUE, REVIEW, and BLOCKED is easier to route, report, and test.

Remember that a business event fires only when its monitored value changes. If the agent writes the value already stored in the field, the event does not trigger. Design state transitions accordingly. Clearing the field before every run may create other risks, so test repeat execution and idempotency instead of assuming every successful agent call causes a new event.

Keep target-form actions separate. Acumatica states that the agent cannot invoke another action of the target form. If the process requires release, assignment, notification, creation of another document, or another command, configure that as a subsequent event or workflow step. This produces clearer logs and lets each action enforce its own rights and validation.

Add an automation stop. Administrators should know how to deactivate the agent, disable an invoking event or workflow transition, and hold affected records. Document the order of operations so an incident response does not create more partially processed work.

Back to Table of Contents

Test the Agent Before Activation

Testing must prove both correctness and containment. On the Agents form, the Test Agent function uses an example record and shows intended changes without saving those changes to the database for most agents. The Result tab identifies the affected entity and displays before-and-after values. The Processing Log records instructions, tool schemas, tool calls, responses, timing, errors, messages, and token consumption.

Build a representative test set rather than selecting only clean examples. Include ordinary records, records at policy boundaries, missing fields, unexpected detail-line counts, inactive or closed statuses, values outside normal ranges, conflicting GI results, no GI results, duplicate references, and attempts to introduce irrelevant instructions through text fields. Use de-identified or suitable nonproduction data according to organizational policy.

For every case, record the expected result before running the agent. A test is weak when reviewers decide after seeing the output that it “looks reasonable.” Compare the actual result with an approved expectation and capture differences. For classification, measure agreement by category. For generated text, define required facts, prohibited claims, maximum length, and acceptable tone.

Inspect tool behavior, not only the final wording. Confirm that the model called the expected inquiry, applied the intended filter, retrieved the correct records, and updated only the permitted fields. A plausible answer produced from the wrong data path is still a failure.

Repeat tests across model or connection changes. Agent LLM Connections can point to supported providers including Azure, Amazon Bedrock, OpenAI, and Anthropic, and providers may retire or change models. Acumatica recommends reviewing provider availability and retesting connections. A connection or model change should trigger functional regression tests, masking-placeholder tests, volume tests, and renewed approval before production use.

Back to Table of Contents

Validate Failure and Exception Paths

Production reliability depends on how the process behaves when the model, connection, data, or surrounding workflow fails. The desired failure mode is usually a visible exception with no unauthorized update, not an improvised answer.

Test invalid credentials, unavailable endpoints, provider timeouts, rate limits, missing GI permissions, empty results, malformed data, excessive record volume, noneditable fields, and an agent output that does not match the controlled vocabulary. Confirm what appears in the Result and Processing Log tabs and how operators identify the affected record.

Define retry rules. Some failures are transient, but an automatic retry can duplicate work or apply a change after the record has moved to another state. Before retrying, verify that the current record is still eligible, that earlier changes were not saved, and that the action is idempotent. Limit retry count and route repeated failures to a named queue.

Distinguish technical errors from business uncertainty. A provider timeout is a technical failure. Missing evidence or contradictory source data is a business exception. They may require different owners, communications, and service targets. Do not let a generic error status hide the cause.

Create a reconciliation view or Generic Inquiry that shows records awaiting agent processing, records completed, exceptions, last-run time, outcome, reviewer status, and related batch or workflow identifiers. This operational view is often more valuable than a polished demonstration because it enables supervisors to manage real work.

Back to Table of Contents

Monitor Activity Tokens Cost and Behavior

Each agent execution can make multiple requests to an LLM, especially when tools are called. Acumatica records token statistics calculated by the ERP and values reported by the provider. The two can differ because providers tokenize and report categories differently. Acumatica documentation states that the provider remains the source of truth for actual usage and billing.

During testing, use the Processing Log to see which requests and tool steps consume tokens. Over time, use AI Automation History ML400000 to review connection tests, agent tests, and production actions invoked by users, business events, import scenarios, or workflows. The history includes Acumatica-calculated values and provider-reported input, output, and total tokens when the provider supplies them.

A blank provider value does not necessarily mean zero usage. It may mean the provider did not report the value. Establish a reconciliation process with the provider dashboard and commercial terms. Monitor both unit economics and business throughput: cost per processed record, cost per accepted result, elapsed time, failure rate, and reviewer effort.

Behavior monitoring is equally important. Track outcome distribution, human override rate, exceptions by cause, tool-call patterns, fields changed, and volume by trigger. A sudden change may indicate new source data, a modified Generic Inquiry, a prompt edit, an endpoint change, a model update, or a shift in incoming records.

Set thresholds for investigation and suspension. Examples include a material rise in NEEDS_REVIEW, repeated writes outside expected fields, processing time that disrupts imports, provider cost above budget, or reviewer disagreement above the pilot baseline. Thresholds should initiate a defined response rather than remain dashboard decoration.

Back to Table of Contents

Establish Change Control and Audit Evidence

An AI agent is a production configuration with dependencies. Its effective behavior comes from the business instructions, system instructions, tool descriptions, endpoint entity and version, writable fields, Generic Inquiry definitions, filters, provider connection, model, invoking configuration, and downstream workflow. Change control must cover that full dependency set.

Maintain an inventory with agent ID, name, purpose, owner, target form, endpoint, tools, supporting inquiries, invoking events or workflows, output fields, approval path, connection, reviewer, activation date, and last validation date. Link the inventory entry to the approved process contract and test evidence.

Require review for material changes. A wording correction that cannot affect behavior may need lightweight review, but a new tool, field, decision rule, model, GI column, filter, or automatic trigger requires regression testing. Changes to shared endpoints or inquiries should identify every dependent agent before publication.

Preserve evidence from testing and production review without copying sensitive content unnecessarily. Useful evidence includes test case IDs, expected and actual controlled outcomes, before-and-after field differences, error classifications, timing, token totals, reviewer decision, and approval. Store logs according to security and retention policy.

Auditability also means explaining current behavior. An administrator should be able to answer why the agent could see a field, why it was allowed to update another field, which version of instructions applied, which process invoked it, and who approved activation. If those answers require reconstructing decisions from emails, the control is incomplete.

Back to Table of Contents

Use a Phased Implementation Plan

A four-phase rollout keeps the first deployment small while producing evidence for each expansion decision.

Phase one defines the process. Select one record-level use case, write the process contract, identify sensitive data, specify permitted outputs, and choose the reviewer. Confirm feature availability, licensing, target build, provider requirements, and environment policy with the appropriate Acumatica partner and internal owners.

Phase two builds in a sandbox. Configure the connection, target form, endpoint-backed tools, supporting Generic Inquiries, instructions, output fields, and manual action. Do not add an automatic trigger yet. Test representative records and correct scope, data, and instruction problems.

Phase three runs a controlled pilot. Activate the command for a limited user group or narrow queue. Require review of every result. Measure accepted results, corrections, exceptions, processing time, token consumption, and operational effort. Keep a conventional fallback process available.

Phase four automates only the proven boundary. Add a business event, workflow, schedule, or import scenario when manual pilot evidence shows consistent behavior and safe failure. Continue sampling accepted outcomes and reviewing exceptions. Expand volume, record types, or write scope one variable at a time.

Each phase needs an exit decision. The team should explicitly approve advancement, repeat the phase with changes, or stop. “No serious complaints” is not sufficient evidence. Use documented acceptance criteria and a named owner.

Back to Table of Contents

Measure Business Value Without Overclaiming

The business case should compare the governed process with its actual baseline. Relevant measures may include review time per record, queue age, percentage of records requiring manual investigation, classification agreement, correction rate, exception resolution time, processing cost, and downstream error rate. Choose measures tied to the selected use case.

Avoid treating model output volume as value. Processing more records is beneficial only when the outputs are correct enough, reviewed at the appropriate level, and used by the next process step. Likewise, a reduction in manual touches is not positive if unresolved exceptions or downstream corrections increase.

Measure accepted automation separately from assisted work. A reviewer may save time even when every result still requires approval. That can be a valid outcome and a safer long-term design for sensitive decisions. Do not force full automation merely to improve an adoption metric.

Include control costs: configuration, source-data maintenance, review, provider consumption, investigation, retraining, and change management. Agent economics can change when record volume, prompt length, tool calls, or provider pricing changes. Review the cost model with actual production history.

Report limitations with results. State the period, record population, model and connection, process version, review method, and exclusions. A pilot on one business unit and one record type does not prove enterprise-wide performance.

Back to Table of Contents

Governance Checklist Before Production Activation

Use the following checklist as a release gate:

• The process owner approved a one-sentence purpose and a bounded business outcome.
• The target form, current entity, endpoint, tools, fields, and supporting inquiries are documented.
• The agent receives only the data required for the task.
• Sensitive fields are removed, masked where supported, or otherwise governed.
• The team understands that Generic Inquiry results are not protected by current-record field masking.
• Permitted updates and prohibited changes are explicit.
• Downstream logic uses controlled values rather than interpreting free-form prose.
• Human approval is placed before consequential or irreversible actions.
• Normal, boundary, missing-data, adverse-input, error, retry, and repeat-run cases passed.
• Reviewers verified tool calls and field differences, not only final wording.
• Token use, provider billing, elapsed time, and expected volume are within budget.
• AI Automation History and operational reconciliation views are assigned to owners.
• Rollback steps can deactivate the agent and its invoking configuration safely.
• Instruction, endpoint, inquiry, workflow, and connection changes require appropriate retesting.
• A named owner approved activation and the next review date.

The checklist should be retained with implementation evidence. If an item does not apply, record the reason rather than deleting it. That creates a reviewable decision and helps future owners understand the original boundary.

Back to Table of Contents

Common Implementation Mistakes

The first mistake is starting with instructions instead of a process contract. Prompt refinement cannot repair an undefined owner, excessive write scope, or missing approval step.

The second is exposing a broad Generic Inquiry because it is convenient. Supporting inquiries should be purpose-built or carefully constrained. Remember that current-record masking does not mask GI results.

The third is combining judgment and consequence. Let the agent propose or classify, then let a person or deterministic workflow authorize the material action.

The fourth is testing one clean record. A production decision needs boundary, missing-data, conflicting-data, volume, repeat-run, and technical-failure cases.

The fifth is relying on free-form text as a workflow condition. Use fixed output values for routing and keep prose for explanation.

The sixth is ignoring dependency changes. Endpoint, GI, model, provider, instructions, and workflow changes can all alter behavior.

The seventh is assuming provider token values are always complete. Blank values can mean unreported usage, and the provider dashboard remains the billing authority.

The eighth is automating a large import too early. Each record can generate a separate execution and multiple LLM requests, so begin with a small batch and reconcile every outcome.

The ninth is presenting Acumatica AI Automation as equivalent to AI Assistant or Biz-Tech AI Analyst. Their purposes and control boundaries differ.

The tenth is treating activation as the end of implementation. Production monitoring, human feedback, exception handling, and scheduled revalidation are part of the operating model.

Back to Table of Contents

Frequently Asked Questions

What is an Acumatica AI agent

An Acumatica AI Automation agent is a configured model-driven capability associated with a target data-entry form. It can retrieve the current record, update fields and editable detail lines through endpoint-backed tools, and retrieve supporting data from published Generic Inquiries. After testing and activation, the related agent action can be invoked manually or through configured business events, workflows, schedules, or import scenarios.

Can an Acumatica AI agent create a new record

The documented agent action works with the current record on its target form and cannot create a new record on that form. A surrounding process must create or identify the record before invoking the agent. The agent may update permitted fields on that current record; other creation or action steps should be configured separately.

Can an agent run another form action?

Acumatica documentation states that an agent cannot invoke another action of the target form. Configure release, notification, assignment, transition, or other commands as separate business-event or workflow steps with their own permissions and validation.

How can agent actions be started

An active agent normally adds a command to the target form for user invocation. An action can also be invoked through a business event, import scenario, or workflow. The appropriate trigger depends on the process risk, record state, desired review point, and expected volume.

Does masking protect data returned by Generic Inquiries

No. Acumatica’s documented field masking applies to selected values returned by the get_current tool. It does not mask data returned by Generic Inquiry tools. Remove sensitive GI columns, use narrow filters, limit records, and review the inquiry as a separate data boundary.

How should an agent communicate a result to a workflow

Use a dedicated field with a fixed set of permitted values, such as NO_ISSUE, REVIEW, or BLOCKED. The agent may also write an explanation, but downstream logic should not have to interpret unrestricted prose. Test repeat execution because a business event is triggered only when the monitored value changes.

Can an import scenario call an agent action

Yes, when AI Automation is enabled. Acumatica documents a Save, agent action, Save sequence for each record, with Commit selected and execution configured for each record. Start with a small batch because each record creates a separate LLM execution and the import waits for the response.

How do I estimate AI Automation cost

Review token consumption in the Processing Log during tests and in AI Automation History over time. Compare Acumatica-calculated values with provider-reported usage, and reconcile with the provider dashboard because the provider remains the source of truth for billing. Include processing volume, tool calls, retries, review effort, and support overhead.

When should a team keep human approval

Keep approval before financial posting, release, payment, external communication, compliance classification, account changes, or another material consequence. Lower-risk internal suggestions may use sampling after a controlled pilot, but the organization should retain an exception path, override evidence, and a way to suspend the automation.

What is the safest first Acumatica AI agent use case

Choose a narrow current-record task with limited data, a small controlled output, an easy human check, and a reversible result. Classification, summarization, or proposal generation is usually safer than autonomous transaction processing. Test manually before adding automatic triggers.

Back to Table of Contents

A Practical Next Step

Start with one real queue, one current record, one decision, and one owner. Write the process contract before configuring an agent. Then build the smallest tool and data boundary that can support the decision, test adverse cases, and run a reviewed pilot. Scale only the part that evidence shows to be reliable.

Biz-Tech Services can help organizations assess Acumatica AI Automation use cases, design controlled workflows and import scenarios, review Generic Inquiry and endpoint exposure, define test evidence, and establish monitoring and rollback procedures. The objective is a production process that remains understandable and governable after the demonstration ends. Explore practical implementation resources in the Biz-Tech Acumatica Lessons library or discuss a scoped automation review with Biz-Tech Services.

Back to Table of Contents

Sources

1. Acumatica 2026 R2 Integration Guide Use of Agent Actions
2. Acumatica 2026 R2 Integration Guide Agent Actions in Import Scenarios
3. Acumatica 2026 R2 Form Reference Agents ML202000
4. Acumatica 2026 R2 Integration Guide Creation of Agents
5. Acumatica 2026 R2 Integration Guide Hiding of Sensitive Data
6. Acumatica 2026 R2 Integration Guide Testing and Troubleshooting Agents
7. Acumatica 2026 R2 Integration Guide Collection of Statistics
8. Acumatica 2026 R2 Form Reference Agent LLM Connections ML201000
9. Acumatica Cloud Platform and 2026 R2 AI Overview
10. Biz-Tech Services Acumatica 2026 R2 Upgrade Guide
11. Biz-Tech Services Acumatica AI Assistant Governance Guide
12. Biz-Tech AI Analyst

Back to Table of Contents

The post Acumatica AI Agents and Agent Actions: A Governed Automation Playbook appeared first on Biz-Tech Services.

The Biz-Tech Services WooCommerce Acumatica Connector also provides separate controls for field-level mapping, item attributes, synchronization direction, variants, and generated WooCommerce product IDs. This guide stays focused on product identity and field mapping. Connection setup, the broader configuration checklist, order import, complete data flow, and inventory quantity synchronization are covered in the related WooCommerce articles for those topics.

WooCommerce Product Mapping Prerequisites

The Biz-Tech Services Acumatica WooCommerce Connector becomes available after its customization package is published through Customization Projects (SM204505). The WooCommerce workspace then contains WooCommerce Store Preferences, WooCommerce Store, and the processing screens used for item synchronization.

On WooCommerce Store, the Item Settings tab controls whether an unmatched WooCommerce product can create an Acumatica item and which defaults apply. The Item Mappings tab controls which field values can be created or updated. The Inventory Mappings tab maps Acumatica Stock Item fields or Attribute values to WooCommerce product fields. Item Details is the workspace for loading items from each system and initiating synchronization.

Before mapping a product, confirm the intended direction. Sync from WooCommerce imports product data into Acumatica. Sync to WooCommerce exports Acumatica item data. This distinction matters because the documentation states that product mapping is supported during import from WooCommerce to Acumatica, while the connector does not support the same mapping function during Acumatica item export.

WooCommerce Product Mapping Step by Step

Use this sequence to set up and verify the product relationship.

1 Open WooCommerce Store and review Item Settings for the selected Store Code.

2 Decide whether Import Item should be selected. When selected, an unmatched WooCommerce product can create a new item in Acumatica according to the configured item settings.

3 Confirm that each WooCommerce product has the SKU that should match the Acumatica Inventory CD.

4 Set Import item type and UOM if the connector may create new Acumatica items.

5 If SKU values may be absent, review Use Numbering Sequence for SKU Generation and confirm that the required numbering sequence exists.

6 On Item Mappings, select the fields that can be created in WooCommerce, updated in WooCommerce, or updated in Acumatica. Keep SKU selected because the documentation identifies it as required for item creation.

7 On Inventory Mappings, use Get WooCommerce Properties, choose the Acumatica Target, and identify the Acumatica Property and WooCommerce Property for each field or attribute mapping.

8 On Item Details, use Load Acumatica items or Load WooCommerce Items to review the records available for synchronization.

9 Use Sync from WooCommerce for the documented WooCommerce-to-Acumatica mapping path, then confirm that the expected Acumatica item was retrieved or created.

10 Verify the generated WooCommerce product ID when an Acumatica item is created in WooCommerce, and confirm that the ID appears in WooCommerce Store and on the Stock Items WooCommerce Inventory tab.

How SKU Matches WooCommerce Products to Inventory CD

The documented product identity rule is direct. During WooCommerce item import, the connector searches for an Acumatica Inventory CD using the WooCommerce Product SKU. If the Inventory CD is found, the connector retrieves that existing item. This is the primary line-level match described in the source.

If no matching Inventory CD is found and Import Item is selected, the connector can create a new Acumatica item using the configured Import item type and UOM. Populate Items in Inventory Details can add the imported item to Inventory Details. Last Page Number for Getting Products records the last WooCommerce product page used for retrieval.

If Import Item is not selected, the connector prohibits item import and creation unless the corresponding item already exists in Acumatica. When the SKU does not resolve to an Inventory CD, the documented error is The item {0} does not exist in the system. The placeholder represents the item value used by the process.

When exporting an Acumatica inventory item to WooCommerce, the documentation states that the Inventory CD becomes the WooCommerce item SKU. This export rule is not the same as the configurable import mapping on Inventory Mappings.

Item Mappings and Synchronization Direction

The Item Mappings tab controls which item field values participate in item synchronization. Its first column contains field names. Create in Woo checkboxes allow selected field values to be exported and created in WooCommerce. The adjacent update control allows values already created in WooCommerce to be updated. Update in Acu allows selected field values to be updated during import from WooCommerce to Acumatica.

The Biz-Tech Services WooCommerce Acumatica Integration uses SKU as a required field for item creation, so the documentation says SKU is selected by default. Other fields should be enabled only in the direction the business expects. A field selected for creation in WooCommerce does not automatically mean it should overwrite Acumatica during import.

The source says that the same logic applies to variants without import logic, but it does not explain that phrase or provide a separate list of variant field rules. Treat the documented synchronization direction checkboxes as the available guidance and validate variant behavior with a controlled record before processing a larger item set.

Inventory Mappings for Fields Attributes and Metadata

Inventory Mappings provides field-level mapping for WooCommerce-to-Acumatica item synchronization. Get WooCommerce Properties loads WooCommerce product main fields, meta fields, or attributes into WooCommerce Property. Acumatica Target identifies whether the destination is a Stock Item field or an Attribute.

DAC Name identifies the Data Access Class. Acumatica Property contains the corresponding Acumatica field or Attribute name. Woo Product Level identifies whether the WooCommerce value is a Main Field, Attribute, or Metadata. WooCommerce Property identifies the source field loaded or updated by Get WooCommerce Properties.

Update in Acumatica permits the selected value to update Acumatica during item synchronization. Update in WooCommerce permits the selected value to update WooCommerce. These controls map properties and attributes; they do not replace the SKU-to-Inventory-CD identity rule described under Item Settings.

The source explicitly says this configurable mapping function is not supported during Acumatica item export. For export, Inventory CD is assigned as the WooCommerce SKU. That limitation should be included in any mapping design before users expect two-way identity translation.

Cross References Product Categories and Item Classes

The Cross-Reference tab does not document product aliases. It maps selected entities between WooCommerce and Acumatica, with examples that include payments, countries, and shipping methods. Get Shipping Methods loads WooCommerce values for mapping to Acumatica Ship Via. Only entities enabled under Cross-Reference Options appear in the Field list.

The documentation does not identify Inventory ID, Inventory CD, product SKU, or item alias as a Cross-Reference entity. It also does not describe alternate IDs, customer part numbers, manufacturer part numbers, or an alias priority. Do not use the shipping and payment cross-reference process as evidence that product aliases are supported.

Product Categories is also separate from Acumatica item classes. WooCommerce categories can be retrieved with Get WooCommerce categories, created or selected in Acumatica, and synchronized with Sync WooCommerce Categories. A preferred category selected on the Stock Item WooCommerce Categories tab is exported with the item.

The source does not document item-class mapping, item-class defaults, or class-based eligibility rules. Import item type is documented, but no Acumatica item class field is named in the product import setup. If an implementation requires item classes, that behavior needs separate confirmation rather than an assumption based on WooCommerce categories.

Variants Template Items and Matrix Items

Item Details can show product variants when variants are selected. The documentation also provides a separate Template Items process for sending Template Items and Matrix Items to WooCommerce.

A user opens Template Items and runs Sync Template Items to WooCommerce. After a successful export, WooCommerce generates a product ID that appears on the WooCommerce Product tab. The user then runs Sync Matrix Items to WooCommerce. The Matrix Items are created as Variations under the related Template Item product.

This process documents the parent product ID and its variations, but it does not provide a separate alias table for variant SKUs. The source also does not define how duplicate variant SKUs, missing parent relationships, or attribute conflicts are resolved. Validate the template and matrix relationship before using batch processing.

Unmapped Products and Validation Rules

The source documents an error path for a WooCommerce SKU that does not match an Acumatica Inventory CD when item creation is not allowed. It also says an error appears when an item has no SKU and the required numbering sequence is absent. The second error message is not provided.

The documentation does not define an unmapped-product queue, an Unmapped status, an alias review screen, a retry counter, or a product-specific error inquiry. Get Order Process Error Messages is explicitly described as containing errors from order retrieval, so it should not be presented as a documented item-mapping exception screen.

Other documented checks are contextual. Quantity synchronization requires the item to exist as a WooCommerce item in Acumatica, to be loaded and saved in Inventory Details, and to use selected warehouses on Warehouse Details. The Is WooCommerce Item checkbox is selected when an item came from WooCommerce and was generated by the connector. These checks help confirm item status but do not describe a general alias resolution process.

Where to Check Your Work

The Biz-Tech Services WooCommerce Acumatica Integrator provides several places to confirm product identity and field behavior after a mapping change.

1 On Item Settings, verify Import Item, Import item type, UOM, Populate Items in Inventory Details, and Use Numbering Sequence for SKU Generation.

2 Confirm that the WooCommerce Product SKU matches the intended Acumatica Inventory CD.

3 On Item Mappings, review Create in Woo, the WooCommerce update selection, and Update in Acu for each enabled field.

4 On Inventory Mappings, review Acumatica Target, DAC Name, Acumatica Property, Update in Acumatica, Update in WooCommerce, Woo Product Level, and WooCommerce Property.

5 On Item Details, use Load Acumatica items and Load WooCommerce Items to compare the records available in each system.

6 After Sync from WooCommerce, confirm that the connector retrieved the matching Inventory CD or created the intended item according to Import Item.

7 After Sync to WooCommerce, confirm the WooCommerce product ID in WooCommerce Store and on the Stock Items WooCommerce Inventory tab.

8 For Template Items, confirm the WooCommerce product ID before synchronizing Matrix Items and verify that the Matrix Items appear as Variations.

9 When no item is created, check for the missing-item error or confirm that the SKU numbering sequence exists if the product has no SKU.

WooCommerce Product Mapping Frequently Asked Questions

What field connects a WooCommerce product to an Acumatica item?

The documented import rule uses WooCommerce Product SKU to search Acumatica Inventory CD. A match retrieves the existing item.

What happens when the SKU does not match an Inventory CD?

If Import Item is selected, the connector can create a new item using the configured item settings. If Import Item is not selected, item creation is prohibited and the process displays The item {0} does not exist in the system.

Can the connector generate a SKU when WooCommerce has none?

Use Numbering Sequence for SKU Generation can generate a number when the SKU is missing, provided that the corresponding numbering sequence has been created. The source says an error appears when the sequence is absent but does not give the message text.

Does the Cross Reference tab map product aliases?

No product-alias behavior is documented there. The examples are payments, countries, and shipping methods, including WooCommerce values mapped to Acumatica Ship Via.

Can I map WooCommerce fields to Acumatica attributes?

Yes. The Biz-Tech Services Acumatica WooCommerce Integration uses Inventory Mappings to map WooCommerce main fields, attributes, or metadata to an Acumatica Stock Item field or Attribute, with update direction controlled by the selected checkboxes.

Does the connector map products during Acumatica item export?

The source says the configurable mapping function is not supported during Acumatica item export. The export process assigns Inventory CD as the WooCommerce item SKU.

Where is the WooCommerce product ID stored after export?

The generated ID appears in WooCommerce Store and on the Stock Items WooCommerce Inventory tab. A Template Item product ID appears on the WooCommerce Product tab.

Where can I review products that failed to map?

The documentation does not identify an unmapped-product queue or a product-specific error inquiry. Review Item Settings, the SKU and Inventory CD, the Item Details result, and the documented error shown when an item does not exist.

Work With Biz Tech Services WooCommerce Mapping

A reliable mapping design separates product identity from field synchronization. Product SKU matches Inventory CD during import, Item Mappings controls selected field directions, and Inventory Mappings connects WooCommerce properties to Acumatica fields or attributes. The documented gaps for aliases, item classes, and unmapped-product queues should be resolved through testing or separate approved requirements.

For help configuring and validating the Biz-Tech Services Acumatica WooCommerce Integrator, visit https://biz-techservices.com to learn more about Biz-Tech Services and schedule a personalized consultation.

The post How to Map WooCommerce Products to Acumatica Inventory Items appeared first on Biz-Tech Services.

Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026

Verified October 15, 2026

Browser change has become an operational Acumatica risk. Chromium is removing XSLT support on November 17, 2026, and Acumatica has warned that Classic UI screens can stop loading in Chromium-based browsers without the applicable update. This guide gives administrators and operations leaders a focused patch, test, and communication plan – while keeping the larger Modern UI transition moving.

Biz-Tech Services can help teams inventory Classic dependencies, validate patches, and plan a controlled Modern UI transition without losing sight of business-critical workflows.

The post Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026 appeared first on Biz-Tech Services.

The Biz-Tech Services DocVision product for Acumatica uses these mappings while turning customer PDF documents into sales orders. This article stays with the documented item-mapping path: choosing the sales order detail target, creating inventory cross-references, activating fields, validating imported lines, and reading the green, red, and yellow status indicators. The guide does not define item-class mapping, alias rules, or a separate unmapped-item queue.

What DocVision Item Mapping Does in Acumatica

DocVision creates Acumatica sales orders from uploaded PDF documents such as purchase orders or shipping requests. A customer-specific template defines how values from a particular PDF structure correspond to Acumatica values. After a PDF is imported in PDF Import Settings, DocVision automatically identifies PDF FieldName and PDF Value entries and sets initial Target Object and Source Field values in the Import Mappings tab.

Users can then map PDF fields to the appropriate Acumatica fields. For item lines, the documented cross-reference feature connects a PDF item value with an Acumatica Inventory ID. This connection lets Validate Items find an existing inventory cross-reference and display the resulting Acumatica value in the Details tab of the imported document.

The documentation does not call the PDF item value a SKU, alias, vendor item, or customer item number. It simply calls the records PDF items and says that they can be mapped to Acumatica Inventory IDs. Use those terms when confirming a DocVision implementation so that broader identifier behavior is not assumed.

Map PDF Line Items to Acumatica Inventory IDs Step by Step

The documented sequence starts with the customer’s PDF template and ends with an imported document whose item lines can be validated against saved inventory cross-references.

1 Open PDF Import Settings and use the Plus button to create a workspace

2 Import a representative PDF file so DocVision can create the template and display the PDF beside the mapping workspace

3 In Import Mappings, review the automatically populated PDF FieldName, PDF Value, Target Object, and Source Field values

4 For sales order detail fields, select Sales Order, Details, and Advanced in the Target Object hierarchy

5 For the Inventory ID field, enable Enable CrossRef so the Inventory Cross-Reference tab appears

6 In Inventory Cross-Reference, map PDF items to Acumatica Inventory IDs manually or import all item mappings through Excel

7 Select Active for each mapped field that should be included when DocVision generates the sales order

8 Import or open the document in Import Document and use Validate Items to apply saved inventory cross-references to the PDF lines

9 Review the Details tab, line colors, and Error Message field before selecting Generate Sales Order

Target Objects and Source Fields for PDF Detail Lines

DocVision separates PDF values from their Acumatica destinations. PDF FieldName and PDF Value describe what was extracted from the uploaded document. Target Object and Source Field define where that extracted value belongs. The Import Mappings tab receives initial values automatically, and the user can manually map PDF fields to corresponding Acumatica values.

For a sales order header, the guide directs users to Sales Order and Advanced in Target Object. For a sales order line, it directs users to Sales Order, Details, and Advanced. The second path matters for Inventory ID because an item belongs to the sales order details rather than the order header. The documentation provides the hierarchy names but no Acumatica screen ID or field-selection example for Inventory ID.

Only mappings with Active selected are uploaded during sales order generation. An inventory mapping can therefore exist in the template while being excluded from the generated order if its Active checkbox is not selected. The source does not describe whether DocVision blocks generation when an inactive mapping would leave an item line incomplete.

Inventory Cross Reference for PDF Items in Acumatica

Enable CrossRef is the documented switch for item-level translation. When it is enabled for Inventory ID, DocVision displays the Inventory Cross-Reference tab. That tab is where a PDF item is paired with its Acumatica Inventory ID. The guide does not describe a separate intermediate item record or a mapping outside the PDF Import Settings template.

A similar but separate customer feature is mentioned in the guide. When Cross Reference is selected, a Customer Cross-Reference tab appears for mapping PDF customer values and locations to Acumatica customers and locations. The source does not explain whether the labels Enable CrossRef and Cross Reference represent the same control in different contexts or two distinct controls.

For inventory work, rely on the explicit instruction tied to the Inventory ID field: enable Enable CrossRef and use Inventory Cross-Reference. Customer mapping should not be treated as evidence for undocumented item-alias or item-class rules.

Manual Mapping and Excel Import for Inventory IDs

DocVision supports two documented ways to populate item cross-references. Users can manually map PDF items to Acumatica Inventory IDs, or they can import all items through Excel. Both methods populate the Inventory Cross-Reference area used when imported document lines are validated.

The manual does not show the Excel file structure, required columns, accepted file type, duplicate handling, update behavior, or error response for rejected rows. It also does not state whether a manual entry overrides an imported entry. Prepare the spreadsheet format only after confirming those details in the installed DocVision version.

Per-customer PDF mapping allows different customers to use different templates and document structures. The guide does not say whether an inventory cross-reference is shared across templates or stored separately for each customer template. That scope should be tested before the same external item value is expected to resolve across multiple PDF layouts.

Validate Items and Unmapped PDF Lines in DocVision

The Import Document screen can open an existing or previously imported document, display the PDF and its mappings, and retain the Template ID. When an item line is yellow because its item is not mapped correctly, Validate Items provides the documented recovery step.

Validate Items maps PDF items to Acumatica values and displays them in the Details tab when those items are already mapped in Inventory Cross Reference on PDF Import Settings. This condition is important: the button applies existing cross-references. The guide does not say that it creates a new inventory mapping from an unknown PDF item.

The documentation does not define a dedicated unmapped-record queue or describe how to jump directly from a yellow line to a new Inventory Cross-Reference entry. It also gives no rule for two PDF values that point to the same Inventory ID, one PDF value that could match more than one Inventory ID, blank item values, or duplicate lines. Those cases require confirmation in the installed product.

Mapping Status and Item Errors in DocVision

DocVision uses three line colors on the Import Document screen. Green indicates that everything is mapped correctly and the file is ready for sales order generation. Yellow indicates, as the guide’s example, that items are not mapped correctly. Red indicates an issue with an item line during import and is paired with an error message in the Error Message field.

The guide names the Error Message field but does not reproduce any item-line error text or provide validation rules that distinguish yellow from red. It does not state whether yellow prevents generation, whether red always blocks an order, or whether users can override either condition. Read the actual line status and Error Message value before generating a sales order.

A separate warning exists for a missing purchase order number during PDF import: The document for the mapping does not have any number. Please select an alternative PO Number. That warning concerns header mapping and Dynamic PO Number, not Inventory ID mapping, so it should not be used as an item-validation rule.

Mapping Features Not Defined in the DocVision Guide

The source documents direct PDF-item-to-Inventory-ID cross-references, but it does not define SKU aliases, alternate identifiers, item-class defaults, wildcard or partial matching, case sensitivity, leading-zero treatment, UOM conversion, or automatic item creation. It does not identify a precedence rule when several cross-references could match the same PDF value.

The guide also does not provide an unmapped-item inquiry, an export of missing values, a cross-reference audit report, or named validation rules. The only documented operational evidence is the mapping data, the Active checkbox, the Details tab, the three line colors, Validate Items, and the Error Message field. Keep any broader mapping requirement separate until it is verified against the installed DocVision customization.

Where to Check Your DocVision Inventory Mapping

Use the documented screens and fields below to review the mapping before and after a sales order is generated.

1 In PDF Import Settings, confirm that the correct customer template and PDF are open

2 In Import Mappings, review PDF FieldName, PDF Value, Target Object, and Source Field

3 For Inventory ID, confirm that Enable CrossRef is enabled and Inventory Cross-Reference is available

4 In Inventory Cross-Reference, confirm that each known PDF item points to the intended Acumatica Inventory ID

5 Confirm that Active is selected for every field that should be included during sales order generation

6 In Import Document, select the document number and confirm its Template ID and mapping details

7 Use Validate Items and inspect the mapped values in the Details tab

8 Review green, yellow, or red line status and read any Error Message value

9 After Generate Sales Order runs, confirm the order number, order type, Generated checkbox, and document number on the Sales Order screen

DocVision Inventory ID Mapping Frequently Asked Questions

Where are PDF items mapped to Acumatica Inventory IDs?

Enable Enable CrossRef for Inventory ID in PDF Import Settings. DocVision then shows the Inventory Cross-Reference tab, where PDF items can be mapped to Acumatica Inventory IDs.

Can DocVision import inventory mappings from Excel?

Yes. The guide says users can import all items through Excel as an alternative to manual mapping. It does not document the spreadsheet columns or validation rules.

Which Target Object should be used for a sales order item line?

Select Sales Order, Details, and Advanced in Target Object for sales order detail fields. The source distinguishes this from Sales Order and Advanced for header fields.

Why is a DocVision item line yellow?

Yellow can indicate that an item is not mapped correctly. If the PDF item already has an Inventory Cross Reference, use Validate Items to map it to the Acumatica value and display it in Details.

What does a red item line mean in DocVision?

Red indicates that an item line had an issue during import. Read the Error Message field for that line. The guide does not provide an error catalog or corrective steps for specific messages.

Does Validate Items create a mapping for an unknown PDF item?

The guide only says Validate Items maps items that are already present in Inventory Cross Reference. It does not state that the button creates a new mapping for an unknown value.

Can DocVision map inventory by item class or alias?

The documentation does not describe item-class rules, aliases, or automatic matching. It documents direct PDF item to Acumatica Inventory ID cross-references.

How do I know the mapped document generated an Acumatica sales order?

After generation, the imported document should show the order number and order type, and Generated should be selected. The document number should also be visible on the Sales Order screen.

Work With Biz Tech Services on DocVision Mapping

A documented DocVision inventory-mapping process links extracted PDF item values to Acumatica Inventory IDs in Inventory Cross-Reference, activates the required detail fields, and validates imported lines before order generation. The Import Document colors and Error Message field provide the available exception evidence.

If your team needs help configuring DocVision templates, inventory cross-references, or PDF line validation in Acumatica, visit https://biz-techservices.com to contact Biz-Tech Services or schedule a personalized demonstration.

The post How to Map PDF Line Items to Acumatica Inventory IDs with DocVision appeared first on Biz-Tech Services.