Master Data

What SKUs, locations, SKU-locations, customers and vendors represent in GAINS, and what identifies each record.

Master data is what every other load refers to: your items, your locations, the items you plan at each location, your customers and your vendors. This page describes what each subject represents in GAINS and what identifies a record. The endpoints, task types and extended data support are listed in Inbound Subjects; the API Reference lists every field.

What identifies a record

SubjectIdentified by
SKUsItemCode
LocationsLocationCode
SKU-locationsItemCode and LocationCode
CustomersCustomerCode and ShipToCode
VendorsVendorCode and ReceiveLocationCode

Every master data record is flat: one record per item, location, SKU-location, customer ship-to or vendor and receiving location. Master data is loaded first; see Initial Load & Load Order.

SKUs

An item in the GAINS item master, independent of where it is stocked. A SKU carries what is true of the item everywhere, such as its description, department and group. Loaded with POST /skus.

Locations

A distribution center, warehouse, branch, plant or other place where items are planned or stocked. ParentDefaultCode names the location it is replenished from by default, so load the parent location first. Loaded with POST /locations.

SKU-locations

An item at a location: the level at which GAINS forecasts and plans inventory. A SKU-location carries what depends on the location, such as costs, prices, lead time, service level and order quantity limits. Send one for each location where you stock or plan an item, after the SKU and the location exist in GAINS. Loaded with POST /skus-locations.

GAINS holds a SKU-location delete until you approve it. See SKU-location delete review.

Customers

A customer and one of its ship-to destinations. A customer with several ship-to addresses is sent as several records, one for each ShipToCode. Loaded with POST /customers.

Vendors

A supplier. A vendor can carry terms and lead times that differ by the location that receives from it: send one record for each receiving location, with ReceiveLocationCode. Loaded with POST /vendors.

A vendor can also be loaded without ReceiveLocationCode. That is why the delete key can be VendorCode alone: send the delete as you sent the load, with the ReceiveLocationCode of each receiving location you loaded, or without one if you loaded the vendor without one.

Which vendors can supply which items is loaded separately, as vendor alternatives.

Related


Did this page help you?