Month: October 2026

How to Configure Serialized and Non-Stock Gift Cards in Acumatica

Configuring serialized and non-stock gift cards in Acumatica starts with choosing the item model that matches how each card will be created, numbered, received, and selected on an order. A non-stock gift card can use numbers generated from Gift Card Preferences, while a stock gift card must be a serialized stock item whose serial number is received and allocated before sale.

The Biz-Tech Services Gift Card Processing product supports both models and also provides a documented mapping path for gift cards imported from an external system. This guide concentrates on item-level setup, external SKU mapping, and the checks that distinguish a valid configuration from an incomplete one.

What Serialized and Non-Stock Gift Card Items Are

A non-stock gift card item is an Acumatica Non-Stock Item associated with the Gift Card Payment Method. It can be sold in Acumatica or mapped to an external gift card for external order import. Its gift card number may be entered manually or generated from the setup on the Gift Card Preferences screen (BZ102000).

A serialized gift card is created as a stock item on the Stock Items screen (IN202500). The documentation states that the Payment Method field is enabled only for serialized items, so a serial class specifically for the gift card item must be created. This model also brings the stock receipt and allocation controls documented for stock gift cards.

The two models therefore use different sources for the number attached to the gift card. The non-stock model can generate a number when an item and quantity are entered on a sales order. The stock model uses a serial number created during receipt and selected from available values during allocation on the sales order.

Gift Card Item Configuration at a Glance

Use this sequence to keep the item, payment method, numbering, and external mapping decisions aligned.

1 Create the Gift Card Payment Method on the Payment Methods screen (CA204000), connect the appropriate cash account, and set a Default Gift Card if one should appear automatically during payment creation.

2 For a non-stock model, prepare the Acumatica Non-Stock Item that uses the Gift Card Payment Method.

3 On Gift Card Preferences (BZ102000), select a Default Gift Card Item for external order import when one default item should represent external gift cards.

4 If external orders can contain multiple gift card SKUs, select Use Multiple Gift Cards in Commerce and map each documented External Gift Card SKU to the corresponding Acumatica Gift Card Item.

5 Choose Gift Card Numbering with Numbering Segments, including the required Auto-Incremental Value, or select Use Random Numbering for automatically generated random numbers.

6 For a stock model, create the item on Stock Items (IN202500), assign a gift-card-specific serial class, associate the Payment Method, and configure expiration tracking when required.

7 Receive stock gift card quantities and generate their serial numbers before trying to allocate them on a sales order.

8 Validate the resulting gift card item, number, and stock status on the documented setup, order, payment, and gift card inquiry screens.

Configure the Gift Card Payment Method Foundation

Both item models depend on the payment method setup. The documentation directs administrators to the Payment Methods screen (CA204000) to create a new Payment Method. Because payment methods are linked to cash accounts, it strongly recommends creating a new general ledger account for the newly created gift card item and adding the Gift Card Payment cash account on the Allowed Cash Accounts tab.

The Default Gift Card field on Payment Methods controls which gift card appears by default in the Gift Card field of the Create Payment popup. This is a payment-entry default, not the same setting as Default Gift Card Item on Gift Card Preferences. The latter determines which non-stock item represents an external gift card during order import when multiple external gift card mapping is not enabled.

Keep those two defaults separate during review. One points to the gift card used as a payment selection; the other points to the non-stock inventory item used when an external order is imported. The source documents both fields but does not describe a validation message that warns if administrators confuse them.

Configure a Non-Stock Gift Card Item and Its Numbering

The non-stock setup is the direct choice when the business wants Acumatica to treat the gift card as a Non-Stock Item and generate or accept a gift card number during order entry. The documentation says that the corresponding Acumatica Non-Stock Item for which the Gift Card Payment Method is selected can be used as a Gift Card Item and can also be mapped to external gift cards for external order import.

Open Gift Card Preferences (BZ102000) screen to control automatic numbering. When Gift Card Numbering is selected, the Numbering Segments tab becomes available. Define the numbering structure there and configure the Auto-Incremental Value, which the source identifies as essential for automatic gift card number generation.

Use Random Numbering is the alternative. When it is selected, the Numbering Segments tab is hidden. The system then generates random numbers when a gift card item and quantity are entered on a sales order. The generated values appear in the Gift Card Numbers popup. The manual says this mode prevents users from relying on a predefined numbering sequence.

For an order created in Acumatica, the gift card number can be entered manually or produced according to Gift Card Preferences. The Gift Card Numbers popup is tied to the selected item line. When quantity is greater than one, the numbers are shown in the popup. The source also states that the shipping rule for the corresponding non-stock gift card becomes Ship Complete on the sales order line.

Map External Gift Card SKUs in Gift Card Preferences

Gift Card Preferences (BZ102000) is the documented mapping point between external gift card items and Acumatica gift card items. The Default Gift Card Item field accepts the non-stock item that should represent an external gift card during order import. If Use Multiple Gift Cards in Commerce is not selected, external order import uses that default non-stock item.

Select Use Multiple Gift Cards in Commerce when the external system sends more than one gift card SKU and those SKUs must resolve to different Acumatica gift card items. The documentation states that this option allows an External Gift Card SKU to be mapped to the corresponding Acumatica Gift Card Item, and that the mapping is used when processing orders involving multiple gift cards.

A practical review should therefore compare the external SKU and the Acumatica item selected in each documented mapping. The manual does not name the individual grid columns beyond External Gift Card SKU and Acumatica Gift Card Item, and it does not describe a separate alias, cross-reference, or alternate-ID table. Use only the fields shown in Gift Card Preferences rather than assuming that another Acumatica cross-reference screen participates in this product workflow.

The documentation also does not state what happens when an incoming external gift card SKU has no matching row while Use Multiple Gift Cards in Commerce is selected. It provides no rejection message, fallback rule, error inquiry, or automatic record-creation behavior for an unmapped SKU. Test that case in a non-production environment and document the observed result before relying on it in live imports.

Configure a Serialized Stock Gift Card Item

Create a stock gift card on the Stock Items screen (IN202500). Associate the chosen item with the Payment Method used for gift card payments. The source states that the Payment Method field is enabled only for serialized items, so create and assign a Serial Class specifically for the gift card item before expecting that field to be available.

If the gift card requires an expiration date, select Track Expiration Date for its serial class. The documentation says the expiration date is established during the gift card receipt process. It does not describe setting or replacing the expiration date as part of the sales order mapping step.

Receive the item before sale. On the Receipts screen, add the Gift Card Item, enter the quantity, and generate the serial numbers with their respective expiration dates in the Line Details popup when expiration tracking is selected. The manual does not provide a screen ID for the Receipts screen or the Lot/Serial Classes screen, so none should be inferred from standard product knowledge.

On the Sales Orders screen (SO301000), allocation is required for stock gift card items. Select the serial number from the Lot/Serial Nbr field on the Line Details tab. The available gift card-related serial numbers and their expiration dates are displayed there. This is the documented stock-item selection rule; it is different from generating a new non-stock number through Gift Card Preferences.

Apply Stock Receipt and Sales Order Validation

The source documents several configuration conditions that can be checked without inventing application behavior.

1 Confirm that the Payment Method is associated with the gift card item. For a stock item, confirm that the item is serialized because the Payment Method field is enabled only for serialized items.

2 If Gift Card Numbering is used for non-stock cards, confirm that Numbering Segments are visible and that Auto-Incremental Value is configured.

3 If Use Random Numbering is selected, expect Numbering Segments to be hidden and check the Gift Card Numbers popup after entering the sales order quantity.

4 If multiple external gift card products are expected, confirm that Use Multiple Gift Cards in Commerce is selected and review each External Gift Card SKU to Acumatica Gift Card Item mapping.

5 If the stock card tracks expiration, enter the expiration date while generating serial numbers during receipt.

6 Before selling a stock gift card, confirm that a received serial number is available for allocation in Lot/Serial Nbr on the sales order Line Details tab.

7 After sale, confirm that the Gift Card tab on Payment Methods contains Customer ID, Inventory ID, Gift Card Serial Number, Order Number, Gift Card Amount, Used Amount, and Remaining Amount.

The manual does not provide the exact text of any validation error raised when these conditions are missing. It documents the required setup and expected field availability, but it does not identify a formal validation-rule list, severity level, or error code.

Handle Mapping Topics the Documentation Does Not Define

The source provides one explicit item-mapping mechanism: External Gift Card SKU to Acumatica Gift Card Item on Gift Card Preferences (BZ102000), enabled through Use Multiple Gift Cards in Commerce. It also provides one defaulting mechanism: Default Gift Card Item for external order import when multiple gift card mapping is not selected.

It does not document Acumatica item cross-references, vendor or customer part numbers, aliases, wildcard mappings, case sensitivity, duplicate external SKUs, or precedence between a mapping row and another inventory identifier. It also does not describe how unmapped records are queued, rejected, logged, or corrected. Administrators should not design those behaviors from assumptions about another connector or standard Acumatica feature.

Item classes are also absent from the Gift Card Processing manual. No item class is required by name, no class-level default is described, and no inheritance rule is given for the Payment Method, Serial Class, or gift card flags. If an implementation uses item classes for internal governance, validate that local design separately; it is not part of the documented product mapping.

Finally, the manual does not state that a serialized stock gift card can be selected as Default Gift Card Item for external imports. Its definition identifies that field as a Non-stock Item. Follow that documented restriction unless Biz-Tech Services supplies product-specific guidance for a different configuration.

