ApplyStorageLocationChangesCommandRequestInput
Applies a list of changes to the storage locations of a warehouse in one go: every row says itself whether it creates, changes or deactivates a location, so thousands of locations can be synchronised with one call instead of thousands. Every row is checked first against the state the set produces; when a row is invalid the request fails with an error naming every faulty row by position and nothing is applied. Otherwise the set is applied asynchronously in one transaction and its state is read from the change set. A location may appear in at most one row. The rules of the single operations apply to every row. This is the one set-wise write of the warehouse, justified by the volume; single operations stay atomic. errorCode is one of: at least one row is invalid. The error lists every faulty row with its position (for example STORAGE_LOCATION_NAME_INVALID, STORAGE_LOCATION_NAME_NOT_UNIQUE, STORAGE_LOCATION_TYPE_NOT_CREATABLE, STORAGE_LOCATION_NOT_FOUND, STORAGE_LOCATION_REFERENCED_TWICE, STORAGE_LOCATION_HAS_STOCK, TOO_MANY_ROWS); WAREHOUSE_NOT_FOUND (the warehouse was not found); WAREHOUSE_TYPE_DOES_NOT_SUPPORT_STORAGE_LOCATIONS (the warehouse has no storage locations). - Request
ApplyStorageLocationChangesCommandRequestInputFields
The ID of the warehouse.
The rows. At least one, at most 10000.
Client-supplied idempotency key. When provided, a repeated request with the same key and payload replays the original result instead of re-executing the mutation.
Was this page helpful?