Plataforma-de-desarrolladores/Revision_CambioEstatus_20260908.md

Revisión del cambio de estatus — 08/09/2026

Estado de entrega

Implementación preparada en archivos. Los scripts SQL no se ejecutaron contra la base de datos. La entrega conserva ASP.NET WebForms, compilación dinámica desde App_Code y .NET Framework 4.8.1.

Aplicar el SQL y los archivos de aplicación como una misma actualización. El código nuevo depende de las columnas y firmas incluidas en estos scripts; el flujo no estará operativo con los PA anteriores.

Acuerdos utilizados

• El desarrollador corresponde a Empresa, CveRol = 3. SuperUsuario = 1 y Administrador = 2.
• El siguiente estatus es el siguiente activo por Orden (CveEstatusSolicitud como desempate). Se determina antes de comprobar EsCliente; no se saltan estatus internos.
• La secuencia consultada es 3 → 4 → 5 → 6 → 7 → 10 → 8. El desarrollador se detiene antes de 7, porque EsCliente = 0.
• Autorizado es CveEstatusSolicitud = 7, con EsCliente = 0.
• Los tipos de documento existentes comienzan con EsCliente = 1. El catálogo permite asignarlos posteriormente a Administrador (0) o Desarrollador (1).
• Se conserva el criterio de pago realizado: existencia de Vta_Pagos activo asociado a la solicitud, concepto de pago y venta. No se exige adicionalmente Autorizado.
• Se considera documento pendiente el requerido que no tiene archivo registrado. La revisión/aprobación documental anterior se conserva y no se agrega como requisito nuevo.

Comportamiento implementado

El modal muestra (Folio) Etapa - Trámite y observaciones obligatorias de 1 a 1000 caracteres. Administrador/SuperUsuario conservan selección libre de estatus, incluso tras autorizar. El desarrollador ve un destino fijo; el servicio verifica nuevamente el destino al guardar.

Las condiciones se capturan solamente al autorizar con EsCliente = 0, para Administrador/SuperUsuario. La lista aplicable proviene del PA existente. Los paneles no aplicables tienen Visible = false, con sus validadores dentro del panel y el grupo CambioEstatusTramite. Las condiciones visibles aceptan únicamente 0/1 en el modelo de captura; NULL bloquea el guardado. Se conserva la asignación automática de AprobadoPrefactibilidad = 1 al autorizar prefactibilidad. El desarrollador no consulta ni actualiza condiciones durante el movimiento.

La validación del servicio se realiza en este orden:

1. Sesión, observaciones, estatus destino y vigencia del estatus anterior.
2. Condiciones aplicables.
3. Documentos requeridos del responsable correspondiente.
4. Pagos requeridos.
5. Movimiento, historial, condiciones, generación de solicitudes y bitácora.

Un requisito pendiente dirige a su pestaña y resalta las filas en rojo. Pagos es de consulta; no permite resolver pagos dentro del modal. Supervisiones es una pestaña vacía del detalle principal.

En Documentos, las etapas disponibles son las solicitudes del mismo tipo de trámite en el fraccionamiento. Cambiar la etapa permite administrar sus documentos. Guardar estatus siempre valida la solicitud original; si faltan documentos suyos, regresa el grid a esa solicitud.

El filtro por responsable también se verifica en el servicio al cargar, eliminar y descargar. Los GIS conservan su flujo especializado de administración de la etapa; no se cargan como archivos genéricos desde el formulario nuevo. La eliminación documental usa DELETE físico del registro y bitácora; conserva el almacenamiento existente, sin agregar purga del archivo físico. Sin el registro, el endpoint de descarga deja de autorizar ese documento.

Atomicidad y concurrencia

TramiteSolicitudService usa TransactionLogic con aislamiento Serializable para leer los requisitos y conservarlos estables hasta terminar. El servicio confirma únicamente después de completar todas las operaciones. La bitácora y la generación de solicitudes participan en la misma transacción.

PA_Tramites_SolicitudEstatusUpdate inserta el historial antes de actualizar Tra_Solicitudes. Registra CveSolicitud, CveEstatusSolicitudAnterior, destino, CveUsuario, Comentarios y FechaAlta. Compara el estatus previo capturado con el actual, además de la comprobación en el servicio.

El historial existente estaba vacío. Se agrega el estatus anterior como nullable para no inventar datos si se instala sobre una instancia con movimientos históricos. El flujo nuevo siempre envía un estatus anterior conocido, un usuario autenticado y observaciones obligatorias.

