Calorie-Based Bulk Manufacturing with Internal Size Packing (Hidden from Customers)

We need help implementing a custom logic in ERPNext’s Manufacturing module for calorie-based bulk production and internal size packing.

Customers order only one product: Item A. During enrollment, they select a target calorie level, and based on that, we internally determine a size variant (mainly differing by quantity). We then map all relevant deliveries throughout the subscription period to that internal size.

  • Small → 20g of Item A
  • Medium → 30g of Item A
  • Large → 40g of Item A

These sizes are only used internally. Customers don’t see them.

What we need:

  1. Based on the calorie level of the customer, the system should internally map to one of the three size variants (Small, Medium, Large).
  2. We should be able to calculate the total bulk quantity of Item A required by summing up all internal sizes (e.g., 10 smalls = 200g, 5 mediums = 150g, etc.).
  3. The bulk Item A is manufactured using raw materials X and Y via a Work Order.
  4. After bulk production, we pack it into the required number of Small/Medium/Large units based on daily demand. ( should able to define the box quantities like a Product Bundle or something)
  5. Customer should only see Item A (no size info) on invoices, delivery, etc.

How can we best implement this using custom doctypes/ (manufacturing module) , stock entries, and work orders? Has anyone done something similar?

Hi,

You can implement the same using standard functionality of ERPNext. You have to use the two items and Item Variant to achive the same One Item for Internal Use and One Item with Variant for Customer.

Thanks,

Divyesh M.

1. Based on the calorie level of the customer, the system should internally map to one of the three size variants (Small, Medium, Large).

Answer:-

We’ve created three Product Bundles to represent the size variants:

  • Item Bulk A - Small (20g)
  • Item Bulk A - Medium (30g)
  • Item Bulk A - Large (40g)

Each of these Product Bundles is internally linked to the main stock item Item Bulk A with the appropriate quantity.

To handle calorie-based mapping:

We can either use a custom intermediate Doctype (e.g., Customer Subscription or Calorie Profile) before Sales Order creation,

Or directly write a Server Script on the Sales Order that maps the calorie level to the correct Product Bundle and adds it to the SO.

Example logic for a Server Script:

calorie = doc.get("customer_calorie_preference")

if calorie:
    if calorie < 250:
        item_code = "Item Bulk A - Small" #service product bundle item 20g
    elif 250 <= calorie < 350:
        item_code = "Item Bulk A - Medium"  #service product bundle item 30g
    else:
        item_code = "Item Bulk A - Large"  #service product bundle item 40g

    doc.items = []
    doc.append("items", {
        "item_code": item_code,
        "qty": 1,
        "uom": "Gram"
    })




2. We should be able to calculate the total bulk quantity of Item A required by summing up all internal sizes (e.g., 10 smalls = 200g, 5 mediums = 150g, etc.).

Answer:-

We use Sales Orders (linked to the Product Bundles) to estimate the demand for each size.

Since each bundle links to a fixed quantity of Item Bulk A, we can use standard ERPNext reports (e.g., Sales Order Analysis or Work Order Summary) to sum total quantity of Item Bulk A required.

Example: 10 Small (20g) + 5 Medium (30g) → 200g + 150g = 350g of Item Bulk A to manufacture.


3. The bulk Item A is manufactured using raw materials X and Y via a Work Order.

Answer:- We can create a BOM for Item Bulk A, listing Raw Material X and Y as components. This BOM is used to create a Work Order and manufacture the bulk quantity based on the estimated demand.

4. After bulk production, we pack it into the required number of Small/Medium/Large units based on daily demand. ( should able to define the box quantities like a Product Bundle or something)

Answer:-

This depends on the business workflow:
a) Make to Order

  • Each Sales Order includes the correct Product Bundle (automatically selected using the calorie logic).

  • From the SO, we can generate Delivery Notes and Sales Invoices directly for the customer.

b) Make to Stock

  • We raise Material Requests based on daily packing requirements.

  • Then create Work Orders for converting bulk into required units (S/M/L).

  • This gives flexibility to pack as per batch demand.

ERPNext supports both workflows natively, depending on how you manage inventory and production planning.

5. Customer should only see Item A (no size info) on invoices, delivery, etc.

Answer:-

Although internally we track Small/Medium/Large, customers should only see “Item A” on Sales Invoices and Delivery Notes.

To achieve this:

We customize the Print Format to display a generic item name (Item A) and hide internal size info.

This ensures the customer always sees a clean and simple product label.

NOTE: Since I don’t use item variants in my case—as it totally depends on whether they are required or not—I felt it became much more complex. So, I used product bundles instead.

Hi Divyesh,
Thanks for your Reply.I already had explored the Item Variant approach, but faced two key issues:

Work Order Limitation:
While we can define a BOM for the parent item (e.g., the master product), ERPNext only allows Work Orders to be created against its variants (e.g., size-based items). This breaks the abstraction we’re trying to maintain.

Product Bundle Restriction:
In Product Bundles, ERPNext doesn’t allow selecting the parent item as a sub item. This further complicates representing internal packing logic cleanly when using the parent as the main customer-facing item.

if i go with the approach of creating separate items just for BOM purposes, it would result in many item maintenance and increase the chances of operational confusions for users.

Thank you @Rehan_Ansari for the detailed reply, your approach is more convenient. However I’d like to add a few more details to explain our use case better:

ERPNext as Backend:
We’re trying move to ERPNext and Frappe as the backend for an existing application that’s already live and working well.

Frontend Integration Needs:
Customers choose their Item through a mobile app. It only show the main item (like Item A) in the menu—without revealing size or packing info. All internal mapping and repacking logic should stay in the backend.

Subscription-Based Ordering:
It is subscription Based. So We’re using the Subscription Doctype with some custom fields to store the items they select daily.
The selected item (e.g., Item A) needs to be mapped to the correct size variant (e.g., Item A - Small) based on the calorie value stored in the Customer Doctype.

Automated Production Planning:
Using this subscription data, we want to automatically generate Production Plans for bulk manufacturing, and then raise Material Requests accordingly.

Post-Production Repacking:
After production, the bulk items are repacked into boxes based on customer needs and delivered.

We’re trying to keep the customer-facing experience simple, while handling size-based logic, packing, and production efficiently in ERPNext.