Where to Check Your Work

Use these documented screens and fields to confirm the configuration from setup through the resulting gift card record.

1. Payment Methods (CA204000): confirm the Gift Card Payment Method, Allowed Cash Accounts, the payment-level Default Gift Card selection, and the Gift Card tab after sale.

2. Gift Card Preferences (BZ102000): confirm Default Gift Card Item, Use Multiple Gift Cards in Commerce, each External Gift Card SKU mapping, Gift Card Numbering, Use Random Numbering, and Numbering Segments when visible.

3. Stock Items (IN202500): confirm that the stock gift card is serialized and that the Payment Method is associated with the item.

4. The item serial class: confirm Track Expiration Date when expiration control is required. The source does not provide the Lot/Serial Classes screen ID.

5. The Receipts screen and Line Details popup: confirm the received quantity, generated serial numbers, and expiration dates when tracked. The source does not provide the Receipts screen ID.

6. Sales Orders (SO301000): for non-stock cards, check Gift Card Numbers on the selected line and in the popup; for stock cards, check Lot/Serial Nbr on Line Details and confirm allocation.

7. Gift Card History (BZ407099): confirm External Gift Card and Is Stock Gift Card indicators and review the card record reached through its serial number.

8. Gift Card Summary: review the corresponding gift card information. The source names this screen but does not provide its screen ID.

Serialized and Non-Stock Gift Card Configuration Frequently Asked Questions

What is the main difference between serialized and non-stock gift cards in Acumatica?

A non-stock gift card can receive a manually entered number or a number generated from Gift Card Preferences. A stock gift card must be serialized, received into stock, and allocated by its available Lot/Serial Nbr on the sales order.

Where do I map an external gift card SKU to an Acumatica item?

Use Gift Card Preferences (BZ102000). Select Use Multiple Gift Cards in Commerce, then map the External Gift Card SKU to the corresponding Acumatica Gift Card Item.

What happens when Use Multiple Gift Cards in Commerce is not selected?

External order import uses the Non-Stock Item selected in Default Gift Card Item. The documented default applies instead of individual external SKU mappings.

Why is the Payment Method field unavailable for my stock gift card item?

The documentation states that the field is enabled only for serialized items. Create and assign a Serial Class specifically for the gift card item, then review the stock item setup again.

Why did the Numbering Segments tab disappear?

The tab is hidden when Use Random Numbering is selected. Clear that option and use Gift Card Numbering when the implementation requires a predefined numbering structure.

Where is the expiration date entered for a serialized gift card?

Select Track Expiration Date for the serial class, then enter the expiration date when serial numbers are generated during the gift card receipt process. The source does not describe adding it during sales order mapping.

Does the product use item cross-references or aliases for gift card mapping?

The documentation does not say that it does. It documents External Gift Card SKU to Acumatica Gift Card Item mapping on Gift Card Preferences and does not define a separate cross-reference or alias process.

How does Acumatica handle an unmapped external gift card SKU?

The manual does not define the result, error message, fallback, or correction queue for an unmapped SKU when multiple mapping is enabled. Test the condition outside production and obtain product-specific guidance before establishing an operating procedure.

Work With Biz-Tech Services Gift Card Processing

A reliable gift card item configuration keeps three decisions distinct: whether the item is non-stock or serialized stock, how its number is created, and how an external SKU resolves to an Acumatica item. Gift Card Preferences handles documented defaulting and external SKU mapping, while serialized stock cards add receipt, expiration, and allocation controls.

If you need help validating serialized and non-stock gift card setup, external SKU mappings, or numbering behavior in your Acumatica environment, visit https://biz-techservices.com to speak with Biz-Tech Services about Gift Card Processing.

Chech also Youtube video for detailed explanation: https://www.youtube.com/watch?v=FyVcs9bR5NY

by Gary

How to Map Consignment Items to Customer Locations in Acumatica

Mapping consignment items to customer locations in Acumatica means associating a customer with a consignment warehouse and placing the correct inventory items on that customer's Consignment Order. The Biz-Tech Services Consignment Processing product then uses the selected customer, warehouse, order lines, and quantities to track stock held at the customer location.

This mapping is operational rather than a separate item-master cross-reference process in the supplied product documentation. The documented flow identifies the customer location through its Consignment Warehouse, identifies products through inventory items on the Consignment Order, and validates the result through quantities and order status. This guide focuses on that relationship and does not repeat the full configuration, shipment-to-invoice, sales order, or location-tracking workflows covered in earlier consignment articles.

Consignment Item Mapping Definition and Prerequisites

Consignment Processing is designed to manage the location, quantity, and valuation of inventory held by customers. It shows sold and unsold quantities and supports invoicing sold items or returning unsold items from a Consignment Order. For item mapping, the important relationship is customer to Consignment Warehouse to inventory item line. The documentation does not define a separate mapping screen where an external stock keeping unit, or SKU, is translated to an Acumatica Inventory ID.

Before building this relationship, the customization package must be published through the Customization Projects form (SM204505). The Sales Order Preferences form (SO101000) must contain the Consignment Order Type, Consignment Invoice Order Type, Consignment Return Order Type, and Consignment Warehouse settings. The warehouse used for consignment must have the Use for Consignment checkbox selected on the Warehouses form (IN204000).

The Consignment Order Type is based on the Transfer Order template, the Consignment Invoice Order Type is based on the Invoice Order template, and the Consignment Return Order Type is based on the Transfer Order template. These order types establish how the documented transactions are created. They do not create item aliases or customer-specific SKU translations.

Consignment Item Mapping Step by Step

Use the following sequence to establish and verify the documented relationship in Acumatica.

1 Confirm that the destination warehouse is marked Use for Consignment on Warehouses (IN204000).

2 Associate the customer with the appropriate Consignment Warehouse. The customer-specific warehouse overrides the default Consignment Warehouse from Sales Order Preferences.

3 Open Sales Orders (SO301000) and select CN as the Order Type.

4 Select the corresponding Customer. This selection associates the Consignment Order with that customer and determines the customer-specific Consignment Warehouse when one is assigned.

5 Add each inventory item that will be shipped on consignment. The item and quantity on each order line are the documented product-level identifiers for the relationship.

6 Review the warehouse roles before processing. The consignment warehouse can be selected only as the destination warehouse, and a standard non-consignment warehouse can be selected only on the lines.

7 Complete Shipment Confirmation and run Update IN from the Actions menu. The system issues the item quantities from the main warehouse and receives them into the selected consignment warehouse.

8 Verify the customer, warehouse, inventory items, quantities, and resulting Consignment or Partial Consignment status before users sell, return, or count the stock.

How the Customer Location Controls the Mapping

The selected customer is the first control in the mapping. The documentation states that the specific Consignment Warehouse associated with the customer is used for the sales order. This customer-level choice overrides any default warehouse entered under Consignment Settings on Sales Order Preferences.

Inage_4_Customers_ShippingTab_ConsignmentWarehouse

That override matters when multiple customers hold consigned stock. A single default warehouse may help populate a new order, but the customer-specific Consignment Warehouse is the documented way to direct the order to the relevant customer location. Before adding item lines, confirm that the customer record points to the intended consignment warehouse.

The documentation does not name a customer form ID, a customer-location tab, or a field other than Consignment Warehouse for this association. It also does not describe separate behavior for multiple locations under the same customer. If the implementation needs one warehouse per customer location, confirm that design in the configured Acumatica environment before loading orders.

How Inventory Items and Quantities Represent the Product Mapping

The item-level side of the mapping is created when the user adds Item(s) to the Consignment Order. After shipment and Update IN, the same items and quantities become part of the stock at the selected consignment warehouse. The documentation later uses the Item Selection pop-up to identify the items and quantities that will be sold or returned.

For a sale, Consignment Sell Items opens Item Selection. The user selects the items and quantities, then clicks Add & Close. The system creates a Consignment Invoice Order with the specified warehouse, items, and quantities. After the invoice is prepared and released, Cons. Sold Qty. on the original Consignment Order is updated.

For a return, Consignment Return Items opens Item Selection. The user selects the items and return quantities and clicks Add & Close. The system creates a Consignment Return Order. Running Update IN for the return creates a Purchase Receipt according to the documented return process.

These actions preserve the connection among the customer, consignment warehouse, item line, and quantity. They do not document a second product identifier, external SKU, or customer-specific item number.

Cross References Aliases and Item Classes

The supplied Consignment Processing documentation does not describe cross-references, alternate IDs, aliases, customer part numbers, external SKUs, barcodes, or item-class mapping. It does not identify a screen, field, import, or rule that translates one product code into another. Therefore, an article based on this source cannot claim that the product automatically resolves an alias to an Acumatica Inventory ID.

The documentation also does not state that item classes control whether an item can be placed on a Consignment Order. It names inventory items and inventory IDs, but it does not define class-based inclusion, exclusion, defaults, or validation. Treat item-class behavior as an implementation question unless it is confirmed in the configured system or in separate approved documentation.

A practical review should use the Inventory ID already present in Acumatica and make sure the intended item appears on the Consignment Order for the correct customer and warehouse. If a business requires aliases or customer-specific SKUs, that requirement needs separate design and validation outside the behavior documented for Consignment Processing.

Warehouse Rules That Validate the Location Relationship

Warehouse designation is the only explicit mapping validation described in the documentation. A warehouse becomes eligible as a consignment warehouse when Use for Consignment is selected on Warehouses (IN204000). The selected consignment warehouse is allowed only as the destination warehouse. A standard non-consignment warehouse is allowed only on the lines.

