VirtualXML provee de 3 funciones que te permitirán llenar un REP de una manera muy sencilla, rápida y sin errores.
Llenar correctamente un REP no es nada complicado, lo complicado es obtener la información para llenar con los datos correctos nuestro CDFI de recepción de pagos, pero eso será tema de nuestra próxima entrega.
El SAT tiene publicada en su página una Guía de Llenado para el REP, donde además de indicarte como debes llenar un REP correctamente, encontrarás información sobre casos especiales de emisión de REPs como el caso de anticipos, factoraje, etc.
Para este artículo nosotros seguiremos la guía de llenado, pero mostrándote con pseudocódigo las funciones que tienes que utilizar para llenar tu REP.
Si quieres un ejemplo funcional "en vivo y a todo color" para un lenguaje de programación en específico, puedes descargarte cualquiera de los ejemplos que tenemos publicados en la página web de VirtualPAC y VirtualXML ya que en todos los ejemplos que hemos publicado, incluimos uno para el llenado del REP.
Empecemos:
Como su nombre oficial lo indica, un REP ó CFDI con COMPLEMENTO de pagos 1.0, atención a la palabra "COMPLEMENTO", indica que el recibo como tal es una parte de un CFDI común y corriente, no es un CFDI por sí mismo, como en el caso de las retenciones.
Cabe mencionar que todas las funciones de las que hablaremos en este artículo las podrás encontrar documentadas en la Página de Documentación de VirtualXML.
Al ser un "COMPLEMENTO" asumimos que va contenido dentro de un CFDI, así pues hemos de crear el CFDI como si de cualquier tipo de documento se tratara, es decir con la función:
hXml := VirtualXML_New("3.3")La cual nos devuelve un "handler" en memoria donde se va a ir construyendo el XML que posteriormente se firmará, sellará y timbrará.
Luego necesitamos indicar nuestras credenciales de acceso al servicio de VirtualPAC:
VirtualXML_SetVirtualPacInfo(hXml,"demo_cibertec","demo")Y ahora la información general del CFDI, es decir la información del nodo <cfdi:Comprobante>:
VirtualXML_SetComprobanteInfo_cfdi33(hXml,; //handle del documento
"PAGO",; //serie
"1",; //folio
"2018-06-01T15:23:11",;//fecha y hora
"",; //forma de pago (no debe existir de acuerdo a la guia de llenado)
"",; //condiciones de pago (no debe existir de acuerdo a la guia de llenado)
"0",; //subtotal(de acuerdo a la guia tiene que llenarse con un 0, sin decimales)
"",; //descuento (no debe existir de acuerdo a la guia de llenado)
"XXX",; //moneda (debe ser XXX de acuerdo a la guia de llenado)
"",; //tipo de cambio (no debe existir de acuerdo a la guia de llenado)
"0",; //total (de acuerdo a la guia tiene que llenarse con un 0 sin decimales)
"P",; //Tipo de comprobante: "P"ago
"",; //metodo de pago (no debe existir de acuerdo a la guia de llenado)
"53050",; //lugar de emision
"") //confirmacion (ya no es necesaria)Comentemos algunos aspectos interesantes de la llamada a esta función.
Como se puede observar, tiene que llevar un número de serie y folio, nosotros recomendamos que los pagos se manejen con su propia serie y folios correspondientes para así llevar un mejor control de los documentos que son de pago, recuerda que estos documentos no tienen carácter de ingreso o egreso fiscal y solo son de tipo informativo.
La fecha se refiere al día y la hora en la cual SE ELABORA EL REP, no es el día en el que el REP se depositó en la cuenta bancaria, sino el día (y la hora, si desconoces la hora deberás poner las 12:00:00) en la que estás elaborando el REP, aunque estas fechas pueden coincidir, sobre todo si elaboras el REP el mismo día en que te hacen el pago, decides hacer tu REP hasta el límite que marca la ley, es decir al décimo día natural del mes siguiente, la fecha del REP deberá ser la del día de elaboración
El tipo de comprobante deberá llevar el valor "P" (en mayúscula), para indicar que es un CFDI de PAGO.
Así mismo deberá de llevar el código postal de el lugar de emisión como un CFDI común y corriente.
La guía de llenado del REP establece que los siguientes valores no deben existir:
- Forma de pago (se definirá en los documentos relacionados del REP)
- Condiciones de pago
- Descuento (es un documento sin totales, no lleva descuentos)
- Tipo de cambio (se utiliza la moneda XXX que no tiene tipo de cambio)
- Método de pago
- Confirmación
Trataremos en la cuarta entrega la sección documentos relacionados, para no confundirnos con otros "documentos relacionados" que también vienen dentro del complemento.
Las dos siguientes secciones son la información del emisor y el receptor respectivamente y utilizaremos las funciones:
VirtualXML_SetEmisorInfo_cfdi33(hXml,; // handle del documento
"AAA010101AAA",; // RFC del emisor del REP
"Empresa de prueba SA de CV",;// Nombre o razón social del emisor (opcional)
"601"; // Clave del regimen fiscal del emisor
)
VirtualXML_SetReceptorInfo_cfdi33(hXml,; //handle del documento
"CTE940531F58",; // RFC del receptor del REP
"Cibernetica y Tecnología SA de CV",; //Nombre o razon social del receptor (opcional)
"",; // Numero de identificación tributaria del receptor (solo en caso de ser extranjero)
"",; // Clave del país de residencia del receptor (solo en caso de ser extranjero)
"P01" // Uso del CFDI.)
Para el caso del EMISOR, los datos son los mismos que en un CFDI normal.
Para el caso del RECEPTOR también, y hay que señalar que el atributo "uso del CFDI", SIEMPRE debe de llevar la clave "P01" (por definir).
Hay que considerar que si vendemos productos al extranjero, y recibimos pagos de nuestros clientes extranjeros que se depositen en cuentas nacionales, TAMBIÉN es obligatorio emitir el Recibo Electrónico de Pago, indicando para esto el RFC genérico para extranjeros "XEXX010101000" y usar los atributos para número de identificación tributaria (el equivalente del RFC en el extranjero) y la clave del país de residencia del cliente, a continuación un ejemplo de como quedaría la llamada a esta función para clientes extranjeros:
VirtualXML_SetReceptorInfo_cfdi33(hXml,; // handle del documento
"XEXX010101000",; // RFC del receptor del REP
"Mitsubishi Corp. Japan Ltd.",; // Nombre o razon social del receptor (opcional)
"B4882097",; // Numero de identificación tributaria del receptor (solo en caso de ser extranjero)
"JPN",; // Clave del país de residencia del receptor (solo en caso de ser extranjero)
"P01" // Uso del CFDI.
)La siguiente sección es la de conceptos, que solo lleva uno, y siempre es el mismo, sin importar cuantos pagos vayas a registrar o cuantas facturas pagues, un REP solo lleva un concepto que es:
VirtualXML_AddConcepto_cfdi33(hXml,; // handle del documento
"84111506",; //clave del producto o servicio
"",; // clave interna del producto o servicio
"1",; // cantidad
"ACT",; // clave de la unidad
"",; // clave interna de la unidad
"Pago",; // descripción
"0",; // Precio unitario
"0",; // Importe
""; // Descuento
)Para el concepto de un REP la clave del producto es 84111506 (Servicios de facturación), la cantidad siempre es 1, la clave de la unidad siempre es ACT (Actividad), la descripción del producto es "Pago" la "P" con mayúscula el resto con minúscula.
No se deben indicar claves de uso interno, descuento y el precio e importe deben ir con un valor de "0" SIN DECIMALES, ya que la moneda del documento es XXX y esta clave de moneda indica que no debe llevar decimales.
Nuestro REP ya no lleva ningún otro nodo o atributo mas, no hay cuentas prediales, números de pedimentos, complementos concepto, ni tampoco existen los nodos para impuestos ni a nivel concepto ni a nivel documento.
Hasta aquí el llenado es el de un CFDI normal, pasemos ahora a analizar como debemos llenar el COMPLEMENTO de recepción de pagos 1.0.
En el capítulo anterior comentamos que el complemento estaba dividido en 2 partes:
- Información sobre el pago
- Información sobre las facturas pagadas
La primer función es:
Esta función recibe como parámetro el handle del documento que estamos generado y lo único que hace es crear el nodo <pagos10:Pago></pagos10:Pago> dentro de nuestro CFDI, es importante mencionar que ANTES de empezar a registrar pagos y facturas pagadas, hay que hacer una llamada (una sola) a esta función.
Hablemos un poco ahora de los pagos como tales.
Los pagos se pueden dividir en 2 grandes familias dependiendo de la manera en que nos los pagan, es importante conocer a que familia pertenece cada pago para poder tener a la mano la información necesaria para poder llenar correctamente el complemento de pagos. Independientemente de a que familia pertenezca el pago, la función VirtualXML_SetPagos10() se utiliza indistintamente.
La primer familia de pagos son los pagos NO BANCARIZADOS, estos pagos se caracterizan porque no hay intervención de una entidad bancaria al momento de realizarlos, ¿ cuales son estos pagos ?, pues los pagos en efectivo, los pagos por aplicación de una nota de crédito, los pagos por compensación o por "dación", etc.
El pago NO BANCARIZADO es el pago mas fácil de registrar ya que no requiere información de alguna entidad bancaria, este es un ejemplo de la llamada a la función VirtualXML_Pagos10SetPago() para un pago en efectivo:
VirtualXML_Pagos10SetPago(hXml, //handle del documento
"2017-05-31T12:00:00",; //fecha y hora de recepción del pago
"01",; // Clave del método de pago
"MXN",; // Clave de la moneda del pago
"",; // Tipo de cambio de la moneda si es distinta de MXN
"1160.00",; // Monto del pago
"","","","","","","","","","")
Este pago requiere de datos básicos:
- La fecha y hora en que se recibió el pago, no la fecha en la cual se deposito en el banco (si es que se deposita) y como la hora la desconocemos, pondremos las 12 del medio día (12:00:00)
- Clave SAT del método de pago de acuerdo al catálogo, esta es la razón por la cual no debemos incluir ni forma de pago ni método de pago en la función VirtualXML_SetComprobanteInfo_cfdi33(), como podemos tener mas de un pago dentro del mismo REP cada pago puede llevar distinto método, por lo tanto es inútil poner un solo método de pago cuando probablemente tengas mas de uno en los pagos.
- Moneda y tipo de cambio: recordar que nos pueden pagar en otra moneda distinta de pesos mexicanos, aun en efectivo.
- Importe total del pago, este monto se aplicará mas adelante a una o mas facturas pendientes de pago.
Los pagos BANCARIZADOS.
Este tipo de pagos son aquellos que se realizan por medio de instrumentos bancarios, como por ejemplo, cheques, tarjetas de crédito o débito, transferencias de fondos o SPEIs (no es lo mismo una transferencia que un SPEI, lo veremos en la proxima entrega), cuando tenemos este tipo de pagos, será necesario incluir mas información que cuando el pago es NO BANCARIZADO.
A continuación un ejemplo de un pago recibido con cheque:
VirtualXML_Pagos10SetPago(hXml, //handle del documento
"2017-05-31T12:00:00",; //fecha y hora de recepción del pago
"02",; // Clave del método de pago
"MXN",; // Clave de la moneda del pago
"",; // Tipo de cambio de la moneda si es distinta de MXN
"1160.00",; // Monto del pago
"652",; // Numero de operación
"BSM970519DU8",; // RFC del banco del cual salen los fondos o RFC generico extranjero en caso de ser Banco extranjero
"",; // Nombre del banco en caso de ser banco extranjero
"002180065145757870",; //Clabe interbancaria de la cuenta de donde salen los fondos
"CFA950629CAA",; // RFC del banco en el cual se depositan los fondos
"002180065145895321",; // Clabe Interbancaria de la cuenta donde se depositan los fondos
"",; // Tipo de cadena de pago cuando se trate de SPEI
"",; // Certificado del CEP cuando se trate de SPEI
"",; // Cadena del CEP cuando se trate de SPEI
""; // Sello del CEP cuando se trate de SPEI
)
Los datos que requerimos para llenar un pago BANCARIZADO en un principio son iguales a los del pago NO BANCARIZADO:
- Fecha y hora de la recepción del pago, es la fecha en que nos entregaron el cheque y como no tenemos manera de saber la hora pondremos las 12 del medio dia (12:00:00), utilizaremos esta hora siempre que no sepamos la hora en que recibimos un pago.
- Método de Pago, En este caso he indicado la clave 02 que es "Cheque nominativo".
- Moneda y Tipo de cambio. Si el pago lo recibimos en pesos, debemos indicar la clave de la moneda y si es difierente de MXN, el tipo de cambio de la moneda. Esto plantea un dilema muy interesante, porque ¿ que pasa si emites la factura en pesos y te la pagan en dólares o viceversa ?, este problema lo analizaremos y resolveremos en la cuarta entrega de esta serie.
- Monto del pago, es decir, la cantidad que nos pagaron, esta cantidad será aplicada posteriormente dentro del mismo complemento a una o mas facturas y siempre deberá ser mayor a la suma de todas las facturas que se registran para pago.
Tengo que señalar, llegados a este punto, que hasta el momento de escribir este artículo, la descripción del complemento publicada por el SAT indica que TODOS LOS DATOS BANCARIOS SON OPCIONALES, es decir, no importa que el pago sea BANCARIZADO o NO BANCARIZADO, todos los datos de los bancos que revisaremos a continuación SON OPCIONALES, desconozco si para cuando entre en vigor la obligatoriedad del uso del REP serán obligatorios o condicionales, pero mientras son peras o son manzanas, revisemos los:
- Número de operación: Se refiere a un numero que el banco asigna a la operación, como puede ser el número de cheque, el número de autorización de la tarjeta, un número de control dado por el propio banco, y en el caso específico de los SPEIs (que analizaremos a profundidad en la tercera entrega) una cosa llamada "clave de rastreo" que veremos de que se trata en el próximo artículo.
- RFC de los bancos que intervienen en pago, tanto del banco de donde salen los fondos y del banco donde se depositan los fondos, es decir, si te pagan con un cheque de HSBC y lo depositas en BBVA Bancomer, necesitaras los RFCs de ambos bancos, la nueva versión de nuestro producto CiberCAT ha sido equipado con un catálogo de bancos que contiene esta y otra valiosa información para el llenado del complemento.
- Número de cuenta de donde salen los fondos y número de cuenta a donde se depositan, nosotros aconsejamos utilizar siempre la CLABE (CLAve Bancaria Estandarizada) ya que la descripción del atributo en el XSD indica que debe tener por lo menos 9 dígitos de longitud y un máximo de 18, muchos bancos manejan menos de 9 dígitos en sus número de cuenta, por lo que el uso de la CLABE, que siempre es de 18 dígitos nos va a evitar muchos errores en el llenado de este parámetro.
A continuación otro ejemplo de llenado pero pagado con una transferencia de un banco extranjero.
VirtualXML_Pagos10SetPago(hXml, //handle del documento
"2017-05-31T12:00:00",; //fecha y hora de recepción del pago
"03",; // Clave del método de pago
"EUR",; // Clave de la moneda del pago
"23.75",; // Tipo de cambio de la moneda si es distinta de MXN
"1000.00",; // Monto del pago
"0054652",; // Numero de operación
"XEXX010101000";, // RFC generico extranjero
"Credit Agricole Banque, Fr, S.A.",; // Nombre del banco en caso de ser banco extranjero
"0021845757870",; //Numero de cuenta del banco extranjero
"CFA950629CAA",; // RFC del banco en el cual se depositan los fondos
"002180065145895321",; // Clabe Interbancaria de la cuenta donde se depositan los fondos
"",; // Tipo de cadena de pago cuando se trate de SPEI
"",; // Certificado del CEP cuando se trate de SPEI
"",; // Cadena del CEP cuando se trate de SPEI
""; // Sello del CEP cuando se trate de SPEI
)
Finalmente hablemos de los 4 últimos parámetros de la función que se utilizarán unicamente cuando te hayan realizado un pago por medio de SPEI (Sistema de Pagos Electrónicos Interbancarios), (vas a desear que nunca te paguen por SPEI).
Debemos de notar que dentro del mundo de las transferencias de fondos, estas pueden estar categorizadas en 3 clases:
- Transferencias de fondos entre cuentas DEL MISMO BANCO
- Transferencias de fondos entre distintos bancos
- Transferencias de fondos realizadas por el sistema SPEI (Sistema de Pagos Electrónicos Interbancarios)
¿ Que diferencia hay entre una transferencia y un SPEI ?, la diferencia básica consiste en que una transferencia tiene aplicación al siguiente día hábil a las 12 del medio día, tal como sucede con un cheque depositado salvo buen cobro, mientras que el SPEI tiene aplicación el mismo día hábil unos pocos minutos después de haber hecho la operación.
En la próxima entrega hablaremos a profundidad del pago por SPEIs, pero a manera de introducción, tenemos que saber que toda la información necesaria para llenar estos 4 parámetros proviene de una cosa llamada CEP (Comprobante Electrónico de Pago).
Un CEP, es un archivo XML que contiene información sobre el SPEI realizado, esta información sera OBLIGATORIA, siempre y cuando utilices el parámetro Tipo Cadena de Pago, y ese tendrás que usarlo cuando registres un pago hecho con un SPEI (no deberás usarlo con una transferencia entre cuentas del mismo banco ni con transferencias de banco a banco).
Los CEPs están resguardados por el Banco de México (Banxico) por 45 días hábiles y los deberás obtener desde la página web de Banxico para poder completar los datos que te pide el pago por SPEI, no te preocupes, hablaremos a profundidad del tema en la tercera entrega y haremos algunos ejemplos adicionales, así que de momento, no nos pongamos nerviosos, si quieres ir avanzando en el tema mientras publico la tercera parte, te recomiendo que visites nuestro nuevo CANAL DE YouTube.
A continuación te muestro un ejemplo del registro de pago, cuando este proviene de un SPEI:
VirtualXML_Pagos10SetPago(hXml, //handle del documento
"2017-05-31T12:00:00",; //fecha y hora de recepción del pago
"02",; // Clave del método de pago
"MXN",; // Clave de la moneda del pago
"",; // Tipo de cambio de la moneda si es distinta de MXN
"1160.00",; // Monto del pago
"652",; // Numero de operación
"BSM970519DU8",; // RFC del banco del cual salen los fondos o RFC generico extranjero en caso de ser Banco extranjero
"",; // Nombre del banco en caso de ser banco extranjero
"002180065145757870",; //Clabe interbancaria de la cuenta de donde salen los fondos
"CFA950629CAA",; // RFC del banco en el cual se depositan los fondos
"002180065145895321",; // Clabe Interbancaria de la cuenta donde se depositan los fondos
"01",; // Tipo de cadena de pago cuando se trate de SPEI
"MIIF+TCCA+GgAwIBAgIUMzAwMDEwMDAwMDAzMDAwMjM3MDgwDQYJKoZIhvcNAQELBQAwggFmMSAwHgYDVQQDDBdBLkMuIDIgZGUgcHJ1ZWJhcyg0MDk2KTEvMC0GA1UECgwmU2VydmljaW8gZGUgQWRtaW5pc3RyYWNpw7NuIFRyaWJ1dGFyaWExODA2BgNVBAsML0FkbWluaXN0cmFjacOzbiBkZSBTZWd1cmlkYWQgZGUgbGEgSW5mb3JtYWNpw7NuMSkwJwYJKoZIhvcNAQkBFhphc2lzbmV0QHBydWViYXMuc2F0LmdvYi5teDEmMCQGA1UECQwdQXYuIEhpZGFsZ28gNzcsIENvbC4gR3VlcnJlcm8xDjAMBgNVBBEMBTA2MzAwMQswCQYDVQQGEwJNWDEZMBcGA1UECAwQRGlzdHJpdG8gRmVkZXJhbDESMBAGA1UEBwwJQ295b2Fjw6FuMRUwEwYDVQQtEwxTQVQ5NzA3MDFOTjMxITAfBgkqhkiG9w0BCQIMElJlc3BvbnNhYmxlOiBBQ0RNQTAeFw0xNzA1MTgwMzU0NTZaFw0yMTA1MTgwMzU0NTZaMIHlMSkwJwYDVQQDEyBBQ0NFTSBTRVJWSUNJT1MgRU1QUkVTQVJJQUxFUyBTQzEpMCcGA1UEKRMgQUNDRU0gU0VSVklDSU9TIEVNUFJFU0FSSUFMRVMgU0MxKTAnBgNVBAoTIEFDQ0VNIFNFUlZJQ0lPUyBFTVBSRVNBUklBTEVTIFNDMSUwIwYDVQQtExxBQUEwMTAxMDFBQUEgLyBIRUdUNzYxMDAzNFMyMR4wHAYDVQQFExUgLyBIRUdUNzYxMDAzTURGUk5OMDkxGzAZBgNVBAsUEkNTRDAxX0FBQTAxMDEwMUFBQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdUcsHIEIgwivvAantGnYVIO3+7yTdD1tkKopbL+tKSjRFo1ErPdGJxP3gxT5O+ACIDQXN+HS9uMWDYnaURalSIF9COFCdh/OH2Pn+UmkN4culr2DanKztVIO8idXM6c9aHn5hOo7hDxXMC3uOuGV3FS4ObkxTV+9NsvOAV2lMe27SHrSB0DhuLurUbZwXm+/r4dtz3b2uLgBc+Diy95PG+MIu7oNKM89aBNGcjTJw+9k+WzJiPd3ZpQgIedYBD+8QWxlYCgxhnta3k9ylgXKYXCYk0k0qauvBJ1jSRVf5BjjIUbOstaQp59nkgHh45c9gnwJRV618NW0fMeDzuKR0CAwEAAaMdMBswDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBsAwDQYJKoZIhvcNAQELBQADggIBABKj0DCNL1lh44y+OcWFrT2icnKF7WySOVihx0oR+HPrWKBMXxo9KtrodnB1tgIx8f+Xjqyphhbw+juDSeDrb99PhC4+E6JeXOkdQcJt50Kyodl9URpCVWNWjUb3F/ypa8oTcff/eMftQZT7MQ1Lqht+xm3QhVoxTIASce0jjsnBTGD2JQ4uT3oCem8bmoMXV/fk9aJ3v0+ZIL42MpY4POGUa/iTaawklKRAL1Xj9IdIR06RK68RS6xrGk6jwbDTEKxJpmZ3SPLtlsmPUTO1kraTPIo9FCmU/zZkWGpd8ZEAAFw+ZfI+bdXBfvdDwaM2iMGTQZTTEgU5KKTIvkAnHo9O45SqSJwqV9NLfPAxCo5eRR2OGibd9jhHe81zUsp5GdE1mZiSqJU82H3cu6BiE+D3YbZeZnjrNSxBgKTIf8w+KNYPM4aWnuUMl0mLgtOxTUXi9MKnUccq3GZLA7bx7Zn211yPRqEjSAqybUMVIOho6aqzkfc3WLZ6LnGU+hyHuZUfPwbnClb7oFFz1PlvGOpNDsUb0qP42QCGBiTUseGugAzqOP6EYpVPC73gFourmdBQgfayaEvi3xjNanFkPlW1XEYNrYJB4yNjphFrvWwTY86vL2o8gZN0Utmc5fnoBTfM9r2zVKmEi6FUeJ1iaDaVNv47te9iS1ai4V4vBY8r",;
// Certificado del CEP cuando se trate de SPEI
"||1|01062018|01062018|131112|40002|BANORTE/IXE|CONSULTORES SA DE CV|40|072180000104200612|VCO980224GM7|BANAMEX|CIBERNETICA Y TECNOLOGIA SA DE CV|40|002180065145757870|CTE940531F58|7415 Consultores|0.00|16762.00|00001000000401205824||",; //Cadena del CEP cuando se trate de SPEI
"KoyfUALQnMJpCHqnY+VA+EmvhzwU8Is4bG5IZdpueeQRBeidJjejQ5VJ0DA21q7b4w4J9QPzYSwnSFO6A6qZxEs68gwPCm4Mm7ztfqCWwbYICLTapLvh2h9WifyadPNsOIJmkmLJtNojTQ90BS67jZf4RanW+ETF+c1tIfFMZ9dakptVZN/wUe3EfujeTuxilsuCPlr+mYiuPZLa/++DIhJCYevIY8s+4UquQhFgVYu/OUg8UYS9TGL/hrf4JPyZUjr4Y6SQ2gprsfpjVUbAYhTC6Jgt7OqQRs3WZTLUThPfSCxo7cqH71O7kOI5Nw638GVwbdS2hrld7WFr0v//4w==",; // Sello del CEP cuando se trate de SPEI
)
En este ejemplo te presento los datos que deben llevar los últimos 4 parámetros del pago. Te recuerdo que estos 4 parámetros solo son obligatorios cuando el pago se realice por medio de un SPEI.
De estos 4 parámetros, 3 se obtienen del CEP, que como comentamos anteriormente es un archivo en formato XML que deberemos obtener desde la página web de Banxico, estos datos son:
- Tipo de cadena de pago, es una clave para identificar el tipo de pago, el catálogo del SAT solo muestra un valor que es 01, y que indica que el pago se hizo por medio de SPEI.
- El siguiente parámetro es el CERTIFICADO expresado como texto en Base64 que se utilizó para timbrar el CEP, esa información viene en el XML del CEP, te enseñaremos como obtener la cadena en Base64 en la proxima entrega.
- El tercer parámetro es el una CADENA ORIGINAL correspondiente al CEP y se encuentra en el mismo XML donde viene el certificado.
- El último parámetro es un Sello digital que arrojó la certificación del CEP en el SAT y que también viene dentro del mismo archivo del CEP.
Pasemos ahora al tema de las facturas que ampara el pago.
VirtualXML incluye la función:
Que nos pemitirá registrar tantas facturas como queramos aplicar a un mismo pago.
La función debe de utilizarse DESPUÉS de la función VirtualXML_Pagos10SetPago() y se repetirá tantas veces como facturas deseemos aplicar a un pago.
Es muy importante recordar que la suma de los montos pagados de cada factura NO DEBE REBASAR el importe del monto establecido con la función VirtualXML_Pagos10SetPago().
Ejemplo del uso:
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,
"D8E18C2F-2859-4927-A0F0-EA3E93642DDC",;// UUID de la factura a la cual aplicamos el pago
"A",; // Serie de la factura
"400",; // folio de la factura
"MXN",; // moneda en la cual fue emitida la factura
"",; // tipo de cambio
"PPD",; // forma de pago
"1",; // numero de parcialidad
"2900.00",; // saldo anterior de la factura
"2900.00",; // importe del apgo
"0.00"; // saldo pendiente de la factura.
)
Los parámetros que necesitaremos para esta función son:
- UUID, Serie y Folio de la factura como identificadores del documento
- Moneda y tipo de cambio al cual fue expedida la factura en su momento
- Forma de pago del documento original que debe ser PPD (Pago en parcialidades o diferido) pero si es PUE tampoco pasa nada (de momento).
- Número de parcialidad pagada
- Saldo anterior de la factura
- Importe del pago
- Saldo pendiente de la factura.
Me podrás decir....
- Pero eso ya lo hago yo en mi modulo de cuentas por cobrar, llevo un estado de cuenta de lo que me deben mis clientes.
Eso es válido y está muy bien, sin embargo ahora, el estado de cuenta no debe ser por cliente sino por factura, ya que deberemos registrar cada uno de los pagos que sean aplicados a dicha factura, el importe del saldo pendiente de pago, y por otro lado aplicar el pago correspondiente y hacer un calculo del saldo pendiente, mismos datos que deberemos almacenar y utilizar en otro pagos posteriores.
En el ejemplo anterior, teníamos una factura de $2,900.00 pesos, hemos recibido un pago de $2,900.00 pesos, por lo tanto, el valor de la parcialidad es 1, el saldo anterior es de $2,900.00, el pago es de $ 2,900.00 y por lo tanto el saldo insoluto de la factura es de 0.00, es decir, se ha liquidado en su totalidad.
¿ Que pasa cuando el pago se tiene que aplicar sobre mas de una factura distinta ?
Pues muy sencillo, he aqui el ejemplo:
// Creamos el pago
VirtualXML_Pagos10SetPago(hXml,"2017-05-15T12:00:00","01","MXN","","5800.00","","","","","","","","","","")
// Ahora aplicamos el pago a 3 facturas distintas:
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"D8E18C2F-2859-4927-A0F0-EA3E93642DDC","A","400","MXN","","PPD","1","2900.00","2900.00","0.00")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"BE1D4B47-E167-47A3-8049-70D4D43BCBE8","A","340","MXN","","PPD","2","1450.00","1450.00","0.00")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"FF93C8BE-AF7B-4FC5-8854-6DAE18CFB5B4","A","434","MXN","","PPD","1","2900.00","1450.00","1450.00")
Primero ejecuto la función VirtualXML_Pagos10SetPago() para establecer que he recibido un pago de $5,800.00, este pago se aplicará a 3 facturas, por lo tanto llamare 3 veces a la función VirtualXML_Pagos10AddPagoDoctoRelacionado(), indicando en cada llamada a que factura y cuanto aplico del pago.
En la primer llamada tenemos una factura de $2,900.00 que queda pagada en su totalidad, es una factura que originalmente era por $2,900.00, y se va a liquidar totalmente, por lo tanto es una sola parcialidad y el saldo insoluto de dicha factura queda en 0.00, nuestro pago total fue de $5,800.00 menos $2,900.00 de este pago, nos quedan $2,900.00 para aplicar.
La segunda factura trae un saldo anterior de $1,450.00, y se le aplicará su segundo pago, por un importe similar para que la factura quede totalmente saldada. Nos quedaban $2,900.00 menos $1,450.00 de este pago, aun tenemos $1,450.00 pendientes de aplicar.
Finalmente tenemos una tercer factura de $2,900.00, pero solo nos quedan $1,450.00, así que vamos a aplicar este primer pago de $1,450.00 a la factura, y dejaremos un saldo insoluto de $1,450.00 mismos que se cubrirán con otro pago.
Como podrás apreciar es muy simple aplicar los pagos a las facturas, pero es MUY IMPORTANTE llevar un control de saldos adecuado para que los números coincidan perfectamente.
Para cerrar este artículo tenemos que mencionar algo importante: Un REP puede contener mas de un pago dentro del mismo CFDI.
Para lograr esto, deberás llamar a la funcion VirtualXML_Pagos10SetPago() seguido de la(s) llamada(s) a la función VirtualXML_Pagos10AddPagoDoctoRelacionado() tantas veces como pagos quieras registar en un solo documento.
Debes de tomar en cuenta que los pagos deben ser DEL MISMO RECEPTOR, no puedes mezclar pagos de distintos clientes un solo REP.
El concentrar todos los pagos de un cliente en un solo REP no depende unilateralmente de tí, deberás concertarlo con tu cliente para ver si quiere un solo REP mensual por todos sus pagos o bien un REP individual por cada pago, en nuestra experiencia en los meses que lleva operando la emisión de REPs la mayoría de los clientes prefieren un REP por cada pago para llevar un mejor control de sus facturas.
Concluimos este artículo con un ejemplo completo de CFDI de recepción de pagos que incluye 2 pagos en el mismo documento:
hXml := VirtualXMl_New("3.3")
VirtualXML_SetVirtualPacInfo(hXml,"demo_cibertec","demo")
VirtualXML_SetComprobanteInfo_cfdi33(hXml,"PAGO","1","%cb_date","","","0","","XXX","","0","P","","53050","")
VirtualXML_SetEmisorInfo_cfdi33(hXml,"AAA010101AAA","Empresa de prueba SA de CV","601")
VirtualXML_SetReceptorInfo_cfdi33(hXml,"CTE940531F58","Cibernetica y Tecnología SA de CV","","","P01")
VirtualXML_AddConcepto_cfdi33(hXml, "84111506", "", "1", "ACT", "", "Pago", "0", "0", "")
VirtualXML_SetPagos10(hXml)
VirtualXML_Pagos10SetPago(hXml,"2017-05-31T12:00:00","02","MXN","","1160.00","652","BSM970519DU8","","002180065145757870","CFA950629CAA","002180065145895321","","","","")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"FF93C8BE-AF7B-4FC5-8854-6DAE18CFB5B4","A","434","MXN","","PPD","1","1160.00","1160.00","0.00")
VirtualXML_Pagos10SetPago(hXml,"2017-05-15T12:00:00","01","MXN","","5800.00","","","","","","","","","","")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"D8E18C2F-2859-4927-A0F0-EA3E93642DDC","A","400","MXN","","PPD","1","2900.00","2900.00","0.00")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"BE1D4B47-E167-47A3-8049-70D4D43BCBE8","A","340","MXN","","PPD","2","1450.00","1450.00","0.00")
VirtualXML_Pagos10AddPagoDoctoRelacionado(hXml,"FF93C8BE-
AF7B-4FC5-8854-6DAE18CFB5B4","A","434","MXN","","PPD","1","2900.00","1450.00","1450.00")
nResultado := VirtualXML_ProcesaDocumento(hXml,"AAA010101AAA.cer","AAA010101AAA.key","12345678a","ejemplo33conpagos.xml")
En la página de VirtualXML en la sección de descargas de los ejemplos de uso de VirtualXML, podrás descargar ejemplos en varios lenguajes de programación sobre el uso de las funciones para el complemento de pagos 1.0.
En la próxima entrega trataremos un tema complicado e interesante: SPEIs y su aplicación al complemento de pago 1.0, si quieres ir adelantando algo en este tema VISITA NUESTRO CANAL DE YOUTUBE
No hay comentarios:
Publicar un comentario