Appearance
Preguntas sobre Comprobantes Pendientes
INFORMACION REQUERIDA - Preguntas generadas durante analisis retrospectivo el 2026-02-09
Preguntas Criticas (Afectan la documentacion de negocio)
1. Tipos de comprobantes pendientes no implementados (Remito, Presupuesto)
Observacion: La factory PendienteServiceFactory contiene comentarios que sugieren tipos de comprobantes adicionales: ComprobantePendiente::REMITO y ComprobantePendiente::PRESUPUESTO, pero estan comentados. El enum TipoComprobantePendiente solo define PEDIDO = 1. El seed de preformul solo inserta el registro "Pedido".
Pregunta: Existen planes de implementar Remito y Presupuesto como tipos de comprobantes pendientes? La tabla preformul esta disenada para soportar multiples tipos (tiene campo nombre y reporte). Se deberian documentar como funcionalidad futura o es codigo abandonado?
Impacto: Afecta si la documentacion debe describir el sistema como "gestion de pedidos" unicamente o como "gestion de comprobantes pendientes" con multiples subtipos. Tambien afecta la arquitectura documentada (patron Strategy/Factory).
2. Flujo de "cancelacion" de pendiente mediante facturacion
Observacion: La tabla prefa tiene un campo id_factura que, segun los comentarios de la migracion, representa "Id de la factura que cancelo el comprobante pendiente". Las queries de consulta siempre filtran por id_factura IS NULL, lo cual implica que solo se muestran pendientes no facturados. Sin embargo, no existe endpoint ni logica en el codigo de Pendientes para asignar id_factura.
Pregunta: Como se realiza la cancelacion de un comprobante pendiente? El proceso de facturacion asigna automaticamente el id_factura al pendiente cuando se genera la factura a partir del pedido? Donde esta implementado ese flujo?
Impacto: Es una regla de negocio central que conecta Comprobantes Pendientes con Facturacion. Sin entender este flujo, la documentacion de negocio estara incompleta respecto al ciclo de vida del comprobante pendiente.
3. Modo oficial vs prueba en pendientes
Observacion: El campo modo en prefa esta definido como 0 => Prueba || 1 => oficial. Sin embargo, el PendienteController configura conexiones tanto a oficial como a prueba (con sufijo _p), pero el codigo actual siempre usa oficial_dbal. No hay logica visible que seleccione entre modo prueba y oficial al crear un pendiente.
Pregunta: Los comprobantes pendientes se crean siempre en modo oficial? El campo modo se asigna desde el frontend o se determina por la conexion activa? Es posible crear pendientes en modo prueba?
Impacto: Afecta la documentacion de reglas de negocio sobre modos de operacion y como interactua con el sistema multi-modo del ERP.
4. Condicion de ejecucion de migraciones: pedido Y remito
Observacion: La migracion NewTablePreformul tiene la condicion ($empres['pedido'] || $empres['remito']) && $this->isVentasEnabled(). Esto significa que las tablas se crean si la empresa tiene habilitado pedido O remito. Sin embargo, actualmente solo Pedido esta implementado.
Pregunta: Que empresas tienen remito habilitado? Es un feature legacy que ya no se usa o es una funcionalidad que esta por implementarse? La tabla preformul podria tener registros de tipo Remito insertados manualmente?
Impacto: Afecta la completitud de la documentacion sobre tipos de comprobantes soportados y la configuracion empresarial requerida.
5. Nivel de schema: EMPRESA y SUCURSAL
Observacion: Las tablas preformul, prefa e iterem se crean en niveles EMPRESA y SUCURSAL (con configuracion dinamica). Esto permite que los tipos de comprobantes y los pendientes existan tanto a nivel empresa (compartidos) como a nivel sucursal (aislados).
Pregunta: En la practica, los comprobantes pendientes se gestionan a nivel empresa o a nivel sucursal? Pueden existir numeraciones independientes de pedidos por sucursal? La configuracion tipica es compartir los tipos de comprobante (preformul) pero tener pendientes separados por sucursal?
Impacto: Afecta como se documenta el alcance multi-tenant de la funcionalidad y las reglas de negocio sobre numeracion e isolamiento de datos.
6. Vista de Comprobantes Pendientes vs vista de Pedidos
Observacion: Existen dos vistas en el frontend: la vista de "Comprobantes Pendientes" (comprobantes-pendientes.php + JS) que muestra/edita los tipos de comprobantes pendientes (tabla preformul), y la vista de "Pedido" (pedido.php) que presumiblemente gestiona los pedidos individuales (tabla prefa). La URL ?loc=mvcp lleva a la vista de tipos, no a los comprobantes individuales.
Pregunta: La vista de "Comprobantes Pendientes" es intencionalmente una pantalla de configuracion de tipos (ABM de preformul)? Donde se visualizan y gestionan los comprobantes pendientes individuales (pedidos creados)? Es en la vista de pedido?
Impacto: Afecta fundamentalmente la documentacion: si "Comprobantes Pendientes" es un recurso de configuracion (Resource) o una vista operativa (View).
Preguntas Tecnicas (Afectan la documentacion tecnica)
7. Iteracion sobre services en PendienteController
Observacion: El PendienteController::get() itera sobre $this->services con foreach, pero solo retorna el ultimo resultado ($pendientes se sobreescribe en cada iteracion). Cuando la factory por defecto solo retorna un servicio (PEDIDO), esto funciona, pero con multiples tipos seria incorrecto.
Pregunta: Es un bug o es intencional? Si se agregan mas tipos de comprobante, deberia consolidar resultados de todos los services? O cada tipo tiene su propio endpoint separado?
Impacto: Afecta la documentacion tecnica sobre el patron de consulta de pendientes y la correcta implementacion del patron Factory.
8. ItemPendiente: delete fisico vs soft delete
Observacion: Mientras Pendiente (tabla prefa) usa soft delete (deleted_at), ItemPendiente (tabla iterem) usa delete fisico (DELETE FROM). El metodo deleteItems() elimina permanentemente los items, y en la migracion el FK tiene 'delete' => 'CASCADE'. Ademas, el metodo updateItems() elimina todos los items y los re-inserta.
Pregunta: Es intencional que los items no usen soft delete? La estrategia de "borrar y re-insertar" para actualizar items es el patron deseado? Hay preocupaciones sobre perdida de datos o trazabilidad de cambios en items?
Respuesta: No existe deleted_at en casi ningún legacy resource
Impacto: Afecta la documentacion tecnica sobre estrategia de eliminacion y consistencia de datos.
9. Campo stock en PendienteDTO usa propiedad incorrecta del tipoComprobantePendiente
Observacion: En PedidoService::mapPendiente(), la linea 'stock' => (bool)$tipoComprobantePendiente->stock referencia ->stock, pero el DTO TipoComprobantePendiente tiene la propiedad maneja_stock. El modelo mapea maneja_stock desde la base de datos. Esto podria funcionar por acceso dinamico de propiedades del DataTransferObject, pero es inconsistente.
Pregunta: El campo stock se esta leyendo correctamente? Es $tipoComprobantePendiente->stock equivalente a $tipoComprobantePendiente->maneja_stock? Podria causar problemas si la libreria de DTO no soporta nombres alternativos?
Impacto: Potencial bug que afecta la logica de stock en comprobantes pendientes.
10. Conexion 'prueba' configurada pero no utilizada
Observacion: Tanto PendienteController como PedidoController configuran una conexion prueba con $payload->db . '_p', pero todo el codigo de servicio usa exclusivamente oficial_dbal. No hay logica que intercambie entre conexiones oficial y prueba.
Pregunta: La conexion prueba esta preparada para uso futuro? Se usara cuando se implemente modo prueba para pendientes? O es codigo legacy innecesario?
Impacto: Afecta la documentacion tecnica sobre multi-modo y las conexiones requeridas.
Como Usar Este Documento
Este documento contiene preguntas que surgieron durante el analisis del codigo. Cada pregunta incluye espacio para agregar la respuesta:
Formato de respuesta:
Respuesta:
Una vez respondidas, estas respuestas se incorporaran a la documentacion final.
Estado de Validacion
- [ ] Preguntas criticas respondidas (6)
- [ ] Preguntas tecnicas respondidas (4)
- [ ] Respuestas validadas con stakeholders
- [ ] Documentacion actualizada con respuestas