If those roles are reversed, the documentation says that an error message with a corresponding notification appears. It does not provide the message text, error code, or a list of conditions that trigger it. Troubleshooting should therefore begin by comparing the destination warehouse and line warehouse against the documented designation rule rather than searching for an undocumented message string.

This rule validates the warehouse relationship, not the identity of an item. The source does not describe validation for inactive inventory items, duplicate aliases, missing cross-references, restricted item classes, or customer-specific product eligibility.

Unmapped Records and Documented Source Limits

The documentation does not define an unmapped-record queue, exception inquiry, mapping status, retry action, or rejection report. It also does not explain what happens when an external SKU cannot be matched, because no external item feed or alias mapping flow is documented for this product.

Within the documented workflow, a missing relationship is more likely to appear as an incorrect or absent customer warehouse selection, an item missing from the order, a quantity that does not agree with the physical stock, or a warehouse-role error. Those are review points, not named product error categories.

Do not interpret a blank alias or missing cross-reference as a Consignment Processing failure unless the implementation includes a separate customization or integration that uses those fields. Keep the documented consignment relationship separate from any external product-master mapping performed by another system.

Physical Inventory as an Item Location Reconciliation Check

Physical inventory provides a documented way to reconcile inventory held at customer locations. On Physical Inventory Types (IN208900), a PI Type can be created with Consignment Inventory Count selected. When that checkbox is enabled, Customer and Location fields are displayed and specified for the PI Type. Consignment orders must already exist for the relevant customer and warehouse.

On Prepare Physical Count (IN504000), select the consignment PI Type ID. The form displays the related Inventory IDs and Book Qty. The documentation defines Book Qty as the sum of Open Qty from the Item Selection pop-up of related Consignment Orders for the specified customer and warehouse.

Generate PI to open Physical Inventory Review (IN305000), enter the actual value in Physical Qty. for each line, and use Finish Counting. Complete PI then generates a Consignment Invoice order based on the recorded physical quantities. After the invoice is released, verify that Open Qty in Item Selection on the original Consignment Order reflects the new balance.

Where to Check Your Work

Use these checks to confirm that items are tied to the intended customer location.

1 On Warehouses (IN204000), confirm that the destination warehouse has Use for Consignment selected.

2 On the customer record, confirm that the intended Consignment Warehouse is associated with the selected customer.

3 On Sales Orders (SO301000), confirm CN as the Order Type and verify the Customer before reviewing the item lines.

4 Confirm that each item and quantity on the order matches the stock being sent to that customer location.

5 Confirm that the consignment warehouse is the destination and that the standard non-consignment warehouse appears on the lines.

6 After Update IN, confirm the Consignment or Partial Consignment status and review the item quantities on the Consignment Order.

7 Use the Consignment Orders Generic Inquiry for order-level information and Consignment Item Details for open item-level information.

8 For a physical count, verify Inventory ID, Book Qty, Physical Qty., and the revised Open Qty after Complete PI and invoice release.

9 Remember that Consignment Item Details no longer displays item-level information for a Closed order. Order-level information remains available in Consignment Orders.

Consignment Item Mapping Frequently Asked Questions

Does Consignment Processing include a separate item mapping screen?

The supplied documentation does not identify a separate mapping screen. It documents the customer's Consignment Warehouse and the inventory items entered on the Consignment Order as the working relationship.

Can I map a customer SKU or alias to an Acumatica Inventory ID?

The documentation does not describe aliases, customer part numbers, alternate IDs, or SKU cross-references. Do not assume that Consignment Processing performs that translation without separate approved documentation or testing.

Do item classes control which products can be consigned?

No item-class rule is documented. The source names items and Inventory IDs but does not state that an item class includes, excludes, or defaults products for consignment.

Why did the default consignment warehouse change after I selected the customer?

A customer-specific Consignment Warehouse overrides the default warehouse from Sales Order Preferences. Verify the warehouse associated with the selected customer.

Why does Acumatica reject the warehouse selection?

Confirm that Use for Consignment is selected for the destination warehouse on Warehouses (IN204000). The consignment warehouse can be used only as the destination, while a standard non-consignment warehouse can be used only on the lines. The source does not provide the exact error text.

Where can I see item level consignment records?

Use the Consignment Item Details Generic Inquiry for item-level information on orders that are not Closed. Closed orders disappear from that inquiry, while order-level records remain in Consignment Orders.

How can I find quantity differences at a customer location?

Use a PI Type with Consignment Inventory Count selected, prepare the count on IN504000, enter Physical Qty. on IN305000, and complete the count. Compare Book Qty, Physical Qty., and the revised Open Qty on the original order.

What happens to the item relationship when the consignment order closes?

When all ordered items have been shipped and all shipped items have been sold or returned, the order changes to Closed. Consignment Sell Items and Consignment Return Items are disabled, and Consignment Item Details no longer shows the item-level information for that order.

Work With Biz Tech Services Consignment Processing

A reliable consignment item relationship starts with the correct customer, the correct customer-specific Consignment Warehouse, and accurate Inventory IDs and quantities on the Consignment Order. The documented checks in Sales Orders, the consignment inquiries, and physical inventory help confirm that stock remains tied to the intended customer location.

If your team needs help configuring or validating Consignment Processing in Acumatica, visit https://biz-techservices.com to learn more about Biz-Tech Services and schedule a personalized consultation.

Check the YouTube video for visual explanation: https://www.youtube.com/watch?v=afFwt8-gZCM

by Gary

How to Map Kit Components to Finished Kit Items in Acumatica

Mapping kit components to finished kit items in Acumatica starts with a kit specification, its current revision, and the component rows assigned to that revision. The Biz-Tech Services Kit Processing product for Acumatica lets a user expose those component rows during sales order processing, while the kit item remains the item being sold or assembled.

For a mapping project, the important distinction is between what the Kit Processing documentation names and what it does not name. It documents Inventory ID, Kit Inventory ID, stock and non-stock components, option categories, option codes, substitute items, kit revisions, and a placeholder item. It does not document a separate SKU-alias table, cross-reference maintenance process, item-class mapping rule, or automated unmatched-record queue. Those requirements should be defined outside this product documentation before an import or integration is approved.

What Kit Component Mapping Means in Acumatica

A finished kit is identified by the Kit Inventory ID on the Kit Specifications screen. The kit must already be marked as a kit on Stock Items IN202500 or Non-Stock Items IN202000. The Kit Assembly feature must be enabled on Enable Disable Features CS100000 for the Kit Specifications form to be available. Within a kit specification, the selected revision supplies the component definition used by the product.

This is a component-to-kit relationship, not a general product-master translation service. A stock component and a non-stock component can be added to a kit specification. A nested kit can also be used as a component or option, with the main kit treated as the Parent Kit and the included kit treated as the Child Kit. That documented structure is the reliable basis for deciding which component belongs to which finished kit.

Kit Component Mapping in Acumatica at a Glance

Use this sequence to establish and validate the documented mapping before a kit is used on a sales order, purchase order, or kit assembly.

1 Confirm that the intended finished item is a stock or non-stock item marked as a kit.

2 Open Kit Specifications and select the Kit Inventory ID and the correct revision.

3 Make the intended revision current and active before expecting the kit to explode on a sales order.

4 Add stock and non-stock component items to the kit specification, or define option components where the kit has options.

5 If a component can be replaced, enable component substitution and assign the allowed substitute item or items.

6 If the kit uses a placeholder after explosion, confirm that the placeholder is a non-stock item and that its unit of measure matches the kit item.

7 Test the kit in Component Details before explosion, then use Load Components or enter a quantity to verify the resulting lines.

8 Treat any external SKU alias, cross-reference, item-class rule, or unmatched-record handling as a separate control because the documentation does not describe it.

Start With the Finished Kit Item and Revision in Acumatica

The Kit Inventory ID anchors the mapping. The documentation says that this ID is the inventory ID assigned to the kit on Stock Items IN202500 or Non-Stock Items IN202000. The Non-Stock indicator is read only on the Kit Specifications form, and Revision ID uniquely identifies the kit specification revision.

A revision must be current for the kit item to explode on the sales order. Changing the Current Revision setting can uncheck the prior current revision after the user saves the change. This makes revision selection a validation step, not merely a description field. A component relationship can be correctly entered on an older revision yet still not be the relationship used by an order.

The source documents Active separately from Current Revision. Keep both states in the review process: use the relevant active specification and confirm that the revision intended for order processing is current. The documentation does not define an item-class rule that selects a kit or revision, so do not assume an item class will perform that mapping.

Map Stock and Non Stock Components to the Kit in Acumatica

The kit specification holds the documented component mapping. Stock and non-stock items can be associated with a kit, and option codes can also contain stock items, non-stock items, and kit items. In the Kit Pricing Summary, the component display loads stock components first and then non-stock components, which is useful when checking the composition of a selected kit.

When a kit is added to a sales order, Component Details provides the operational view of its mapped components. Before explosion, a user can add or delete components, exchange a component for a substitute item, and change options. The source also states that when component addition is not enabled, users cannot add new components but can delete existing ones before explosion. After explosion, Component Details is limited to changing Quantity and Warehouse; further component additions or deletions are handled from the Document Details tab with the available controls.

This behavior helps distinguish the finished-kit mapping from the order-level result. The kit definition supplies the initial components; the sales order can show or adjust permitted component details before and after explosion. The documentation does not describe a line-level field that maps an external SKU to an Acumatica component. If an outside record must identify a component, that field mapping needs its own design and test evidence.

