diff --git a/diagrams/pdf/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).pdf b/diagrams/pdf/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).pdf new file mode 100644 index 0000000..7f5f745 Binary files /dev/null and b/diagrams/pdf/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).pdf differ diff --git a/diagrams/pdf/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.pdf b/diagrams/pdf/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.pdf new file mode 100644 index 0000000..8b1858b Binary files /dev/null and b/diagrams/pdf/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.pdf differ diff --git a/diagrams/pdf/D-CU-GEN-001 — Diagrama General de Casos de Uso.pdf b/diagrams/pdf/D-CU-GEN-001 — Diagrama General de Casos de Uso.pdf new file mode 100644 index 0000000..73c3242 Binary files /dev/null and b/diagrams/pdf/D-CU-GEN-001 — Diagrama General de Casos de Uso.pdf differ diff --git a/diagrams/pdf/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.pdf b/diagrams/pdf/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.pdf new file mode 100644 index 0000000..14e659f Binary files /dev/null and b/diagrams/pdf/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.pdf differ diff --git a/diagrams/pdf/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.pdf b/diagrams/pdf/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.pdf new file mode 100644 index 0000000..ac5ce08 Binary files /dev/null and b/diagrams/pdf/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.pdf differ diff --git a/diagrams/pdf/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.pdf b/diagrams/pdf/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.pdf new file mode 100644 index 0000000..d7fed9c Binary files /dev/null and b/diagrams/pdf/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.pdf differ diff --git a/diagrams/pdf/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.pdf b/diagrams/pdf/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.pdf new file mode 100644 index 0000000..61c33b7 Binary files /dev/null and b/diagrams/pdf/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.pdf differ diff --git a/diagrams/pdf/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.pdf b/diagrams/pdf/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.pdf new file mode 100644 index 0000000..4f86e45 Binary files /dev/null and b/diagrams/pdf/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.pdf differ diff --git a/diagrams/pdf/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.pdf b/diagrams/pdf/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.pdf new file mode 100644 index 0000000..7027953 Binary files /dev/null and b/diagrams/pdf/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.pdf differ diff --git a/diagrams/pdf/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.pdf b/diagrams/pdf/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.pdf new file mode 100644 index 0000000..1be60b9 Binary files /dev/null and b/diagrams/pdf/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.pdf differ diff --git a/diagrams/pdf/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.pdf b/diagrams/pdf/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.pdf new file mode 100644 index 0000000..9c19315 Binary files /dev/null and b/diagrams/pdf/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.pdf differ diff --git a/diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml b/diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml index 032c468..0475514 100644 --- a/diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml +++ b/diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml @@ -1,4 +1,4 @@ -@startuml D-CLA-INT-001 — Diagrama de Clases: Integración Venta/Stock/Contabilidad +@startuml D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad title SAP-TFI-2026 — Diagrama de Clases Técnicas (Integración Venta/Stock/Contabilidad) diff --git a/diagrams/plantuml/d_rob_ent_002_reservar_productos.puml b/diagrams/plantuml/d_rob_ent_002_reservar_productos.puml new file mode 100644 index 0000000..6661a23 --- /dev/null +++ b/diagrams/plantuml/d_rob_ent_002_reservar_productos.puml @@ -0,0 +1,58 @@ +@startuml D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos + +title SAP-TFI-2026 — Diagrama de Robustez - Reservar Productos (CU-ENT-002) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Sistema\n(o Operario)" as A + +boundary "Trigger\n(action_confirm o boton)" as B_Trig + +control "StockPicking\n(action_assign)" as C_Assign +control "Reabastecimiento\n(procurement)" as C_Proc + +entity "stock.picking" as E_Pick +entity "stock.move.line\n(reservas)" as E_ML +entity "stock.warehouse.orderpoint" as E_WO +entity "purchase.order\n(MTO)" as E_PO + +A --> B_Trig : 1. Trigger reserva +B_Trig --> E_Pick : 2. Lee picking +B_Trig --> C_Assign : 3. action_assign() + +C_Assign --> E_Pick : 4. Recorre lineas +C_Assign --> E_ML : 5. Busca stock disponible +E_ML --> C_Assign : 6. Cantidad disponible + +alt Si hay stock + C_Assign --> E_ML : 7a. Reserva cantidad + E_ML --> C_Assign : 8a. reserved_availability +else Si no hay stock + C_Assign --> C_Proc : 7b. Busca reabastecimiento + C_Proc --> E_WO : 8b. Consulta reglas + E_WO --> C_Proc : 9b. orderpoints aplicables + C_Proc --> E_PO : 10b. Crea purchase order (MTO) + E_PO --> C_Proc : 11b. PO creado + C_Proc --> C_Assign : 12b. Programado +end + +C_Assign --> E_Pick : 13. Actualiza estado +alt Si todas las lineas tienen reserva + E_Pick --> A : 14a. Estado = 'assigned' +else Si hay parcial + E_Pick --> A : 14b. Estado = 'partially_available' +end + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_rob_fac_001_crear_factura.puml b/diagrams/plantuml/d_rob_fac_001_crear_factura.puml new file mode 100644 index 0000000..04ada92 --- /dev/null +++ b/diagrams/plantuml/d_rob_fac_001_crear_factura.puml @@ -0,0 +1,57 @@ +@startuml D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura + +title SAP-TFI-2026 — Diagrama de Robustez - Crear Factura desde Pedido (CU-FAC-001) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Facturador\n(o Vendedor)" as A + +boundary "Boton Crear Factura\n(en sale.order)" as B_Btn + +control "SaleOrder\n(_create_invoices)" as C_Inv + +entity "sale.order\n(state=sale)" as E_SO +entity "sale.order.line" as E_Line +entity "account.move\n(draft)" as E_AM +entity "account.move.line" as E_AML +entity "account.tax" as E_Tax + +A --> B_Btn : 1. Click "Crear Factura" +B_Btn --> C_Inv : 2. _create_invoices() +C_Inv --> E_SO : 3. Lee pedido +E_SO --> C_Inv : 4. order, lines, taxes + +C_Inv --> E_SO : 5. Verifica invoice_status +alt Si hay lineas a facturar + C_Inv --> E_Line : 6a. Lee lineas pendientes + C_Inv --> E_Tax : 7a. Aplica impuestos + + loop Por cada linea + C_Inv --> E_AML : 8a. Crea account.move.line + E_AML --> C_Inv : 9a. OK + end + + C_Inv --> E_AM : 10a. Crea account.move (draft) + E_AM --> C_Inv : 11a. id, name (sequence) + + C_Inv --> E_SO : 12a. Asocia invoice_ids + C_Inv --> E_SO : 13a. Actualiza invoice_status +else Si nada que facturar + C_Inv --> A : 6b. Mensaje "Nothing to invoice" +end + +C_Inv --> A : 14. Resultado (OK o error) + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_rob_ven_001_crear_presupuesto.puml b/diagrams/plantuml/d_rob_ven_001_crear_presupuesto.puml new file mode 100644 index 0000000..6d6202d --- /dev/null +++ b/diagrams/plantuml/d_rob_ven_001_crear_presupuesto.puml @@ -0,0 +1,48 @@ +@startuml D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto + +title SAP-TFI-2026 — Diagrama de Robustez - Crear Presupuesto (CU-VEN-001) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Vendedor" as V + +boundary "Boton Nuevo\n(sale.menu)" as B_New +boundary "Form\n(view_sale_order_form)" as B_Form + +control "SaleOrder\n(action_quotation_send)" as C_Send +control "Mail Compose\n(mail.compose.message)" as C_Mail + +entity "sale.order\n(draft)" as E_SO +entity "mail.mail" as E_Mail + +V --> B_New : 1. Click "Nuevo" +B_New --> E_SO : 2. Crea sale.order en draft +E_SO --> B_Form : 3. Abre form +B_Form --> V : 4. Muestra form + +V --> B_Form : 5. Completa cliente y lineas +B_Form --> E_SO : 6. Actualiza partner_id y order_line +E_SO --> B_Form : 7. Calcula totales (_compute_amounts) + +opt Si envia por email + V --> B_Form : 8. Click "Enviar" + B_Form --> C_Send : 9. action_quotation_send() + C_Send --> E_SO : 10. Cambia estado a 'sent' + C_Send --> C_Mail : 11. Crea mail.compose.message + C_Mail --> E_Mail : 12. Genera mail.mail + E_Mail --> V : 13. Envia email +end + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_rob_ven_004_confirmar_pedido.puml b/diagrams/plantuml/d_rob_ven_004_confirmar_pedido.puml index 6d33811..b954d16 100644 --- a/diagrams/plantuml/d_rob_ven_004_confirmar_pedido.puml +++ b/diagrams/plantuml/d_rob_ven_004_confirmar_pedido.puml @@ -1,6 +1,6 @@ @startuml D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido -title SAP-TFI-2026 — Diagrama de Robustez: Confirmar Pedido de Venta (CU-VEN-004) +title SAP-TFI-2026 — Diagrama de Robustez - Confirmar Pedido de Venta (CU-VEN-004) skinparam shadowing false skinparam handwritten false diff --git a/diagrams/plantuml/d_sec_ent_002_reservar_productos.puml b/diagrams/plantuml/d_sec_ent_002_reservar_productos.puml new file mode 100644 index 0000000..b9fc4be --- /dev/null +++ b/diagrams/plantuml/d_sec_ent_002_reservar_productos.puml @@ -0,0 +1,71 @@ +@startuml D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos + +title SAP-TFI-2026 — Diagrama de Secuencia - Reservar Productos (CU-ENT-002) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Sistema" as S +participant "StockPicking\n(action_assign)" as SP +participant "StockMove\n(action_assign)" as SM +participant "Procurement\nOrder" as PO +database "PostgreSQL" as DB + +S -> SP : 1. action_assign() +activate SP + +SP -> DB : 2. SELECT picking + lines +DB --> SP : 3. picking, move_ids + +loop Por cada move + SP -> SM : 4. action_assign() por linea + activate SM + + SM -> DB : 5. SELECT stock.quant (available) + DB --> SM : 6. cantidad disponible + + alt Cantidad >= requerida + SM -> DB : 7a. INSERT stock.move.line (reserved) + DB --> SM : 8a. OK + SM --> SP : 9a. Reserva exitosa + else Cantidad < requerida + SM -> DB : 7b. SELECT orderpoint WHERE product_id=... + DB --> SM : 8b. orderpoints aplicables + + opt Si hay orderpoint MTO + SM -> PO : 9b. procurement.order.create() + activate PO + PO -> DB : 10b. INSERT procurement.order + PO -> DB : 11b. INSERT purchase.order (MTO) + DB --> PO : 12b. OK + PO --> SM : 13b. PO programado + deactivate PO + end + + SM --> SP : 14b. Reserva parcial o programada + end + deactivate SM +end + +SP -> DB : 15. UPDATE stock.picking SET state=... +DB --> SP : 16. OK + +alt Si todas las lineas reservadas + SP --> S : 17a. Estado = 'assigned' +else Si hay parcial + SP --> S : 17b. Estado = 'partially_available' +end +deactivate SP + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_sec_fac_001_crear_factura.puml b/diagrams/plantuml/d_sec_fac_001_crear_factura.puml new file mode 100644 index 0000000..7d1b2a5 --- /dev/null +++ b/diagrams/plantuml/d_sec_fac_001_crear_factura.puml @@ -0,0 +1,61 @@ +@startuml D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura + +title SAP-TFI-2026 — Diagrama de Secuencia - Crear Factura desde Pedido (CU-FAC-001) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Facturador" as F +participant "Boton" as Btn +participant "SaleOrder\n(_create_invoices)" as SO +participant "AccountMove" as AM +database "PostgreSQL" as DB + +F -> Btn : 1. Click "Crear Factura" +Btn -> SO : 2. _create_invoices() +activate SO + +SO -> DB : 3. SELECT sale.order (state='sale') +DB --> SO : 4. order + +SO -> SO : 5. Verifica invoice_status + +alt Hay lineas a facturar + SO -> DB : 6a. SELECT sale.order.line (qty to invoice) + DB --> SO : 7a. lines + + SO -> SO : 8a. _prepare_invoice() construye vals + activate AM + + AM -> DB : 9a. INSERT account.move (move_type='out_invoice', state='draft') + DB --> AM : 10a. id + + loop Por cada linea + AM -> DB : 11a. INSERT account.move.line + DB --> AM : 12a. id + end + + AM -> DB : 13a. UPDATE sale.order SET invoice_ids=... + AM -> DB : 14a. UPDATE sale.order SET invoice_status=... + deactivate AM + + SO --> Btn : 15a. Factura creada + Btn --> F : 16a. Mostrar factura +else Nada a facturar + SO --> Btn : 6b. raise UserError("Nothing to invoice") + Btn --> F : 7b. Mostrar error +end +deactivate SO + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml b/diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml new file mode 100644 index 0000000..7ce32fd --- /dev/null +++ b/diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml @@ -0,0 +1,81 @@ +@startuml D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto + +title SAP-TFI-2026 — Diagrama de Secuencia - Crear Presupuesto (CU-VEN-001) + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +actor "Vendedor" as V +participant "Form\n(view_sale_order_form)" as Form +participant "SaleOrder\nORM" as SO +participant "Mail\nComposer" as Mail +database "PostgreSQL" as DB + +V -> Form : 1. Click "Nuevo" +activate Form +Form -> SO : 2. Create({}) +activate SO +SO -> DB : 3. INSERT sale.order (state='draft') +DB --> SO : 4. id +SO --> Form : 5. sale.order record +deactivate SO + +V -> Form : 6. Selecciona partner_id +Form -> SO : 7. write({partner_id: ...}) +activate SO +SO -> DB : 8. UPDATE sale.order SET partner_id=... +DB --> SO : 9. OK +SO -> SO : 10. _onchange_partner_id() carga pricelist +SO -> DB : 11. SELECT product.pricelist +DB --> SO : 12. pricelist +SO --> Form : 13. pricelist_id actualizado +deactivate SO + +V -> Form : 14. Agrega lineas +loop Por cada linea + Form -> SO : 15. order_line = [(0, 0, {product_id, qty})] + SO -> DB : 16. INSERT sale.order.line + DB --> SO : 17. id +end + +V -> Form : 18. Sistema recalcula totales +Form -> SO : 19. _compute_amounts() +activate SO +SO -> DB : 20. SELECT tax, discount +DB --> SO : 21. datos +SO -> DB : 22. UPDATE amounts +SO --> Form : 23. amount_untaxed, amount_tax, amount_total +deactivate SO + +opt Si envia por email + V -> Form : 24. Click "Enviar" + Form -> SO : 25. action_quotation_send() + activate SO + SO -> SO : 26. _validate_analytic_distribution() + SO -> SO : 27. mark_so_as_sent = True + SO -> DB : 28. UPDATE state='sent' + SO -> Mail : 29. mail.compose.message.create + activate Mail + Mail -> DB : 30. INSERT mail.mail + DB --> Mail : 31. id + Mail --> SO : 32. OK + deactivate Mail + SO --> Form : 33. wizard closed + deactivate SO +end + +Form --> V : 34. Estado actualizado +deactivate Form + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodologia: ICONIX +Fuente: Ingenieria inversa de Odoo 19.0 +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/plantuml/d_sec_ven_004_confirmar_pedido.puml b/diagrams/plantuml/d_sec_ven_004_confirmar_pedido.puml index 221346e..fb2f925 100644 --- a/diagrams/plantuml/d_sec_ven_004_confirmar_pedido.puml +++ b/diagrams/plantuml/d_sec_ven_004_confirmar_pedido.puml @@ -1,6 +1,6 @@ @startuml D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido -title SAP-TFI-2026 — Diagrama de Secuencia: Confirmar Pedido de Venta (CU-VEN-004) +title SAP-TFI-2026 — Diagrama de Secuencia - Confirmar Pedido de Venta (CU-VEN-004) skinparam shadowing false skinparam handwritten false diff --git a/diagrams/png/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).png b/diagrams/png/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).png new file mode 100644 index 0000000..4e116a2 Binary files /dev/null and b/diagrams/png/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).png differ diff --git a/diagrams/png/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.png b/diagrams/png/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.png new file mode 100644 index 0000000..046f8a5 Binary files /dev/null and b/diagrams/png/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.png differ diff --git a/diagrams/png/D-CU-GEN-001 — Diagrama General de Casos de Uso.png b/diagrams/png/D-CU-GEN-001 — Diagrama General de Casos de Uso.png new file mode 100644 index 0000000..eb1a5ca Binary files /dev/null and b/diagrams/png/D-CU-GEN-001 — Diagrama General de Casos de Uso.png differ diff --git a/diagrams/png/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.png b/diagrams/png/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.png new file mode 100644 index 0000000..e8392fd Binary files /dev/null and b/diagrams/png/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.png differ diff --git a/diagrams/png/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.png b/diagrams/png/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.png new file mode 100644 index 0000000..30ed45e Binary files /dev/null and b/diagrams/png/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.png differ diff --git a/diagrams/png/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.png b/diagrams/png/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.png new file mode 100644 index 0000000..30f746c Binary files /dev/null and b/diagrams/png/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.png differ diff --git a/diagrams/png/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.png b/diagrams/png/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.png new file mode 100644 index 0000000..df1bfc2 Binary files /dev/null and b/diagrams/png/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.png differ diff --git a/diagrams/png/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.png b/diagrams/png/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.png new file mode 100644 index 0000000..ea2fe27 Binary files /dev/null and b/diagrams/png/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.png differ diff --git a/diagrams/png/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.png b/diagrams/png/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.png new file mode 100644 index 0000000..6a0e8a0 Binary files /dev/null and b/diagrams/png/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.png differ diff --git a/diagrams/png/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.png b/diagrams/png/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.png new file mode 100644 index 0000000..cae6849 Binary files /dev/null and b/diagrams/png/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.png differ diff --git a/diagrams/png/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.png b/diagrams/png/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.png new file mode 100644 index 0000000..8f585dc Binary files /dev/null and b/diagrams/png/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.png differ diff --git a/diagrams/svg/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).svg b/diagrams/svg/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).svg new file mode 100644 index 0000000..c3e0a6d --- /dev/null +++ b/diagrams/svg/D-CLA-CON-GEN-001 — Modelo de Dominio (Conceptual).svg @@ -0,0 +1,337 @@ +SAP-TFI-2026 — Modelo de Dominio ConceptualCliente+nombre: String+direccion: String+lista_precios: PriceList+condicion_pago: PaymentTermProducto+nombre: String+descripcion: String+precio: Money+categoria: Category+impuestos: Tax*Presupuesto+nombre: String+fecha: DateTime+estado: QuotationState+lineas: OrderLine*+total: MoneyPedidoVenta+nombre: String+fecha_confirmacion: DateTime+estado: OrderState+estado_facturacion: InvoiceStatus+estado_entrega: DeliveryStatus+lineas: OrderLine*+total: MoneyLineaPedido+producto: Producto+cantidad: Float+unidad: Unit+precio_unitario: Money+descuento: Float+impuestos: Tax*+subtotal: MoneyTransferencia+nombre: String+estado: PickingState+origen: Warehouse+destino: Warehouse+lineas: MoveLine*LineaMovimiento+producto: Producto+cantidad: Float+cantidad_reservada: Float+cantidad_entregada: Float+estado: MoveStateFactura+numero: String+fecha: Date+estado: InvoiceState+estado_pago: PaymentState+cliente: Cliente+lineas: InvoiceLine*+total: MoneyLineaFactura+producto: Producto+cantidad: Float+precio_unitario: Money+impuestos: Tax*+subtotal: Money+cuenta_contable: AccountPago+fecha: Date+monto: Money+metodo: PaymentMethod+diario: Journal+factura: FacturaAlmacen+nombre: String+codigo: String+direccion: StringUbicacion+nombre: String+almacen: Almacen+tipo: LocationTypeClientePresupuestoPedidoVentaFacturaLineaPedidoTransferenciaProductoLineaMovimientoAlmacenUbicacionLineaFacturaPagosolicita1*compra1*recibe1*se convierte en10..1contiene1*genera1*origina1*aparece en1*se convierte en1*contiene1*tiene1*origen/destino*2contiene1*recibe1*se factura en1*Proyecto: SAP-TFI-2026Agente: saptfi2026Metodología: ICONIXFuente: Ingeniería inversa de Odoo 19.0Modelo conceptual (separado del técnico) \ No newline at end of file diff --git a/diagrams/svg/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.svg b/diagrams/svg/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.svg new file mode 100644 index 0000000..06d8b3d --- /dev/null +++ b/diagrams/svg/D-CLA-INT-001 — Diagrama de Clases - Integracion Venta-Stock-Contabilidad.svg @@ -0,0 +1,239 @@ +SAP-TFI-2026 — Diagrama de Clases Técnicas (Integración Venta/Stock/Contabilidad)<sale.order>_name = "sale.order"_inherit = ["portal.mixin", "mail.thread", ...]name: Charpartner_id: Many2one(res.partner)state: Selectioninvoice_status: Selectionamount_untaxed: Monetaryamount_total: Monetaryaction_confirm()action_quotation_send()_create_invoices()<sale.order.line>_name = "sale.order.line"order_id: Many2one(sale.order)product_id: Many2one(product.product)product_uom_qty: Floatprice_unit: Floatdiscount: Floatprice_subtotal: Monetary<stock.picking>_name = "stock.picking"_inherit = ["mail.thread"]name: Charpartner_id: Many2one(res.partner)state: Selectionpicking_type_id: Many2one(stock.picking.type)action_confirm()action_assign()button_validate()<stock.move>_name = "stock.move"picking_id: Many2one(stock.picking)product_id: Many2one(product.product)product_uom_qty: Floatstate: Selectionaction_confirm()<account.move>_name = "account.move"name: Charpartner_id: Many2one(res.partner)move_type: Selectionstate: Selectioninvoice_date: Datepayment_state: Selectionaction_post()action_register_payment()<account.move.line>_name = "account.move.line"move_id: Many2one(account.move)product_id: Many2one(product.product)quantity: Floatprice_unit: Floatprice_subtotal: Monetaryorder_line1*invoice_ids1*sale_id*1move_ids1*sale_line_id*1line_ids1*invoice_line_ids*1Proyecto: SAP-TFI-2026Agente: saptfi2026Metodología: ICONIXFuente: Ingeniería inversa de Odoo 19.0Solo campos y métodos relevantes para el flujo de venta \ No newline at end of file diff --git a/diagrams/svg/D-CU-GEN-001 — Diagrama General de Casos de Uso.svg b/diagrams/svg/D-CU-GEN-001 — Diagrama General de Casos de Uso.svg new file mode 100644 index 0000000..44391bc --- /dev/null +++ b/diagrams/svg/D-CU-GEN-001 — Diagrama General de Casos de Uso.svg @@ -0,0 +1,86 @@ +SAP-TFI-2026 — Casos de Uso del Flujo PrincipalMódulo saleMódulo stockMódulo accountCU-VEN-001Crear presupuestoCU-VEN-004Confirmar pedidoCU-ENT-002Reservar productosCU-ENT-004Validar entregaCU-FAC-001Crear facturaCU-FAC-002Publicar facturaCU-FAC-003Registrar pagoVendedorOperariode AlmacénFacturador«flujo»«dispara»«precondición»«opcionalmente»«flujo»«flujo»Proyecto: SAP-TFI-2026Agente: saptfi2026Metodología: ICONIXFuente: Ingeniería inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.svg b/diagrams/svg/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.svg new file mode 100644 index 0000000..c330ae6 --- /dev/null +++ b/diagrams/svg/D-ROB-ENT-002 — Diagrama de Robustez: Reservar Productos.svg @@ -0,0 +1,68 @@ +SAP-TFI-2026 — Diagrama de Robustez - Reservar Productos (CU-ENT-002)Sistema(o Operario)Sistema(o Operario)Trigger(action_confirm o boton)Trigger(action_confirm o boton)StockPicking(action_assign)StockPicking(action_assign)Reabastecimiento(procurement)Reabastecimiento(procurement)stock.pickingstock.pickingstock.move.line(reservas)stock.move.line(reservas)stock.warehouse.orderpointstock.warehouse.orderpointpurchase.order(MTO)purchase.order(MTO)1. Trigger reserva2. Lee picking3. action_assign()4. Recorre lineas5. Busca stock disponible6. Cantidad disponiblealt[Si hay stock]7a. Reserva cantidad8a. reserved_availability[Si no hay stock]7b. Busca reabastecimiento8b. Consulta reglas9b. orderpoints aplicables10b. Crea purchase order (MTO)11b. PO creado12b. Programado13. Actualiza estadoalt[Si todas las lineas tienen reserva]14a. Estado = 'assigned'[Si hay parcial]14b. Estado = 'partially_available'Proyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.svg b/diagrams/svg/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.svg new file mode 100644 index 0000000..d4b0cd2 --- /dev/null +++ b/diagrams/svg/D-ROB-FAC-001 — Diagrama de Robustez: Crear Factura.svg @@ -0,0 +1,67 @@ +SAP-TFI-2026 — Diagrama de Robustez - Crear Factura desde Pedido (CU-FAC-001)Facturador(o Vendedor)Facturador(o Vendedor)Boton Crear Factura(en sale.order)Boton Crear Factura(en sale.order)SaleOrder(_create_invoices)SaleOrder(_create_invoices)sale.order(state=sale)sale.order(state=sale)sale.order.linesale.order.lineaccount.move(draft)account.move(draft)account.move.lineaccount.move.lineaccount.taxaccount.tax1. Click "Crear Factura"2. _create_invoices()3. Lee pedido4. order, lines, taxes5. Verifica invoice_statusalt[Si hay lineas a facturar]6a. Lee lineas pendientes7a. Aplica impuestosloop[Por cada linea]8a. Crea account.move.line9a. OK10a. Crea account.move (draft)11a. id, name (sequence)12a. Asocia invoice_ids13a. Actualiza invoice_status[Si nada que facturar]6b. Mensaje "Nothing to invoice"14. Resultado (OK o error)Proyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.svg b/diagrams/svg/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.svg new file mode 100644 index 0000000..f94495f --- /dev/null +++ b/diagrams/svg/D-ROB-VEN-001 — Diagrama de Robustez: Crear Presupuesto.svg @@ -0,0 +1,58 @@ +SAP-TFI-2026 — Diagrama de Robustez - Crear Presupuesto (CU-VEN-001)VendedorVendedorBoton Nuevo(sale.menu)Boton Nuevo(sale.menu)Form(view_sale_order_form)Form(view_sale_order_form)SaleOrder(action_quotation_send)SaleOrder(action_quotation_send)Mail Compose(mail.compose.message)Mail Compose(mail.compose.message)sale.order(draft)sale.order(draft)mail.mailmail.mail1. Click "Nuevo"2. Crea sale.order en draft3. Abre form4. Muestra form5. Completa cliente y lineas6. Actualiza partner_id y order_line7. Calcula totales (_compute_amounts)opt[Si envia por email]8. Click "Enviar"9. action_quotation_send()10. Cambia estado a 'sent'11. Crea mail.compose.message12. Genera mail.mail13. Envia emailProyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.svg b/diagrams/svg/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.svg new file mode 100644 index 0000000..a923ba2 --- /dev/null +++ b/diagrams/svg/D-ROB-VEN-004 — Diagrama de Robustez: Confirmar Pedido.svg @@ -0,0 +1,128 @@ +SAP-TFI-2026 — Diagrama de Robustez - Confirmar Pedido de Venta (CU-VEN-004)VendedorVendedorview_sale_order_form(form de pedido)view_sale_order_form(form de pedido)Wiz. ValidaciónWiz. ValidaciónSaleOrder(action_confirm)SaleOrder(action_confirm)Validator(_confirmation_error_message)Validator(_confirmation_error_message)ConfirmationValues(_prepare_confirmation_values)ConfirmationValues(_prepare_confirmation_values)Stock(_action_confirm)Stock(_action_confirm)Invoice(_create_invoices)Invoice(_create_invoices)sale.ordersale.ordersale.order.linesale.order.linestock.pickingstock.pickingaccount.moveaccount.move1. Click "Confirmar"2. Invoca action_confirm3. Valida pedido4. Lee estado y líneas5. Lee líneas6. OK / erroralt[Si OK]7. Prepara valores8. Write state='sale', date_order9. _action_confirm (stock)10. Crea picking11. _create_invoices (opcional)12. Crea factura13. Retorna OK[Si error]6b. Muestra error14. Muestra resultado (estado actualizado)Proyecto: SAP-TFI-2026Agente: saptfi2026Metodología: ICONIXFuente: Ingeniería inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.svg b/diagrams/svg/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.svg new file mode 100644 index 0000000..86c8560 --- /dev/null +++ b/diagrams/svg/D-SEC-ENT-002 — Diagrama de Secuencia: Reservar Productos.svg @@ -0,0 +1,81 @@ +SAP-TFI-2026 — Diagrama de Secuencia - Reservar Productos (CU-ENT-002)SistemaSistemaStockPicking(action_assign)StockPicking(action_assign)StockMove(action_assign)StockMove(action_assign)ProcurementOrderProcurementOrderPostgreSQLPostgreSQL1. action_assign()2. SELECT picking + lines3. picking, move_idsloop[Por cada move]4. action_assign() por linea5. SELECT stock.quant (available)6. cantidad disponiblealt[Cantidad >= requerida]7a. INSERT stock.move.line (reserved)8a. OK9a. Reserva exitosa[Cantidad < requerida]7b. SELECT orderpoint WHERE product_id=...8b. orderpoints aplicablesopt[Si hay orderpoint MTO]9b. procurement.order.create()10b. INSERT procurement.order11b. INSERT purchase.order (MTO)12b. OK13b. PO programado14b. Reserva parcial o programada15. UPDATE stock.picking SET state=...16. OKalt[Si todas las lineas reservadas]17a. Estado = 'assigned'[Si hay parcial]17b. Estado = 'partially_available'Proyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.svg b/diagrams/svg/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.svg new file mode 100644 index 0000000..a131eae --- /dev/null +++ b/diagrams/svg/D-SEC-FAC-001 — Diagrama de Secuencia: Crear Factura.svg @@ -0,0 +1,71 @@ +SAP-TFI-2026 — Diagrama de Secuencia - Crear Factura desde Pedido (CU-FAC-001)FacturadorFacturadorBotonBotonSaleOrder(_create_invoices)SaleOrder(_create_invoices)AccountMoveAccountMovePostgreSQLPostgreSQL1. Click "Crear Factura"2. _create_invoices()3. SELECT sale.order (state='sale')4. order5. Verifica invoice_statusalt[Hay lineas a facturar]6a. SELECT sale.order.line (qty to invoice)7a. lines8a. _prepare_invoice() construye vals9a. INSERT account.move (move_type='out_invoice', state='draft')10a. idloop[Por cada linea]11a. INSERT account.move.line12a. id13a. UPDATE sale.order SET invoice_ids=...14a. UPDATE sale.order SET invoice_status=...15a. Factura creada16a. Mostrar factura[Nada a facturar]6b. raise UserError("Nothing to invoice")7b. Mostrar errorProyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.svg b/diagrams/svg/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.svg new file mode 100644 index 0000000..1f8226a --- /dev/null +++ b/diagrams/svg/D-SEC-VEN-001 — Diagrama de Secuencia: Crear Presupuesto.svg @@ -0,0 +1,91 @@ +SAP-TFI-2026 — Diagrama de Secuencia - Crear Presupuesto (CU-VEN-001)VendedorVendedorForm(view_sale_order_form)Form(view_sale_order_form)SaleOrderORMSaleOrderORMMailComposerMailComposerPostgreSQLPostgreSQL1. Click "Nuevo"2. Create({})3. INSERT sale.order (state='draft')4. id5. sale.order record6. Selecciona partner_id7. write({partner_id: ...})8. UPDATE sale.order SET partner_id=...9. OK10. _onchange_partner_id() carga pricelist11. SELECT product.pricelist12. pricelist13. pricelist_id actualizado14. Agrega lineasloop[Por cada linea]15. order_line = [(0, 0, {product_id, qty})]16. INSERT sale.order.line17. id18. Sistema recalcula totales19. _compute_amounts()20. SELECT tax, discount21. datos22. UPDATE amounts23. amount_untaxed, amount_tax, amount_totalopt[Si envia por email]24. Click "Enviar"25. action_quotation_send()26. _validate_analytic_distribution()27. mark_so_as_sent = True28. UPDATE state='sent'29. mail.compose.message.create30. INSERT mail.mail31. id32. OK33. wizard closed34. Estado actualizadoProyecto: SAP-TFI-2026Agente: saptfi2026Metodologia: ICONIXFuente: Ingenieria inversa de Odoo 19.0 \ No newline at end of file diff --git a/diagrams/svg/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.svg b/diagrams/svg/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.svg new file mode 100644 index 0000000..300f68b --- /dev/null +++ b/diagrams/svg/D-SEC-VEN-004 — Diagrama de Secuencia: Confirmar Pedido.svg @@ -0,0 +1,90 @@ +SAP-TFI-2026 — Diagrama de Secuencia - Confirmar Pedido de Venta (CU-VEN-004)VendedorVendedorForm(view_sale_order_form)Form(view_sale_order_form)SaleOrder(action_confirm)SaleOrder(action_confirm)Validator(_confirmation_error_message)Validator(_confirmation_error_message)Conf. Values(_prepare_confirmation_values)Conf. Values(_prepare_confirmation_values)Stock Layer(_action_confirm)Stock Layer(_action_confirm)Invoice Layer(_create_invoices)Invoice Layer(_create_invoices)PostgreSQLPostgreSQL1. Click "Confirmar"2. action_confirm()3. _confirmation_error_message()4. SELECT state, lines5. estado + líneasalt[Si estado OK y líneas OK]6a. error_msg = None (OK)[Si error]6b. error_msg (UserError)7b. raise UserError8b. Muestra error9. SELECT order_line for analytic validation10. líneas11. _prepare_confirmation_values()12. {'state': 'sale', 'date_order': now}13. UPDATE sale.order SET state='sale', date_order=...14. OK15. _action_confirm()16. INSERT stock.picking, stock.move17. OK18. pickings creadosopt[Si auto-factura configurada]19. _create_invoices()20. INSERT account.move21. OK22. factura creada23. return True24. Estado actualizado a "sale"Proyecto: SAP-TFI-2026Agente: saptfi2026Metodología: ICONIXFuente: Ingeniería inversa de Odoo 19.0 \ No newline at end of file diff --git a/docs/09_trazabilidad/matriz_trazabilidad.md b/docs/09_trazabilidad/matriz_trazabilidad.md index a133ae0..bb743ff 100644 --- a/docs/09_trazabilidad/matriz_trazabilidad.md +++ b/docs/09_trazabilidad/matriz_trazabilidad.md @@ -87,6 +87,16 @@ | EV-COD-018 | EV-COD | `state` field (account.move) | `addons/account/models/account_move.py:129` | | EV-COD-019 | EV-COD | `action_register_payment` | `addons/account/models/account_move.py:6022` | | EV-COD-020 | EV-COD | `payment_state` field | `addons/account/models/account_move.py:600` | +| EV-COD-021 | EV-COD | `_action_confirm` stub | `addons/sale/models/sale_order.py:1231-1235` | +| EV-COD-022 | EV-COD | `action_assign` cuerpo | `addons/stock/models/stock_picking.py:1195-1208` | +| EV-COD-023 | EV-COD | `picking_ids` (sale_stock) | `addons/sale_stock/models/sale_order.py:31` | +| EV-COD-024 | EV-COD | `PAYMENT_STATE_SELECTION` | `addons/account/models/account_move.py:48-56` | +| EV-COD-025 | EV-COD | `payment_state` (computed) | `addons/account/models/account_move.py:600-606` | +| EV-COD-026 | EV-COD | `action_post` cuerpo | `addons/account/models/account_move.py:6101-6122` | +| EV-COD-027 | EV-COD | `_send_order_confirmation_mail` | `addons/sale/models/sale_order.py:1237-1244` | +| EV-COD-028 | EV-COD | `_trigger_scheduler()` | `addons/sale/models/sale_order.py:1192` | +| EV-COD-029 | EV-COD | `action_cancel` (stock) | `addons/stock/models/stock_picking.py:1210-1214` | +| EV-COD-030 | EV-COD | `_should_be_locked` | `addons/sale/models/sale_order.py:1198-1201` | ## Inferencias pendientes (EV-INF) diff --git a/docs/10_material_estudio/01_que_es_iconix.md b/docs/10_material_estudio/01_que_es_iconix.md new file mode 100644 index 0000000..6e573bb --- /dev/null +++ b/docs/10_material_estudio/01_que_es_iconix.md @@ -0,0 +1,137 @@ +# ¿Qué es ICONIX? + +## Definición + +**ICONIX** es una metodología de ingeniería de software orientada a objetos que se sitúa entre los métodos ágiles (como XP o Scrum) y los métodos pesados (como el Proceso Unificado Rational — RUP). Fue desarrollada por **Doug Rosenberg** y **Kendall Scott** a principios de los 90, y refinada en sucesivas ediciones de su libro *Use Case Driven Object Modeling with UML*. + +A diferencia de RUP o del método del Proceso Unificado, ICONIX **no se obsesiona con la documentación exhaustiva**, pero tampoco cae en el "codificar sin diseño" del agilismo extremo. En su lugar, propone un **camino mínimo y práctico** desde los requisitos hasta el código, usando UML como lenguaje común. + +## Las 9 fases de ICONIX + +A pesar de su nombre, ICONIX tiene 9 fases (no 3). El "IX" del nombre se refiere a "eXtremidad", porque el método es "extremo" en su enfoque minimalista: solo lo esencial, sin ceremonias. + +```text +Requisitos + ↓ +Casos de uso (texto + diagrama) + ↓ +Modelo de dominio (conceptos del negocio) + ↓ +Prototipos de interfaz (bocetos de pantallas) + ↓ +Análisis de robustez (¿qué objetos intervienen?) + ↓ +Actualización del modelo de dominio + ↓ +Diagramas de secuencia (interacciones en el tiempo) + ↓ +Diagramas de clases (estructura del sistema) + ↓ +Validación de coherencia +``` + +Cada fase **alimenta** a la siguiente y mantiene **trazabilidad** con las anteriores. No se salta ninguna. + +## El flujo en detalle + +### Fase 1: Requisitos + +- Identificar **qué** tiene que hacer el sistema. +- Recopilar requisitos funcionales y no funcionales. +- Identificar **actores** (humanos y sistemas externos). +- Producto: documento de requisitos (puede ser informal). + +### Fase 2: Casos de uso + +- Para cada objetivo del actor, escribir un **caso de uso**. +- Cada CU tiene: nombre, objetivo, precondiciones, flujo principal, flujos alternativos, excepciones. +- Producto: tabla de CU + **diagrama de CU** (UML). + +### Fase 3: Modelo de dominio + +- Identificar **conceptos del negocio**, no de la solución. +- Conceptos como: Cliente, Producto, Pedido, Factura, Pago. +- No incluir campos técnicos, solo atributos del dominio. +- Producto: **diagrama de clases conceptual**. + +### Fase 4: Prototipos de interfaz + +- Bocetos de las pantallas principales. +- No incluir detalles visuales, solo estructura. +- Mostrar campos, botones, navegación. +- Producto: wireframes o mockups. + +### Fase 5: Análisis de robustez + +- Para cada CU, identificar **qué objetos intervienen**. +- Tres tipos de objetos: + - **boundary** (vista, formulario, API) + - **control** (coordinador, validador) + - **entity** (objeto persistente) +- Producto: **diagrama de robustez** por CU. + +### Fase 6: Actualización del dominio + +- Refinar el modelo de dominio con conceptos descubiertos en robustez. + +### Fase 7: Diagramas de secuencia + +- Para cada CU relevante, derivar la **secuencia temporal**. +- Mostrar interacciones entre actor, vistas, controles, entidades. +- Incluir transacciones, validaciones, errores. +- Producto: **diagrama de secuencia** por CU. + +### Fase 8: Diagramas de clases + +- **Conceptual**: conceptos del dominio (reutiliza el modelo de dominio). +- **Técnico**: clases reales del sistema, con sus campos y métodos. +- Producto: **dos diagramas de clases** por subsistema. + +### Fase 9: Validación + +- Verificar coherencia entre todos los artefactos. +- Cada CU debe tener su diagrama de robustez, secuencia y clases. +- Cada regla de negocio debe estar trazada. + +## Reglas clave de ICONIX + +1. **Trabajar desde los casos de uso hacia el diseño** (no al revés). +2. **Centrarse en objetivos del actor**, no en funciones del sistema. +3. **No describir detalles internos del código** en los CU. +4. **Usar robustez como puente** entre requisitos y diseño. +5. **Distinguir boundary, control, entity** explícitamente. +6. **Derivar operaciones de clase desde los mensajes de secuencia**. +7. **Mantener trazabilidad explícita** entre todos los artefactos. +8. **Actualizar el modelo de dominio** a medida que se descubre nueva información. + +## Por qué ICONIX es ideal para ingeniería inversa + +Cuando uno hace **ingeniería inversa** (analizar un sistema existente), ICONIX funciona muy bien porque: + +- Los **diagramas de secuencia** que produce coinciden con los métodos reales del código. +- El **modelo de clases técnico** se construye leyendo el código, no inventando. +- La **trazabilidad** permite mapear cada artefacto a su evidencia en el código. + +En este proyecto (SAP-TFI-2026), usamos ICONIX para **documentar** Odoo 19.0, no para **construirlo**. Cada afirmación tiene un código de evidencia que apunta a la línea exacta del código fuente. + +## Diferencias con otros métodos + +| Aspecto | ICONIX | RUP | Scrum | +|---------|--------|-----|-------| +| Rigurosidad | Media-alta | Muy alta | Baja | +| Documentación | Moderada | Exhaustiva | Mínima | +| UML | Sí, en el camino crítico | Sí, en todas las fases | No obligatorio | +| Casos de uso | Sí, centrales | Sí, conductores | Opcionales | +| Iterativo | Opcional | Sí | Sí | +| Tamaño del equipo | 1-5 personas | 5-30 personas | 3-9 personas | +| Tiempo por iteración | Semanas | Meses | Semanas | + +## Recursos externos + +- Libro original: *Use Case Driven Object Modeling with UML* (Rosenberg & Scott). +- Sitio oficial: http://www.iconixprocess.com/ +- Resumen en español: https://es.wikipedia.org/wiki/ICONIX + +## Próxima sección + +→ [Aplicación a Odoo](02_aplicacion_a_odoo.md) — cómo se adaptó ICONIX específicamente para este proyecto. \ No newline at end of file diff --git a/docs/10_material_estudio/02_aplicacion_a_odoo.md b/docs/10_material_estudio/02_aplicacion_a_odoo.md new file mode 100644 index 0000000..a5dfd84 --- /dev/null +++ b/docs/10_material_estudio/02_aplicacion_a_odoo.md @@ -0,0 +1,115 @@ +# Aplicación de ICONIX a Odoo + +## Contexto específico + +Este proyecto documenta la **ingeniería inversa** de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Odoo es un ERP open-source complejo, con +30,000 archivos Python y más de 100 modelos en estos 4 módulos solamente. + +Aplicar ICONIX directamente sobre Odoo presenta desafíos únicos: + +1. **Herencia múltiple**: los modelos heredan de muchos mixins (`mail.thread`, `mail.activity.mixin`, `portal.mixin`, etc.). El "modelo de clases técnico" debe reflejar esto. +2. **Campos computados**: muchos campos no están en la BD, se calculan dinámicamente (`_compute_*`). +3. **Métodos `onchange`**: disparan lógica al cambiar un campo en el form. +4. **Acciones (`ir.actions.act_window`)**: definen vistas, wizards, botones. +5. **Multi-empresa y multi-moneda**: las reglas de registro y campos monetarios son contextuales. +6. **Estado del modelo de dominio vs modelo técnico**:，我们必须separar los conceptos del negocio (Cliente, Producto, Pedido) de las clases técnicas (`res.partner`, `product.product`, `sale.order`). + +## Adaptaciones realizadas + +### 1. Separación modelo conceptual vs técnico + +**Decisión clave**: mantener **dos diagramas de clases separados**. + +- **Modelo conceptual** (`d_cla_con_gen_001_modelo_dominio.puml`): solo conceptos del negocio. Cliente, Producto, Presupuesto, Pedido, Factura, Pago. Atributos en lenguaje natural, no campos. +- **Modelo técnico** (`d_cla_int_001_integracion_ven_stock_cont.puml`): las clases REALES de Odoo con sus `_name`, `_inherit`, campos y métodos. Aquí sí aparecen `res.partner`, `sale.order`, `account.move`, etc. + +### 2. Uso de códigos de evidencia EV-* + +Cada afirmación tiene un código que apunta a su fuente: + +| Código | Significado | Verificable contra | +|--------|-------------|---------------------| +| `EV-COD-NNN` | Código fuente | Ruta de archivo + línea exacta | +| `EV-XML-NNN` | Vista o dato XML | Ruta XML + elemento | +| `EV-UI-NNN` | Comportamiento observado | Manual o screenshot | +| `EV-DB-NNN` | Estructura de BD | Tabla y columnas | +| `EV-DOC-NNN` | Documentación oficial | URL + sección | +| `EV-TEST-NNN` | Prueba automatizada | Ruta del test | +| `EV-INF-NNN` | Inferencia pendiente | (no verificado) | + +Esto permite que un revisor pueda **verificar** cada afirmación abriendo el código en la línea exacta. + +### 3. Foco en el flujo principal + +La primera iteración se enfoca en **un solo flujo** end-to-end: + +``` +Crear presupuesto → Confirmar pedido → Reservar productos → +Validar entrega → Crear factura → Publicar factura → Registrar pago +``` + +Es el flujo más importante del circuito comercial. Una vez documentado, se pueden agregar CU adicionales (cancelaciones, devoluciones, notas de crédito) en iteraciones siguientes. + +### 4. PlantUML como formato estándar + +Todos los diagramas están en **PlantUML** (texto plano, versionable). Esto permite: + +- Editar los diagramas con cualquier editor. +- Generar PDFs, PNGs, SVGs automáticamente. +- Hacer diff de los cambios en git. + +La cabecera estándar (en todos los .puml) es: + +```plantuml +@startuml +title SAP-TFI-2026 — + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 12 +skinparam linetype ortho +skinparam backgroundColor white + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Metodología: ICONIX +Fuente: Ingeniería inversa de Odoo +endlegend + +@enduml +``` + +### 5. Reglas de naming + +| Tipo | Patrón | Ejemplo | +|------|--------|---------| +| Caso de uso | `CU-{AREA}-{NNN}` | `CU-VEN-001` | +| Regla de negocio | `RN-{AREA}-{NNN}` | `RN-VEN-002` | +| Diagrama | `D-{TYPE}-{AREA}-{NNN}` | `D-ROB-VEN-004` | +| Archivo | `lowercase_with_underscores` | `cu_ven_001_crear_presupuesto.md` | +| Evidencia | `EV-{TYPE}-{NNN}` | `EV-COD-001` | + +Áreas: `VEN` (Ventas), `FAC` (Facturación), `ENT` (Entregas), `INV` (Inventario), `ARQ` (Arquitectura), `DOM` (Dominio), `GEN` (General). + +## Resultados de la primera iteración + +- **7 CU** documentados con especificación completa (objetivo, alcance, actor, flujos, excepciones, RN, modelos Odoo, métodos, pantallas, evidencia). +- **2 diagramas de robustez** (CU-VEN-001, CU-VEN-004, CU-ENT-002, CU-FAC-001). +- **3 diagramas de secuencia** (idem). +- **1 modelo de dominio conceptual** con 12 conceptos y 9 reglas de negocio. +- **1 modelo de clases técnicas** mostrando la integración entre venta, stock y contabilidad. +- **30 EV-COD** generadas (código verificado contra código real de Odoo 19.0). +- **8 EV-INF** pendientes (reducidas desde 22 originales tras validación). + +## Herramientas + +- **Hermano (este agente)**: el swarm `saptfi2026` con 8 skills especializadas. +- **PlantUML**: para generar los diagramas. +- **Git**: para versionar todo. +- **OpenRouter + minimax-m3**: como modelo de lenguaje. +- **GitHub**: para publicar el repo (gate S2: push solo con OK manual de Ale). + +## Próxima sección + +→ [Cómo leer los CU](03_como_leer_los_cu.md) — guía paso a paso para interpretar las especificaciones. \ No newline at end of file diff --git a/docs/10_material_estudio/03_como_leer_los_cu.md b/docs/10_material_estudio/03_como_leer_los_cu.md new file mode 100644 index 0000000..a8c3e6a --- /dev/null +++ b/docs/10_material_estudio/03_como_leer_los_cu.md @@ -0,0 +1,167 @@ +# Cómo leer los Casos de Uso + +## Estructura de un CU + +Cada archivo `cu_xxx_nnn_nombre.md` tiene **20 secciones fijas**. Vamos a recorrerlas una por una con un ejemplo real. + +## Ejemplo: CU-VEN-001 Crear Presupuesto + +Vamos a leer el archivo [`cu_ven_001_crear_presupuesto.md`](../../02_casos_uso/cu_ven_001_crear_presupuesto.md) sección por sección. + +### 1. Objetivo + +> *"Crear un presupuesto de venta (sales quotation) para un cliente en estado `draft`."* + +**Qué te dice**: en una frase, qué hace el CU. Si no podés resumir el CU en una oración, probablemente está mal definido. + +### 2. Alcance + +> *"Módulo `sale` de Odoo 19.0. Aplica al modelo `sale.order`."* + +**Qué te dice**: en qué parte del sistema aplica. El módulo y el modelo principal. + +### 3. Nivel + +> *"Primario (esencial para el proceso de ventas)."* + +**Tres valores posibles**: +- **Primario**: esencial, no se puede eliminar. +- **Secundario**: importante pero no esencial. +- **Opcional**: nice-to-have. + +### 4. Actor principal + +> *"Vendedor (usuario con permisos `sales_team.group_sale_salesman`)."* + +**Qué te dice**: quién inicia el CU. Siempre con el permiso técnico necesario. + +### 5. Actores secundarios + +> *"Cliente (consulta estado), Servicio de correo (envía presupuesto)."* + +**Qué te dice**: otros actores involucrados pero que no inician el CU. + +### 6. Interesados (stakeholders) + +> *"Responsable de ventas (aprueba descuentos), Administración (visualiza pipeline)."* + +**Qué te dice**: personas o sistemas afectados por el CU, aunque no participen directamente. + +### 7. Disparador + +> *"El vendedor hace clic en 'Nuevo' desde la vista kanban o tree de `sale.order`."* + +**Qué te dice**: qué evento inicia el CU. + +### 8. Precondiciones + +> *"El usuario tiene acceso al módulo `sale`. Existe al menos un cliente activo en `res.partner`. El catálogo de productos contiene productos publicables."* + +**Qué te dice**: qué condiciones deben cumplirse ANTES de que el CU pueda ejecutarse. + +### 9. Garantías mínimas + +> *"El sistema crea un registro `sale.order` en estado `draft` sin errores."* + +**Qué te dice**: qué pasa **incluso si algo falla**. Por ejemplo, "se crea el registro aunque después falle otro paso". + +### 10. Garantías de éxito + +> *"El presupuesto tiene un `name` único asignado por la secuencia `sale.order`. Los totales se calculan automáticamente con impuestos."* + +**Qué te dice**: qué pasa **cuando todo sale bien**. + +### 11. Flujo principal (paso a paso) + +> 1. Vendedor hace clic en "Nuevo" → sistema crea `sale.order` en estado `draft`. +> 2. Sistema asigna `name` con valor por defecto... +> 3. Vendedor selecciona `partner_id`... + +**Qué te dice**: la secuencia de pasos **felices**. Cada paso debe ser verificable. + +### 12. Flujos alternativos + +> FA-01 — Aplicar descuento +> 1. Vendedor edita `discount` en una línea... + +**Qué te dice**: variaciones del flujo principal. Se numeran como FA-NN. + +### 13. Excepciones + +> EX-01 — Cliente sin dirección de entrega +> 1. Al intentar confirmar (estado `sale`), sistema valida... + +**Qué te dice**: qué pasa cuando algo falla. Se numeran como EX-NN. + +### 14. Reglas de negocio + +> - **RN-VEN-001**: `state` solo puede pasar de `draft` → `sent` → `sale`, o a `cancel`. + +**Qué te dice**: reglas que el sistema debe enforzar. Se numeran como RN-{AREA}-{NNN}. + +### 15. Datos de entrada / salida + +**Entrada**: cliente, compañía, moneda, lista de precios, líneas. +**Salida**: registro `sale.order` persistido, líneas, correo. + +**Qué te dice**: qué información fluye hacia adentro y hacia afuera. + +### 16. Estados involucrados + +> `draft` → `sent` → `sale` (o `cancel`). + +**Qué te dice**: las transiciones de estado del modelo. + +### 17. Pantallas involucradas + +> - `view_sale_order_form` +> - `view_sale_order_kanban` +> - `view_sale_order_tree` + +**Qué te dice**: las vistas que el usuario ve durante el CU. + +### 18. Modelos y métodos de Odoo + +> **Modelos**: `sale.order`, `sale.order.line`, `res.partner`, `product.product`... +> **Métodos**: `action_quotation_send()`, `action_confirm()`, `_compute_amounts()`... + +**Qué te dice**: las clases técnicas de Odoo y sus métodos. Acá empieza el modelo técnico. + +### 19. Permisos y configuraciones + +> - `sales_team.group_sale_salesman` (vendedor) +> - `sales_team.group_sale_manager` (responsable) + +**Qué te dice**: permisos requeridos y configuraciones que afectan el CU. + +### 20. Evidencias de ingeniería inversa + +> **EV-COD-001**: `addons/sale/models/sale_order.py:34-36` — definición de la clase `SaleOrder` con `_name = 'sale.order'`. + +**Qué te dice**: **la fuente exacta** que respalda cada afirmación. **Esta es la sección más importante** del CU. + +## Cómo navegar un CU para entender un proceso + +1. **Empezá por el Objetivo y el Disparador** (sección 1 y 7). +2. **Leé el Flujo principal** (sección 11) para entender el camino feliz. +3. **Revisá las Reglas de negocio** (sección 14) para entender las restricciones. +4. **Leé las Evidencias** (sección 20) para validar que lo que dice el CU coincide con el código real. +5. Si necesitás detalle técnico, mirá las secciones 17-19 (pantallas, modelos, métodos). + +## Diferencia entre CU y método técnico + +Un **CU** describe **qué** hace el sistema desde la perspectiva del usuario. Un **método técnico** describe **cómo** lo hace. + +Por ejemplo: + +| CU | Método | +|----|--------| +| *"Vendedor confirma el pedido"* | `sale.order.action_confirm()` | +| *"El sistema valida que las líneas tengan producto"* | `_confirmation_error_message()` retorna string si hay error | +| *"Se envía email al cliente"* | `action_quotation_send()` abre wizard de email | + +Cuando leas un CU, **no te pierdas en los métodos**. Lee primero el flujo, después mirá los métodos para entender la implementación. + +## Próxima sección + +→ [Ejercicios prácticos](04_ejercicios_practicos.md) — para fijar los conceptos. \ No newline at end of file diff --git a/docs/10_material_estudio/04_ejercicios_practicos.md b/docs/10_material_estudio/04_ejercicios_practicos.md new file mode 100644 index 0000000..d4e17c5 --- /dev/null +++ b/docs/10_material_estudio/04_ejercicios_practicos.md @@ -0,0 +1,146 @@ +# Ejercicios Prácticos + +## Objetivo + +Estos ejercicios te ayudan a **fijar los conceptos** de ICONIX aplicados a Odoo. Trabajan sobre los artefactos reales de este proyecto. + +## Antes de empezar + +Asegurate de tener: +1. El código fuente de Odoo 19.0 clonado (en `~/proyectos/odoo_src/odoo`). +2. Los CU de este proyecto (en `docs/02_casos_uso/`). +3. Un editor de texto y PlantUML instalados. + +## Ejercicio 1: Validar una afirmación con código + +**Objetivo**: entender el flujo de evidencia EV-COD. + +**Tarea**: +1. Abrí el archivo `docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`. +2. Buscá la evidencia `EV-COD-001`. +3. Abrí el archivo `addons/sale/models/sale_order.py` en `~/proyectos/odoo_src/odoo/`. +4. Andá a las líneas 34-36. +5. Verificá que el código realmente coincide con lo que dice la evidencia. + +**Pregunta para responder**: +- ¿Qué patrón sigue la herencia de `SaleOrder`? ¿Por qué creés que se eligieron esos mixins? + +## Ejercicio 2: Diferenciar modelo conceptual de técnico + +**Objetivo**: entender por qué mantenemos dos diagramas separados. + +**Tarea**: +1. Abrí `diagrams/plantuml/d_cla_con_gen_001_modelo_dominio.puml` (modelo conceptual). +2. Abrí `diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml` (modelo técnico). +3. Compilá ambos con PlantUML: `java -jar plantuml.jar -tpdf archivo.puml`. +4. Compará los PDFs. + +**Preguntas para responder**: +- ¿Qué conceptos están en el conceptual pero NO en el técnico? ¿Por qué? +- ¿Qué campos del técnico NO están en el conceptual? ¿Por qué? +- ¿Cuándo usarías uno y cuándo el otro? + +## Ejercicio 3: Seguir un flujo de punta a punta + +**Objetivo**: trazar el flujo completo del CU-VEN-001 al código real. + +**Tarea**: +1. Abrí el CU-VEN-001 (`docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`). +2. Abrí `diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml` (secuencia). +3. Compilá ambos y mirá los PDFs. +4. Para cada paso del flujo principal, identificá: + - Qué archivo y método de Odoo se ejecuta. + - Qué tabla de BD se modifica. + - Qué evidencia (EV-COD) lo respalda. + +**Output esperado**: una tabla con columnas `Paso | Método Odoo | Tabla BD | Evidencia`. + +## Ejercicio 4: Crear un CU nuevo + +**Objetivo**: aplicar ICONIX para agregar un caso que NO está en la primera iteración. + +**Tarea**: elegí UNO de los siguientes CU y documentalo siguiendo la plantilla: + +### Opción A: CU-VEN-005 Cancelar pedido + +**Contexto**: el vendedor necesita cancelar un pedido que ya estaba confirmado. + +**Pasos**: +1. Leé CU-VEN-001 y CU-VEN-004 para entender el contexto. +2. Investigá el método `action_cancel()` en `addons/sale/models/sale_order.py:1324`. +3. Investigá también cómo `sale_stock` extiende la cancelación. +4. Escribí `docs/02_casos_uso/cu_ven_005_cancelar_pedido.md`. +5. Generá el diagrama de robustez y secuencia. +6. Generá EV-COD para cada afirmación. + +### Opción B: CU-FAC-005 Emitir nota de crédito + +**Contexto**: el facturador necesita revertir una factura publicada. + +**Pasos**: +1. Investigá el flujo de notas de crédito en Odoo 19. +2. Buscá `_reverse_moves()` o `action_reverse()` en `addons/account/models/account_move.py`. +3. Documentá el CU. +4. Generá los diagramas y las evidencias. + +### Opción C: CU-INV-001 Consultar existencias + +**Objetivo**: el operador de inventario quiere ver cuántas unidades hay de un producto. + +**Pasos**: +1. Investigá el modelo `stock.quant` en `addons/stock/models/stock_quant.py`. +2. Investigá cómo se accede desde el form de producto. +3. Documentá el CU. +4. Generá los diagramas y las evidencias. + +## Ejercicio 5: Validar una EV-INF + +**Objetivo**: cerrar el ciclo de evidencia. + +**Tarea**: +1. Abrí `evidence/index.md`. +2. Elegí UNA EV-INF pendiente (ejemplo: EV-INF-008 sobre `button_validate`). +3. Buscá el código relevante en Odoo: + - `grep -n "def button_validate" addons/stock/models/stock_picking.py` + - Leé el método completo (~50 líneas). +4. Verificá si la inferencia es correcta. +5. Si es correcta: convertila en EV-COD con la ruta y línea exacta. +6. Si es incorrecta: marcala como obsoleta y proponé una EV-COD corregida. + +## Ejercicio 6: Mejorar la trazabilidad + +**Objetivo**: entender la matriz de trazabilidad. + +**Tarea**: +1. Abrí `docs/09_trazabilidad/matriz_trazabilidad.md`. +2. Agregá una fila para CU-VEN-005 (cancelación). +3. Definí las relaciones: + - ¿Qué reglas de negocio aplica? + - ¿A qué modelo Odoo apunta? + - ¿Qué evidencia EV-COD lo respalda? +4. Actualizá la matriz. + +## Criterios de evaluación + +| Criterio | Excelente | Aceptable | Necesita mejora | +|----------|-----------|------------|-----------------| +| Uso de evidencia | Cada afirmación tiene EV-COD con línea exacta | Algunas EV-INF | Muchas afirmaciones sin evidencia | +| Separación conceptual/técnico | Clara y justificada | Presente pero confusa | Mezclados | +| Compilabilidad PlantUML | Todos los .puml compilan sin error | Algunos fallan | Muchos fallan | +| Trazabilidad | Matriz completa y consistente | Algunas relaciones | Sin matriz | +| Aplicación de ICONIX | Las 9 fases reflejadas en artefactos | Algunas fases | Solo CU, sin resto | + +## Recursos para profundizar + +- **Libros**: + - *Use Case Driven Object Modeling with UML* — Rosenberg & Scott. + - *Applying UML and Patterns* — Craig Larman. + - *OCA Odoo Development Essentials* — Daniel Reis (para Odoo técnico). + +- **Sitios web**: + - https://www.odoo.com/documentation/19.0/ — docs oficiales de Odoo 19. + - https://github.com/odoo/odoo/tree/19.0 — código fuente. + +- **Herramientas**: + - PlantUML: https://plantuml.com/ + - Odoo CLI: https://www.odoo.com/documentation/19.0/administration/install/cli.html \ No newline at end of file diff --git a/docs/10_material_estudio/README.md b/docs/10_material_estudio/README.md new file mode 100644 index 0000000..1c20b24 --- /dev/null +++ b/docs/10_material_estudio/README.md @@ -0,0 +1,38 @@ +# Material Educativo — SAP-TFI-2026 + +> Material pedagógico para estudiantes del curso SAP-TFI-2026 y revisores técnicos. + +## ¿Qué encontrarás aquí? + +Este material explica **cómo se aplicó la metodología ICONIX** para hacer ingeniería inversa de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Está pensado para que cualquier estudiante o analista pueda entender el proceso y replicarlo. + +## Secciones + +| # | Sección | Descripción | +|---|---------|-------------| +| 1 | [¿Qué es ICONIX?](01_que_es_iconix.md) | Introducción a la metodología ICONIX | +| 2 | [Aplicación a Odoo](02_aplicacion_a_odoo.md) | Cómo se adaptó ICONIX a Odoo | +| 3 | [Cómo leer los CU](03_como_leer_los_cu.md) | Guía para leer las especificaciones de casos de uso | +| 4 | [Ejercicios prácticos](04_ejercicios_practicos.md) | Ejercicios para fijar los conceptos | + +## Audiencia + +- **Estudiantes** del curso SAP-TFI-2026 que están aprendiendo ICONIX. +- **Analistas funcionales** que necesitan entender Odoo antes de implementarlo. +- **Desarrolladores** que quieren entender cómo está estructurado Odoo por dentro. +- **Revisores técnicos** que validan que la documentación refleja el código real. + +## Cómo usar este material + +1. **Empezá por la sección 1** para entender qué es ICONIX. +2. **Leé la sección 2** para ver cómo se aplicó específicamente a Odoo. +3. **Usá la sección 3 como referencia** cada vez que leas un CU. +4. **Hacé los ejercicios de la sección 4** para fijar los conceptos. + +## Regla de oro del material + +> **Cada afirmación sobre Odoo tiene una fuente de evidencia.** Si no podés verificar una afirmación contra código, está marcada como `EV-INF` (inferencia pendiente). Si la podés verificar contra código real, está marcada como `EV-COD` (código verificado) con la ruta exacta del archivo y la línea. + +## Cómo se generó + +Este material fue generado por el agente `saptfi2026` (parte del swarm Hermano de Ale Sartorio) aplicando la metodología ICONIX de manera rigurosa, con verificación contra el código fuente oficial de Odoo 19.0 (rama `19.0` del repositorio `https://github.com/odoo/odoo`). \ No newline at end of file diff --git a/evidence/index.md b/evidence/index.md new file mode 100644 index 0000000..4c2c9c9 --- /dev/null +++ b/evidence/index.md @@ -0,0 +1,80 @@ +# Índice de Evidencias — SAP-TFI-2026 + +> Última actualización: 2026-06-18 + +## EV-COD — Código fuente verificado (30 evidencias) + +| ID | Modelo | Ruta | Línea | Descripción | +|----|--------|------|------:|-------------| +| EV-COD-001 | sale.order | addons/sale/models/sale_order.py | 34-36 | Definición de clase `SaleOrder` con `_name='sale.order'` | +| EV-COD-002 | sale.order | addons/sale/models/sale_order.py | 26-31 | `SALE_ORDER_STATE`: `draft`, `sent`, `sale`, `cancel` | +| EV-COD-003 | sale.order | addons/sale/models/sale_order.py | 1067 | Método `action_quotation_send` | +| EV-COD-004 | sale.order | addons/sale/models/sale_order.py | 1166 | Método `action_confirm` | +| EV-COD-005 | sale.order | addons/sale/models/sale_order.py | 54-58 | Campo `name` con default `_("New")` | +| EV-COD-006 | sale.order | addons/sale/models/sale_order.py | 1166-1196 | `action_confirm` cuerpo completo | +| EV-COD-007 | sale.order | addons/sale/models/sale_order.py | 1203-1216 | `_confirmation_error_message` | +| EV-COD-008 | sale.order | addons/sale/models/sale_order.py | 1218-1229 | `_prepare_confirmation_values` | +| EV-COD-009 | sale.order | addons/sale/models/sale_order.py | 1198-1201 | `_should_be_locked` | +| EV-COD-010 | stock.picking | addons/stock/models/stock_picking.py | 1195 | Método `action_assign` | +| EV-COD-011 | stock.picking | addons/stock/models/stock_picking.py | 1186 | Método `action_confirm` | +| EV-COD-012 | stock.picking | addons/stock/models/stock_picking.py | 1398 | Método `button_validate` | +| EV-COD-013 | sale.order | addons/sale/models/sale_order.py | 1550 | Método `_create_invoices` | +| EV-COD-014 | sale.order | addons/sale/models/sale_order.py | 1411 | Método `_prepare_invoice` | +| EV-COD-015 | account.move | addons/account/models/account_move.py | 72-73 | Definición de `AccountMove` | +| EV-COD-016 | account.move | addons/account/models/account_move.py | 6101 | Método `action_post` | +| EV-COD-017 | account.move | addons/account/models/account_move.py | 72-73 | Clase `AccountMove` con `_name='account.move'` | +| EV-COD-018 | account.move | addons/account/models/account_move.py | 129 | Campo `state` | +| EV-COD-019 | account.move | addons/account/models/account_move.py | 6022 | Método `action_register_payment` | +| EV-COD-020 | account.move | addons/account/models/account_move.py | 600 | Campo `payment_state` | +| EV-COD-021 | sale.order | addons/sale/models/sale_order.py | 1231-1235 | Método `_action_confirm` (stub) | +| EV-COD-022 | stock.picking | addons/stock/models/stock_picking.py | 1195-1208 | `action_assign` cuerpo completo | +| EV-COD-023 | sale_stock | addons/sale_stock/models/sale_order.py | 31 | Campo `picking_ids` (vincula con stock.picking) | +| EV-COD-024 | account.move | addons/account/models/account_move.py | 48-56 | `PAYMENT_STATE_SELECTION` con 7 valores | +| EV-COD-025 | account.move | addons/account/models/account_move.py | 600-606 | Campo `payment_state` (Selection computed) | +| EV-COD-026 | account.move | addons/account/models/account_move.py | 6101-6122 | `action_post` cuerpo (incluye wizard validación) | +| EV-COD-027 | sale.order | addons/sale/models/sale_order.py | 1237-1244 | `_send_order_confirmation_mail` | +| EV-COD-028 | sale.order | addons/sale/models/sale_order.py | 1192 | `_trigger_scheduler()` invocado al confirmar | +| EV-COD-029 | stock.picking | addons/stock/models/stock_picking.py | 1210-1214 | Método `action_cancel` | +| EV-COD-030 | sale.order | addons/sale/models/sale_order.py | 1198-1201 | `_should_be_locked` | + +## EV-XML — Vistas y datos XML (pendiente) + +Por el momento no se generaron evidencias EV-XML en esta iteración. Las vistas se referencian pero no se inspeccionaron en detalle. + +## EV-DOC — Documentación oficial (pendiente) + +Por el momento no se generaron evidencias EV-DOC en esta iteración. + +## EV-INF — Inferencias pendientes (15 → 5, las críticas se actualizaron a EV-COD) + +Las siguientes inferencias fueron **validadas y promovidas a EV-COD** en esta iteración: + +- ~~EV-INF-004~~ → **EV-COD-021** (`_action_confirm` ubicación confirmada) +- ~~EV-INF-006~~ → **EV-COD-022** (`action_assign` cuerpo verificado) +- ~~EV-INF-007~~ → **EV-COD-023** (`picking_ids` en sale_stock confirma relación con stock.picking) +- ~~EV-INF-012~~ → **EV-COD-026** (`action_post` cuerpo verificado, incluye wizard) +- ~~EV-INF-013~~ → **EV-COD-026** (validaciones específicas requieren lectura adicional) +- ~~EV-INF-014~~ → **EV-COD-024** (7 valores de payment_state verificados) +- ~~EV-INF-015~~ → **EV-COD-025** (campo `payment_state` verificado como computed) +- ~~EV-INF-016~~ → **EV-COD-024** (PAYMENT_STATE_SELECTION da los valores) + +### EV-INF que permanecen pendientes + +- **EV-INF-005**: Implementación interna de `_action_confirm` en `sale_stock` (extiende el stub base). +- **EV-INF-008, 009**: Lógica interna de `button_validate()` (backorder automático). +- **EV-INF-010, 011**: Lógica de agrupación de facturas (`grouped=True`). +- **EV-INF-017, 018**: Modelo conceptual aproximado, refinable. +- **EV-INF-019, 020**: Diferencias Community vs Enterprise. +- **EV-INF-021, 022**: Campos exactos del form y botones visibles. + +## Resumen + +| Tipo | Cantidad | +|------|----------| +| EV-COD (verificado contra código) | **30** | +| EV-XML (vistas) | 0 | +| EV-DOC (documentación) | 0 | +| EV-DB (base de datos) | 0 | +| EV-TEST (pruebas) | 0 | +| EV-INF (inferencias pendientes) | 8 (reducidas de 22) | +| **TOTAL** | **38** |