Skip to main content
Question

API: Creating multiple StockItem WarehouseDetails with different Replenishment Sources

  • September 28, 2026
  • 2 replies
  • 57 views
Freshman I

We are using the Acumatica contract-based REST API (25.200.001) to create Stock Items and their Warehouse Details.

We need to create two warehouse detail records for a new stock item:

Warehouse Replenishment Source Replenishment Warehouse
A001 Manufacturing  
B004 Transfer A001

Our custom endpoint exposes WarehouseDetails under StockItem.

The relevant fields are mapped to the Warehouses detail object, including:

  • WarehouseID → Warehouse

  • Source / ReplenishmentSource → Replenishment Source

  • RepWhs / ReplenishmentWarehouse → Replenishment Warehouse

The screen field was verified with Element Inspector as:

  • Data Class: INItemSite

  • Data Field: ReplenishmentSource

  • View Name: itemsiterecords

  • Business Logic: InventoryItemMaint

Problem

If we PUT a single WarehouseDetails record, the Replenishment Source is set correctly.

For example, creating only A001 as Manufacturing works:

{
  "InventoryID": {
    "value": "TESTITEM"
  },
  "WarehouseDetails": [
    {
      "WarehouseID": {
        "value": "A001"
      },
      "Source": {
        "value": "Manufacturing"
      }
    }
  ]
}

A001 is correctly created with Replenishment Source = Manufacturing.

However, if we create two WarehouseDetails records with different sources:

{
  "InventoryID": {
    "value": "TESTITEM"
  },
  "WarehouseDetails": [
    {
      "WarehouseID": {
        "value": "A001"
      },
      "Source": {
        "value": "Manufacturing"
      }
    },
    {
      "WarehouseID": {
        "value": "B004"
      },
      "Source": {
        "value": "Transfer"
      },
      "RepWhs": {
        "value": "A001"
      }
    }
  ]
}

both warehouse records end up with the same Replenishment Source.

In this example, both A001 and B004 end up as Transfer instead of:

A001 = Manufacturing
B004 = Transfer

We have also tried creating the WarehouseDetails records with separate PUT requests. The behavior is similar: setting the source on one warehouse can result in the other warehouse receiving the same source.

We also tested the manufacturing-related override fields:

"AMReplenishmentSourceOverride": {
  "value": true
},
"AMSourceSiteIDOverride": {
  "value": true
}

but this did not resolve the issue.

GET results

After creation, $expand=WarehouseDetails confirms that Acumatica has created two distinct WarehouseDetails records.

For example:

"WarehouseDetails": [
  {
    "id": "<GUID 1>",
    "WarehouseID": {
      "value": "A001"
    },
    "ReplenishmentSource": {
      "value": "Manufacturing"
    }
  },
  {
    "id": "<GUID 2>",
    "WarehouseID": {
      "value": "B004"
    },
    "ReplenishmentSource": {
      "value": "Manufacturing"
    }
  }
]

So the two INItemSite/WarehouseDetails records exist independently, but the Replenishment Source does not appear to be applied independently during the REST operation.

Questions

Is there a supported way through the contract-based REST API to create multiple WarehouseDetails / INItemSite records for the same Stock Item with different ReplenishmentSource values?

Specifically, can this be done in one StockItem PUT so that:

A001 → Manufacturing
B004 → Transfer, Replenishment Warehouse A001

If not, can each warehouse detail be created independently through REST while setting its own Replenishment Source and Replenishment Warehouse?

Would the recommended approach be to expose/use the ItemWarehouse entity directly instead of StockItem.WarehouseDetails?

We would prefer to avoid creating the WarehouseDetails first, GETting their REST entity IDs, and then issuing additional PUT requests to update each detail record individually if there is a supported way to set these values correctly during creation.

Thanks for any guidance or examples.

2 replies

Steve Milner
Varsity III
Forum|alt.badge.img+4
  • Steve Milner
  • Varsity III
  • September 30, 2026

@asouza I'd stop setting replenishment through StockItem.WarehouseDetails. On Stock Items that grid is read-only except the Default and Status columns. On an MRP or DRP item the AM override flags don't protect a new row there either. Whenever the item changes while a warehouse row is still new, the item's own source is copied onto that row, override or not.

Per-warehouse replenishment lives on Item Warehouse Details (IN204500), which is the ItemWarehouse entity. Even Add Warehouse Detail on the Stock Items Warehouses tab opens that form. It's keyed on InventoryID and WarehouseID, so one PUT per warehouse creates or updates the record. There are no detail IDs to fetch.

In 2026 R1, which fields hold depends on the item's planning method.

