Captura de pantalla frente a CEP firmado: ¿qué puede aceptar tu conciliación?

El problema: una imagen no es el registro original

Una captura de la app bancaria muestra un monto, una fecha y quizá una clave de rastreo. Puede recortarse, editarse o corresponder a otra transferencia. Un CEP (Comprobante Electrónico de Pago) es el comprobante electrónico original de un pago SPEI existente y puede incluir una firma y datos que lo vinculan a una sola operación. La decisión del lector es concreta: qué evidencia puede aceptar tu proceso antes de marcar una factura como pagada y qué debe dejar abierto. La captura sirve como pista para iniciar una consulta, pero no debería ser lo que tu proceso acepta.

Qué comprueba el producto y qué no

El producto mx-cep obtiene el CEP de un pago existente autorizado y revisa su firma y vinculación con la operación. Las entradas son fecha de operación, clave de rastreo, códigos de institución emisora y receptora, cuenta, monto y una referencia de autorización. La salida informa estado de la tarea, disponibilidad de la evidencia original, estado de la firma y vinculación exacta con la operación. Los límites importan: no inicia transferencias ni prueba control actual de la cuenta, identidad o que un pago saliente sea seguro. Las restricciones de acceso a la fuente pueden retrasar una tarea, así que un resultado puede quedar pendiente un tiempo. La ejecución como comercio requiere capacidades vigentes, autorización y una cotización aceptada; la documentación no es evidencia de una consulta real.

Escenario hipotético y salida esperada del fixture

Hipotético: la factura de un comercio sintético muestra una transferencia entrante y una captura del cliente. El proceso envía fecha de operación, clave de rastreo, ambos códigos de institución, cuenta, monto y referencia de autorización. El ejemplo de contrato sintético devuelve exactamente: status pending, original_available false, signature_status not_checked, transaction_binding not_checked, verified false. Este ejemplo no realiza ninguna solicitud real a un proveedor. La lectura correcta es que aún no se ha establecido nada: el original no está disponible, la firma no se revisó y el CEP no se comparó con la factura. La factura sigue abierta, etiquetada como en espera de evidencia, ni pagada ni fraudulenta.

Regla de aceptación propuesta para tu aplicación

Esto es un diseño de aplicación propuesto, no un comportamiento implementado del producto. Acepta un pago como evidenciado solo cuando verified sea true, original_available sea true, y tanto signature_status como transaction_binding indiquen una comprobación exitosa que hayas mapeado explícitamente. Compara la operación vinculada con tu propio monto, cuenta, instituciones y fecha esperados en lugar de confiar en un solo indicador. Trata pending, no disponible, not_checked y cualquier valor desconocido como no concluyentes. Mantén la decisión de enviar mercancía o liberar fondos como una regla de negocio separada en tu código; un CEP coincidente dice que ocurrió un pago, no que la contraparte sea quien dice ni que pagarle sea seguro.

Manejo de fallos sin duplicados

Cuando una tarea está pendiente, guarda su identificador junto a la factura con una fecha límite y usa get para leer el estado o recover para reanudarla, en lugar de enviar una segunda solicitud por el mismo pago. Los retrasos por restricciones de acceso a la fuente son esperables; no los conviertas en rechazo. Si vence el plazo sin conclusión, envía la factura a revisión manual con el motivo registrado. Si la vinculación falla, marca la discrepancia para que una persona la investigue; puede ser un error en las entradas o una transferencia equivocada. Nunca dejes que un tiempo de espera, un error o una captura llenen el hueco por defecto.

Lista de aceptación

Antes de depender de esto en conciliación, confirma: la salida sintética anterior se interpreta como en espera de evidencia, no pagada; verified false nunca marca una factura como pagada; pendiente y no disponible siguen siendo no concluyentes; las seis entradas y la referencia de autorización se registran por solicitud; las repeticiones reutilizan la tarea existente en vez de crear duplicados; las discrepancias van a revisión; las decisiones de liberación están separadas de la evidencia de pago; y el equipo entiende que el fixture es un ejemplo de contrato sintético, no una aceptación real, sin asumir capacidades reales hasta contar con autorización de comercio y cotización aceptada.

Revisar este producto

https://gridzen.ai/tools/mx-cep/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.

gridzen tools --product mx-cep

Fuentes y alcance

https://gridzen.ai/tools/mx-cep/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.