Buscar en este blog

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.
Es muy importante recordarles que el uso de esta función tiene costo de 1 timbre fiscal por UUID consultado, el cual se cobrará una unica vez, la primera vez que se solicite la consulta, despues de la primer consulta, podrás realizar todas las consultas que desees sobre el mismo UUID tantas veces como quieras sin costo, solo se cobra la primer consulta.

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
 
Los wrappers de las nuevas funciones ya se encuentran disponbiles en los respectivos ejemplos en cada lenguaje que pueden descargar de nuestra pagina web: www.virtual-pac.mx



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:

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:

VirtualXML_CancelaCFDI( cUsuario,         
                        cRfcEmisor,
                        cRfcReceptor,
                        cTotal,
                        cUuid,
                        cCert,
                        cKey,
                        cPwd,
                        cArchResult,
                        cArchLog ) -> nResultado

 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. 
Ejemplo:

nResultado := VirtualXML_CancelaCFDI( "Usuario",                        "AAA010101AAA",
                        "CTE940531F58",
                        "1160.00",
                        "D8E18C2F-2859-4927-A0F0-EA3E93642DDC",
                        "c:\certificados\archivo.cer",
                        "c:\certificasos\archivo.key",
                        "PasswordDelKey",
                        "d:\resultados\resultado.ini",
                        "d:\resultados\bitacora.log")

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:

  1. 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.
  2. 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.
  3. 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. 
El hecho que de en esta ocasión tengamos que cobrar los timbres por algunos servicios, se debe a que los PACs que prestan el servicio de cancelación también nos van a cobrar a nosotros por las cancelaciones, y tienen razón, se está utilizando un servicio que les ha costado desarrollar, implementar y mantener, por lo mismo tienen que cobrar el servicio.

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:

"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
O lo que es lo mismo:


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:
  1. 11 digitos del 0 al 9
  2. 18 digitos del 0 al 9 (esto equivale a la Clave Bancaria Estandarizada CLABE) 
Hasta aquí aparentemente no hay problema, si nos pagan con cheque nominativo entonces la cuenta debe de ir expresada con 11 dígitos, o bien debo poner la CLABE que siempre van a ser 18 digitos.

¿ 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:
  1. 10 dígitos del 0 al 9
  2. 16 dígitos del 0 al 9
  3. 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.