- Inventory Replenishment: send OverrideReplenishmentSettings set to true with ReplenishmentSource and ReplenishmentWarehouse. Without the override, those values are ignored.
- MRP or DRP: a plain ReplenishmentSource gets put back when the record updates. The values that stick are in the Source and Source Warehouse boxes, each with its own Override check box (AMReplenishmentSource, AMReplenishmentSourceOverride, AMSourceSiteID, AMSourceSiteIDOverride). Each box is only editable once its Override is checked, and the Source Warehouse Override unlocks once Source is Transfer. The Default ItemWarehouse entity doesn't have those four fields, so add them to your endpoint.

Steve Milner - Acumatica Consultant, Acumaven Inc. | acumaveninc.com | linkedin.com/in/steve-milner-52654b3
    Freshman I
    • asouza
    • Author
    • Freshman I
    • October 1, 2026

    @asouza I'd stop setting replenishment through StockItem.WarehouseDetails. On Stock Items that grid is read-only except the Default and Status columns. On an MRP or DRP item the AM override flags don't protect a new row there either. Whenever the item changes while a warehouse row is still new, the item's own source is copied onto that row, override or not.

    Per-warehouse replenishment lives on Item Warehouse Details (IN204500), which is the ItemWarehouse entity. Even Add Warehouse Detail on the Stock Items Warehouses tab opens that form. It's keyed on InventoryID and WarehouseID, so one PUT per warehouse creates or updates the record. There are no detail IDs to fetch.

    In 2026 R1, which fields hold depends on the item's planning method.

    - Inventory Replenishment: send OverrideReplenishmentSettings set to true with ReplenishmentSource and ReplenishmentWarehouse. Without the override, those values are ignored.
    - MRP or DRP: a plain ReplenishmentSource gets put back when the record updates. The values that stick are in the Source and Source Warehouse boxes, each with its own Override check box (AMReplenishmentSource, AMReplenishmentSourceOverride, AMSourceSiteID, AMSourceSiteIDOverride). Each box is only editable once its Override is checked, and the Source Warehouse Override unlocks once Source is Transfer. The Default ItemWarehouse entity doesn't have those four fields, so add them to your endpoint.

    Thanks — We moved away from StockItem.WarehouseDetails and are now working directly with the ItemWarehouse entity (IN204500 / INItemSiteMaint), one warehouse per PUT. We also extended our custom endpoint to expose the MRP/DRP fields from the inventoryPlanningSettings view. Using Element Inspector, we confirmed:

    • Source: AMReplenishmentSource
    • Source Override: AMReplenishmentSourceOverride
    • Source Warehouse: AMSourceSiteID
    • Source Warehouse Override: AMSourceSiteIDOverride

    AMReplenishmentSourceOverride works correctly through REST — after the PUT, the Source Override checkbox is checked in IN204500. AMReplenishmentSource also appears to be the correct field. For example, setting it to Manufacturing through REST successfully changes the Source field in IN204500. The issue occurs when we attempt to set B004 to Transfer. For example:

    {
      "InventoryID": { "value": "TESTITEM" },
      "WarehouseID": { "value": "B004" },
      "AMReplenishmentSourceOverride": { "value": true },
      "AMSourceSiteIDOverride": { "value": true },
      "AMSourceSiteID": { "value": "A001" },
      "AMReplenishmentSource": { "value": "Transfer" }
    }

    Acumatica returns:

    “Replenishment Warehouse cannot be empty.”

    We have also tried separate PUTs so that the overrides are saved before changing the values. The result is the same. The last problem seems to be exposing/writing AMSourceSiteID. Element Inspector identifies the Source Warehouse control as:

    Data Class:     INItemSite
    Data Field:     AMSourceSiteID
    View Name:      inventoryPlanningSettings
    Business Logic: INItemSiteMaint

    However, when extending ItemWarehouse in the Web Service Endpoint editor, AMSourceSiteID itself is not available as a mapped field. The available Source Warehouse-related fields/relationships we have tried do not populate the value that the AMReplenishmentSource = Transfer validation is checking. We confirmed the desired configuration itself is valid by setting it manually in IN204500:

    B004
    Source Override:           checked
    Source:                    Transfer
    Source Warehouse Override: checked
    Source Warehouse:          A001

    After saving manually, a REST GET correctly returns:

    "WarehouseID": { "value": "B004" },
    "ReplenishmentSource": { "value": "Transfer" },
    "ReplenishmentWarehouse": { "value": "A001" }

    So the remaining question is: How should INItemSite.AMSourceSiteID be exposed/mapped on an extended ItemWarehouse contract endpoint in 2026 R1?

    Specifically, which mapped object/field should be added to ItemWarehouse so that REST can populate the Inventory Planning Source Warehouse before/while changing AMReplenishmentSource to Transfer? If AMSourceSiteID cannot be exposed through a contract-based endpoint, is there a supported REST approach for creating this MRP ItemWarehouse configuration, or would this require an Import Scenario/customization?

    Terms & ConditionsAccessibility statement
    About Acumatica ERP system
    Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
    © 2008 — 2024  Acumatica, Inc. All rights reserved