Sourcing & Product Structure

These subjects tell GAINS where items come from and how they relate to each other: which vendors can supply an item, the terms they impose, what a kit is made of, which item replaces another, and what can be substituted. This page describes what each subject represents, what identifies a record, and how records nest. The endpoints, task types and extended data support are listed in Inbound Subjects; the API Reference lists every field.

All of these subjects refer to SKUs, locations, SKU-locations or vendors, so load that master data first; see Initial Load & Load Order.

What identifies a record

Vendor alternatives

The vendors that can supply an item at a location, with their costs, lead times and production capacity. One record is a SKU-location, with each vendor that can supply it under Vendors. A delete removes the record with all its vendors. Loaded with POST /vendor-alternatives.

Vendor constraints

Purchase order minimums, maximums and lead times a vendor imposes. A constraint applies to one receiving location, or to every receiving location when you leave ReceiveLocationCode out. One record per constraint. Loaded with POST /vendor-constraints.

🚧

Each submit replaces every constraint

GAINS replaces the whole set of purchase order constraints with each submit: a submit that carries only some constraints removes all the others. Send the complete set every time, including the constraints that have not changed. There is no delete endpoint: to remove a constraint, send the set without it.

Partner vendor parameters

Vendor costs, capacity and price breaks for an item, sent by a partner on the vendor's behalf rather than by you. One record is an item and vendor, with its locations under Locations. See Partner APIs. Loaded with POST /partners/vendor-parameters.

Bills of material

The components that make up a kit at the location where it is assembled. Loaded with POST /bills-of-material. Records nest three levels deep:

[
  {
    "KitItemCode": "ASM-7701",
    "KitLocations": [
      {
        "KitLocationCode": "CHI01",
        "Components": [
          {
            "ComponentItemCode": "HUB-100",
            "ComponentLocationCode": "CHI01",
            "ComponentQty": 1,
            "EffectiveFrom": "2026-01-01"
          }
        ]
      }
    ]
  }
]

EffectiveFrom is part of what identifies a component, so the same component can be sent more than once with different dates. A delete names one dated component, so send its EffectiveFrom as you loaded it.

Supercessions

A new SKU-location that replaces one or more old ones. One record is the new SKU-location, under NewItem, with the SKU-locations it replaces under OldItems. Each old SKU-location says how its history and inventory carry over to the new one. A delete removes one old-to-new replacement, named by its NewItem and OldItem. Loaded with POST /supercessions.

SKU-location alternatives

A SKU-location that can be substituted for another, with the cost of substituting and of transporting it. One record per substitution, from a source SKU-location to a target. Loaded with POST /skul-alternatives.

Price breaks

Quantity discounts and expediting costs for a SKU-location. One record is a SKU-location, with its breaks under PriceBreaks. The delete key is the SKU-location alone, without a Break number: a delete removes all the price breaks of that SKU-location. Loaded with POST /price-breaks.

Related

• Inbound Subjects: endpoints, deletes and task types.
• Master Data: the SKUs, locations and vendors these subjects refer to.
• Deleting Data: how deletes work.
• Partner APIs: partner vendor parameters.
• Master Data & Product Structure: reading bills of material and supercessions back.