Forced Item Stock UOM via db.set_value — what should I verify afterward?

ERPNext Stock/Inventory
, , ,
1

Hi everyone,

I ran into the standard ERPNext restriction while trying to change an Item’s Default Unit of Measure through Data Import:

Default Unit of Measure for Item PL0023 cannot be changed directly because you have already made some transaction(s) with another UOM. You will need to create a new Item to use a different Default UOM.

To understand the behavior, I updated the Item directly from the System Console using frappe.db.set_value(), which bypasses the normal document validation.

Afterward, I verified the following:

  • The Item’s stock_uom now shows the expected value.

  • The item has 134 Stock Ledger Entries.

  • All historical Stock Ledger Entries already use the same stock_uom value, so there doesn’t appear to be any immediate mismatch.

My questions are:

  1. Since db.set_value() bypasses validate_uom() and related document validations, what other records should I verify manually to ensure the system is still consistent? For example:

    • Bin

    • BOM

    • Open Purchase/Sales Orders

    • Item Prices

    • Stock Reconciliation

    • Any other stock-related tables

  2. Is there a supported way to execute the same validation methods (validate_uom(), check_stock_uom_with_bin(), etc.) against the current database state without actually changing the Item again, so I can confirm nothing is inconsistent?

  3. If an Item already has transaction history and its Stock UOM genuinely needs to change, is creating a new Item Code the only supported approach, or is there any officially recommended migration process (for example using Stock Reconciliation or another workflow)?

My goal is to ensure that bypassing the validation hasn’t introduced any hidden inconsistencies and to understand the recommended approach for similar situations in the future.

Any guidance or best practices would be greatly appreciated.