- ccprrp018: agrega MAIN, GROUP BY por nombre, y reemplaza la salida Excel/DDE
(G:\ESTADO.XLS, DEL G:\ESTADOS) por un reporte Genero (ccprrp018.4rp); carga con
un solo INSERT...SELECT en tabla temporal.
- ccprrp003: reemplaza el REPORT de texto con codigos de impresora por
ccprrp003.4rp; agrega por cliente en una consulta (DATEDIFF, mismas reglas).
- ccprrp001: agrega MAIN, GROUP BY por nombre, reporte Genero (ccprrp001.4rp) y
registra el formulario ccfmrp001 en FORMULARIOS_CC (faltaba, -1110).
- ccprrp052: la validacion del campo Orden estaba al reves.
- ccprmt002: cctb00002.fecha es datetime en SQL Server; el formulario, la variable
global relacion (ccprgb000) y el CONSTRUCT la manejan como DATE; corrige que
eLiminar mostrara exito sin actualizar filas.
- mbsERP.4pw: registra los .4rp, libgre y ccfmrp001 (sin credenciales).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- otrodir/enviacorreo.4gl: TRY/CATCH al ejecutar el procedimiento de correo
(si falla avisa y no se pierde la grabacion; antes una cotizacion con
reserva se perdia completa) y desvio opcional MBS_CORREO_PRUEBA para
ambientes de prueba (en produccion no existe la variable).
- ccprmt001, ccprmt003, ccprrp049, ccprrp054: salida SVG fija -> PDF.
- bin/ccprrp054.4rp: era de otro reporte (reporte54); se usa el de
ccprrp049 (mismo REPORT r_email).
- *.sch: columnas DECIMAL/MONEY con precision > 32 (vistas como
ventas_facturas, analisiscotizaciones, rotacioniventario) bajadas a 32
con la misma escala; Genero daba -6634 y no compilaban veprrp058/059/060.
- mbsERP.4pw: agregado vefmrp060.4fd a FORMULARIOS_VE (-1110).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Dos usuarios convirtiendo la misma cotizacion a la vez creaban dos ordenes
(cot 340001 -> 262237 y 262238, ticket 12234). La validacion "cotizacion
tiene orden" corria antes del BEGIN WORK; el segundo usuario la pasaba,
esperaba el bloqueo de prtb00020 y al liberarse insertaba otra orden.
- vedir/veconvierteorden: re-valida dentro de la transaccion, ya con el
bloqueo de prtb00020.
- WEBSERVICES/veconvierteorden: misma re-validacion (no tenia ninguna).
- ccdir/ccprmt003 verifica_orden(): COUNT(*) en vez de SELECT num_oc,
que daba -284 con ordenes duplicadas.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>