Este es un recorrido de producto, no el caso de ningún despacho real: describe cómo se mueve -y dónde se desconecta de la norma- el timbrado de un CFDI dentro de FieldOps cuando la orden se cobró en efectivo. La pregunta que resuelve es concreta: ¿en qué paso exacto el dato real de "efectivo", que sí se capturó, deja de viajar hacia el comprobante fiscal? Según lo visto en en FieldOps, el CFDI del servicio siempre declara "transferencia electrónica" aunque el cliente pagó en efectivo.
Esquema del recorrido · ilustración, no es una pantalla del sistema
- 1. El técnico cierra la orden y cobra en efectivoLo registra en la app eligiendo "efectivo" en el formulario de cobro.
- 2. El cobro se guarda con su forma de pago realLa fila de
paymentsincluye la columnamethod = 'cash'. - 3. El despacho solicita el CFDI de esa ordenEl servicio de facturación arma emisor, receptor, partidas, total y folio.
- 4. El servicio de facturación no consulta el cobroNo lee la tabla
paymentsni pide la forma de pago real. - 5. El adaptador de timbrado usa un valor fijoEnvía "03 - Transferencia electrónica" al proveedor, sin condición.
- 6. El CFDI se timbra y se sella asíEl comprobante final declara transferencia, aunque el cobro fue en efectivo.
1-3. El cobro sí distingue efectivo; la solicitud de CFDI no lo pide
El formulario de cobro en campo obliga a elegir entre efectivo y transferencia -no hay una tercera opción ni un valor por omisión-. Ese dato se guarda en la base de datos de forma correcta. Cuando el despacho pide facturar esa orden, el servicio de facturación reúne los datos necesarios para el comprobante: quién emite, quién recibe, qué se cobró, cuánto y con qué folio. La forma de pago real no forma parte de esa lista de datos que reúne.
4-6. Ningún paso pregunta cómo se cobró; el CFDI ya salió decidido
Al no recibir ningún dato de forma de pago, el adaptador que llama al proveedor de timbrado no tiene margen para decidir distinto: siempre envía la misma clave, "transferencia electrónica", sin excepción. No hay ninguna pantalla intermedia que pregunte "¿cómo se cobró esta orden?" ni ningún mensaje que avise que el comprobante va a declarar algo distinto de lo que realmente ocurrió. El CFDI se timbra y se sella con ese dato fijo, sin que nadie en el flujo -ni el sistema, ni la persona que factura- tenga oportunidad de corregirlo antes de que salga.
| Parada | ¿Se detiene o avisa antes de declarar la forma de pago? |
|---|---|
1-2. Cobro en efectivo, guardado como cash | No aplica -el dato se captura y se guarda bien |
| 3. Solicitud del CFDI de la orden | No -no incluye la forma de pago en los datos que reúne |
| 4. Armado de la llamada al proveedor de timbrado | No -no consulta la tabla de cobros |
| 5. Envío de la forma de pago al PAC | No -usa un valor fijo, sin condición |
| 6. Timbrado y sellado del CFDI | No -ejecuta con los datos ya decididos |
Puedes estimar la exposición de este hallazgo, con tus propios números, en la calculadora de exposición por forma de pago fija en el CFDI.
Preguntas frecuentes
¿Por qué FieldOps no usa el dato de cobro que ya tiene guardado?
El servicio de facturación arma la solicitud de timbrado sin volver a consultar la tabla de cobros de la orden: reúne emisor, receptor, partidas y total, pero no la forma de pago real.
¿Pasa lo mismo si el cliente paga por transferencia?
No: en ese caso el valor fijo que se envía ("transferencia electrónica") coincide con la realidad por casualidad, no porque el sistema lo haya verificado.
¿FieldOps corrige esto automáticamente?
No, hoy no. Es un hallazgo verificado en el código actual, no una función ya resuelta.
Ve el recorrido completo en tu propia demo
Te mostramos en vivo el cobro en efectivo y el timbrado de su factura.
Agenda una demo gratis