[IMP] sale_order_type_automation: add sale order and invoice exclusio…#1631
[IMP] sale_order_type_automation: add sale order and invoice exclusio…#1631matiasperalta1 wants to merge 1 commit into
Conversation
|
|
matiasperalta1
force-pushed
the
19.0-t-66258-mnp
branch
from
6f2f81f to
f56c057
Compare
There was a problem hiding this comment.
Pull request overview
Este PR ajusta la automatización de facturación por tipo de pedido de venta para permitir exclusiones de auto-validación, tanto a nivel de factura como a nivel de pedido de venta.
Changes:
invoice_validate_domaincambia de “dominio de inclusión” a “dominio de exclusión” para el posteo automático.- Se añade
sale_order_filter_domainpara excluir pedidos de venta del posteo automático (manteniendo la creación de la factura). - Se expone el nuevo dominio en la vista de tipos de pedido.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| sale_order_type_automation/views/sale_order_type_views.xml | Añade el campo de dominio para exclusión de pedidos de venta en el formulario. |
| sale_order_type_automation/models/sale_order_type.py | Actualiza el texto/semántica del dominio de factura y agrega el dominio de exclusión de SO. |
| sale_order_type_automation/models/sale_order.py | Implementa el “skip validation” por dominio de SO y aplica exclusión al dominio de facturas. |
Comments suppressed due to low confidence (1)
sale_order_type_automation/models/sale_order.py:67
- Falta un test para el cambio de semántica de
invoice_validate_domain(ahora exclusión): con un dominio configurado, las facturas que lo matchean no deberían postearse y el resto sí. Esto ayuda a evitar regresiones, dado que el comportamiento cambió respecto a la implementación anterior.
domain = safe_eval(
rec.type_id.invoice_validate_domain,
{
"datetime": safe_eval_datetime,
"context_today": lambda: fields.Date.context_today(rec),
| sale_order_filter_domain = fields.Char( | ||
| string="Sale Order Exclusion Domain", | ||
| help="Domain to exclude sale orders from automatic invoice validation. Sale orders matching this domain will still have their invoice created, but it will remain in draft.", | ||
| ) |
There was a problem hiding this comment.
El nuevo campo se llama sale_order_filter_domain, pero la etiqueta/ayuda lo describen como “Exclusion Domain”. El nombre técnico sugiere un filtro genérico y puede inducir a configurar lo contrario. Recomendación: renombrarlo ahora (p. ej. sale_order_exclusion_domain o sale_order_skip_validation_domain) antes de que haya datos en producción; si se decide mantenerlo, al menos alinear nombre/etiqueta/semántica.
| @@ -94,8 +94,12 @@ class SaleOrderType(models.Model): | |||
| compute="_compute_auto_done_setting", | |||
| ) | |||
| invoice_validate_domain = fields.Char( | |||
There was a problem hiding this comment.
Se cambió la semántica de invoice_validate_domain a “exclusión” pero se mantiene el mismo nombre técnico. En bases ya instaladas, cualquier dominio guardado previamente pasará a comportarse al revés (excluirá lo que antes incluía), alterando validaciones automáticas tras el upgrade. Para evitar upgrades peligrosos: o bien introducir un campo nuevo para exclusión y conservar el significado del existente, o bien añadir un script de migración que convierta los dominios existentes al nuevo significado (negación correcta del dominio completo).
| invoice_validate_domain = fields.Char( | |
| invoice_validate_domain = fields.Char( | |
| string="Invoice Validation Domain", | |
| help="Domain to include invoices for automatic validation. Invoices matching this domain will be validated automatically.", | |
| ) | |
| invoice_validate_exclusion_domain = fields.Char( |
| <field name="invoicing_atomation"/> | ||
| <field name="background_post" invisible="invoicing_atomation != 'validate_invoice'"/> | ||
| <field name="invoice_validate_domain" widget="domain" options="{'model': 'account.move', 'allow_expressions': True, 'no_create': True, 'in_dialog': False, 'foldable': True}" invisible="invoicing_atomation != 'validate_invoice'"/> | ||
| <field name="sale_order_filter_domain" widget="domain" options="{'model': 'sale.order', 'allow_expressions': True, 'no_create': True, 'in_dialog': False, 'foldable': True}" invisible="invoicing_atomation == 'none'"/> |
There was a problem hiding this comment.
En la vista el nuevo sale_order_filter_domain queda visible cuando invoicing_atomation es create_invoice, pero el help indica que aplica a la auto-validación (solo relevante en validate_invoice). Ajustar la condición invisible para que el campo solo se muestre cuando corresponda (por coherencia con invoice_validate_domain).
| <field name="sale_order_filter_domain" widget="domain" options="{'model': 'sale.order', 'allow_expressions': True, 'no_create': True, 'in_dialog': False, 'foldable': True}" invisible="invoicing_atomation == 'none'"/> | |
| <field name="sale_order_filter_domain" widget="domain" options="{'model': 'sale.order', 'allow_expressions': True, 'no_create': True, 'in_dialog': False, 'foldable': True}" invisible="invoicing_atomation != 'validate_invoice'"/> |
| # Check sale order exclusion domain: create invoice but skip validation | ||
| skip_validation = False | ||
| if rec.type_id.sale_order_filter_domain: | ||
| so_domain = safe_eval( | ||
| rec.type_id.sale_order_filter_domain, |
There was a problem hiding this comment.
Falta un test que cubra el nuevo flujo sale_order_filter_domain: si el SO matchea el dominio, debe generarse la factura pero no validarse (quedar en draft), incluso con invoicing_atomation='validate_invoice'. Hay tests en el módulo pero hoy no verifican este caso.
matiasperalta1
force-pushed
the
19.0-t-66258-mnp
branch
2 times, most recently
from
2ee7597 to
47ca2b7
Compare
…n for auto-validation
matiasperalta1
force-pushed
the
19.0-t-66258-mnp
branch
from
47ca2b7 to
d07ad68
Compare
|
@roboadhoc r+ bump |
…n for auto-validation