Skip to content

[#69230] Fix Kit BoM Handling in RMA Repair Processes#9

Open
peregrine-2024 wants to merge 1 commit into
10.0from
pf_ticket_69230_20251120_174141
Open

[#69230] Fix Kit BoM Handling in RMA Repair Processes#9
peregrine-2024 wants to merge 1 commit into
10.0from
pf_ticket_69230_20251120_174141

Conversation

@peregrine-2024
Copy link
Copy Markdown

: This pull request addresses ticket #69230 which resolved an issue where Kit Bill of Materials (BoMs) were incorrectly being broken down during repair processes in the RMA module. The fix modifies the RMA wizard responsible for creating pickings to properly recognize and handle kit products without decomposing them into individual components. This ensures that kit products maintain their integrity when generating repair orders and pickings from RMA lines, preventing incorrect inventory allocations and processing errors. The solution maintains backward compatibility while preserving the intended behavior of kit product handling in repair workflows.

Implemented solution using Cursor CLI automation
@peregrine-2024
Copy link
Copy Markdown
Author

🛠️ Automated Fix: Prevent Kit BoM Explosion in RMA Repair Pickings

This pull request addresses ticket #69230 titled "RMA: Kit BoMs break out in repair" by implementing a targeted override of the _action_explode method in the stock.move model. The goal is to prevent kit products (those with phantom BoMs) from being automatically exploded into their component parts when creating pickings from RMA claims intended for repair.


🔧 Changes Made

File Modified:
crm_claim_rma/models/stock_move.py

Change Summary:
A new method _action_explode was added to the StockMove class that overrides the default behavior for handling BoM explosions. This custom logic ensures that:

  • If a stock move belongs to a picking associated with an RMA claim (picking.claim_id), and
  • The product involved is a kit product (i.e., has a phantom BoM),

...then the move will not be exploded into its components — instead, it returns the original move unchanged.

For all other cases (non-RMA or non-kit moves), the standard Odoo behavior is preserved by calling super()._action_explode(...).


📌 Technical Details

  • Method Added: _action_explode(cr, uid, move, context=None)
  • Logic Override: Checks if the move originates from an RMA claim and whether the product is a phantom BoM (kit).
  • Backward Compatibility: Uses the legacy Odoo 9.0 API signature (cr, uid) to align with existing core implementations.
  • Error Handling: Gracefully handles cases where mrp.bom module may not be available, falling back to default behavior.

✅ How This Fixes the Issue

Previously, during RMA repair processes, kit products were incorrectly expanded into individual components due to automatic BoM explosion. This caused confusion and incorrect inventory tracking.

With this change:

  • Kit products remain as kits in RMA repair pickings.
  • Inventory and reporting reflect the correct logical structure of the kits.
  • No unintended side effects occur for non-RMA or non-kit scenarios.

⚠️ Review & Testing Notes

  • Please verify that the override does not interfere with normal picking workflows outside of RMA contexts.
  • Ensure that the logic correctly identifies phantom BoMs and avoids unnecessary database lookups.
  • Test with both kit and non-kit products in RMA repair scenarios to confirm expected behavior.

This fix should be reviewed carefully to ensure compatibility with any customizations or extensions relying on the default _action_explode behavior.


🔗 View Ticket #69230

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants