Estos días hemos estado recibiendo numerosos mensajes con respecto a que distintos validadores no reconocen los certificados con los que fue sellado un documento emitido por VirtualPAC desde el día 15 de Noviembre del 2018.
Este error se debe a que el PAC DFacturE renovó sus certificados el día 15 de Noviembre de 2018, y el SAT le otorgó un nuevo CSD, por este motivo muchos validadores no tiene registrado este nuevo certificado y están rechazando las facturas con el mensaje de "no se encuentra el certificado con el que fue sellado el CFDI" o algún mensaje similar.
Para solucionar este problema será necesario actualizar el certificado del PAC en el validador, para esto será necesario que entres en la pagina:
En esa plataforma del SAT deberás proporcionar los Captcha correspondientes y solicitar descarga POR NUMERO DE CERTIFICADO.
El nuevo número de certificado de DFacturE es: 00001000000412706402.CER
La parte de seguridad:
¿ Como sé que este número es el número de certificado correcto ?
Este numero aparece en el timbre fiscal digital de tu CFDI, en la propiedad:
NoCertificadoSAT="00001000000412706402"
Abre el XML del CFDI con cualquier editor de textos y busca la sección <tfd:TimbreFiscalDigital> y ahi localiza la propiedad NoCertificadoSAT, verás el número mencionado anteriormente.
A ese número agrégale la extensión .CER y tendrás el nombre del archivo de certificado de sello digital, mismo que deberás descargar de la página del SAT.
¿ Porqué descargarlo de la página del SAT ?
¿ No lo puedes poner en el sitio de VirtualPAC para decargarlo directamente ?.
Sí, si podríamos, pero hemos tenido quejas de que los archivos podrían haber sido "manipulados", con lo cual preferimos que hagas directamente la descarga desde la página del SAT para que tengas la certeza de que el certificado es obtenido directamente del SAT sin manipulación de ninguna índole.
Proporciona el nuevo certificado a tu validador y podrás validar correctamente tus CFDIs generados por VirtualPAC a partir del 15 de Noviembre.
martes, 27 de noviembre de 2018
miércoles, 14 de noviembre de 2018
(VirtualPAC) Aviso IMPORTANTE sobre CFDIs no existentes en el SAT
El pasado día Jueves 8 de
Noviembre 2018, nuestro PAC primario “DFacturE” (Facturación Electrónica, S.A.) emitió erróneamente
CFDI’s con UUID que no fueron registrados en el SAT, notando esta falla el día Viernes 9 de Noviembre.
Para
corregir este error, DFacturE re-emitió los CFDI erróneos el día 10 de
Noviembre, lo que generó distinto UUID al que originalmente fue emitido.
El contenido del CFDI se mantuvo exactamente igual y el CFDI se encuentra debidamente registrado en el SAT
cambiando únicamente el timbre fiscal digital y su correspondiente
UUID. En algunos casos, la re-emisión del CFDI no fue posible.
Para
ayudar a nuestros usuarios a identificar los documentos afectados por
esta falla, DFActurE nos ha proporcionado un listado con los UUID
erróneos, los UUID
correctos y los UUID que no pudieron re-emitirse, ordenados por RFC
emisor.
Dentro
de las próximas 24 hrs. pondremos a su disposición a través del portal
de Administración de VirtualPAC (http://admin.virtual-pac.mx), un archivo ZIP conteniendo los archivos
XML con el timbre fiscal digital correcto; así como una hoja de MS
Excel con la información correspondiente al RFC Emisor, UUID Erróneo,
UUID Correcto, así como UUID que no pudieron ser re-emitidos.
Lamentamos
las molestias que esto pueda ocasionarles y en compensación por nuestra parte, asignaremos
sin costo 10 timbres fiscales a cada emisor por cada UUID que no haya
sido procesado correctamente.
Para
más información relativa a esta falla y dado que escapa a nuestra competencia directa, les pedimos atentamente se
pongan en contacto directo con el PAC “DFacturE” en el teléfono: 01-222-248-5252 con la Srta. Pilar Curiel o al correo integraciones@dfacture.com
Reiteramos nuestro compromiso con nuestros clientes para proporcionarles el mejor servicio de timbrado.
viernes, 9 de noviembre de 2018
(VirtualXML) El valor del campo TotalImpuestosRetenidos debe ser igual a la suma de los importes registrados en el elemento hijo Retencion
El día de hoy Viernes 9 de Noviembre 2018 muchos emisores han comenzado a obtener este mensaje de error:
CFDI33181 El valor del campo TotalImpuestosRetenidos debe ser igual a la suma de los importes registrados en el elemento hijo Retencion. El nodo Impuestos:Retenciones no contiene elementos.
No es un mensaje de error, es un error de llenado del XML mismo que las nuevas guias de llenado publicadas por el SAT en Septiembre de 2018 ya habían comentado que se validaría.
¿ En que consiste el error ?
El error consiste en poner 0.00 en el nodo TotalImpuestosRetenidos, cuando el CFDI NO TIENE RETENCION DE IMPUESTOS, es decir, no hay retención de IVA o de ISR (retenciones que solo existen cuando las personas físicas emiten recibos de honorario ó arrendamiento a personas morales) o bien en algunos casos de retención por ventas a gobierno.
Por lo tanto, si un CFDI no tiene retenciones no tiene porque contener el nodo TotalImpuestosRetenidos y por ende este nodo no debe tener ningúnn valor.
Usando VirtualXML y la función:
CFDI33181 El valor del campo TotalImpuestosRetenidos debe ser igual a la suma de los importes registrados en el elemento hijo Retencion. El nodo Impuestos:Retenciones no contiene elementos.
No es un mensaje de error, es un error de llenado del XML mismo que las nuevas guias de llenado publicadas por el SAT en Septiembre de 2018 ya habían comentado que se validaría.
¿ En que consiste el error ?
El error consiste en poner 0.00 en el nodo TotalImpuestosRetenidos, cuando el CFDI NO TIENE RETENCION DE IMPUESTOS, es decir, no hay retención de IVA o de ISR (retenciones que solo existen cuando las personas físicas emiten recibos de honorario ó arrendamiento a personas morales) o bien en algunos casos de retención por ventas a gobierno.
Por lo tanto, si un CFDI no tiene retenciones no tiene porque contener el nodo TotalImpuestosRetenidos y por ende este nodo no debe tener ningúnn valor.
Usando VirtualXML y la función:
Es la causa del problema pero al mismo tiempo la solución.
El problema se causa cuando haces:
VirtualXML_SetImpuestosInfo_cfdi33(hXml, "ImporteTraslados","0.00")
El último parámetro de la función es el que se utiliza para indicar el importe de los impuestos retenidos, si estos no existen en tu CFDI, debes usar esta función así:
VirtualXML_SetImpuestosInfo_cfdi33(hXml, "ImporteTraslados","")
Como verás el último parámetro está vacío, con lo cual no se generará el nodo "TotalImpuestosRetenidos"cuando estos no existan.
Este mismo error lo tendrás cuando pongas un valor de "0.00" en los descuentos de las partidas, pero este asunto ya lo hemos tratado en otro post del blog que puedes consultar en:
http://virtual-pac.blogspot.com/2018/02/virtualxml-el-problema-de-los.html
Es importante recalcar que cuando un nodo relativo a importes (SubTotal, Total, Descuentos, etc) cuando no tienen valor NO DEBEN SER LLENADOS CON 0.00, simplmente o deben existir.
Es importante que realices este cambio ya que el SAT continuará siendo mas exigente con el llenado de los CFDI 3.3
lunes, 22 de octubre de 2018
(VirtualXML) 2 Nuevas funciones para el nuevo esquema de cancelaciones
El día de hoy Lunes 22 de Octubre de 2018, estamos liberando una nueva version de VirtualXML que incluye 2 funciones muy importantes para el nuevo esquema de cancelación:
La función:
VirtualXML_CancelaCFDI()
Que publicamos la semana pasada, sufrió algunos cambios internos para mejorar su desempeño y 2 validaciones adicionales que no estabamos realizando. Ahora funciona correctamente en todos los casos.
Les recuerdo que cuando la función devuelva un valor 1 (que indica que se ha solicitado la cancelación por medio del buzón tributario, se cobrará 1 timbre por el uso del servicio), cuando la cancelación sea directa, o no proceda ya sea porque el CFDI no es cancelable o bien porque no se encuentre en los registros del SAT, no habrá cobro por el uso de la función.
Incluimos una nueva fucnión:
VirtualXML_GetStatusCFDI()
Esta función tiene como objetivo obtener el estado de un CFDI (Cancelable, no cancelable o no existente) durante el proceso de cancelación bajo el nuevo esquema, por ejemplo:
- Puedes consultar el estado (ver si es cancelable, no cancelable y como se puede cancelar: directamente o con autorización) de un CFDI ANTES de cancelarlo
- Puedes consultar si un CFDI ya se encuentra en los registros del SAT y es cancelable
- Puedes consultar si un CFDI ya se autorizó para cancelación o bien esta en PROCESO de autorización
- Puedes consultar si un CFDI aplicó cancelación Ficta o fue rechazado por el el receptor.
La documentación y ejemplo de esta nueva función ya se encuentra en la documentación en línea de VirtualXML:
http://www.virtual-pac.mx/doc/html/Virtualxml_GetStatusCFDI.htm
Les recordamos que el nuevo esquema de cancelaciones entra en vigor el día 1 de Noviembre, por lo que cuentan con poco mas de 1 semana para realizar los cambios en sus sistemas.
La nueva DLL se encuentra disponible como siempre en nuestro sitio:
http://www.virtual-pac.mx/vxml_x86x64_xp2003.zip
sábado, 13 de octubre de 2018
(VirtualXML) Nueva función de Cancelación Vigente a partir del 1 de Noviembre 2018
Tenemos el tiempo encima para la entrada del nuevo esquema de cancelaciones el cual entrará en vigor el día 1 de Noviembre de 2018.
El nuevo método de cancelación es bastante complejo y esta vez TENDRA COSTO en un caso específico, por favor, lee este artículo hasta el final para saber cuando tendrás que pagar un timbre y cuando la cancelación será sin costo.
La nueva función es:
No confundir con VirtualXML_CancelaUUID(), esta función es la que esta actualmente vigente pero no funcionará a partir del 1 de Noviembre.
Veamos la sintaxis de esta nueva función:
Donde :
cUsuario: Nombre del usuario VirtualPAC
cRfcEmisor: RFC del emisor del CFDI que deseamos cancelar.
cRefReceptor: RFC del receptor del CFDI que deseamos cancelar
cTotal: Importe total del CFDI que queremos cancelar
cUuid: UUID del CFDI a cancelar:
cCert: Ruta y nombre del archivo .CER del emisor del CFDI
cKey: Ruta y nombre del archivo .KEY del emisor del CFDI
cPwd: Password de archivo KEY
cArchResult: Ruta y nombre de un archivo donde se colocará el resultado de la cancelación
cArchLog: Ruta y nombre de un archivo donde se colocará una bitacora donde se registrarán los eventos del proceso de cancelación.
Devuelve:
nResultado: Un valor numérico que nos indica el resultado del proceso de cancelación y que puede tener 5 posibles valores:
Por favor nota que esta nueva función incluye 2 archivos de resultados, el primero es un archivo donde aparecerán los resultados completos del proceso de cancelación, si el nombre lo indicas con la extensión ".INI", obtendras un archivos con los resultados expresados en formato INI, si utlizas otra extensión o no le pones extensión al archivo, lo obtendrás como un texto plano dividido en renglones. En este archivo se guardará toda la información devuelta por el SAT del proceso de cancelación
Entre otros datos podrás encontrar el error de la cancelación, el estado del comprobante, si el comprobante es cancelable y el estatus de cancelación, así como también el PAC que canceló el documento.
El segundo archivo es un archivo de bitácora similar al VirtualXML.LOG donde la función guarda todos los pasos seguidos en el proceso de cancelación, este archivo solo será necesario para fines de depuración y control de errores, pero te recomendamos tenerlo a mano para hacerlo llegar a nuestra area de soporte en caso de que tengas fallas (que las vas a tener) con el nuevo esquema de cancelaciones.
Esta nueva función ya esta disponible en la versión de VirtualXML del 08 de Octubre de 2018 y que ya está disponible en nuestra página web (www.virtual-pac.mx).
TODOS LOS EMISORES DEBERAN ACTUALIZAR SU DLL PARA TENER ACCESO A LA NUEVA FUNCION DE CANCELACIONES.
Nuestros PACs nos han informado que ya es posible realizar pruebas en un entorno "real" proporcionado por el mismo SAT ya que hasta la fecha, todas las pruebas solo se podían realizar en entornos simulados por los PACs no reales.
La batería de funciones de cancelación no está concluida aún, faltan 3 funciones muy importantes que de momento no podemos liberar hasta que empiecen a fluir las cancelaciones reales bajo el nuevo esquema y que son:
Esperamos que esta información te sea de utilidad para comenzar a trabajar con el nuevo esquema de cancelaciones, por nuestra parte seguimos trabajando para tener pronto toda la batería de funciones lista.
El nuevo método de cancelación es bastante complejo y esta vez TENDRA COSTO en un caso específico, por favor, lee este artículo hasta el final para saber cuando tendrás que pagar un timbre y cuando la cancelación será sin costo.
La nueva función es:
VirtualXML_CancelaCFDI()
No confundir con VirtualXML_CancelaUUID(), esta función es la que esta actualmente vigente pero no funcionará a partir del 1 de Noviembre.
Veamos la sintaxis de esta nueva función:
Donde :
cUsuario: Nombre del usuario VirtualPAC
cRfcEmisor: RFC del emisor del CFDI que deseamos cancelar.
cRefReceptor: RFC del receptor del CFDI que deseamos cancelar
cTotal: Importe total del CFDI que queremos cancelar
cUuid: UUID del CFDI a cancelar:
cCert: Ruta y nombre del archivo .CER del emisor del CFDI
cKey: Ruta y nombre del archivo .KEY del emisor del CFDI
cPwd: Password de archivo KEY
cArchResult: Ruta y nombre de un archivo donde se colocará el resultado de la cancelación
cArchLog: Ruta y nombre de un archivo donde se colocará una bitacora donde se registrarán los eventos del proceso de cancelación.
Devuelve:
nResultado: Un valor numérico que nos indica el resultado del proceso de cancelación y que puede tener 5 posibles valores:
- 1 - Significa que el CFDI no puede cancelarse directamente y que se ha solicitado al receptor, mediante el buzon tributario, la cancelación del CFDI, en este caso habrá que esperar las 72 horas que marca la ley para obtener una cancelación FICTA si el receptor no rechaza la cancelación o bien si el receptor rechaza la cancelación, el documento no se cancelará, en cualquier caso, si la función devuelve un valor de "1" (UNO) se te cobrará un timbre del saldo del emisor. El cobro de este timbre NO GARANTIZA que la cancelación proceda exitosamente, queda a criterio del SAT y del receptor aplicar la cancelación correspondiente.
- 0 - Significa que el CFDI se puede cancelar directamente y que se ha cancelado con éxito, en este caso no se te cobrará timbre por la cancelación del documento.
- -1 - Significa que el CFDI NO SE PUEDE CANCELAR, esto puede deberse a varios motivos, como por ejemplo, el CFDI ha sido previamente cancelado o bien, el CFDI esta en estado de "PROCESANDO", la cancelación ha sido rechazada por el receptor, el CFDI tiene documentos relacionados y otros posibles errores, mismos que podrán consultarse mas a detalle en el archivo de resultados.
- -2 Indica que el CFDI no existe aún en los registros del SAT, si obtienes este resultado, deberás revisar que has indicado un CFDI correcto o bien tendrás que esperar algun tiempo hasta que el CFDI sea registrado en el SAT, te recordamos que el tiempo que marca la ley para que el PAC envie al SAT los CFDI es de un máximo de 72 horas.
- -3 Indica que existe algún error en el proceso interno de cancelación como por ejemplo que el servicio de cancelaciones del SAT no está disponbile, para mas detalles deberás consultar el archivo de bitácora (ultimo parámetro de la función) donde se guardan detalles técnicos de operación de la función.
Por favor nota que esta nueva función incluye 2 archivos de resultados, el primero es un archivo donde aparecerán los resultados completos del proceso de cancelación, si el nombre lo indicas con la extensión ".INI", obtendras un archivos con los resultados expresados en formato INI, si utlizas otra extensión o no le pones extensión al archivo, lo obtendrás como un texto plano dividido en renglones. En este archivo se guardará toda la información devuelta por el SAT del proceso de cancelación
Entre otros datos podrás encontrar el error de la cancelación, el estado del comprobante, si el comprobante es cancelable y el estatus de cancelación, así como también el PAC que canceló el documento.
El segundo archivo es un archivo de bitácora similar al VirtualXML.LOG donde la función guarda todos los pasos seguidos en el proceso de cancelación, este archivo solo será necesario para fines de depuración y control de errores, pero te recomendamos tenerlo a mano para hacerlo llegar a nuestra area de soporte en caso de que tengas fallas (que las vas a tener) con el nuevo esquema de cancelaciones.
Esta nueva función ya esta disponible en la versión de VirtualXML del 08 de Octubre de 2018 y que ya está disponible en nuestra página web (www.virtual-pac.mx).
TODOS LOS EMISORES DEBERAN ACTUALIZAR SU DLL PARA TENER ACCESO A LA NUEVA FUNCION DE CANCELACIONES.
Nuestros PACs nos han informado que ya es posible realizar pruebas en un entorno "real" proporcionado por el mismo SAT ya que hasta la fecha, todas las pruebas solo se podían realizar en entornos simulados por los PACs no reales.
La batería de funciones de cancelación no está concluida aún, faltan 3 funciones muy importantes que de momento no podemos liberar hasta que empiecen a fluir las cancelaciones reales bajo el nuevo esquema y que son:
- Función para revisar el estado de un documento en PROCESO y saber si la cancelación ya fue autorizada o bien fue rechazada por el receptor, estamos considerando utilizar una función que ya viene incluida en VirtualXML que es VirtualXML_ConsultaEstadoCFDI() que ya existe actualmente y que debemos modificar para devolver nuevos valores, de momento no podemos hacerlo hasta ver que resultados nos va a devolver el SAT exactamente, que ya hasta el momento de escribir este artículo aún no esta disponible la plataforma de consultas.
- Función para descargar todas las peticiones de cancelación de nuestros proveedores, a fin de evitar tener que estar consultado el buzón fiscal todos los dias, tendremos una función que te permitirá descargar todas las peticiones de cancelacions que hayas recibido en tu buzón fiscal, el uso de esta función se cobrará a 1 timbre por consulta.
- Función para autorizar/rechazar las peticiones de cancelación recibidas, esta función tiene por objeto que puedas autorizar o rechazar las peticiones que hayas descargado sin necesidad de utilizar el buzón fiscal, el uso de esta función también tiene el costo de 1 timbre por uso.
Esperamos que esta información te sea de utilidad para comenzar a trabajar con el nuevo esquema de cancelaciones, por nuestra parte seguimos trabajando para tener pronto toda la batería de funciones lista.
viernes, 5 de octubre de 2018
(VirtualXML) CRP213 El campo CtaOrdenante no cumple con el patrón requerido
Lo sabía, lo sabía, lo sabía.
Conforme avanza la implementación del Complemento de Recepción de Pago (CRP) también conocido como Recibo Electrónico de Pago (REP) entre nuestros emisores, surgen distintos casos, muchas dudas, y problemas que "antes no pasaban".
Uno de ellos, que es por el que mas nos han llamado esta semana es un error que dice textualmente lo siguiente:
Y venga la avalancha de llamadas de..... es que me esta rechazando pagos que antes si dejaba pasar....
Bien aclaremos y resolvamos esta incógnita de una vez y para siempre.
Para dar con el culpable, tendremos que irnos al Catálogo de Complemento de Pagos, publicado por el SAT en:
Este catálogo es una hoja de Excel, donde el primer libro, llamado c_FormaPago tiene la respuesta a nuestras preguntas.
En este libro tenemos el Catálogo de Formas de Pago que tendremos que usar para llenar nuestro complemento y esta divido, entre otras en las siguientes columnas, que son las que nos importan realmente:
Como podemos ver, en la columna Patrón para cuenta ordenante, está definida la EXPRESION REGULAR (Regular Expression) que define como debe de ir conformado el numero de cuenta ordenante.
No voy a entrar en detalle de lo que es una expresión regular, asumo que ya lo sabes, pero por si acaso, te dejo el link de la Wikipedia para mas información:
Bien, volviendo al tema, si revisamos las RegEx (Regular Expressions) de los patrones de cuenta ordenante lo primero que podemos apreciar, es que el patrones que define el pago con Cheque nominativo no es el mismo que el patrón que define el pago con Transferencia electrónica de fondos, ni el mismo de la tarjeta de crédito.
Veamos:
Para pago con cheque nominativo la RegEx es:
¿ Que pasa si la cuenta tiene menos de 11 dígitos ?, por ejemplo una cuenta de Banamex tiene solo 7 dígitos, muy fácil, rellenaré con ceros "0" a la izquierda, hasta alcanzar los 11 dígitos, por ejemplo:
La cuenta Banamex: 4575787
Quedaría como: 00004575787
Pero si utilizo la CLABE no tengo problema: 002180065145757870
Conforme avanza la implementación del Complemento de Recepción de Pago (CRP) también conocido como Recibo Electrónico de Pago (REP) entre nuestros emisores, surgen distintos casos, muchas dudas, y problemas que "antes no pasaban".
Uno de ellos, que es por el que mas nos han llamado esta semana es un error que dice textualmente lo siguiente:
"CRP213 El campo CtaOrdenante no cumple con el patrón requerido."
Y venga la avalancha de llamadas de..... es que me esta rechazando pagos que antes si dejaba pasar....
Bien aclaremos y resolvamos esta incógnita de una vez y para siempre.
Para dar con el culpable, tendremos que irnos al Catálogo de Complemento de Pagos, publicado por el SAT en:
Este catálogo es una hoja de Excel, donde el primer libro, llamado c_FormaPago tiene la respuesta a nuestras preguntas.
En este libro tenemos el Catálogo de Formas de Pago que tendremos que usar para llenar nuestro complemento y esta divido, entre otras en las siguientes columnas, que son las que nos importan realmente:
- Clave de la Forma de Pago
- Descripción
- Bancarizado
- Numero de operacion
- RFC del emisor de la cuenta ordenante
- Cuenta ordenate y.......
- PATRON PARA LA CUENTA ORDENANTE
Como podemos ver, en la columna Patrón para cuenta ordenante, está definida la EXPRESION REGULAR (Regular Expression) que define como debe de ir conformado el numero de cuenta ordenante.
No voy a entrar en detalle de lo que es una expresión regular, asumo que ya lo sabes, pero por si acaso, te dejo el link de la Wikipedia para mas información:
Bien, volviendo al tema, si revisamos las RegEx (Regular Expressions) de los patrones de cuenta ordenante lo primero que podemos apreciar, es que el patrones que define el pago con Cheque nominativo no es el mismo que el patrón que define el pago con Transferencia electrónica de fondos, ni el mismo de la tarjeta de crédito.
Veamos:
Para pago con cheque nominativo la RegEx es:
[0-9]{11}|[0-9]{18}
Que significa lo siguiente:
Este patron acepta 2 formatos:
- 11 digitos del 0 al 9
- 18 digitos del 0 al 9 (esto equivale a la Clave Bancaria Estandarizada CLABE)
¿ Que pasa si la cuenta tiene menos de 11 dígitos ?, por ejemplo una cuenta de Banamex tiene solo 7 dígitos, muy fácil, rellenaré con ceros "0" a la izquierda, hasta alcanzar los 11 dígitos, por ejemplo:
La cuenta Banamex: 4575787
Quedaría como: 00004575787
Pero si utilizo la CLABE no tengo problema: 002180065145757870
Analicemos ahora la RegEx para el pago con transferencia electrónica de fondos:
[0-9]{10}|[0-9]{16}|[0-9]{18}
A diferencia del anterior, este patrón acepta 3 formatos:
- 10 dígitos del 0 al 9
- 16 dígitos del 0 al 9
- 18 dígitos del 0 al 9
Vemos que salvo el caso de la CLABE (18 digitos), el patrón para pago con cheque NO ES EL MISMO QUE EL PATRON PARA PAGO CON TRANSFERENCIA, por lo tanto NO PODEMOS USAR EL MISMO NUMERO DE CUENTA QUE USAMOS EN EL PAGO CON CHEQUE QUE EN EL PAGO CON TRANSFERENCIA.
Volviendo al ejemplo de Banamex:
La cuenta Banamex: 4575787
Para pago con cheque quedaría: 00004575787
Para pago con transferencia quedaría: 0004575787
Para pago con cheque y transferencia indistintamente: 002180065145757870
Nota que para el pago con cheque he tenido que añadir 4 ceros a la izquierda para alcanzar la logitud de 11 caracteres mientras que para el pago con transferencia he tenido que agregar solo 3 ceros para alcanzar la longitud de 10 dígitos.
¿ No es incoherente que para un caso la cuenta se maneje con 10 dígitos mientras que para otra forma de pago la misma cuenta se maneje con 11 dígitos ?
Probablemente sí, sin embargo hay una solución universal para este problema: Utilizar la CLAve Bancaria Estandarizada (CLABE), que siempre tiene una longitud de 18 dígitos y que todo parece indicar que el SAT junto con BANXICO quieren fomentar su uso, en el complemento de pagos.
Con esto queda revelado el misterio de porqué "el campo CuentaOrdenante no cumple con el patrón requerido".
¿ Porque algunas veces no timbra otros documentos que antes si timbraba ?, no hay misterio, seguramente estas metiendo el numero de cuenta que usabas para el pago con cheque en el pago con transferencia o viceversa.
Pare de sufrir: utiliza siempre la CLABE y te olvidas de problemas que si con 10 dígitos cuando es transferencia ú 11 dígitos cuando es cheque.
lunes, 24 de septiembre de 2018
(VirtualXML) Como poner un "namespace" en la seccion Comprobante de un CFDI con VirtualXML
Con la entrada del nuevo Complemento de Recepción de Pagos 1.0, algunos de nuestros usuarios nos han comentado que ciertos validadores de terceros marcan un error en la ubicación de los "namespace" del complemento de pagos (o de otros complementos).
De acuerdo a la Wikipedia, un "namespace" o "espacio de nombres" es un contexto en el que un grupo de uno o más identificadores pueden existir. En términos generales podríamos decir que un namespace, es una forma de agrupar clases, funciones, tipos de datos, etc. que están relacionadas entre sí.
Para que te des una idea de lo que es un namespace, estas son las lineas que lo definen para un CFDI:
xmlns:cfdi="http://www.sat.gob.mx/cfd/3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.sat.gob.mx/cfd/3 http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv33.xsd"
En el caso del CFDI un "namespace" nos sirve para ubicar en internet la definción que establece las reglas de como debe de conformarse un CFDI en cualquiera de sus variantes.
Un namespace consta básicamente de 3 partes:
Si bien no existe una regla general que obligue a un namespace a colocarlo en alguna parte específica del XML, usualmente este se define en el punto donde sus reglas van a aplicarse, en el caso de un CFDI este lugar puede ser el nodo principal <cfdi:Comprobante> o bien cualquiera de sus subnodos en el caso de los complementos.
Algunos validadores de terceros requieren que los namespaces de los complementos usados en un CFDI se coloquen al nivel del nodo <cfdi:Comprobante> y no a nivel del nodo que define el complemento, que es como lo hace VirtualXML.
En todo caso, tu puedes editar manualmente el XML con cualquier editor de textos y mover los namespaces de la definición del complemento a la definción del nodo <cfdi:Comprobante> y no tendrá repercusión alguna ya que los namespaces no se utilizan para la generación de los sellos digitales por lo tanto pueden ir en cualquier parte del documento XML.
Debido a que entendemos que tener que editar un XML manualmente, mover namespaces y luego guardar el XML es un tarea tediosa, sobre todo si tienes muchos XMLs que requieran mover los namespaces, hemos desempolvado del baúl de los recuerdos de VirtualXML una función que hacía mucho tiempo no utilizabamos.:
Esta función, como su nombre lo indica te permitirá añadir un namespace directo en la definición de namespaces del nodo <cfdi:Comprobante>, solucionando con esto el problema de la ubicación que algunos validadores te pueden marcar.
Esta función NO MUEVE LOS NAMESPACES DE LUGAR, crea nuevos namespaces a la altura del nodo <cfdi:Comprobante> pero los namespaces definidos en los complementos se van a mantener, esta duplicidad de namespaces NO AFECTA LA INTEGRIDAD DEL XML, por lo que será timbrado sin problema por el PAC y reconocido por los validadores.
Sintaxis:
Donde:
<hHandle> Identificador en memoria devuelto por la función VirtualXML_New()
<cNombre> Cadena de caracteres con el nombre del namespace
<cUrl> Cadena de caracteres con el URL del namespace
<cSchemaLocation> Cadena de caracteres con la URL del archivo XSD que define la estructura del XML.
Ejemplo:
Supongamos que queremos poner los namespaces del Timbre Fiscal Digital y del complemento de pagos a nivel del nodo <cfdi:Comprobante>, haríamos lo siguiente:
nHandler := VirtualXML_New("3.3")
/* Agregamos el namespace del TFD */
VirtualXML_AddNameSpace(nHandler,;
"xmlns:tfd",;
"http://www.sat.gob.mx/TimbreFiscalDigital","http://www.sat.gob.mx/sitio_internet/cfd/TimbreFiscalDigital/TimbreFiscalDigitalv11.xsd")
/* Agregamos el namespace del Complemento de pagos*/
VirtualXML_AddNameSpace(nHandler,;
"xmlns:pago10",;
"http://www.sat.gob.mx/Pagos","http://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd")
Y de esta manera agregamos 2 namespaces nuevos dentro la definición del nodo <cfdi:Comprobante> y aunque estos se van a repetir cuando agreguemos los complementos correspondientes, no afectarán la integridad del XML.
¿ Hasta cuantos namespace puedo agregar usando esta función ? Todos los que tu quieras o consideres necesarios, si quieres agregar TODOS los namespaces de TODOS los complementos lo puedes hacer sin ningún problema.
Esperamos que esta función te solucione los problemas que alguno que otro validador de CFDI te pueda dar.
De acuerdo a la Wikipedia, un "namespace" o "espacio de nombres" es un contexto en el que un grupo de uno o más identificadores pueden existir. En términos generales podríamos decir que un namespace, es una forma de agrupar clases, funciones, tipos de datos, etc. que están relacionadas entre sí.
Para que te des una idea de lo que es un namespace, estas son las lineas que lo definen para un CFDI:
xmlns:cfdi="http://www.sat.gob.mx/cfd/3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.sat.gob.mx/cfd/3 http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv33.xsd"
En el caso del CFDI un "namespace" nos sirve para ubicar en internet la definción que establece las reglas de como debe de conformarse un CFDI en cualquiera de sus variantes.
Un namespace consta básicamente de 3 partes:
- Nombre del namespace
- URL en internet del namespace
- Schema Location, que es la ubicación del archivo XSD que define las reglas de conformación del XML.
Si bien no existe una regla general que obligue a un namespace a colocarlo en alguna parte específica del XML, usualmente este se define en el punto donde sus reglas van a aplicarse, en el caso de un CFDI este lugar puede ser el nodo principal <cfdi:Comprobante> o bien cualquiera de sus subnodos en el caso de los complementos.
Algunos validadores de terceros requieren que los namespaces de los complementos usados en un CFDI se coloquen al nivel del nodo <cfdi:Comprobante> y no a nivel del nodo que define el complemento, que es como lo hace VirtualXML.
En todo caso, tu puedes editar manualmente el XML con cualquier editor de textos y mover los namespaces de la definición del complemento a la definción del nodo <cfdi:Comprobante> y no tendrá repercusión alguna ya que los namespaces no se utilizan para la generación de los sellos digitales por lo tanto pueden ir en cualquier parte del documento XML.
Debido a que entendemos que tener que editar un XML manualmente, mover namespaces y luego guardar el XML es un tarea tediosa, sobre todo si tienes muchos XMLs que requieran mover los namespaces, hemos desempolvado del baúl de los recuerdos de VirtualXML una función que hacía mucho tiempo no utilizabamos.:
VirtualXML_AddNameSpace()
Esta función, como su nombre lo indica te permitirá añadir un namespace directo en la definición de namespaces del nodo <cfdi:Comprobante>, solucionando con esto el problema de la ubicación que algunos validadores te pueden marcar.
Esta función NO MUEVE LOS NAMESPACES DE LUGAR, crea nuevos namespaces a la altura del nodo <cfdi:Comprobante> pero los namespaces definidos en los complementos se van a mantener, esta duplicidad de namespaces NO AFECTA LA INTEGRIDAD DEL XML, por lo que será timbrado sin problema por el PAC y reconocido por los validadores.
Sintaxis:
VirtualXML_AddNameSpace (
<hHandle>,
<cNombre>,
<cUrl>,
<cSchemaLocation>)
Donde:
<hHandle> Identificador en memoria devuelto por la función VirtualXML_New()
<cNombre> Cadena de caracteres con el nombre del namespace
<cUrl> Cadena de caracteres con el URL del namespace
<cSchemaLocation> Cadena de caracteres con la URL del archivo XSD que define la estructura del XML.
Ejemplo:
Supongamos que queremos poner los namespaces del Timbre Fiscal Digital y del complemento de pagos a nivel del nodo <cfdi:Comprobante>, haríamos lo siguiente:
nHandler := VirtualXML_New("3.3")
/* Agregamos el namespace del TFD */
VirtualXML_AddNameSpace(nHandler,;
"xmlns:tfd",;
"http://www.sat.gob.mx/TimbreFiscalDigital","http://www.sat.gob.mx/sitio_internet/cfd/TimbreFiscalDigital/TimbreFiscalDigitalv11.xsd")
/* Agregamos el namespace del Complemento de pagos*/
VirtualXML_AddNameSpace(nHandler,;
"xmlns:pago10",;
"http://www.sat.gob.mx/Pagos","http://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd")
Y de esta manera agregamos 2 namespaces nuevos dentro la definición del nodo <cfdi:Comprobante> y aunque estos se van a repetir cuando agreguemos los complementos correspondientes, no afectarán la integridad del XML.
¿ Hasta cuantos namespace puedo agregar usando esta función ? Todos los que tu quieras o consideres necesarios, si quieres agregar TODOS los namespaces de TODOS los complementos lo puedes hacer sin ningún problema.
Esperamos que esta función te solucione los problemas que alguno que otro validador de CFDI te pueda dar.
lunes, 13 de agosto de 2018
(VirtualXML) Mas sobre el tema de las cancelaciones (Actualizado al dia 15 de Agosto 2018)
Estamos a unos días en que entren en vigencia los nuevos cambios en el esquema de cancelaciones del SAT, por lo que considero importante hacer un resumen de todo lo que sabemos hasta ahora para que puedan empezar a tomar medidas al respecto y comenzar a indicarles el funcionamiento de las nuevas funciones de cancelación de VitualXML.
Quiero agradecer a nuestro PAC principal DFacturE, por la información y las gráficas que nos ha facilitado para escribir este artículo.
Antes de empezar, revisemos como estamos realizando el proceso de cancelación actualmente, y lo hacemos según el siguiente diagrama:
Bajo el esquema actual un CFDI solo puede tener 2 estados: CANCELADO y VIGENTE; si un CFDI esta VIGENTE luego entonces es CANCELABLE y podemos proceder con una CANCELACION DIRECTA.
Sin embargo, el nuevo esquema de cancelación es un poco mas complejo como veremos mas adelante, pero antes de continuar, debemos saber CUANDO SI se pueden cancelar facturas sin necesidad de "autorización" por parte del receptor, sin importar el monto que ampare dicho comprobante.
Estos son los casos en los que se pueden cancelar los CFDI sin necesidad de una autorización por parte del receptor, ni del proceso de cancelación a través del Buzón Tributario:
Si el CFDI no se encuentra en los supuestos anteriores, o bien ya pasaron mas de 72 horas desde su emisión, para cancelarlos será necesario tomar en cuenta el nuevo esquema de cancelaciones, que gráficamente se presenta así:
Similarmente a como estabamos acostumbrados, el CFDI puede tener 2 estados: CANCELADO y VIGENTE, en el caso de los CFDIs vigentes, en el nuevo esquema de cancelaciones, estos pueden presentar 2 estados: CANCELABLE y NO CANCELABLE.
Para poder considerar un documento como CANCELABLE, este deberá ser de Ingreso, estar vigente, Y NO TENER DOCUMENTOS RELACIONADOS, esto último es muy importante, ya que si existen documentos relacionados al documento que se desea cancelar, el CFDI será NO CANCELABLE, para convertirlo en un CFDI CANCELABLE será necesario cancelar primero los documentos relacionados y posteriormente cancelar el documento original, SE VALIDARA LA EXISTENCIA DE DOCUMENTOS RELACIONADOS AL MOMENTO DE INTENTAR CANCELAR.
Si un documento es CANCELABLE, puede presentar 3 estados:
NO REQUIERE ACEPTACION, en este caso podemos proceder a cancelarlo directamente como lo habíamos venido haciendo hasta el dia de hoy, es decir mediante la función VirtualXML_CancelaUUID().
Un CFDI CON ACEPTACION requerirá realizar una solicitud de cancelación del mismo por 2 vías:
Una vez hecha la solicitud por cualquiera de los dos medios mencionados anteriormente, esta será enviada al SAT y el comprobante quedará en el estado de "OPERANDO", que es algo así como el limbo de los comprobantes fiscales, durante el plazo que indica el SAT para aceptar o cancelar el documento que es de 72 horas contadas a partir de la fecha de solicitud de la cancelación.
El estado del CFDI se podrá verificar desde código usando la función VirtualXML_ConsultaEstadoCFDI(), la cual ahora devolverá 3 posibles valores: VIGENTE, CANCELADO y OPERANDO.
Si el receptor ACEPTA la cancelación antes de 72 horas, el documento quedará automáticamente cancelado en los registros del SAT, y deberás utilizar la función de ConsultaEstadoCFDI() para saber si ya pasó del estado de OPERANDO al estado de CANCELADO.
Si después de las 72 horas el receptor explicitamente NO RECHAZA la solicitud de cancelación, el documento quedará cancelado en los registros del SAT y no habrá necesidad de hacer ningún otro procedimiento adicional, a este proceso se le llama "aceptación FICTA o aceptación por plazo vencido", esto minimiza en impacto que nuestros usuarios pudieran tener en sus sistemas, sin embargo, es su responsabilidad el estar revisando constantemente el estado del CFDI hasta que transcurran las 72 horas de plazo.
En caso de que el receptor RECHACE la cancelación del documento y el emisor vuelva a solicitarla, nuevamente tendrá el plazo de 72 horas para manifestarse al respecto, pero en este segundo intento de cancelación, si no hay respuesta por parte del receptor NO SE CANCELARA EL DOCUMENTO, a esto se le llama "rechazo FICTO".
En el caso de que existan documentos relacionados a un CFDI que se quiera cancelar, se deberá seguir el orden inverso para ir cancelado los documentos relacionados ANTES de cancelar el CFDI que los referencie.
Debemos de tener en cuenta que nuestros emisores estan en los dos lados, tanto necesitan cancelar CFDIs como autorizar la cancelación de CFDIs, por ello VirtualXml incluirá 5 funciones para realizar el proceso de cancelación, de momento estos son los PROTOTIPOS de las funciones, aun nos falta pulirlas, ver su lista de parámetros, probarlas e incluirlas en la DLL, NO SON FUNCIONALES NI ESTAN INCLUIDAS EN VIRTUALXML, así que por favor, no pidan documentación, parámetros ni área de pruebas hasta que les informemos que ya están implementadas y que ya hemos liberado una nueva versión de la DLL.
Serán 5 funciones para cancelación, divididas en 2 categorías:
Funciones para cancelar CFDI emitidos:
VirtualXML_ConsultaStatusCFDI() : esta función se utiliza para obtener el estado del CFDI antes de intentar cancelarlo y devolverá los siguientes valores:
Funciones para consultar las peticiones recibidas de emisores:
VirtualXML_ConsultaPeticionesPendientes(): Esta función se utiliza para obtener una lista de los UUID que estan pendientes de Autorizar/Rechazar solicitados por nuestros emisores, devuelve los sigientes valroes:
En los proximos días publicaremos mas información sobre estas funciones a fin de que puedan implementarlas en sus sistemas.
El SAT ha publicado un video donde podrán conocer mas a detalle aspectos relacionados con el nuevo esquema de cancelación:
Quiero agradecer a nuestro PAC principal DFacturE, por la información y las gráficas que nos ha facilitado para escribir este artículo.
Antes de empezar, revisemos como estamos realizando el proceso de cancelación actualmente, y lo hacemos según el siguiente diagrama:
Bajo el esquema actual un CFDI solo puede tener 2 estados: CANCELADO y VIGENTE; si un CFDI esta VIGENTE luego entonces es CANCELABLE y podemos proceder con una CANCELACION DIRECTA.
Sin embargo, el nuevo esquema de cancelación es un poco mas complejo como veremos mas adelante, pero antes de continuar, debemos saber CUANDO SI se pueden cancelar facturas sin necesidad de "autorización" por parte del receptor, sin importar el monto que ampare dicho comprobante.
Estos son los casos en los que se pueden cancelar los CFDI sin necesidad de una autorización por parte del receptor, ni del proceso de cancelación a través del Buzón Tributario:
- Comprobantes de cualquier tipo (I, E, N, P, T) y cualquier monto y que no hayan pasado mas de 72 horas desde su emisión.
- Comprobantes de Nomina, Egreso, Traslado, Pago y Retención, sin limite de monto ni tiempo.
- El comprobante emitido para contribuyente del Sector Primario.
- El comprobante emitido para contribuyente del Regimen de Incorporación Fiscal (RIF).
- El comprobante fue emitido por un integrante del Sistema Financiero (bancos)
- El comprobante de Ingreso con importe menor a $5,000.00 ANTES DE IMPUESTOS
- El comprobante de Ingreso emitido a través del portal "Mis Cuentas" de la página del SAT.
- El comprobante de Ingreso emitido al publico en general (Rfc generico: XAXX010101000)
- El comprobante de ingreso emitido al un cliente extranjero (Rfc genérico extranjero: XEXX010101000)
Si el CFDI no se encuentra en los supuestos anteriores, o bien ya pasaron mas de 72 horas desde su emisión, para cancelarlos será necesario tomar en cuenta el nuevo esquema de cancelaciones, que gráficamente se presenta así:
Similarmente a como estabamos acostumbrados, el CFDI puede tener 2 estados: CANCELADO y VIGENTE, en el caso de los CFDIs vigentes, en el nuevo esquema de cancelaciones, estos pueden presentar 2 estados: CANCELABLE y NO CANCELABLE.
Para poder considerar un documento como CANCELABLE, este deberá ser de Ingreso, estar vigente, Y NO TENER DOCUMENTOS RELACIONADOS, esto último es muy importante, ya que si existen documentos relacionados al documento que se desea cancelar, el CFDI será NO CANCELABLE, para convertirlo en un CFDI CANCELABLE será necesario cancelar primero los documentos relacionados y posteriormente cancelar el documento original, SE VALIDARA LA EXISTENCIA DE DOCUMENTOS RELACIONADOS AL MOMENTO DE INTENTAR CANCELAR.
Si un documento es CANCELABLE, puede presentar 3 estados:
NO REQUIERE ACEPTACION, en este caso podemos proceder a cancelarlo directamente como lo habíamos venido haciendo hasta el dia de hoy, es decir mediante la función VirtualXML_CancelaUUID().
Un CFDI CON ACEPTACION requerirá realizar una solicitud de cancelación del mismo por 2 vías:
- Buzón tributario del contribuyente en el portal del SAT
- A través de los servicios de un PAC.
Una vez hecha la solicitud por cualquiera de los dos medios mencionados anteriormente, esta será enviada al SAT y el comprobante quedará en el estado de "OPERANDO", que es algo así como el limbo de los comprobantes fiscales, durante el plazo que indica el SAT para aceptar o cancelar el documento que es de 72 horas contadas a partir de la fecha de solicitud de la cancelación.
El estado del CFDI se podrá verificar desde código usando la función VirtualXML_ConsultaEstadoCFDI(), la cual ahora devolverá 3 posibles valores: VIGENTE, CANCELADO y OPERANDO.
Si el receptor ACEPTA la cancelación antes de 72 horas, el documento quedará automáticamente cancelado en los registros del SAT, y deberás utilizar la función de ConsultaEstadoCFDI() para saber si ya pasó del estado de OPERANDO al estado de CANCELADO.
Si después de las 72 horas el receptor explicitamente NO RECHAZA la solicitud de cancelación, el documento quedará cancelado en los registros del SAT y no habrá necesidad de hacer ningún otro procedimiento adicional, a este proceso se le llama "aceptación FICTA o aceptación por plazo vencido", esto minimiza en impacto que nuestros usuarios pudieran tener en sus sistemas, sin embargo, es su responsabilidad el estar revisando constantemente el estado del CFDI hasta que transcurran las 72 horas de plazo.
En caso de que el receptor RECHACE la cancelación del documento y el emisor vuelva a solicitarla, nuevamente tendrá el plazo de 72 horas para manifestarse al respecto, pero en este segundo intento de cancelación, si no hay respuesta por parte del receptor NO SE CANCELARA EL DOCUMENTO, a esto se le llama "rechazo FICTO".
En el caso de que existan documentos relacionados a un CFDI que se quiera cancelar, se deberá seguir el orden inverso para ir cancelado los documentos relacionados ANTES de cancelar el CFDI que los referencie.
Debemos de tener en cuenta que nuestros emisores estan en los dos lados, tanto necesitan cancelar CFDIs como autorizar la cancelación de CFDIs, por ello VirtualXml incluirá 5 funciones para realizar el proceso de cancelación, de momento estos son los PROTOTIPOS de las funciones, aun nos falta pulirlas, ver su lista de parámetros, probarlas e incluirlas en la DLL, NO SON FUNCIONALES NI ESTAN INCLUIDAS EN VIRTUALXML, así que por favor, no pidan documentación, parámetros ni área de pruebas hasta que les informemos que ya están implementadas y que ya hemos liberado una nueva versión de la DLL.
Serán 5 funciones para cancelación, divididas en 2 categorías:
Funciones para cancelar CFDI emitidos:
VirtualXML_ConsultaStatusCFDI() : esta función se utiliza para obtener el estado del CFDI antes de intentar cancelarlo y devolverá los siguientes valores:
- Codigo: 201 Mensaje: Comprobante obtenido satisfactoriamente, Cancelable: Cancelable SIN aceptacion
- Codigo: 211 Mensaje: Comprogante obtenido satisfactoriamente, Cancelable: Cancelable CON aceptacion
- Codigo: 602 Mensaje: Comprobante no encontrado, Cancelable: No
aplica
- Codigo: 215 Mensaje: El UUID no cumple con la estructura
válida, Cancelable: No aplica
- Codigo: 201 Mensaje: UUID Correctamente cancelado
- Codigo: 211 Mensaje: UUID Cancelable con aceptacion
- Codigo: 221 Mensaje: El UUID enviado no tiene un formato valido
- Codigo: 205 Mensaje: El comprobante aun no se encuentra
reportado en el SAT
- Codigo:2000 Mensaje: Se encontraron CFDIs relacionados y un texto con la estructura "padre, UUID,RFCMISOR,RFCRECEPTOR", seguido del texto "hijo,UUID,RFCEMISOR,RFCRECEPTOR"
- Codigo:2001 Mensaje: No existen CFDI relacionados
Funciones para consultar las peticiones recibidas de emisores:
VirtualXML_ConsultaPeticionesPendientes(): Esta función se utiliza para obtener una lista de los UUID que estan pendientes de Autorizar/Rechazar solicitados por nuestros emisores, devuelve los sigientes valroes:
- Codigo: 1001 Mensaje: Una lista con los UUIDS pendientes de Autorizar/Rechazar, uno por renglon
- Codigo: 1101 Mensaje: No hay UUIDs pendientes de cancelar.
- Codigo: 1000, Mensaje: "UUID, Aceptado ó Rechazado" dependiendo si se autorizo o se rechazo la autorización
- Codigo: 1001, Mensaje: "UUID, Rechazado,No existen peticiones de cancelacion en espera"
En los proximos días publicaremos mas información sobre estas funciones a fin de que puedan implementarlas en sus sistemas.
El SAT ha publicado un video donde podrán conocer mas a detalle aspectos relacionados con el nuevo esquema de cancelación:
miércoles, 1 de agosto de 2018
(VXmlTools y CiberLine) el SAT libera servicio de descarga masiva de CFDI
Hago un paréntesis en la serie que veníamos trabajando sobre el complemento de pagos para hablar un poco de los "Descargadores" masivos de los CFDI de la página del SAT.
El día Lunes 30 de Julio de 2018, el SAT implemento un nuevo mecanismo de seguridad para evitar que programas como VXmlTools o CiberLine pudieran "hackear" la pagina del SAT para realizar la descarga masiva de los CFDI emitidos y recibidos.
Pues bien, el mismo día por la tarde, el SAT se dio cuenta de que el tráfico a la página de descargas de CFDI se volvió intratable ya que al no tener herramientas de descarga masivas, todos los contribuyentes que las usaban entraron al portal para realizar la descarga manualmente, lo cual ocasionó que el servicio de descargas presentara caídas y fallos, en pocas palabras, se volvió una locura el nuevo sitio de descargas.
En respuesta a lo anterior, el día de hoy recibimos por parte de uno de nuestros PACs asociados el siguiente comunicado del SAT:
Así pues, el día 6 de Agosto el SAT publicará los requisitos para el consumo del WebService de descarga masiva, a partir de ese día, integraremos en VXmlTools y en CiberLine la conexión al servicio WEB del SAT para realizar la descarga masiva, ahora de manera "legal".
Es importante recalcar que será necesario contar con los archivos CER y KEY de la E-Firma (o sea de la FIEL, FIrma ELectronica avanzada) actualizada para poder realizar la descarga masiva, ya que al clave CIEC de acceso ya no será reconocida como mecanismo de autenticación para el WebService.
Seguiremos informado por medio de nuestras redes sociales el avance de la modificación a nuestros productos de descarga.
El día Lunes 30 de Julio de 2018, el SAT implemento un nuevo mecanismo de seguridad para evitar que programas como VXmlTools o CiberLine pudieran "hackear" la pagina del SAT para realizar la descarga masiva de los CFDI emitidos y recibidos.
Pues bien, el mismo día por la tarde, el SAT se dio cuenta de que el tráfico a la página de descargas de CFDI se volvió intratable ya que al no tener herramientas de descarga masivas, todos los contribuyentes que las usaban entraron al portal para realizar la descarga manualmente, lo cual ocasionó que el servicio de descargas presentara caídas y fallos, en pocas palabras, se volvió una locura el nuevo sitio de descargas.
En respuesta a lo anterior, el día de hoy recibimos por parte de uno de nuestros PACs asociados el siguiente comunicado del SAT:
Así pues, el día 6 de Agosto el SAT publicará los requisitos para el consumo del WebService de descarga masiva, a partir de ese día, integraremos en VXmlTools y en CiberLine la conexión al servicio WEB del SAT para realizar la descarga masiva, ahora de manera "legal".
Es importante recalcar que será necesario contar con los archivos CER y KEY de la E-Firma (o sea de la FIEL, FIrma ELectronica avanzada) actualizada para poder realizar la descarga masiva, ya que al clave CIEC de acceso ya no será reconocida como mecanismo de autenticación para el WebService.
Seguiremos informado por medio de nuestras redes sociales el avance de la modificación a nuestros productos de descarga.
viernes, 6 de julio de 2018
(VirtualXML) Todo lo que necesitas saber sobre el Complemento de Pagos 1.0 (Parte 3 de 4)
Como lo hemos comentado en nuestros 2 artículos anteriores, en esta entrega trataremos un tema delicado y laborioso, por eso tiene un capítulo por separado.
Antes de empezar a tratar este tema, que es largo y complejo, tenemos que aclarar que hasta el momento de escribir estos artículos, todo lo relacionado con información bancaria y por lo tanto lo mencionado en esta entrega está marcado como OPCIONAL en la descripción del CFDI con complemento de Pagos.
Esto quiere decir que en este momento y hasta nuevo aviso del SAT, estamos en libertad de usar o no usar la información que presentamos a continuación dentro de nuestro REP, sin embargo, no dudamos que muy pronto, quizá cuando entre en vigor oficialmente el REP el día 1 de Septiembre, la información que en este momento está marcada como opcional se vuelva obligatoria, por lo tanto les recomendamos que por favor lean este artículo hasta el final, y después decidan si implementan esta parte o la dejan para un futuro.
En este artículo hablaremos de los SPEIs y la forma en que tenemos que reportarlos dentro del Recibo Electrónico de Pagos, y tiene su propio artículo porque es una labor muy detalla reportar un SPEI en un complemento de pagos.
Comencemos por hablar un poco del SPEI.
SPEI son la iniciales del Sistema de Pagos Electrónicos Interbancarios, es un estandar establecido por el Banco de México, (Banxico) para aplicar transferencias de fondos banco a banco el mismo día y en cuestión de minutos e incluso segundos.
Los SPEI son mas eficientes que un depósito en efectivo, mas seguros (ejem, ejem) y proveen de una forma mas rápida de intercambiar fondos entre bancos y cuenta habientes.
Básicamente en un SPEI, sale dinero de una cuenta del Banco A y se deposita en una cuenta del Banco B, el principio es muy simple, pero aquí es donde entra en acción la mano de hierro del SAT para controlar los SPEIs.
Para dar fe y legalidad de un SPEI, el SAT solicita al Banco A que elabore un CFDI de Egreso a favor del Banco B, con esta operación el SAT tiene certidumbre de que hay un traspaso de fondos entre los dos bancos, pero......
Si se tiene que emitir un CFDI de Egreso con el Banco A como emisor y el Banco B como receptor, este se convierte en un CFDI de Ingreso para el Banco B ¿ cierto ?, es correcto.
Si esta operación se quedara como la hemos descrito, entonces el Banco A tendría un montón de gastos y el Banco B un montón de ingresos, que a su vez se compensarían por los CFDIs de Egreso que el Banco B tiene que emitir a favor del Banco A, y así sucesivamente hasta el infinito.
Solo para darnos una idea de la cantidad de CFDIs que vinculan las operaciones SPEI y los estados de cuenta bancarios, debes saber que existe una empresa que es el mayor PAC privado de México, esta empresa se llama CeCoBan, S.A.de C.V. CeCoBan son las iniciales de Centro de Compensación Bancaría, y es lo que conocemos como "cámara de compensación", es una empresa cuyos socios son la mayoría de los bancos que operan en México y que se encarga de la compensación de fondos entre ellos.
Pues bien además de ser la "cámara de compensación", CeCoBan es el PAC que mas CFDIs ha timbrado desde que existe el modelo de Comprobante Fiscal Digital por Internet, hasta Marzo del 2018, CeCoBan llevaba emitidos mas de 4,000,000,000 (sí, leiste bien, no me sobraron ceros: cuatro mil millones de CFDIs).
CeCoBan, S.A. de C.V. es la empresa que timbra todos los CFDIs emitidos por concepto de SPEI para la mayoría de los bancos que operan en el país, excepto aquellos que son PACs por sí mismos como BBVA Bancomer, Banorte y BanBajio, que se timbran sus propios documentos.
Si quieres tener mas información con respecto a que PAC timbra mas y cual timbra menos, puedes descargar este documento que es la estadística de facturas timbradas por proveedor de certificación publicada por el SAT semestralmente.
Pero continuemos con el tema de los SPEIs, de los cuatro mil millones de CFDIs ¿ Cuantos corresponderán a SPEIs unicamente ?, seguramente mas de tres mil millones, y de esos tres mil millones ¿ cuantos corresponderán a SPEIs por pagos a proveedores ?, seamos conservadores y pensemos que la mitad, eso nos deja en la cantidad de 1,500 millones de CFDIs que se realizan por concepto de pagos a proveedores, pero tranquilidad, los 1,500 millones se han hecho en 7 años, asi que si dividimos entre 7 los 1,500 millones nos quedan mas o menos 215 millones de CFDIs emitidos anualmente por concepto de SPEIs que representarían pagos a proveedores por concepto de facturas. Eso quiere decir que en cuanto el CFDI con complemento de pagos entre en vigor obligatoriamente, el dia 1 de Septiembre, anualmente tendremos que hacer mas de 215 millones de CFDIs adicionales, que divididos entre los 80 proveedores autorizados que existen nos da que a cada PAC le toca emitir 2,687,500 CFDIs adicionales por año..... no es una mala cifra ¿ no ?
Bien regresemos al SPEI y a la parte que nos interesa que es... ¿ Como juega el SPEI para el Recibo Electrónico de Pago ?.
Pues bien, para evitar que los CFDIs que se intercambian entre los bancos por motivo los SPEIs sean considerados comprobantes de Ingresos por un lado y comprobantes de Egresos por el otro, el SAT obliga a los participantes del SPEI a agregar un complemento especial dentro de los CFDIs que se intercambian y que se llama Complemento SPEI de Tercero a Tercero.
Este complemento SPEI de tercero a tercero, contiene información detallada sobre la naturaleza del CFDI que se emite, que evita que sea considerado un Ingreso y/o un Egreso fiscalmente hablando por parte de los bancos y contiene importante información que será necesaria para el llenado del REP, de hecho, con solo la información contenida en el complemento SPEI de Tercero a Tercero puedes llenar perfectamente un REP.
¿ Que datos contiene el SPEI de Tercero a Tercero ?
El complemento SPEI de tercero a tercero es una estructura en formato XML que contiene la siguiente información:
Revisemos que datos tenemos:
Adicionalmente tenemos 2 nodos mas dentro del XML que también necesitaremos para el correcto llenado del REP:
El primero tenemos los datos del ordenante del SPEI:
Los datos que contiene son:
Los datos que contiene son:
La pregunta que puede surgir ahora es.... ¿ de donde saco los SPEIs de Tercero a Tercero para incluirlos en mi REP ?
En el sistema bancario, el SPEI de tercero a tercero es conocido con otro nombre que es: Comprobante Electrónico de Pago, o CEP por sus iniciales.
¿ De donde lo obtengo ?
Con en la entrada en vigor del CFDI 3.3 en Enero de 2018, muchos bancos han incluido en sus portales la capacidad de proporcionarte los CEPs desde el mismo portal bancario, en nuestra experiencia propia, Banamex y Banorte ya te ofrecen facilidades para que puedas descargar tu CEP desde sus portales:
En las imagenes anteriores he marcado con rojo los links para descargar los CEPs y con verde un dato muy importante llamado "Clave de Rastreo", volveremos a ella un poco mas adelante en este artículo.
Si tu haces click en alguno de los links que te ofrecen los portales de los bancos, estos te llevarán a una página del Banco de México (Banxico) desde donde se podrán descargar INDIVIDUALMENTE los CEPs.
¿ Qué papel juega Banxico en el tema SPEI y CEP ?
Banxico juega un papel muy importante, porque los complementos SPEI de tercero a tercero, también conocidos como CEPs, se almacenan en los registros de Banxico, digamos que el Banco de México es algo así como el SAT para los CFDIs pero de los CEPs.
Banxico almacenará durante 45 días hábiles bancarios tus CEPs y podrás descargalos de 3 maneras distintas:
¿ Que pasa si por alguna razón la liga que me da mi banco no funciona, o quiero descargar yo mismo mi CEP ?
Para eso tenemos la segunda manera de descargar un CEP ya que Banxico te proporciona una página para que tu puedas manualmente descargarlos uno por uno:
Esta página te pide los siguientes datos para poder obtener tu CEP:
El dato mas importante aquí es la CLAVE DE RASTREO, este número, generado por el banco emisor, es el equivalente del UUID del CFDI pero aplicable a un CEP, para validar que el interesado es quien está obteniendo el CEP, el Banxico utiliza la CLABE de la cuenta receptora y el monto para asegurarse de alguna manera que quien está recuperando el CEP es realmente el interesado, aunque cualquiera que conozca estos datos podría descargar cualquier CEP.
En nuestro Canal de YouTube, he puesto un video tutorial que te guiará paso a paso en el proceso de descarga individual de los CEPs desde la página de Banxico:
Ya hemos visto 2 maneras de descargar los CEPs de Banxico, pero ¿ Que pasa si tu tienes un montón de SPEIs, de distintos bancos y de distintas cuentas ?, descargarlos individualmente es una tarea de romanos por lo que Banxico, pensando en la comodidad del usuario, tiene también una página que te permite hacer una descarga masiva de tus SPEIs de una manera muy simple mediante un archivo de texto que tienes que subir a la siguiente página:
Para descargar masivamente tus CEPs desde esta página, deberás hacer un archivo de texto que contenga los mismos datos básicos que usaste para la consulta individual, con algunas modificaciones, los datos deberán ir separados por ",".:
2018-06-15,BNET0100180615000281097,40021,40012,2180065145757870,1276.00
2018-06-14,BB2322013043,40052,40030,218006514575787,350.00
2018-06-28,HSBC078234,40021,40052,2180065145757870,1276.00
2018-06-01,357439551,40044,40052,2180065145757870,2465.00
2018-06-01,7875PAB201806010595041932,40072,40052,218006051005757870,16762.00
2018-06-01,208060140014HDH0000460909070,40014,40052,218006051005757870,63800.00
2018-06-01,201806140014BMOV0000460038060,40014,40052,218006051005757870,4930.00
2018-06-13,8502CAP421806130599180826,40072,40052,218006051005757870,1276.00
2018-06-04,8502CAP201806040595760992,40072,40052,218006051005757870,1276.00
2018-06-04,BB4511208237,40030,40052,218006051005757870,3944.00
2018-06-05,BB5838608401,40030,40052,218006051005757870,7888.00
2018-06-12,MBAN1001806120003760245,40012,40052,218006051005757870,250.00
2018-06-05,BNET1001806050001533473,40012,40052,218006051005757870,1276.00
2018-06-01,BB5675008412,40030,40052,218006051005757870,5950.00
2018-06-14,BB2322013043,40030,40052,218006051005757870,319.00
2018-06-15,BNE01001806150002810974,40012,40052,218006051005757870,1276.00
2018-06-27,357496937,40044,40052,218006051005757870,829.40
2018-06-22,8846CAP301806220602994381,40072,40052,218006051005757870,1276.00
2018-06-26,036INBU606201834756340,40036,40052,218006051005757870,36917.00
2018-06-13,MBAN011806130003896842,40012,40052,218006051005757870,69.00
2018-06-13,MBAN010006130003896541,40012,40052,218006051005757870,69.00
2018-06-12,MBAN010018020003760945,40012,40052,218006051005757870,250.00
Deberás subir un archivo de texto similar a este en estructura por medio de la página mencionada anterioremente, y la ventaja es que puedes obtener inmediatamente el resultado, no hay necesidad de esperar nada de tiempo, los resultados los obtienes inmediatamente.
Banxico te responderá con un archivo .ZIP que contendrá los XMLs y los PDFs solicitados, junto con un archivo de texto que contiene los resultados de la operación.
Hemos creado un video tutorial que encontrarás en nuestro Canal de YouTube que te explica detalladamente el proceso de descarga masiva de los CEPs:
Todo bien hasta aquí, ya tenemos todos los CEPs descargados y como ya analizamos, en cada CEP tenemos la información necesaria para el correcto llenado del REP, ¿ en donde encajan todas las piezas ?
Todas las piezas encajan en la función VirtualXML_Pagos10SetPago() que muestra la siguiente sintaxis
He resaltado los 4 últimos parámetros porque es aquí donde va la información por la cual hemos descargado el CEP de Banxico.
Estos 4 datos son:
Para finalizar este artículo, hablemos ahora de como obtener una cadena de texto en Base64 a partir de un archivo .CER, para hacer esto VirtualXML tiene integrada la función:
Su uso es muy sencillo:
Para ello es necesario que previamente hayas descargado desde la pagina del SAT el certificado cuyo número aparece en el REP y lo tengas en el disco duro de tu computadora.
Esta función devuelve una cadena de caracteres similar a esta, que es el valor del archivo .CER experesado como un texto en Base64:
"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"
También la puedes usar "anidada" dentro de la llamada a la funcion VirtualXML_Pagos10SetPago(), a continuación aprovecho para mostrarte como quedaría a la llamada a la función con todos los parámetros obtenidos del CEP del 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
VirtualXML_CerTo64("c:\carpeta\archivo.cer");// 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
)
Como verás el manejo de los SPEIs para el complemento de pago es un tema laborioso, se requiere programación extra para integrar los CEPs a nuestros programas y de ahí aplicarlos como REPs a las facturas pendientes de pago.
Supongo que hasta este punto, debes tener un montón de dudas en las cabeza, es por eso que la cuarta entrega la demoraremos ya que queremos incluir todas las dudas que vayas teniendo en un solo artículo.
Puedes plantearnos tus dudas en los comentarios de estos artículos y nosotros las iremos colectando para integrarlas dentro del artículo final de esta serie.
También te recordamos que estaremos ofreciendo un curso especial del Complemento de Pagos todos los jueves y viernes de Julio y Agosto a fin de que puedas aclarar tus dudas directamente con nosotros, puedes pedir informes sobre horarios y precio a los teléfonos (55) 5560 0168 y (55) 5373 6404 o bien en el correo electrónico info@ciber-tec.com.
Te invitamos a suscribirte a nuestro Canal de YouTube porque pronto tendremos mas videotutoriales sobre el uso de nuestras herramientas y mucho contenido mas.
Antes de empezar a tratar este tema, que es largo y complejo, tenemos que aclarar que hasta el momento de escribir estos artículos, todo lo relacionado con información bancaria y por lo tanto lo mencionado en esta entrega está marcado como OPCIONAL en la descripción del CFDI con complemento de Pagos.
Esto quiere decir que en este momento y hasta nuevo aviso del SAT, estamos en libertad de usar o no usar la información que presentamos a continuación dentro de nuestro REP, sin embargo, no dudamos que muy pronto, quizá cuando entre en vigor oficialmente el REP el día 1 de Septiembre, la información que en este momento está marcada como opcional se vuelva obligatoria, por lo tanto les recomendamos que por favor lean este artículo hasta el final, y después decidan si implementan esta parte o la dejan para un futuro.
En este artículo hablaremos de los SPEIs y la forma en que tenemos que reportarlos dentro del Recibo Electrónico de Pagos, y tiene su propio artículo porque es una labor muy detalla reportar un SPEI en un complemento de pagos.
Comencemos por hablar un poco del SPEI.
SPEI son la iniciales del Sistema de Pagos Electrónicos Interbancarios, es un estandar establecido por el Banco de México, (Banxico) para aplicar transferencias de fondos banco a banco el mismo día y en cuestión de minutos e incluso segundos.
Los SPEI son mas eficientes que un depósito en efectivo, mas seguros (ejem, ejem) y proveen de una forma mas rápida de intercambiar fondos entre bancos y cuenta habientes.
Básicamente en un SPEI, sale dinero de una cuenta del Banco A y se deposita en una cuenta del Banco B, el principio es muy simple, pero aquí es donde entra en acción la mano de hierro del SAT para controlar los SPEIs.
Para dar fe y legalidad de un SPEI, el SAT solicita al Banco A que elabore un CFDI de Egreso a favor del Banco B, con esta operación el SAT tiene certidumbre de que hay un traspaso de fondos entre los dos bancos, pero......
Si se tiene que emitir un CFDI de Egreso con el Banco A como emisor y el Banco B como receptor, este se convierte en un CFDI de Ingreso para el Banco B ¿ cierto ?, es correcto.
Si esta operación se quedara como la hemos descrito, entonces el Banco A tendría un montón de gastos y el Banco B un montón de ingresos, que a su vez se compensarían por los CFDIs de Egreso que el Banco B tiene que emitir a favor del Banco A, y así sucesivamente hasta el infinito.
Solo para darnos una idea de la cantidad de CFDIs que vinculan las operaciones SPEI y los estados de cuenta bancarios, debes saber que existe una empresa que es el mayor PAC privado de México, esta empresa se llama CeCoBan, S.A.de C.V. CeCoBan son las iniciales de Centro de Compensación Bancaría, y es lo que conocemos como "cámara de compensación", es una empresa cuyos socios son la mayoría de los bancos que operan en México y que se encarga de la compensación de fondos entre ellos.
Pues bien además de ser la "cámara de compensación", CeCoBan es el PAC que mas CFDIs ha timbrado desde que existe el modelo de Comprobante Fiscal Digital por Internet, hasta Marzo del 2018, CeCoBan llevaba emitidos mas de 4,000,000,000 (sí, leiste bien, no me sobraron ceros: cuatro mil millones de CFDIs).
CeCoBan, S.A. de C.V. es la empresa que timbra todos los CFDIs emitidos por concepto de SPEI para la mayoría de los bancos que operan en el país, excepto aquellos que son PACs por sí mismos como BBVA Bancomer, Banorte y BanBajio, que se timbran sus propios documentos.
Si quieres tener mas información con respecto a que PAC timbra mas y cual timbra menos, puedes descargar este documento que es la estadística de facturas timbradas por proveedor de certificación publicada por el SAT semestralmente.
Pero continuemos con el tema de los SPEIs, de los cuatro mil millones de CFDIs ¿ Cuantos corresponderán a SPEIs unicamente ?, seguramente mas de tres mil millones, y de esos tres mil millones ¿ cuantos corresponderán a SPEIs por pagos a proveedores ?, seamos conservadores y pensemos que la mitad, eso nos deja en la cantidad de 1,500 millones de CFDIs que se realizan por concepto de pagos a proveedores, pero tranquilidad, los 1,500 millones se han hecho en 7 años, asi que si dividimos entre 7 los 1,500 millones nos quedan mas o menos 215 millones de CFDIs emitidos anualmente por concepto de SPEIs que representarían pagos a proveedores por concepto de facturas. Eso quiere decir que en cuanto el CFDI con complemento de pagos entre en vigor obligatoriamente, el dia 1 de Septiembre, anualmente tendremos que hacer mas de 215 millones de CFDIs adicionales, que divididos entre los 80 proveedores autorizados que existen nos da que a cada PAC le toca emitir 2,687,500 CFDIs adicionales por año..... no es una mala cifra ¿ no ?
Bien regresemos al SPEI y a la parte que nos interesa que es... ¿ Como juega el SPEI para el Recibo Electrónico de Pago ?.
Pues bien, para evitar que los CFDIs que se intercambian entre los bancos por motivo los SPEIs sean considerados comprobantes de Ingresos por un lado y comprobantes de Egresos por el otro, el SAT obliga a los participantes del SPEI a agregar un complemento especial dentro de los CFDIs que se intercambian y que se llama Complemento SPEI de Tercero a Tercero.
Este complemento SPEI de tercero a tercero, contiene información detallada sobre la naturaleza del CFDI que se emite, que evita que sea considerado un Ingreso y/o un Egreso fiscalmente hablando por parte de los bancos y contiene importante información que será necesaria para el llenado del REP, de hecho, con solo la información contenida en el complemento SPEI de Tercero a Tercero puedes llenar perfectamente un REP.
¿ Que datos contiene el SPEI de Tercero a Tercero ?
El complemento SPEI de tercero a tercero es una estructura en formato XML que contiene la siguiente información:
Revisemos que datos tenemos:
- Fecha de la operación, necesario para el REP
- Hora de la operación, necesario para el REP
- Clave SPEI, NO es necesario para el REP
- Sello es necesario para el REP
- Numero de certificado es necesario para descargar un archivo .CER del SAT para posteriormente incluirlo en el REP
- Cadena CDA, necesaria para el REP
Adicionalmente tenemos 2 nodos mas dentro del XML que también necesitaremos para el correcto llenado del REP:
El primero tenemos los datos del ordenante del SPEI:
Los datos que contiene son:
- Nombre del banco emisor, lo necesitaremos porque el REP lleva el RFC del banco del cual salen los fondos, aquí viene el nombre del banco, si quieres conocer su RFC, utiliza nuestra herramienta CiberCAT para obtener el RFC del banco.
- Nombre o razón social de quien ordena el envío, lo necesitaremos en el REP para el nombre del emisor, aunque este es un dato opcional
- Tipo de cuenta, NO es necesaria para el REP
- Cuenta es necesaria para el REP y la ventaja es que ya viene en formato CLABE
- RFC del ordenante, que necesitaremos para incluirlo en la información del emisor del REP.
- Banco Receptor, es el nombre del banco y lo necesitaremos en el REP para agregar el RFC del banco receptor, si quieres consultar los RFCs de todos los bancos del sistema bancario mexicano nuevamente te sugerimos utilizar nuestra herramienta CiberCAT
- Nombre: de la persona fisica o moral receptora del SPEI, se necesita para el REP aunque su uso es opcional
- Tipo Cuenta: NO es necesario para el REP
- Cuenta: al igual que la anterior, es necesaria para el REP y ya viene en formato CLABE
- RFC del receptor del SPEI, necesario para el REP
- Concepto: Concepto del SPEI, NO es necesario para el REP
- IVA: Importe del IVA, es opcional y NO es necesario para el REP
- Monto del Pago: es MUY necesario para el REP.
La pregunta que puede surgir ahora es.... ¿ de donde saco los SPEIs de Tercero a Tercero para incluirlos en mi REP ?
En el sistema bancario, el SPEI de tercero a tercero es conocido con otro nombre que es: Comprobante Electrónico de Pago, o CEP por sus iniciales.
¿ De donde lo obtengo ?
Con en la entrada en vigor del CFDI 3.3 en Enero de 2018, muchos bancos han incluido en sus portales la capacidad de proporcionarte los CEPs desde el mismo portal bancario, en nuestra experiencia propia, Banamex y Banorte ya te ofrecen facilidades para que puedas descargar tu CEP desde sus portales:
En las imagenes anteriores he marcado con rojo los links para descargar los CEPs y con verde un dato muy importante llamado "Clave de Rastreo", volveremos a ella un poco mas adelante en este artículo.
Si tu haces click en alguno de los links que te ofrecen los portales de los bancos, estos te llevarán a una página del Banco de México (Banxico) desde donde se podrán descargar INDIVIDUALMENTE los CEPs.
¿ Qué papel juega Banxico en el tema SPEI y CEP ?
Banxico juega un papel muy importante, porque los complementos SPEI de tercero a tercero, también conocidos como CEPs, se almacenan en los registros de Banxico, digamos que el Banco de México es algo así como el SAT para los CFDIs pero de los CEPs.
Banxico almacenará durante 45 días hábiles bancarios tus CEPs y podrás descargalos de 3 maneras distintas:
- Por medio del link que te proporcione cada banco
- Individualmente por medio de la misma página que Banxico ha dispuesto para tal fin
- Masivamente desde otra página dentro del mismo Banxico.
¿ Que pasa si por alguna razón la liga que me da mi banco no funciona, o quiero descargar yo mismo mi CEP ?
Para eso tenemos la segunda manera de descargar un CEP ya que Banxico te proporciona una página para que tu puedas manualmente descargarlos uno por uno:
Esta página te pide los siguientes datos para poder obtener tu CEP:
- Fecha en que se realizó el SPEI
- CLAVE DE RASTREO, ¿ te acuerdas que en las imágenes de los portales bancarios marqué con verde la clave de rastreo ?, aquí es donde se utiliza.
- Los bancos participantes en el SPEI, el banco de origen y el banco de destino
- La cuenta en formato CLABE donde se ingresaron los fondos
- El monto del pago.
El dato mas importante aquí es la CLAVE DE RASTREO, este número, generado por el banco emisor, es el equivalente del UUID del CFDI pero aplicable a un CEP, para validar que el interesado es quien está obteniendo el CEP, el Banxico utiliza la CLABE de la cuenta receptora y el monto para asegurarse de alguna manera que quien está recuperando el CEP es realmente el interesado, aunque cualquiera que conozca estos datos podría descargar cualquier CEP.
En nuestro Canal de YouTube, he puesto un video tutorial que te guiará paso a paso en el proceso de descarga individual de los CEPs desde la página de Banxico:
Ya hemos visto 2 maneras de descargar los CEPs de Banxico, pero ¿ Que pasa si tu tienes un montón de SPEIs, de distintos bancos y de distintas cuentas ?, descargarlos individualmente es una tarea de romanos por lo que Banxico, pensando en la comodidad del usuario, tiene también una página que te permite hacer una descarga masiva de tus SPEIs de una manera muy simple mediante un archivo de texto que tienes que subir a la siguiente página:
Para descargar masivamente tus CEPs desde esta página, deberás hacer un archivo de texto que contenga los mismos datos básicos que usaste para la consulta individual, con algunas modificaciones, los datos deberán ir separados por ",".:
- Fecha de la operación en formato AAAA-MM-DD
- CLAVE DE RASTREO (sí, otra vez)
- Claves BANXICO de los bancos emisores y receptores..... ¿ donde están las claves Banxico ?, que por cierto NO SON las claves que vienen en los catálogos del SAT. Las Claves Banxico se puden consultar con nuestra herramienta CiberCAT.
- Cuenta CLABE del beneficiario
- Monto de la operación.
2018-06-15,BNET0100180615000281097,40021,40012,2180065145757870,1276.00
2018-06-14,BB2322013043,40052,40030,218006514575787,350.00
2018-06-28,HSBC078234,40021,40052,2180065145757870,1276.00
2018-06-01,357439551,40044,40052,2180065145757870,2465.00
2018-06-01,7875PAB201806010595041932,40072,40052,218006051005757870,16762.00
2018-06-01,208060140014HDH0000460909070,40014,40052,218006051005757870,63800.00
2018-06-01,201806140014BMOV0000460038060,40014,40052,218006051005757870,4930.00
2018-06-13,8502CAP421806130599180826,40072,40052,218006051005757870,1276.00
2018-06-04,8502CAP201806040595760992,40072,40052,218006051005757870,1276.00
2018-06-04,BB4511208237,40030,40052,218006051005757870,3944.00
2018-06-05,BB5838608401,40030,40052,218006051005757870,7888.00
2018-06-12,MBAN1001806120003760245,40012,40052,218006051005757870,250.00
2018-06-05,BNET1001806050001533473,40012,40052,218006051005757870,1276.00
2018-06-01,BB5675008412,40030,40052,218006051005757870,5950.00
2018-06-14,BB2322013043,40030,40052,218006051005757870,319.00
2018-06-15,BNE01001806150002810974,40012,40052,218006051005757870,1276.00
2018-06-27,357496937,40044,40052,218006051005757870,829.40
2018-06-22,8846CAP301806220602994381,40072,40052,218006051005757870,1276.00
2018-06-26,036INBU606201834756340,40036,40052,218006051005757870,36917.00
2018-06-13,MBAN011806130003896842,40012,40052,218006051005757870,69.00
2018-06-13,MBAN010006130003896541,40012,40052,218006051005757870,69.00
2018-06-12,MBAN010018020003760945,40012,40052,218006051005757870,250.00
Deberás subir un archivo de texto similar a este en estructura por medio de la página mencionada anterioremente, y la ventaja es que puedes obtener inmediatamente el resultado, no hay necesidad de esperar nada de tiempo, los resultados los obtienes inmediatamente.
Banxico te responderá con un archivo .ZIP que contendrá los XMLs y los PDFs solicitados, junto con un archivo de texto que contiene los resultados de la operación.
Hemos creado un video tutorial que encontrarás en nuestro Canal de YouTube que te explica detalladamente el proceso de descarga masiva de los CEPs:
Todo bien hasta aquí, ya tenemos todos los CEPs descargados y como ya analizamos, en cada CEP tenemos la información necesaria para el correcto llenado del REP, ¿ en donde encajan todas las piezas ?
Todas las piezas encajan en la función VirtualXML_Pagos10SetPago() que muestra la siguiente sintaxis
VirtualXML_Pagos10SetPago( int p, string FechaPago, string FormaDePagoP, string MonedaP, string TipoCambioP, string Monto, string NumOperacion, string RfcEmisorCtaOrd, string NomBancoOrdExt, string CtaOrdenante, string RfcEmisorCtaBen, string CtaBeneficiario,
string TipoCadPago,
string CertPago,
string CadPago,
string SelloPago,
)
He resaltado los 4 últimos parámetros porque es aquí donde va la información por la cual hemos descargado el CEP de Banxico.
Estos 4 datos son:
- Tipo de Cadena de pago, este dato se obtiene de los catálogos publicados por el SAT para el CFDI con complemento de pago y solo contiene un valor que es "01", este dato tendremos que incluirlo cuando el pago sea realizado por medio de un SPEI, y el hecho de utilizar este parámeto hace OBLIGATORIOS LOS SIGUIENTES 3.
- Certificado de Pago, en la descripción del complemento de pago, indica que este valor tiene que llevar el archivo .CER con el que se firmó el CEP expresado como un texto en Base64, dentro del XML del CEP encontraremos unicamente EL NUMERO DE CERTIFICADO, con este numero, tendremos que ir a la página del SAT para descargas de certificados (https://portalsat.plataforma.sat.gob.mx/RecuperacionDeCertificados/) y recuperar el archivo .CER con el cual se firmó el CEP, mas adelante explicaré como obtener el texto en Base64 a partir del archivo.CER
- Cadena de Pago: es un atributo que viene dentro del CEP y esta identificado en el XML como CadenaCDA.
- Sello Pago: es un atributo que viene dentro del CEP y esta identificado simplemente como Sello dentro del XML del CEP.
Su uso es muy sencillo:
cCertificado := VirtualXML_CerTo64("disco:\directorio\archivo.cer")
Para ello es necesario que previamente hayas descargado desde la pagina del SAT el certificado cuyo número aparece en el REP y lo tengas en el disco duro de tu computadora.
Esta función devuelve una cadena de caracteres similar a esta, que es el valor del archivo .CER experesado como un texto en Base64:
"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"
También la puedes usar "anidada" dentro de la llamada a la funcion VirtualXML_Pagos10SetPago(), a continuación aprovecho para mostrarte como quedaría a la llamada a la función con todos los parámetros obtenidos del CEP del 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
VirtualXML_CerTo64("c:\carpeta\archivo.cer");// 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
)
Como verás el manejo de los SPEIs para el complemento de pago es un tema laborioso, se requiere programación extra para integrar los CEPs a nuestros programas y de ahí aplicarlos como REPs a las facturas pendientes de pago.
Supongo que hasta este punto, debes tener un montón de dudas en las cabeza, es por eso que la cuarta entrega la demoraremos ya que queremos incluir todas las dudas que vayas teniendo en un solo artículo.
Puedes plantearnos tus dudas en los comentarios de estos artículos y nosotros las iremos colectando para integrarlas dentro del artículo final de esta serie.
También te recordamos que estaremos ofreciendo un curso especial del Complemento de Pagos todos los jueves y viernes de Julio y Agosto a fin de que puedas aclarar tus dudas directamente con nosotros, puedes pedir informes sobre horarios y precio a los teléfonos (55) 5560 0168 y (55) 5373 6404 o bien en el correo electrónico info@ciber-tec.com.
Te invitamos a suscribirte a nuestro Canal de YouTube porque pronto tendremos mas videotutoriales sobre el uso de nuestras herramientas y mucho contenido mas.
jueves, 5 de julio de 2018
(VirtualXML) Todo lo que necesitas saber sobre el Complemento de Pagos 1.0 (parte 2 de 4)
En esta segunda entrega de nuestra serie de 4 artículos, hablaremos sobre las funciones que incluye VirtualXML para el llenado del Recibo Electrónico de pago (REP) también conocido como CFDI con Complemento de Pagos, o Factura de recepción de pagos.
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:
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:
Y ahora la información general del CFDI, es decir la información del nodo <cfdi:Comprobante>:
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:
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:
)
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:
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:
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:
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:
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:
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:
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:
¿ 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:
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:
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
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
Suscribirse a:
Entradas (Atom)