Para poder generar y emitir CFDIs con Recibo Electrónico de Pago en AdminPAQ®, toma en cuenta las siguientes consideraciones.
Solo se permiten saldar/pagar facturas que hayan sido previamente timbradas.
Las facturas timbradas con la versión 3.3 solo podrán ser pagadas con documentos de pago versión 3.3 que incluyan el Recibo Electrónico de Pago (cuando aplique).
Si las facturas fueron pagadas al momento el Recibo Electrónico de Pago es opcional y se podrá realizar un pago tradicional para saldar la factura, solo si la forma de pago no es 99-Por definir.
Si la forma de pago seleccionada es 99 - Por definir se mostrará el siguiente mensaje:
Si la forma de pago seleccionada es 99-Por definir y método de Pago PUE-Pago en una sola exhibición, se mostrará el siguiente mensaje:
Se podrá asociar más de una factura por documento de pago en la versión 3.3.
En la asociación de facturas al pago electrónico, solo se mostrarán las facturas de la versión que le corresponde.
Se podrán capturar y timbrar documentos de pagos versión 3.3 sin necesidad de asociar una factura al documento.
Se podrá dejar saldo pendiente en el documento de pago antes de ser timbrado.
Si el documento de pago ya está timbrado, la asociación y des asociación quedará bloqueada.
Los botones Pagar electrónicamente, pago en parcialidades y documentación de deuda quedarán deshabilitados para conceptos de factura 3.3.
El botón pagar en los documentos de Factura 3.3 se mostrarán los conceptos de Abono al cliente tradicionales y los configurados con versión 3.3.
El botón de Saldar factura con abonos del cliente en los documentos de Factura 3.3 mostrarán los conceptos de Abono al cliente tradicionales y los configurados con versión 3.3.
Será posible timbrar pagos (Recibo Electrónico de Pago) desde la ventana que se abre al presionar el botón de pagar.
Al ejecutar un documento desde el menú de la aplicación el botón F3 del documento mostrará únicamente los conceptos del mismo tipo del documento. Ejemplo:
Concepto pago tradicional solo mostrará conceptos de pago tradicional.
Pagos 3.2 solo mostrarán conceptos de pago 3.2.
Pagos 3.3 (Recibo Electrónico de Pago) solo mostrarán conceptos de Recibo Electrónico de Pago.
Se permitirán seleccionar conceptos 3.3 (Recibo Electrónico de Pago) desde Generar Abono con concepto para las facturas.
En el campo Fecha se debe registrar la fecha y hora en la que el beneficiario recibe el pago, en el XML se toma como FechaPago la fecha capturada en el documento, y el comprobante se emite con la FechaEmision, la fecha en que se efectúa la emisión y timbrado.
Para el llenado correcto de los datos en el XML, los campos Numero Parcialidad, Importe saldo anterior e Importe Saldo Insoluto, se deben capturar ordenadamente, ya que la información que se va en el XML es un reflejo de la situación de saldos y número de parcialidades al momento de generarse y timbrarse el pago, si se capturan en desorden puede provocar inconsistencias entre el XML y reportes.
Nota:
Por el momento el sistema no realiza la validación de que el CFDI con Recibo Electrónico de Pago se emita a más tardar al décimo día natural del mes siguiente al que se recibió el pago, ya que los documentos técnicos publicados no contienen dicha validación, por lo que será responsabilidad del usuario emitirlo en el tiempo establecido.
Consideraciones Cuenta Beneficiario y Cuenta Ordenante
Al momento de timbrar el Recibo Electrónico de Pago, con forma de pago 03-Transferencia Electrónica de Fondos se tomará en cuenta lo siguiente:
El número de cuenta deberá de contar con una longitud mínima de 10 caracteres y una máxima de 30.
Si el número de cuenta es menor a 10 dígitos, el sistema buscará la cuenta CLABE capturada en la cuenta bancaria del Cliente o cuenta bancaria de la Empresa, de tenerla, esta información se irá al XML.
Si la cuenta del cliente o empresa no tiene capturada la cuenta CLABE, se podrá capturar desde el menú Adicionales, opción Modificar datos de la cuenta bancaria del cliente o Modificar datos de la cuenta bancaria de la empresa.
Si no sé cuenta con la cuenta CLABE o un número de cuenta mayor a 10 caracteres, no se enviará la información al XML, a pesar de verla dentro del Recibo electrónico de pago, ya que no es un dato obligatorio para el Anexo 20.
Nota:
Cuando se usan cuentas bancarias para timbrar un Recibo Electrónico de Pago, la cuenta ordenante es la del cliente y la cuenta beneficiaria es la cuenta de la empresa.
Si el Número de la cuenta no cumple con la longitud requerida y no se tiene CLABE capturada se enviará el siguiente mensaje:
Cuenta
Validación
Mensaje
Ordenante
(Cliente)
Si la cuenta no cumple con el patrón correspondiente a la forma de pago del documento.
CRP213 El campo CtaOrdenante no cumple con el patrón requerido.
Si se usa una cuenta con menos de 10 dígitos/caracteres.
El archivo XML que representa al documento digital no está bien formado. Error en la restricción minLegth.
De acuerdo con su tipo de datos el atributo CtaOrdenante no tiene un valor admisible.
Beneficiario
(Empresa)
Si la cuenta no cumple con el patrón correspondiente a la forma de pago del documento.
CRP215 El campo CtaBeneficiario no cumple con el patrón requerido.
Si se usa una cuenta con menos de 10 dígitos/caracteres.
El archivo XML que representa al documento digital no está bien formado. Error en la restricción minLegth.
De acuerdo con su tipo de datos el atributo CtaBeneficiario no tiene un valor admisible.
Importante:
Para mayor información sobre las validaciones adicionales en el Recibo Electrónico de Pago consulta la Matriz de errores publicada por el SAT