Purchasing Vs Selling Unit Of Measure

Sections in this article

Purchasing Vs Selling Unit Of Measure (UOM)

One of the more challenging concepts of K3S when doing an install is understanding the UOM and where it applies when selling or purchasing. The terminology seems simple on the surface, yet the meaning of “one” changes depending on whether you’re talking about selling, purchasing, or converting between the two.

This article establishes consistent definitions, provides real examples, and identifies the interface fields where UOM matters most.

Unified Definitions

Selling Unit of Measure (Selling UOM) This is the smallest quantifiable amount a distributor sells to its customers. Importantly, this is not the unit that a retailer might sell to their own patrons. It is the level at which all demand, on-hand, on-order, and sales movement should be represented in the interface files.

Purchasing Unit of Measure (Purchasing UOM) This is the smallest quantity you are able to purchase from a supplier. It may be eaches, boxes, cartons, or cases. When the Purchasing UOM differs from the Selling UOM, the buy multiple bridges the two.

Examples

Example 1 There are 12 boxes in 1 case.

  • Selling UOM = 12 (boxes)
  • Purchasing UOM = 1 (case)
  • Buy Multiple = 12

Whenever the system sees “1” it treats that as one selling unit—which in this example is one box.

Example 2 A product is both bought and sold by the case.

  • Selling UOM = 1 case
  • Purchasing UOM = 1 case
  • Buy Multiple = 1

No conversion is required.

What About “Each”?

In some customer environments, an “each” is simply the smallest subdivision of the selling UOM (e.g., a single can inside a 12-pack). In others an “each” SKU is treated as its own standalone product with its own product ID. When this happens, the UOM conversion is not a math problem; it’s a cross-product relationship.

K3S uses the K_VAPXREF file to manage those relationships.

How K3S Treats UOM in Interface Data

K3S expects interface quantities in selling units.

This applies to on-hand, on-order, sales, outs, receipts, and purchase orders. During discussions, “selling unit of measure” and “base unit of measure” were used as interchangeable terms. Functionally, the system treats the Selling UOM as the base unit for all quantity calculations.

Below is a reference of the key fields and how they interpret “1”.

Critical UOM Fields in Interface Files

K_INTPROD (Product Master / Inventory Data)

  • IP_BUYMULT – Buy multiple
  • IP_QTYOHND – Quantity on hand
  • IP_QTYOORD – Quantity on order
  • IP_QTYBACK – Back orders
  • IP_DLYSALE – Daily sales
  • IP_DLYOUTS – Daily outs
  • IP_MINQTY – Minimum quantity (commonly sent as 1)
  • IP_CONVPAK – Convenience pack
  • IP_PURINCR – Purchase increment
  • IP_COSTREG – Regular cost
  • IP_COSTDIV – Cost divisor
  • IP_WEIGHT / IP_WEIGHTD – Weight and divisor
  • IP_VOLUME / IP_VOLUMED – Volume and divisor
  • IP_UOM – Display UOM
  • IP_PACKSIZ – Display pack size

K_PRODLTM (Receipts and Line Tracking)

  • PL_QTYRECV – Quantity received* PL_QTYORDR – Quantity ordered

K_INTDALY (Daily Movement)

  • IE_DLYSALE – Daily sales
  • IE_DLYOUTS – Daily outs

K_POFILE (Purchase Orders)

  • ID_SOQACT – Suggested quantity actual
  • ID_SOQACTO – Suggested quantity original
  • ID_COSTORD – Cost orders
  • ID_COSTDIV – Cost divisor
  • ID_COSTEAC – Cost each
  • ID_COSTREG – Regular cost

Why This Matters

When the interface says 1, K3S assumes that means one selling unit.

Returning to Example 1 (12 boxes per case):

  • If you order 1 case, K3S records the order as 12 units in K_POFILE.
  • If you receive 1 case, K3S records it as 12 units in K_PRODLTM.
  • If you sell 1 case, K3S records the movement as 12 units in K_INTDALY.

K3S can store the case-count value in a user field for reference, but the stored and calculated quantities are always expressed in selling units unless explicitly overridden.

Closing Notes

Clear terminology prevents inventory drift, improper forecasting, and misaligned purchase orders. As new customers onboard—and particularly when multiple sites feed data in different formats—ensuring everyone uses consistent UOM definitions is essential.

If your team is implementing K3S and needs help mapping Selling UOM, Purchasing UOM, or buy multiples in your interface files, our technical team can assist in validating your data model and guiding UOM configuration during onboarding.