- 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>
jsotoandClaude Opus 5.5