SQL separado y objetos afectados

Tramites_CambioEstatus_Estructura_20260908.sql

• Tra_TiposDocumento: EsCliente bit NOT NULL, predeterminado 1 para los tipos existentes.
• Tra_HistorialEstatusSolicitud: CveEstatusSolicitudAnterior int y llave foránea a Tra_EstatusSolicitud.
• No se crean tablas para Supervisiones.

Tramites_CambioEstatus_Procedimientos_20260908.sql

Modifica:

• PA_Tramites_SolicitudEstatusUpdate: observaciones e historial; se retiran el bloqueo por rol > 2 y el bloqueo por autorización previa. Las condiciones se actualizan mediante el servicio y PA_Fraccionamientos_EtapaCondicionUpdate, sin duplicar sus modificaciones dentro de este PA.
• PA_Tramites_EstatusSolicitudOptionList: devuelve todos los estatus activos para poder calcular correctamente el siguiente. El método público usado por los filtros conserva en C# la vista EsCliente del desarrollador.
• PA_Tramites_DocumentoSolicitudFraccionamientoList: agrega responsable, obligatoriedad y SeValida. El parámetro IncluirRequisitos permite consultar todos los requisitos activos, también opcionales y pendientes de solicitudes finales; el modo ordinario conserva su selección anterior.
• PA_Tramites_DocumentoSolicitudUploadContextGet: agrega EsCliente y traslada el bloqueo de estado final al servicio C#.
• PA_Tramites_DocumentoSolicitudSave y PA_Tramites_DocumentoSolicitudDelete: retiran el bloqueo general de solicitud final. C# conserva el bloqueo para desarrollador y permite administrador. Se elimina la administración de transacciones SQL y XACT_ABORT, según la arquitectura del proyecto.
• PA_Tra_TipoDocumentoList, PA_Tra_TipoDocumentoGet y PA_Tra_TipoDocumentoSave: leen/guardan EsCliente.

Crea:

• PA_Tra_SolicitudPagoList: consulta pagos configurados y realizados por solicitud, incluyendo requisitos todavía sin venta o sin detalles. No ejecuta cobros ni aplica reglas de rol.

No se agregaron bloqueos SQL por responsable o por avance secuencial. Las comprobaciones preexistentes de acceso al cliente en consultas documentales se conservaron.

Comparación con BD

Las versiones usadas como base se consultaron directamente en localhost / SIG_PlataformaDesarolladores. Las nueve definiciones originales se volvieron a comparar al terminar: no cambiaron durante el trabajo.

• No se encontraron definiciones de los PA_Tramites_* afectados en los scripts anteriores revisados. Los scripts nuevos parten de las definiciones de BD, no de reconstrucciones del repositorio.
• PA_Tra_TipoDocumentoList/Get/Save coincidían con Catalogos_Tramites_Internos.sql tras normalizar formato y comentarios.
• PA_Tra_MostrarCondicionesporTramite y PA_Fraccionamientos_EtapaCondicionUpdate coincidían con Tramites_CambioEstatus_Condiciones_20260907.sql; se reutilizan sin modificarlos.
• PA_Tra_GenerarSolicitudesPorFlujo tiene una diferencia funcional: la BD requiere también EsCliente = 0 para considerar cumplido el trámite padre; el script anterior del repo no. Se conserva el PA de BD y su invocación, sin reemplazarlo ni incluirlo en el script de instalación.
• La BD contiene lógica adicional de condiciones y parámetros opcionales en PA_Tramites_SolicitudEstatusUpdate; se revisó esa definición antes de preparar el cambio.
• El PA documental Save instalado contenía BEGIN/COMMIT/ROLLBACK y XACT_ABORT; el script preparado los elimina para que el servicio sea dueño de la transacción.

Portlet y carga de archivos

Patrón reutilizado de Metronic:

<div id="PortletDocumentoEstatus" class="portlet box blue">
    <div class="portlet-title">
        <div class="caption">Agregar o Actualizar</div>
        <div class="tools">
            <a href="javascript:;" class="expand"
                title="Mostrar u ocultar captura"></a>
        </div>
    </div>
    <div class="portlet-body" style="display:none;">
        <!-- Captura -->
    </div>
</div>

El selector real es .portlet-title > .tools > .collapse/.expand, y el cuerpo .portlet-body. Un portlet inicialmente cerrado usa expand; al abrirlo se cambia a collapse. El id estable permite que custom.js conserve su estado durante postbacks parciales. No se modificaron Metronic ni custom.js.

