ccprmt001/003/005 leen cctb00003 por tipo_doc esperando una sola fila. En SQL
Server un SELECT INTO que devuelve varias filas da -284 (en Informix tomaba la
primera). Al dar de alta un rango, ccprmt002 insertaba una fila PG por vendedor
y, con ella, nadie podia registrar recibos. Ahora solo crea la fila si no existe
ninguna PG.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- 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>
jpegueroandClaude Sonnet 5.5
jsotoandClaude Opus 5.5