Use Acumatica Options and Substitutions as Controlled Mapping Variations

Options are the documented way to vary a kit configuration. With Kit has options enabled, Option Category and Option Codes tabs appear. An option code is assigned to an option category, given an option price, and associated with stock, non-stock, or kit items. A Required option code must be selected in the Options popup before the kit order can proceed.

Default Code provides a documented fallback for cases in which a user cannot select options, including API, import scenarios, processing screens, Opportunities, and Sales Quotes. It is a default option selection, not a documented alias or SKU cross-reference mechanism. Option Rules can exclude a target option code when a specified source category and source code are selected. Review these rules as part of mapping validation because they can make a component option unavailable to the user.

Component substitution is another controlled variation. Enable Allow Component Substitution, mark the component on the Stock Components tab, and assign replacement items on the Substitution tab. The Biz-Tech Services Kit Processing product for Acumatica therefore documents substitutions as explicit item choices linked to a component. It does not state that substitutions are selected through item classes, aliases, or an automatic cross-reference lookup.

Handle Acumatica Placeholder and Explosion Settings Before Testing Lines

When Explode Kit is selected, the product enables Kit Placeholder Item, Explode Option, and Price Calculation. The placeholder is a non-stock item that replaces the kit item on the sales order after explosion while the component items are added to the order. Its purpose is to prevent double counting of item costs while functioning like the kit item in the order.

The placeholder unit of measure must match the kit item unit of measure. A mismatch produces a warning error message. Explosion may be Prompt, Automatically, or Do Not Explode. A customer or vendor setting named Block Kit Items Explosion, as well as the Biz-Tech Kit Processing Settings section on Order Types, can prevent explosion regardless of the selected explode option.

For a non-stock kit with a stock option item, the documentation requires Automatically as the explode option so the stock option is allocated during shipment. For a nested non-stock kit used as a component or option, both the Parent Kit and Child Kit must use Automatically. These are configuration validation rules that affect whether the mapped items reach the expected order lines.

Validate Acumatica Mapping Through Sales Orders Assemblies and Imports

A practical test begins by entering the kit item on a sales order and reviewing Component Details. Use Load Components to explode the kit, or assign a quantity to the new kit item. After explosion, the placeholder and components appear on the order with their prices, quantities, and costs. The documented Total Cost of Components uses the component unit cost when the sales order is created multiplied by quantity, remains unchanged, and is displayed on the placeholder row and carried to the invoice.

For kit assembly, select the kit Inventory ID, revision, warehouse, and quantity on the Kit Assembly screen. The generated document includes required stock components with quantities and costs based on the selected revision. A kit assembly can also be generated from a sales order without exploding the kit; sales-order-generated assemblies use the current Kit Specifications revision. Mark for assembly is disabled for non-stock kit items.

The documentation also supports Import by Scenario for kit items and says to perform proper data mapping between an external data source and corresponding Acumatica fields. Its listed scenarios enable Is a Kit for stock or non-stock items, configure the kit header, add stock components, add non-stock components, add option categories and option codes with associated components, and add substitute items. This supports structured import of the documented kit relationships. It does not specify how to resolve duplicate SKU aliases, cross references, item classes, or unmatched external records.

Where to Check Your Acumatica Mapping Work

1 Enable Disable Features CS100000 to confirm that Kit Assembly is enabled when Kit Specifications or Kit Assembly work is required.

2 Stock Items or Non-Stock Items to confirm the finished item is marked as a kit.

3 Kit Specifications to verify Kit Inventory ID, Revision ID, Current Revision, Active, and Explode Kit settings.

4 Stock Components and non-stock component entries to confirm the intended kit composition.

5 Option Category and Option Codes tabs to check required selections, default codes, prices, and option components.

6 Option Rules to verify that a chosen source option is not excluding an expected target option.

7 Substitution tab to confirm each allowed replacement item for an eligible component.

8 Sales Orders Component Details to inspect components, options, substitutions, and the result of Load Components.

9 The placeholder row after explosion to check the unit of measure, cost total, and component lines.

10 Kit Assembly to verify inventory ID, selected revision, warehouse, quantity, and any linked sales order.

11 Import by Scenario to confirm the selected kit import scenario and the source-to-field mapping used by the import.

Kit Component Mapping in Acumatica Frequently Asked Questions

Can an Acumatica kit map both stock and non-stock components?

Yes. The documentation describes stock and non-stock components in the kit specification and in the kit import scenarios. It also states that option codes can include stock items, non-stock items, and kit items.

What makes a kit revision available for sales order explosion?

The current revision must be enabled for the kit to explode on a sales order. The source also describes the Active setting for the kit specification, so a review should confirm the intended active specification and current revision.

Can Acumatica use a SKU alias or cross-reference to find a kit component?

The Kit Processing documentation does not describe a SKU alias or cross-reference feature for component lookup. It documents kit inventory IDs, components, options, substitutions, and import scenarios, but not an alias-resolution rule.

How are unmapped external item records handled?

The source instructs users to perform proper mapping between the external source and Acumatica fields before import. It does not define an unmatched-record queue, error disposition, or fallback behavior. Establish those controls separately and test them before production import.

Do item classes decide which component is mapped to a kit?

No item-class mapping behavior is described in the supplied Kit Processing documentation. Do not rely on item classes to choose a kit component unless another approved source documents that design.

Why does the kit not explode after the component mapping is complete?

Check the current revision, Explode Kit setting, selected explode option, and the customer or order-type controls that can block kit explosion. Also check the specific non-stock kit rules when stock option items or nested kits are involved.

Why does the kit show a placeholder line after explosion?

The placeholder is a non-stock item that replaces the kit item while the mapped component items are added to the order. The documentation says this prevents double counting of item costs.

Can a substitute item be selected for any component?

Only components configured for substitution are documented as eligible. Enable Allow Component Substitution, mark the component, and add the substitute item or items on the Substitution tab.

Work With the Biz-Tech Services Kit Processing Product for Acumatica

The Biz-Tech Services Kit Processing product for Acumatica gives teams a documented path from a finished kit Inventory ID and revision to component rows, options, substitutions, order explosion, assemblies, and import scenarios. Keep the kit specification and its current revision as the source of truth for component composition. For SKU aliases, item classes, cross references, or unmatched-record policies, create a separate documented mapping design because these behaviors are not defined by the supplied product documentation.

If your team needs help planning a reliable Kit Processing setup in Acumatica, visit https://biz-techservices.com to learn more about Biz-Tech Services or schedule a personalized demonstration.

Check the video for more details: https://www.youtube.com/watch?v=sP89DBTxCJU

by Gary

How to Sync ServiceTitan Inventory Movements with Acumatica

ServiceTitan inventory movements can be imported into Acumatica when the ServiceTitan Store is configured for inventory transactions and the related item and warehouse mappings are in place. The supplied ServiceTitan documentation identifies receipts, transfers, adjustments, and returns as supported transaction categories, but it does not define the source quantity calculation or a stock allocation process.

For an inventory workflow, the ServiceTitan Store is the control point for item handling, warehouse and branch mapping, transaction processing, purchase orders, receipts, and bills. The Biz-Tech Services ServiceTitan Acumatica Connector should therefore be configured around the mappings and import choices documented on that store record before transaction imports begin.

What ServiceTitan Inventory Sync Covers in Acumatica

The documentation describes an Inventory area on the ServiceTitan Store that can import items, generate items, load ServiceTitan materials, equipment, and services, and map warehouses. It also describes an Inventory Transactions tab with setup options for receipts, transfers, adjustments, and returns. This describes the available integration controls, rather than a complete inventory accounting design.

When Import Item is selected, Generate Item from ServiceTitan becomes available. The source says this option can generate stock and non-stock items from the selected Stock Item Class, Non-Stock Item Class, and Unit of Measure values. It also says manual mapping of ServiceTitan items to Acumatica items is possible. The Biz-Tech Services Acumatica ServiceTitan Connector can support either documented approach, subject to the store configuration.

ServiceTitan Inventory Sync at a Glance

Use this sequence as a concise checklist for the documented inventory workflow.

1 Configure the ServiceTitan Store because its settings control inventory and transaction handling

2 Select Import Item if items should be imported, then review the item generation option and its stock class, non-stock class, and UOM settings

3 Load Materials, Equipment, and Services to display ServiceTitan items on the Inventory tab in Acumatica

4 Confirm whether each ServiceTitan item is manually mapped to an Acumatica item or created through the documented generation option

5 Load ServiceTitan Warehouse and Truck IDs, then map them to Acumatica warehouses

6 Configure receipts, transfers, adjustments, and returns on the Inventory Transactions tab, including release-after-import choices

7 Import and review the resulting documents in Acumatica using the records and status behavior documented for the transaction type

Quantity Basis and Stock Visibility

The source confirms that materials and equipment create stock items, while services create non-stock items. It also identifies Unit of Measure as an input to item generation. These are the documented foundations for how imported items are classified and measured in Acumatica.

However, the documentation does not state how ServiceTitan calculates movement quantities, whether quantities are signed for each transaction type, how available quantity is displayed, or how quantity changes are reconciled to a physical count. The Biz-Tech Services ServiceTitan Acumatica Integration should be evaluated against those requirements during implementation rather than assuming an undocumented quantity basis.

Map ServiceTitan Warehouses and Trucks to Acumatica Warehouses