Se reutiliza ADSdropzoneLocal y su API ADSLocalDropzone.getFile. El botón copia el File seleccionado a FileUpload mediante DataTransfer y realiza un postback completo declarado con PostBackTrigger. La entrada nativa sigue disponible como alternativa. La persistencia pasa por TramiteDocumentoService y su almacenamiento protegido existente. Los eventos nuevos se inicializan una vez por elemento y utilizan el puente global ya existente de SIGDetalle para cargas y postbacks parciales.

Verificación realizada

• Precompilación completa con aspnet_compiler de .NET Framework: correcta, incluyendo páginas, App_Code y AjaxControlToolkit. No se generó ni desplegó SIG.Web.dll.
• Sintaxis JavaScript de la página revisada con node --check: correcta.
• Ambos scripts analizados con Microsoft.SqlServer.TransactSql.ScriptDom TSql160Parser: cero errores de sintaxis, sin conexión de ejecución SQL.
• git diff --check: correcto.
• 31 pruebas de comportamiento sobre las clases de servicio realmente compiladas, con contratos simulados y transacciones ambientales, sin conexiones a BD:
  • 20 de estatus: secuencia, prohibición de saltos, admin/superusuario después de autorizar, observaciones, condiciones 0/1 y NULL, condiciones no aplicables, orden de requisitos, requisitos opcionales, pago activo, captura obsoleta y rollback ante fallos.
  • 11 documentales: filtrado por responsable, carga/descarga/eliminación, pertenencia de la solicitud, estado final y registro de archivos externos.
• Los escenarios de rollback comprueban que TransactionScope revierte y no confirma cuando falla el movimiento, la bitácora o la generación. La escritura SQL real del historial queda pendiente de la prueba de integración tras instalar los scripts.

Pendiente tras autorización e instalación de BD: prueba integrada en navegador con usuarios reales, carga/reemplazo/eliminación de archivos, pestañas/validadores tras postbacks parciales y comprobación de filas reales en historial y bitácora. No se presenta esa integración como ya probada.

Archivos modificados

• SIG.Web/App_Code/Models/Tramites/TramiteSolicitudModels.cs
• SIG.Web/App_Code/Models/Tramites/TramiteCatalogModels.cs
• SIG.Web/App_Code/Models/Documentos/TramiteDocumentoModels.cs
• SIG.Web/App_Code/Services/Tramites/TramiteSolicitudService.cs
• SIG.Web/App_Code/Repositories/Tramites/TramiteSolicitudRepository.cs
• SIG.Web/App_Code/Services/Tramites/TramiteSolicitudBitacoraFactory.cs
• SIG.Web/App_Code/Services/Documentos/TramiteDocumentoService.cs
• SIG.Web/App_Code/Repositories/Documentos/TramiteDocumentoRepository.cs
• SIG.Web/App_Code/Contracts/Tramites/ITramiteSolicitudService.cs
• SIG.Web/App_Code/Contracts/Tramites/ITramiteSolicitudRepository.cs
• SIG.Web/App_Code/Contracts/Documentos/ITramiteDocumentoService.cs
• SIG.Web/App_Code/Contracts/Documentos/ITramiteDocumentoRepository.cs
• SIG.Web/App_Code/Repositories/Tramites/TramiteCatalogRepository.cs
• SIG.Web/App_Code/Services/Tramites/TramiteCatalogBitacoraFactory.cs
• SIG.Web/App_Code/Configuration/AppServices.cs
• SIG.Web/Pages/Catalogos/TiposDocumento.aspx
• SIG.Web/Pages/Catalogos/TiposDocumento.aspx.cs
• SIG.Web/Pages/Fraccionamientos/FraccionamientoDetalle.aspx
• SIG.Web/Pages/Fraccionamientos/FraccionamientoDetalle.aspx.cs
• SIG.Web/Styles/FraccionamientoDetalle.css

Archivos nuevos

• Tramites_CambioEstatus_Estructura_20260908.sql
• Tramites_CambioEstatus_Procedimientos_20260908.sql
• Revision_CambioEstatus_20260908.md
• Entrega_CambioEstatus_20260908.zip

El ZIP incluye los 20 archivos de aplicación, los dos scripts y este informe; excluye binarios, credenciales, archivos ajenos al cambio y su propia copia. No se crearon commits.