---
title: "Understanding Parent and Child Products"
canonical: "https://kb.myframeworks.com.au/space/FRAM/28413398/Understanding%20Parent%20and%20Child%20Products"
format: markdown
---
Certain products, like rolls of cable, necessitate multiple identifiers to distinguish between the parent item (the roll) and the individual units (the linear meters).

To effectively manage inventory for such products, Frameworks offers the capability to establish parent-child relationships between items. This feature makes it easier to see and manage the products by linking the whole item (like a roll) with its smaller parts (like meters). This helps keep track of stock more accurately and makes inventory management simpler.

## Parent-Child Product Relationship

A **parent-child product relationship** describes a structured hierarchy where a **parent product** acts as the main item, and its **child products** represent specific variations or units derived from it. This relationship is useful for managing products that can be sold in different forms, like lengths or sizes.

To better understand this relationship, it's important to define what constitutes parent and child products:

### Parent Product

The main product (e.g., a full roll of cable). It represents the whole item, including its total dimensions or packaging.

### Child Products

Variations or specific units of the parent product (e.g., different lengths of cable). They inherit pricing from the parent and are sold individually.

![image-20251028-011945.png](media://3a976288-ecdd-4586-9fb8-ea96a7a5d0b2)

**Key Points**

- A parent product can have multiple child products.
- Each child product is linked to one parent only.
- All child products inherit the cost and sell price from the parent.
- For tally products, each child product must have a length specified.
- Parent products cannot be sold on their own unless they are set up as Independently Traded (which applies to non-tally products only)

> 📝 **What is “Independently Traded”? **
> 📝 
> 📝 "Independently Traded" refers to a status indicating that the parent product can be bought or sold independently, without the necessity of selecting a child product; this checkbox is informational and can be modified within Product Maintenance for non-tally products.

> ✅ Refer to [Defining Parent-Child Products](https://sterlandsupport.atlassian.net/wiki/spaces/CO/pages/30509486) for more information.

## Tally vs Non-tally Products

The relationship between **parent** and **child products** depends on whether measurements like length are required.

### Tally Products

Tally parent products require child products to have a specific measurement, such as length. For example, a roll of cable (parent) can have child products like 1 metre or 2 metre lengths.

![image-20251028-012020.png](media://0c8e3716-f077-4b7e-a2be-da232f2a94ed)

**Key Points**

- Child products must have a defined length.
- The parent product cannot be sold directly—only through its child products.

### Non-tally Products

Non-tally parent products don’t require measurements for their child products. Instead, child products represent variations like size or color. For example, a T-shirt (parent) could have child products in different sizes or colors. Non-tally parent products can also be sold directly if flagged as **Independently Traded**.

![image-20251028-012058.png](media://415a67f2-79a3-4eec-92a0-72bf3354ac50)

**Key Points**

- Child products represent variations (e.g., sizes, colors) — no measurements required.
- A parent product can be sold directly if flagged as **Independently Traded**.
- Child products inherit cost and sell price from the parent.
- Can have new or existing child products.
- Quantity per child must be set.
- Can be added directly to sales and purchase orders.
- Can be included in kits (if flagged).

## Contract and Promotion Pricing

When using parent and child products, Frameworks applies a hierarchical approach to determine the most appropriate contract or promotion price for each product in a transaction.

The system evaluates pricing in the following order of precedence:

1. **Child-specific contract or promotion** — if one exists for the exact product being sold.
2. **Parent contract or promotion** — if no child pricing exists but the parent product has one.
3. **Product Group contract or promotion** — as per standard Frameworks behaviour.

This hierarchy applies to all three pricing methods (Fixed Price, Discount, and GP%) and ensures the most specific applicable pricing is always used. Frameworks automatically handles unit of measure conversions between parent and child products where necessary.

> **Example:** Your store has a Fixed Price contract with a builder for 90x45 H3 F7 (parent product) at $4.50/LM. When the builder orders 90x45 H3 F7 5.8M (child product), the system applies $26.10 ($4.50 × 5.8M) as the contract sell price.

> ✅ Refer to [Contract and Promotion Pricing for Parent and Child Products](https://sterlandsupport.atlassian.net/wiki/spaces/FRAM/pages/234225682) for detailed information on how each pricing method works with parent/child relationships.

## Configuration

> ⚠️ This functionality is feature-code driven. Please contact [Support](https://kb.myframeworks.com.au/page/support) if you require this to be enabled.

The following feature code is required to be **Active **to utilise the **Parent/Child functionality in Frameworks. **

1. **PCP (Parent Child Products)**: Enables management of parent and child product relationships within the system.
2. **MSP (Multi-Select Products**): Allows adding one or multiple products to a sale, quote, or order, streamlining the product selection process.

> ✅ Refer to [Feature Codes](https://sterlandsupport.atlassian.net/wiki/spaces/FRAM/pages/28401618) for more information.

## Initial Considerations when Moving to Parent Child products 

To help you better understand what will happen to existing stock when moving to parent-child products.

<details>
<summary>Pre-existing Consignment Stock</summary>

When processing **consignment stock** for an existing **consignment purchase order**, where stock is **automatically receipted**, Frameworks behaves as follows:

- If the **received lengths** match existing **child products**, the **parent tally product** is replaced by those child products in the receipt.
- If the **lengths don't exist** as child products, the **stock is receipted against the parent product** instead.

This ensures **accurate Stock on Hand (SOH)** tracking.

> ℹ️ Note: This logic applies only to **tally products**, as **non-tally products** use unique product codes for each item.
</details>

<details>
<summary>Pre-existing Requisition lines</summary>

For **pre-existing requisitions** where a tally parent product was added through **Sales Order Fulfilment**, **Stock Reorder**, **Add to Requisition**, or **manual entry**, Frameworks will handle the conversion during receipting of the generated purchase order. At that point, the **parent product is split into the appropriate child products**
</details>

<details>
<summary>Pre-existing Purchase Order lines</summary>

For **pre-existing purchase order lines** that include a tally parent product, Frameworks will manage the split during receipting by converting the parent product into its corresponding child products.
</details>

<details>
<summary>Pre-existing Stock Returns</summary>

When receipting a **pre-existing stock return order** that includes **parent tally products**, Frameworks processes the stock as follows:

- **If the returned lengths match existing child products**, the Stock on Hand (SOH) of the **parent product is initially decreased** as part of the receipting process. A **stock adjustment** is then triggered to:
  - **Decrease the SOH of the child products (lengths)**, and
  - **Increase the SOH of the parent product** (based on the equivalent linear metres received).  
This ensures accurate reconciliation of returned stock.
- **If the returned lengths do not match any child products**, the stock is receipted against the **parent product only**, and **no stock adjustment** is performed.
- **For non-tally products**, the stock adjustment logic **does not apply**. The SOH of the **non-tally parent product** is updated directly through the receipting process.

> ℹ️ **Note:** The stock adjustment process applies only to **tally products** where length-based child products are used to represent individual stock units.
</details>

<details>
<summary>Stocktakes </summary>

> ❌ We **strongly recommend** all open Stocktakes are completed prior to cutting over to Parent Child products
</details>

> ✅ ## Related Information
> ✅ 
> ✅ Refer to [Parent and Child Products](https://sterlandsupport.atlassian.net/wiki/spaces/CO/pages/30509486) for more information.