The Warehouses section maps Acumatica warehouses with ServiceTitan Warehouse and Truck IDs. Selecting Load Warehouses retrieves and displays ServiceTitan Warehouse and Truck ID values, which can then be manually mapped with Acumatica Warehouse values. This mapping is the documented location for connecting a ServiceTitan warehouse or truck identifier with an Acumatica warehouse.

Business units are handled separately: ServiceTitan Business Unit IDs are mapped to Acumatica branches after Load Business Units retrieves their values. Keep the warehouse map and branch map distinct, because the source presents them as separate mappings. The Biz-Tech Services Acumatica ServiceTitan Integration relies on these documented mapping records for warehouse and branch correspondence.

Configure Inventory Transaction Imports

The Inventory Transactions tab lists receipts, transfers, adjustments, and returns. The source says there are setup options for each transaction type. It also lists checkboxes for releasing a receipt, transfer, adjustment, or return after import.

When the applicable release checkbox is selected, the source says the document can be imported into Acumatica and released. The source does not describe the default status for every inventory transaction type when release is not selected, nor does it provide a transaction-by-transaction field map. The Biz-Tech Services Acumatica ServiceTitan Integrator should be configured only with the release behavior actually documented for the chosen transaction.

Item Creation and Manual Item Mapping

Load Materials, Equipment, Services retrieves and displays the corresponding ServiceTitan items on the Inventory tab in Acumatica. The source explicitly distinguishes their resulting item types: Materials and Equipment create stock items, and Service creates non-stock items.

An organization can instead manually map ServiceTitan items with Acumatica items. The source does not prescribe which method is best or explain duplicate-item handling, substitutions, lot or serial tracking, replenishment, or allocation rules. Choose the documented generation or manual-mapping option based on the item master design in Acumatica, and test it before live imports.

Purchase Receipts and Related Inventory Review

For purchase activity, ServiceTitan Purchase Orders are imported as Acumatica Purchase Orders. If a ServiceTitan Purchase Receipt or Bill already exists when the purchase order is imported, it is imported as part of the same process. A receipt or bill that does not yet exist is not imported at that time and can later be imported separately using the appropriate processing screen.

A PO receipt cannot be imported until its related purchase order has already been imported. When the purchase order exists, the receipt import locates it and attaches the receipt document in the PO History tab of the Purchase Orders screen. If Release is selected in store setup, the receipt imports with a Released status; otherwise, the source says it imports with a Balanced status. The Biz-Tech Services Acumatica ServiceTitan Integrator supports this documented order-of-operations dependency.

Allocation and Reconciliation Limits in the Documentation

The supplied source does not describe inventory allocation, reservation, availability calculations, pick or fulfillment logic, warehouse replenishment, cycle counts, or a formal inventory reconciliation report. It also does not identify stock inquiry screens, screen IDs, or fields for comparing ServiceTitan movement quantities to Acumatica quantities.

A practical review should therefore focus on what the source does document: the store configuration, item class and UOM inputs, item mappings, warehouse and truck mappings, transaction selection, release settings, and the PO History attachment behavior for imported receipts. Use implementation testing to establish any allocation or reconciliation procedure that the business needs.

Where to Check Your Work

1 ServiceTitan Stores screen for the store record and its Inventory area

2 Connection Settings tab for testing credentials used to connect to the ServiceTitan store through the API

3 Inventory tab for loaded Materials, Equipment, and Services

4 Import Item and Generate Item from ServiceTitan options for the selected item-import approach

5 Stock Item Class, Non-Stock Item Class, and Unit of Measure values used for generated items

6 Warehouses mapping area for ServiceTitan Warehouse and Truck IDs mapped to Acumatica warehouses

7 Business Units mapping area for ServiceTitan Business Unit IDs mapped to Acumatica branches

8 Inventory Transactions tab for receipts, transfers, adjustments, returns, and release-after-import choices

9 Import ServiceTitan Purchase Orders screen for the required related purchase order

10 Import ServiceTitan Receipts screen and the PO History tab of the Purchase Orders screen for an imported receipt

ServiceTitan Inventory Sync Frequently Asked Questions

Which ServiceTitan items become stock items in Acumatica?

The source states that Materials and Equipment create stock items, while Service creates non-stock items.

Can ServiceTitan items be manually mapped to Acumatica items?

Yes. The source says ServiceTitan items can be manually mapped with Acumatica items instead of being created through the generation option.

How are ServiceTitan warehouses mapped in Acumatica?

Load Warehouses retrieves ServiceTitan Warehouse and Truck ID values. Those values can be manually mapped with Acumatica Warehouse values.

Can receipts, transfers, adjustments, and returns be released after import?

The source lists a release-after-import checkbox for each of those transaction types. When selected, it allows the document to be imported and released in Acumatica.

Why cannot a ServiceTitan PO receipt be imported?

The related ServiceTitan purchase order must already be imported. The source gives the error text POOrder document for Receipt 433272225 has not been created yet for an attempted receipt import without that purchase order.

Does the connector define how inventory quantities are calculated?

No. The source identifies item classes and UOM as item-generation settings, but it does not define the movement quantity calculation or stock-availability calculation.

Does the source describe inventory allocation or reconciliation?

No. Allocation and a formal reconciliation process are not described in the supplied documentation.

Work With the Biz-Tech Services ServiceTitan Connector

The documented ServiceTitan inventory workflow centers on store setup, item generation or manual item mapping, warehouse and truck mapping, transaction configuration, and the purchase-order dependency for receipts. It does not document every inventory-control detail, especially allocation, quantity calculation, and reconciliation. For help configuring the Biz-Tech Services ServiceTitan Acumatica Connector around your Acumatica item and warehouse design, visit https://biz-techservices.com to discuss the integration with Biz-Tech Services.

by Gary

How Salesforce Orders Affect Inventory Allocation in Acumatica

Salesforce orders affect inventory allocation in Acumatica only through the sales order they create during import. The Salesforce integration documentation identifies the default warehouse, order type, item matching, and order status inquiry, but it does not document Acumatica allocation rules, available quantity calculations, lot or serial handling, or warehouse transfer behavior.

That distinction matters when a sales team expects a Salesforce order to reserve stock. The import can place the order in an Acumatica document type and default warehouse, while the inventory consequences depend on the Acumatica sales order configuration outside the supplied Salesforce documentation. This article explains the documented handoff and the checks a team should make before treating imported demand as allocated inventory.

What the Salesforce Order Import Documents

The Biz-Tech Services Salesforce Acumatica Connector provides Salesforce Store settings for order import. In Order Settings, the documented Default Import Options include Order Type and Warehouse ID. The Order Type indicates the document type where the order is imported and placed in Acumatica. Warehouse ID defines the default warehouse for the order.

The documentation also says that Get Orders retrieves Salesforce orders related to the setup date in Order Settings. Import brings selected displayed orders into Acumatica, while Import All imports all displayed orders. The Salesforce Orders Inquiry then shows the initial Salesforce order details together with the Acumatica SO number and SO status.

Salesforce Inventory Handling at a Glance

Use the following sequence to understand what the integration documents and where Acumatica inventory processing begins.

1 Configure the Salesforce Store with an Order Type and default Warehouse ID

2 Set whether customers and items can be created during order import

3 Retrieve Salesforce orders with Get Orders based on the last imported order date

4 Import a selected order or all displayed orders into the configured Acumatica document type

5 Match an order item by Salesforce Product SKU to an Acumatica Inventory CD, or create the item if Import Item is enabled

6 Review the resulting SO number and SO status in Salesforce Orders Inquiry

7 Apply your Acumatica sales order and inventory policies to determine whether the imported demand is allocated, available, shipped, or otherwise processed

The Biz-Tech Services Acumatica Salesforce Connector supports the integration setup and import path above. The supplied manual does not say that Salesforce itself calculates, commits, or reserves Acumatica quantities.

Quantity Basis Starts With the Imported Sales Order

The source documentation explains how an item is found during an order import: the integration searches the Acumatica Inventory CD using the Salesforce Product SKU. If a matching inventory item is found, it retrieves that item. If no item is found and Import Item is not enabled, the documented error is “The item {0} does not exist in the system”.

This identifies the item matching basis, but not a quantity availability basis. The manual does not state which quantity fields are evaluated before import, whether Salesforce on-hand figures are sent to Acumatica, or whether a Salesforce quantity is checked against available inventory. A team should therefore avoid representing an imported order as inventory-confirmed until its Acumatica order and inventory settings have been reviewed.

If Import Item is selected, new items can be created in Acumatica based on configured settings. If it is not selected, the program prohibits import and creation of items unless the corresponding items already exist in Acumatica. Add Items in Inventory Sync enables synchronization with Salesforce items, but the source does not define inventory quantity synchronization or stock availability synchronization.

How the Default Warehouse Shapes the Imported Order

The Biz-Tech Services Salesforce Acumatica Integration documents Warehouse ID as the field used to define the default warehouse for an order. That is the clearest warehouse control described in the manual. It means the store setup supplies a warehouse value for imported orders, rather than the manual describing a warehouse selected from each Salesforce order.

The source does not describe multiple-warehouse selection, warehouse mapping tables, location-level assignment, branch-to-warehouse logic, or reallocation after import. It also provides no screen ID for the Salesforce Store, Import Salesforce Orders, or Salesforce Orders Inquiry screens. If a business has more than one fulfillment warehouse, it should validate the imported sales order in Acumatica and confirm that the configured default Warehouse ID is appropriate for the actual fulfillment process.

Allocation Is an Acumatica Policy Decision Not a Salesforce Import Setting

