[17.0][ADD] sale_financial_risk_exclude_order_type

[atgalvez08]

@BinhexTeam

Description

This module extends sale_financial_risk to support
financial risk behavior configuration directly on
sale.order.type.

It allows configuring sale order types to:

• exclude orders from financial risk computation
• bypass financial risk blocking validation

The implementation intentionally keeps the design
simple and business-oriented by integrating the
configuration directly into sale order types.

Features

• Exclude order types from risk computation
• Allow blocking bypass by order type
• Independent control of computation and blocking
• Multi-company compatible behavior
• Seamless integration with sale_order_type

Included components

• sale.order.type extensions
• Risk computation domain extension
• Financial risk blocking override
• Automated test suite

Design considerations

The implementation intentionally avoids introducing
additional configuration models.

The module:

• keeps configuration close to business semantics
• reduces maintenance complexity
• avoids duplicating framework logic
• preserves existing sale_financial_risk behavior
• follows a lightweight extension approach

Technical details

• Extends sale.order.type
• Overrides evaluate_risk_message
• Extends _get_risk_sale_order_domain
• Supports optional blocking bypass
• Supports optional exclusion from risk computation

Dependencies

• sale_financial_risk
• sale_order_type

Testing

Includes automated tests for:

• blocking bypass behavior
• risk computation domain generation
• separation of concerns
• neutral order types
• multi-company behavior
• domain integrity

Checklist

• Module follows OCA structure
• README aligned with implementation
• Tests included
• No duplicated framework logic
• License headers included

[rrebollo]

From a technical perspective, it looks good. However, regarding the design or approach used for the implementation—why not just integrate the risk management directly into sale_order_type? I mean, the glue addon is fine, but I don't understand why you went with the company settings approach. Why not simply incorporate the feature into the sale order type itself?

[atgalvez08]

From a technical perspective, it looks good. However, regarding the design or approach used for the implementation—why not just integrate the risk management directly into sale_order_type? I mean, the glue addon is fine, but I don't understand why you went with the company settings approach. Why not simply incorporate the feature into the sale order type itself?

Good point, and I agree after revisiting the design.

The initial implementation used a separate configuration model to keep the feature highly configurable and isolated from sale.order.type. The idea was to support company-specific rules without modifying the business model itself.

However, after reviewing the use case more carefully, the additional configuration layer introduced unnecessary complexity for a behavior that is naturally tied to the order type definition itself.

I have now simplified the implementation by moving the configuration directly into sale.order.type through dedicated boolean fields:

• exclude_from_risk
• allow_blocking_bypass

This approach is cleaner because it:

• keeps configuration closer to the business semantics
• removes unnecessary indirection
• reduces maintenance overhead
• simplifies the UX
• avoids an extra model and settings view

The current implementation preserves the same functional behavior while significantly simplifying the architecture.

[rrebollo]

Do we really need two flag fields? There seems to be some common ground between the two behaviors. Could you explain this more clearly?

Based on the naming alone, "excluded" appears to result in no sale financial risk behavior, while "allow blocking" seems to do the same. Perhaps the issue is just a lack of clear documentation.

If both paths are legitimate and distinct, I would suggest implementing a single selection field with a range of choices. That said, it's possible that I simply lack enough functional knowledge of the addon.

[rrebollo]

Code Review. LGTM!

After reading the documentation, I understand that the two paths address distinct scenarios within the financial risk framework.