The Biz-Tech Services Acumatica Salesforce Integration does not document a setting called allocation, an allocation status, or a rule that reserves stock when an order is imported. It documents the order type and default warehouse that shape where the order is placed. Whether the resulting Acumatica sales order allocates inventory depends on Acumatica configuration and operational steps that are outside this Salesforce integration guide.

For that reason, use the imported SO number and SO status as the integration evidence, not as proof of allocated stock. The manual says these values are visible in Salesforce Orders Inquiry. It does not define which SO statuses indicate allocation, shipment, backorder, fulfillment, or release. Teams should establish their own Acumatica status and allocation checks with the inventory administrator.

Stock Visibility and Item Synchronization Limits

The Biz-Tech Services Salesforce Acumatica Integrator supports item-related operations through the Item Settings and Item Details areas. Load Acumatica Items retrieves Acumatica items and displays them in a table. Sync to Salesforce creates or updates Acumatica items in Salesforce. Sync All from Salesforce retrieves and creates Salesforce items in Acumatica.

Item Details includes the synced item Salesforce ID, product code, product name, price, and weight. Those fields support product record visibility. The documentation does not list on-hand quantity, available quantity, allocated quantity, safety stock, warehouse quantity, or a stock synchronization schedule. It therefore cannot support a claim that Salesforce inventory visibility is real-time, warehouse-specific, or based on allocated inventory.

Price books have separate behavior. The Price Book Details tab can load Salesforce price books based on Last Imported Price Book Date, and Export Salesforce Price Books sends only items that have been updated or changed. Price book activity should not be confused with stock synchronization because the source describes list prices and products, not inventory balances.

Reconciliation Checks After an Import

The Biz-Tech Services Acumatica Salesforce Integrator gives operations staff a documented path for reconciling the integration result. Start in Import Salesforce Orders, where Get Orders, Import, and Import All control the import process. Then select the Order ID hyperlink to open Salesforce Orders Inquiry and compare the Salesforce order details with the Acumatica SO number and SO status shown there.

1 Confirm the Salesforce Store Order Type and default Warehouse ID before retrieving orders

2 Confirm that the imported order received the intended Acumatica SO number and SO status

3 Review whether the Salesforce Product SKU matched an Acumatica Inventory CD or required item creation

4 Review customer behavior: Import Customer creates a new customer with email, contact information, and the selected customer class, while an unselected setting uses the default customer

5 Review shipping and billing addresses because the manual documents override checkboxes, but its opposite-case wording is contradictory

6 Use your Acumatica inventory process to verify availability and allocation because the Salesforce manual does not provide those checks

Order Updates Do Not Establish Inventory Reconciliation

Sync Orders To Salesforce can process updated imported order data from Acumatica back to Salesforce. At the line level, the guide says it can update line description, discount code, discounted amount, and added or deleted lines. At the document level, it can update addresses, country, order date, description, total, freight, discount, and tax amounts.

The Biz-Tech Services Salesforce Acumatica Integrator can therefore support order-detail updates back to Salesforce. However, the guide does not say that inventory allocations, warehouse changes, quantity availability, shipments, or fulfillment statuses are sent back. It also says only modified orders with On Hold or Open status are displayed on this screen. Use that documented filter when investigating a missing order, but do not infer a broader inventory synchronization rule.

How Salesforce Orders Affect Inventory Allocation in Acumatica Frequently Asked Questions

Does importing a Salesforce order allocate inventory in Acumatica?

The supplied Salesforce integration documentation does not state that import allocates inventory. It documents the order type, default Warehouse ID, item matching, and the resulting SO number and SO status. Confirm allocation through your Acumatica sales order and inventory configuration.

Which warehouse is used for an imported Salesforce order?

The Salesforce Store Order Settings documentation says Warehouse ID defines the default warehouse for the order. The manual does not describe warehouse mapping by Salesforce order, multiple warehouses, or location-level handling.

How does the integration identify the item on a Salesforce order?

It searches the Acumatica Inventory CD using the Salesforce Product SKU. If it cannot find the item and item import is not enabled, the source documents the error The item {0} does not exist in the system.

Can Salesforce show Acumatica available quantity or allocated quantity?

The source does not document an available quantity, on-hand quantity, allocated quantity, or inventory balance synchronization feature. It documents item IDs, product code, product name, price, and weight.

Where can I verify that an order was imported?

Use the Order ID hyperlink on Import Salesforce Orders to open Salesforce Orders Inquiry. The guide says that inquiry shows initial Salesforce order details along with the Acumatica SO number and SO status.

Why did an item fail to import from Salesforce?

When Import Item is not selected, the item must already exist in Acumatica. The documented matching uses Salesforce Product SKU against the Inventory CD, and the guide gives the missing-item error text.

Can a changed Acumatica order be sent back to Salesforce?

Yes, the guide documents Sync Orders To Salesforce for selected imported order changes. It limits the displayed modified orders to On Hold or Open status and does not document inventory allocation or shipment updates.

Work With the Biz-Tech Services Salesforce Acumatica Connector

A reliable process separates what the Salesforce import is documented to do from what Acumatica inventory policy must decide. Configure the default warehouse and order type carefully, validate the imported SO number and SO status, and use Acumatica controls to confirm availability and allocation before promising fulfillment.

For help aligning Salesforce order imports with your Acumatica warehouse and inventory process, work with the Biz-Tech Services Salesforce Acumatica Connector team. Visit https://biz-techservices.com to learn more about Biz-Tech Services integrations.

by Gary

How PayPal Payments Affect Inventory and Order Status in Acumatica

PayPal payments affect order status in Acumatica by creating an Accounts Receivable payment that remains on Hold until PayPal confirms the invoice has been fully paid. The payment request can start from a sales order, an invoice, or a standalone payment, but the documented integration does not change inventory quantities, warehouse balances, allocations, or replenishment settings.

For teams using the Biz-Tech Services PayPal Acumatica Connector, the practical control point is the payment lifecycle: Sent, Partially Paid, Paid, Cancelled, Refunded, or Partially Refunded. This article focuses on that lifecycle and its relationship to sales-order and invoice payment records; for the request-creation workflow, see How to Create PayPal Invoices from Acumatica Orders.

How PayPal Payments Affect Order Status in Acumatica

The integration is a customization for sending payment invoices to customers, checking their payment status, and applying the resulting action to the AR Payment record. A request sent from Sales Orders creates an AR Payment linked to the order. A request sent from an AR invoice creates a payment pre-applied to that invoice. In either case, the initial payment is placed on Hold with a Sent status while the customer receives the invoice by email.

The integration checks the provider only when a user triggers a check. A fully paid invoice releases the payment. A cancelled invoice deletes the AR Payment. A partial payment records the amount received but keeps the original payment on Hold until the entire invoice is paid.

PayPal Payment Status at a Glance

Use this sequence to understand what the documented status check changes.

1 Sent: the invoice was sent, the AR Payment remains on Hold, and no release action occurs.

2 Partially Paid: the provider reports PARTIALLY_PAID; the PayPal Paid Amount is updated, but the AR Payment stays on Hold at its original amount.

3 Paid: the provider reports PAID or MARKED_AS_PAID; the system confirms the payment amount, releases the payment, and stores the transaction ID.

4 Cancelled: the provider reports CANCELLED; the AR Payment record is deleted.

5 Refunded: a full refund voids the payment and stores the refund ID.

6 Partially Refunded: the integration updates the status and refund ID, but a user must create a Credit Memo for the refunded amount because the payment record is not automatically partially voided.

Before You Send a PayPal Payment Request

The Biz-Tech Services Acumatica PayPal Integrator requires Accounts Receivable and Sales Orders, a Business account, and API credentials. For testing, the manual specifies a Sandbox account with its own credentials. The server must be able to reach the appropriate endpoint over HTTPS on port 443.

Set up the payment method in Payment Methods (CA205000). Enter the Client ID and Client Secret, supply the Sandbox and Live base URLs as appropriate, select Is PayPal Payment, test the connection, and add the cash or bank account on the Allowed Cash Accounts tab. When a Sandbox URL is populated, the integration uses it and ignores the Live URL.

Each payer also needs a Customer Payment Method in Customer Payment Methods (AR303010) screen with a PayPal email address. That email is carried into new payments, although it can be overridden for a one-off payment.

From Sales Order or Invoice to a PayPal Payment

The Biz-Tech Services PayPal Acumatica Integration provides three documented entry points. In Sales Orders (SO301000), use Create Payment on the Payments tab, supply the cash account and payment reference, then use New Request PayPal Payment. The integration reads the order total, currency, and customer details, creates the linked AR Payment, sends the PayPal invoice, and stores the PayPal invoice identifiers and URL on the payment.

If billing has already been posted, open the invoice through Invoices (SO303000) and use Request PayPal Payment. The payment is pre-applied to the invoice, and the PayPal invoice amount matches the outstanding AR invoice balance. For a deposit or another standalone request, create a payment in Payments and Applications (AR302000), select the PayPal method, enter the amount, optionally apply it to an order or invoice, and use Send PayPal Request.

After a request is sent, the Payment Method ID is locked to prevent an accidental change. The result is a payment-status workflow, not an inventory transaction. The manual does not describe a PayPal request as changing stock availability or shipping quantities.

How Status Checks Change the AR Payment

The Biz-Tech Services Acumatica PayPal Integration checks status on demand rather than in the background. For one payment, open Payments and Applications (AR302000), confirm that it is Sent or Partially Paid and on Hold, then select Remove Hold. The integration calls PayPal and applies the action associated with the returned status.

If the invoice is still SENT, the system reports that it cannot release the payment because it has not been paid, and no record changes are made. If it is PAID, the payment is released. If it is CANCELLED, the payment record is deleted. For several outstanding requests, use the Check PayPal Payment Status processing screen under the Sales Order Processes module, select rows, and use Process or Process All. The processing log shows results for the checked records.

Partial Payments and Refunds

The Biz-Tech Services PayPal Acumatica Integration recognizes multiple payments against the same invoice. When the provider reports PARTIALLY_PAID, the PayPal Paid Amount field receives the cumulative amount collected. The payment amount does not change, and the payment remains on Hold until the provider reports a full payment. This lets the accounts-receivable record retain the agreed amount while the customer returns to the same invoice for the remainder.

For a full refund, use Void Check or Refund on the released AR Payment. The integration calls the provider, voids the payment through the standard workflow, stores the refund ID, and sets the PayPal Invoice Status to Refunded. If a partial refund is issued directly in the portal, the next status check identifies PARTIALLY_REFUNDED, but the user must create the Credit Memo manually.

Inventory and Warehouse Scope

The article-plan topic includes inventory, warehouse, quantity, allocation, and reconciliation handling. The Biz-Tech Services PayPal Acumatica Integration user guide does not document any inventory quantity basis, warehouse mapping, inventory allocation rule, stock-visibility update, or inventory reconciliation process. Its documented scope is PayPal invoice creation and AR Payment status handling.

Accordingly, do not treat a payment status change as evidence of an inventory adjustment. The source supports monitoring payment and order-linked records, not changing inventory records. If a business needs inventory allocation or warehouse actions to follow payment collection, those rules must be confirmed in its own configuration rather than inferred from this integration guide.

Where to Check PayPal Payment Results in Acumatica

The Biz-Tech Services PayPal Acumatica Integrator exposes the following documented places and fields for payment-status review.

1 Sales Orders (SO301000): review the order Payments tab and open the linked payment record.

2 Invoices (SO303000): review the pre-applied payment created when an invoice request was sent.

3 Payments and Applications (AR302000): review payment status, Hold status, and the Remove Hold action.

4 Check PayPal Payment Status: filter by PayPal Invoice Status and use Process or Process All for outstanding rows.

5 PayPal Customer Email: confirm the address to which the PayPal invoice notification was sent.

6 PayPal Invoice Status: distinguish Sent, Partially Paid, Paid, Cancelled, Refunded, and Partially Refunded.

7 PayPal Invoice ID and PayPal Invoice Number: identify the invoice created in PayPal.

8 PayPal Invoice URL: use the documented Open in PayPal link to access the PayPal invoice.

9 Transaction ID and Refund Number: identify the confirmed payment or refund transaction.

10 PayPal Paid Amount: monitor the cumulative amount received while an invoice is Partially Paid.

PayPal Payments and Order Status in Acumatica Frequently Asked Questions

Does a PayPal payment automatically release in Acumatica?

No. The integration does not poll PayPal automatically. Use Remove Hold for an individual payment or process records in the Check PayPal Payment Status screen. The payment releases when the check confirms that PayPal reports the invoice as fully paid.

What happens when a customer makes only a partial PayPal payment?

The payment stays on Hold at its original amount. The PayPal Paid Amount field is updated, and the customer can return to the same PayPal invoice to pay the balance. Acumatica releases the payment only after the invoice is fully paid.

Can a PayPal payment status change inventory quantities or warehouse allocation?

The supplied PayPal Integration guide does not document inventory quantity changes, warehouse mapping, allocation, or reconciliation. It documents AR Payment and PayPal-invoice status actions only.

Why is a payment still Sent after the customer says they paid?

Trigger a status check manually or through the processing screen, because Acumatica does not poll PayPal in the background. Also verify that the PayPal invoice is marked PAID in the PayPal account.

Why does Remove Hold say that the payment is not paid in PayPal?

The PayPal invoice is still unpaid. The guide describes this as expected behavior; wait for payment and check again later, or use the processing screen for a bulk check.

What happens when I cancel a PayPal invoice?

A payment in Sent status and on Hold can be cancelled from AR302000. The integration calls PayPal, sends the cancellation notification, and deletes the AR Payment. The guide states that cancellation is irreversible.

How should a partial PayPal refund be handled?

The Biz-Tech Services PayPal Acumatica Integrator records the Partially Refunded status and the refund ID after a check, but it does not partially void the payment. Create a Credit Memo manually for the refunded amount.

Work With the Biz-Tech Services PayPal Integration

Payment requests give users a controlled way to send invoices, monitor collection, release a fully paid AR Payment, and handle cancellation or refund outcomes. They do not, based on the supplied documentation, define inventory or warehouse behavior. To discuss the Biz-Tech Services Acumatica PayPal Integrator and the payment workflow for your environment, visit https://biz-techservices.com to learn more or schedule a personalized demonstration.

Check the video for more details: https://www.youtube.com/watch?v=wkjPKdLzv2M

by Gary

How to Create Consignment Sales Orders in Acumatica

This guide shows you how to create a consignment sales order in Acumatica ERP, move stock into a customer-held consignment warehouse, and turn the units your customer sells into invoices without re-keying anything. Consignment selling breaks the usual rule that shipping equals revenue: the goods leave your building but stay yours until the consignee sells them. The Consignment Processing product from Biz-Tech Services, Inc. adds that distinction to Acumatica, so one order document can carry stock out, hold it at the customer site, and then bill or reclaim it piece by piece.

What follows is a hands-on walkthrough of the order itself: the setup you need before you can pick the order type, the sequence of entries and actions, the documents each action generates in Acumatica, the mapping rules that decide where consigned stock lands, and the errors and disabled buttons that stop users mid-task. Configuration is background here, mentioned only where it changes what happens during order entry.

Before You Start: What Must Be Configured

A consignment order in Acumatica will not behave correctly unless four pieces of setup are in place. The Consignment Processing customization project is published from the Customization Projects (SM204505) form, so if the Consignment Settings below are missing entirely, the package has not been published to your tenant yet.

1. Three consignment order types, defined in the Consignment Settings section of the Sales Orders Preferences (SO101000) form: the Consignment Order Type you select on the order, the Consignment Invoice Order Type used for invoices generated from consigned stock, and the Consignment Return Order Type used when unsold goods come back.

2. The right templates behind those types. The Consignment Order Type and the Consignment Return Order Type must both be created from the Transfer Order template, because both move stock between warehouses rather than recognizing a sale. The Consignment Invoice Order Type must come from the Invoice Order template, because that is the document that bills the customer.

3. A consignment warehouse, defined on the Warehouses (IN204000) form with the Use for Consignment check box selected. That check box designates the warehouse as a consignment location, and until it is selected the warehouse cannot be chosen in the Consignment Settings section at all.

4. A consignment warehouse on the customer record. The Consignment Warehouse associated with the selected customer is used for the sales order and overrides the default set in Sales Order Preferences. This is how a business with many consignees keeps each customer pointed at its own location.

The Consignment Warehouse field in Sales Order Preferences is a fallback, not a rule. It supplies the warehouse selected automatically when you choose a consignment order type on the Sales Orders form, and the customer-level value takes precedence. That hierarchy explains most of the "why did Acumatica pick that warehouse" questions users raise early on.

Creating a Consignment Sales Order, Step by Step

The whole process happens on the Sales Orders (SO301000) form your team already knows. What changes is the order type you pick, where each warehouse is allowed to go, and one extra action after the shipment. Work the steps in order; skipping the last one leaves consigned stock in an incomplete state.

Step 1: Select the Consignment Order Type

Open the Sales Orders form and set the Order Type to your consignment order type. The Biz-Tech Services documentation shows this type as CN, but what matters is the type your administrator entered in the Consignment Order Type field on Sales Orders Preferences. Selecting it switches the document into consignment behavior and triggers automatic selection of the consignment warehouse. Because the type is built from the Transfer Order template, Acumatica treats the document as a stock movement, which is why shipping it will not post revenue.

Step 2: Choose the Customer

Select the customer from the list. The consignment order is associated with that customer for the rest of its life, and the association is not cosmetic: the customer record is where Acumatica reads the consignment warehouse for the order. Changing the customer changes where the goods are destined to sit, so confirm it before adding lines.

Step 3: Add the Items to Be Consigned

Add the items to be shipped as part of the consignment order, with the quantities you intend to place at the customer site. Enter the full quantity you are willing to leave on consignment, not just what you expect the customer to sell, because that quantity is the pool the later sell and return actions draw from. There is no need to split the order by expected outcome; Acumatica tracks sold and unsold quantities against the same document.

Step 4: Apply the Destination Warehouse Versus Line Warehouse Rule

This is where new users get stuck. The consignment warehouse can only be selected as the destination warehouse; a standard, non-consignment warehouse can only be selected in the lines. Reverse them and Acumatica stops you with an error message. The lines say where stock is coming from and the destination says where it is going, so the customer-held location belongs in the destination and your own stocking warehouse belongs on each line.

Step 5: Confirm the Shipment

Proceed with the standard shipment confirmation process. Nothing here is special to consignment: warehouse staff pick, pack, and confirm exactly as they do for any Acumatica sales order. Confirming the shipment drives the consignment order status forward, so the order is not ready for the sell and return actions until at least part of it has been confirmed.

Step 6: Run Update IN

After the shipment is confirmed, open the Actions menu on the consignment order and click Update IN. This action reflects the consigned items in inventory. Until you run it, the goods have physically left but the Acumatica inventory records have not caught up, and the consignment-specific actions stay unavailable. Treat Update IN as a required step, not an optional refresh.

Once Update IN completes, the order carries a status of Consignment when all ordered quantities have shipped, or Partial Consignment when only part have gone out. Either status means Acumatica now recognizes the stock as sitting at the customer location and the order is ready to work.

Document Triggers: What Each Action Creates

Three actions on a consignment order generate documents elsewhere in Acumatica. Knowing which action produces which document tells you where to look when something did not appear.

Update IN Creates a Transfer-Type Purchase Receipt

When you run Update IN on a confirmed consignment order, the corresponding items and quantities are issued from the main warehouse and received into the selected consignment warehouse. Acumatica automatically generates and releases a Transfer-type purchase receipt to record the movement. Because the receipt is created and released for you, no separate step is needed; a missing receipt usually means Update IN was never run.

Consignment Sell Items Creates a Consignment Invoice Order

The Consignment Sell Items action opens the Item Selection pop-up, where you select the items and quantities the customer has sold. After clicking Add and Close, Acumatica generates a consignment invoice order with the specified warehouse, items, and quantities, using the Consignment Invoice Order Type from Sales Orders Preferences. Once that invoice is prepared and released, the Cons. Sold Qty. field on the original consignment order is updated. Note the timing: sold quantity moves on release, not when you click Add and Close.

Consignment Return Items Creates a Consignment Return Order

The Consignment Return Items action opens the same Item Selection pop-up, where you specify the items and quantities coming back from the customer. Clicking Add and Close generates a consignment return order. The return then follows a process similar to the original consignment order, including its own Update IN, which creates a purchase receipt. Returning consigned stock is not a one-click reversal in Acumatica; it is a second short document you work to completion.

Mapping Rules That Decide Where Consigned Stock Lands

Two rules govern the destination of consigned inventory in Acumatica, and understanding them prevents most rework on consignment sales orders.

The first rule is positional. A warehouse flagged with Use for Consignment can only be selected as the destination warehouse; a standard warehouse can only be selected in the lines. Acumatica enforces this rather than silently correcting it, so an order that will not save is usually an order with the warehouses transposed. The plain-language version: the consignment warehouse is never a source. Stock always originates from a normal warehouse you control and terminates in the consignment warehouse that represents the customer site.

The second rule is precedence. The Consignment Warehouse field on Sales Orders Preferences is selected automatically when a consignment order type is chosen, but the consignment warehouse associated with the selected customer overrides it. Because the customer value wins, changing the customer on a draft order can change the destination under you. With a single consignee the Preferences default may be all you need; add a second and the customer-level warehouse becomes the field that matters.

Validation and Common Exceptions

Most of what interrupts a user on a consignment order in Acumatica is not an outright failure but a control that refuses to do anything. Here is what the product enforces and what each block means.

The Warehouse Placement Error

If you select a consignment warehouse anywhere other than the destination, or a standard warehouse anywhere other than the lines, Acumatica displays an error message with the corresponding notification and the entry does not stand. The fix is always the same: consignment warehouse in the destination, standard warehouse in the lines.

The Sell and Return Buttons Are Greyed Out

The Consignment Sell Items and Consignment Return Items buttons are enabled under the Actions menu only after Update IN has run and the consignment order has a status of Consignment or Partial Consignment. An order still at Open, or one shipped but not updated, shows both buttons unavailable. When a user reports that they cannot sell consigned items, check the status first and Update IN second.

The Buttons Disable Again on a Closed Order

When all ordered items have been shipped and all shipped items sold or returned, the consignment order status changes to Closed. Item quantities and statuses are updated and the Consignment Sell and Consignment Return buttons are disabled again. This is expected Acumatica behavior, not a permission problem: nothing is left at the customer site to sell or reclaim. If the customer needs more stock, the answer is a new consignment order.

Item-Level Detail Disappears for Closed Orders

Consignment information is available through two Acumatica generic inquiries: Consignment Orders for order-level data and Consignment Item Details for item-level data. The Consignment Item Details inquiry no longer displays item-level information for consignment orders once they reach Closed status, while order-level information for those same orders remains available in Consignment Orders. Users who audit line detail will hit this, so it is worth stating plainly rather than letting it look like missing data.

Consignment Statuses Do Not Match Sales Order Statuses

The statuses of consignment orders and of regular sales orders are entirely distinct and unrelated. Open means the order exists but none of the ordered quantities have shipped. Consignment means all ordered quantities have shipped for consignment. Partial Consignment means some have shipped and others remain pending. Closed means all actions on the order are complete. Do not fold these into standard Acumatica sales order reporting; they function independently.

Where to Check Your Work

Before you hand a consignment order off as finished, walk this list in Acumatica. Each item names a specific field, check box, or document, so a colleague can repeat the check without your context.

1. Order Type on the Sales Orders (SO301000) form matches the Consignment Order Type set in Sales Orders Preferences.

2. Consignment Order Type and Consignment Return Order Type on Sales Orders Preferences (SO101000) were both created from the Transfer Order template, and Consignment Invoice Order Type from the Invoice Order template.

3. The Use for Consignment check box is selected on the Warehouses (IN204000) form for the warehouse you are consigning into.

4. The destination warehouse on the order is the consignment warehouse, and every line warehouse is a standard, non-consignment warehouse.

5. The consignment warehouse on the order matches the Consignment Warehouse on the customer record, not just the Sales Order Preferences default.

6. The shipment has been confirmed for the quantities you expect to be at the customer site.

7. Update IN has been run from the Actions menu after shipment confirmation.

8․ A Transfer-type purchase receipt exists showing the issue from the main warehouse and the receipt into the consignment warehouse.

9․ The consignment order status reads Consignment or Partial Consignment and matches how much of the order actually shipped.

10․ Cons. Sold Qty. on the consignment order has updated after the consignment invoice was released.

11․ For a return, Update IN has been run on the consignment return order and its purchase receipt exists.

12․ The order appears in the Consignment Orders generic inquiry, and its lines appear in Consignment Item Details while the order is still open.

Creating Consignment Sales Orders: Frequently Asked Questions

Why can I not select my consignment warehouse on the order lines?

Because the product does not allow it. A warehouse flagged with Use for Consignment can be selected only as the destination warehouse, while a standard warehouse can be selected only in the lines. Either one placed the other way around produces an error message in Acumatica. Move the consignment warehouse to the destination and put your own stocking warehouse on the lines.

Why are the Consignment Sell Items and Consignment Return Items buttons disabled?

Those actions become available only after Update IN has run and the consignment order carries a status of Consignment or Partial Consignment. If the order is still Open, or the shipment was confirmed but Update IN was never clicked, both buttons stay unavailable. They also disable permanently once the order reaches Closed status.

Why did no purchase receipt appear after I shipped a consignment order in Acumatica?

Confirming the shipment does not create the receipt on its own. The Transfer-type purchase receipt is generated and released automatically by the Update IN action on the Actions menu of the consignment order. If the receipt is missing, open the order and check whether Update IN has been run.

Why has Cons. Sold Qty. not increased after I used Consignment Sell Items?

Selecting items in the Item Selection pop-up and clicking Add and Close only generates the consignment invoice order. Cons. Sold Qty. on the consignment order updates once that invoice has been prepared and released. If the number has not moved, the invoice is most likely still unreleased.

Which warehouse wins, the one on the customer or the one in Sales Order Preferences?

The customer wins. The Consignment Warehouse on Sales Orders Preferences is the default selected automatically when you pick a consignment order type, but the consignment warehouse associated with the selected customer overrides it for that order. This is what lets one Acumatica tenant consign to many customer locations from a single configuration.

How do I return unsold consigned stock?

Use the Consignment Return Items action on the consignment order, select the items and quantities in the Item Selection pop-up, and click Add and Close. That generates a consignment return order, which you process much like the original consignment order. Running Update IN on the return creates its purchase receipt.

Why can I no longer see line detail for an old consignment order?

The Consignment Item Details generic inquiry stops displaying item-level information for consignment orders once they reach Closed status. This is by design rather than a data problem. Order-level information for those orders is still available through the Consignment Orders generic inquiry.

Do consignment order statuses mean the same thing as regular sales order statuses?

No. The statuses of consignment orders and regular sales orders are entirely distinct and unrelated, and they function independently within their own processes. Open, Consignment, Partial Consignment, and Closed describe only the consignment lifecycle, so do not interpret them against standard Acumatica sales order reporting.

Work With the Biz-Tech Services Consignment Processing Product

Creating a consignment sales order in Acumatica comes down to a short, repeatable sequence: pick the consignment order type, pick the customer, add the items, keep the consignment warehouse in the destination and the standard warehouse on the lines, confirm the shipment, and run Update IN. From there the order is a working record of what sits at the customer site. The Consignment Processing product from Biz-Tech Services, Inc. adds all of this to Acumatica ERP so your business can manage quantities and valuation of inventory across multiple consignee locations, see sold versus unsold quantities at a glance, and invoice or reclaim stock straight from the consignment order.

To see how Consignment Processing fits your inventory and order processes, or to talk through configuring consignment order types and warehouses for your Acumatica environment, visit https://biz-techservices.com to learn more and to contact the Biz-Tech Services team.

Watch the video tutorial https://www.youtube.com/watch?v=afFwt8-gZCM

by Gary