Contact us at +1.415.901.7500 or contact@itconvergence.com

¿Cómo cumplir con los nuevos requerimientos fiscales de México?

¿Cómo cumplir con los nuevos requerimientos fiscales de México?
Mexico SAT Cambios

Hace dos semanas IT Convergence presentó un exitoso seminario web llamado: ¿Cómo cumplir con los nuevos requerimientos fiscales de México?

El evento fue muy concurrido, y tuvimos muchas más preguntas de las que pudimos responder en vivo. Por esta razón, en tanto lo prometido es deuda, les acercamos hoy la transcripción de la sesión de Preguntas y Respuestas.

1.    ¿Qué solución ofrecen cuando el mapeo entre el catálogo del SAT y el nuestro es incompatible? Por ejemplo, el SAT contempla “Clientes Nacionales” y “Clientes Extranjeros”, pero nosotros solo tenemos “Clientes”, haciendo imposible esa desagrupación desde GL.

En este caso estamos hablando de una regulación, con lo cual no tenemos opción más que abrirlo de acuerdo a la información del SAT. Esto nos llevará a quizás abrir una subcuenta, o a registrar flexfields desde los subledgers.

2.    Contamos con una cuenta global a la cual le puede corresponder más de un código agrupador del SAT. ¿Es necesario crear distintas cuentas en el sistema origen, o una cuenta puede tener más de un código en el mapeo?

Una cuenta puede tener más de un código agrupador. Hay que revisar el catálogo de cuentas de cada cliente para ver específicamente si tienen otros segmentos de subcuenta para evaluar cómo asociar todos los campos. Pero es posible que una cuenta tenga más de un código.

3.    ¿Es necesario traducir al Español los nombres de nuestras cuentas?

Sí, es un requisito traducirlos al español. Si no tienen dónde ingresarlo, es posible abrir un campo para agregar allí la traducción al español.

4.    Si una cuenta puede pertenecer a más de un código agrupador, ¿cómo se refleja la información en la balanza que se entregará al SAT?

Nuestra solución da la posibilidad de hacer el mapeo a nivel de la combinación contable. Si ustedes en la combinación contable tienen un segmento para la Cuenta de Mayor o Natural, y otro para la subcuenta, sí pueden configurarse dos códigos agrupadores para la misma cuenta, teniendo en cuenta que en realidad estamos hablando de una misma cuenta con dos subcuentas distintas. Pero si ustedes en su estructura de plan de cuentas solamente tienen un segmento para la Cuenta de Mayor, en ese caso no se pueden mapear dos códigos agrupadores a la misma cuenta ya que no se podría separar la información de balanzas y pólizas y no se sabría a qué código agrupador informarlo. Pero si la subcuenta o cualquier otro segmento en el flexfield contable son distintos, sí pueden indicarse códigos agrupadores distintos.

5.    ¿El mapeo se hace a nivel de cuenta o de combinación contable?

Se hace nivel de combinación contable.

6.    ¿Cómo se hace la importación de todos los datos de los CFDI’s que se deben manejar para el detalle en el detalle de pólizas?

La regulación del SAT no requiere en concreto que se envíe el CFDI. Sino el identificador electrónico único (UUID), con lo cual no es necesario importar el CFDI a la aplicación sino solamente el código de 36 dígitos  del UUID. Lo que nuestra solución prevé es el agregado de campos descriptivos a nivel de cabecera de documentos para facturas de clientes y proveedores, donde habría que ingresar ese valor, sea manualmente o con algún tipo de solución automática (lo que sería conveniente debido a la longitud y complejidad de hacerlo manualmente). En el caso de recibos de pago de nómina, como es información que generalmente no está en EBS, nuestra solución implementa una tabla de interface donde se pueden ingresar los códigos UUID e informarlos en la sección de comprobantes de los archivos de pólizas que requiere el SAT. 

7.    Tenemos un plan de cuentas global definido por Corporativo de unos 7 dígitos. Bajo las nuevas reglas, ¿tenemos que tener un catálogo de cuentas con los dígitos definidos por el SAT?

En este caso, lo que hacemos es definir un campo adicional donde ingresar el código agrupador. No es que tengamos que crear un catálogo, sino que a los valores que ya tienen actualmente, le asociamos el código agrupador, para poder pasarle esa información al SAT. Pero es un mapeo nada más, no es necesario cambiar el catálogo corporativo.

8.    ¿Qué sucede cuando en una cuenta corporativa existen tres o más cuentas locales?

Se pueden mapear a una subcuenta, o se podría abrir un campo descriptivo. Generalmente se decide generar subcuentas para las cuentas que se tienen que abrir.

9.    ¿Si tenemos una sola cuenta de clientes con un campo que identifica clientes nacionales y extranjeros, se puede utilizar este campo para asignarle el código agrupador del SAT?

No. Si bien sería muy fácil técnicamente hacer eso para generar el archivo que requiere el SAT, el SAT solicita que la información se envíe en dos niveles (clientes nacionales e internacionales). Por este motivo, si contablemente tenemos una sola cuenta, no podríamos enviarle al SAT datos de balanzas y pólizas que simulan tener dos cuentas, ya que cuando el SAT quiera cruzar esa información con nuestros estados contables al fin del ejercicio, va a dar distinto.


10.    ¿Esta solución funciona para empresas que tienen algún producto adicional que no sea de Oracle?

La solución espera encontrar datos de facturas de clientes y proveedores dentro de los módulos estándar del E-Business Suite. Si ustedes tuvieran esa información en algún sistema externo, podríamos analizar la posibilidad de integrarlo. Pero de alguna manera tenemos que poder acceder desde la base de datos del E-Business Suite a los datos de facturas de clientes y proveedores. Lo mismo sucede con los recibos de pago de nómina. La única diferencia es que como es muy infrecuente que las empresas tengan la información electrónica de los recibos de pago de nómina ya en la base de datos, para esa funcionalidad nosotros incorporamos una tabla de interfaz abierta donde se puede mapear la información electrónica, ingresar el identificador único electrónico de cada uno de los recibos de pago y poder tenerlo integrado a la solución directamente.

11.     ¿La solución estándar incluye el catalogo, balanza y pólizas?

Sí, esto es correcto.

12.    ¿Pueden profundizar un poco más en el proceso de implementación? ¿ITC se encarga de la implementación u ofrecen la solución y uno hace la instalación y configuración? ¿Cuál es el tiempo de implementación o entrega de producto?

La solución tiene un alcance muy acotado que responde solamente a los requerimientos del SAT. En concreto, son unas pocas configuraciones: los códigos agrupadores, su mapeo y los procesos para generar los archivos y exportar e importar la información de un Excel. ITC brinda el software que compone esta solución, sus procesos automatizados de instalación y soporte durante la instalación del mismo. El administrador de base de datos o de sistemas de su entorno puede ejecutar esta instalación con nuestro soporte en línea, ya sea por teléfono, por una sesión web o por el chat. Si desearan que ITC realizara la instalación, esto se puede coordinar también, necesitaríamos simplemente que nos dieran acceso a su entorno de manera remota.

La implementación de este producto es mínima, ya que consiste en ingresar el mapeo de cuentas (una actividad contable) y ejecutar los procesos que generan los archivos. No requiere ningún tipo de entrenamiento ni implementación del tipo del que estamos acostumbrados con los procesos de módulos de Oracle. Igualmente tenemos previsto un soporte funcional en caso de tener ustedes algún problema, con lo que van a poder comunicarse con uno de nuestros consultores para solicitar asistencia sobre la operación o generación de los archivos.

13.     ¿La solución ya está disponible en este momento? 

ITC está lanzando esta solución en dos etapas. La primera etapa incluye todo lo referente a la configuración y generación de archivos de catálogo y de balanzas. Esa solución va a estar disponible este mes durante septiembre, y ya la estamos mostrando en las demos. En la demostración mostramos el producto final tal como sería instalado en sus entornos.

En caso del tercer archivo, el de pólizas, tenemos previsto lanzarlo en octubre, dando tiempo suficiente a realizar las pruebas necesarias durante noviembre, diciembre e incluso enero, ya que la información se empezaría a enviar al SAT en enero.

14.    ¿Qué validación realiza la solución en el momento de Importar los archivos para el catálogo de cuentas?

Lo que se valida es que las combinaciones contables importadas sean correctas y que los códigos agrupadores sean válidos. Lo interesante es que el archivo de mapeos que se importa también se genera desde la aplicación. Hay un primer proceso que genera una planilla de Excel con todos los valores de combinaciones contables y su descripción, y sobre ese archivo uno debe ingresar los mapeos para luego volver a enviarlo a la aplicación de Oracle. No hay que ponerse a tipiar cada una de las combinaciones contables, la aplicación ya genera una planilla con esos valores cargados.

15.    En la solución, ¿la importación del catálogo de cuentas es por DDL o por un concurrente?

Es un proceso concurrente.

16.    Con respecto al proceso de Generación de las pólizas, ¿se generará automáticamente la información de las facturas (AP o AR)?

Correcto. Si ustedes tienen la información de pagos y proveedores en el módulo de facturas a pagar, al generar el archivo de pólizas de un período, se va a generar la información de la póliza en sí misma (combinación contable, importes al débito, al crédito, demás datos descriptivos) y la sección de cheques o transferencias. En la sección del comprobante también irían los datos del comprobante electrónico de la factura recibida al proveedor o enviada al cliente. 

17.     ¿Esta solución sirve sólo para Release 12 o puede adaptarse a R11?

Puede adaptarse. La solución es básicamente la misma, para las dos versiones, la única diferencia es que en versión 12 hay un módulo nuevo de pagos, con lo cual las estructuras de datos son distintas. Nosotros desarrollamos para R12 porque es la versión actual, pero si ustedes están trabajando con la versión 11 se puede adaptar fácilmente, ya que sólo requiere cambios en la sección de datos de pagos.

18.    ¿Tienen considerada alguna solución para la cuestión del manejo de versiones del catálogo de cuentas? Por ejemplo, hoy el SAT lanzó la versión 1, si en unos meses lanza la versión 2… ¿estas versiones quedan grabadas en el ERP o sólo se mantiene la última?

Si se refiere a los cambios en las cuentas contables, estamos hablando de mantenimiento. Si es cambio a la estructura, en cuanto a la forma como se está integrando al SAT, veríamos el caso, si es posible considerarla una mejora o como mantenimiento.

A la fecha de hoy no existe un requerimiento del SAT de poder mantener distintas tablas de mapeo para informar los datos de póliza y balanza usando distintos tipos de mapeo por fecha. Lo que se sabe hoy es que hay un catálogo definido y una gran expectativa sobre eventuales modificaciones a ese catálogo. De momento, nuestra solución no incorpora esta opción porque no es parte del requerimiento legal.

19.    En caso de contingencias, ¿qué solución tienen en el caso de requerir el reproceso de los archivos XML?

Sí, por supuesto. Sin llegar al caso de contingencias, puede suceder que una vez cerrado un período deba ingresarse una póliza con fecha pasada, y deban volver a enviarse los archivos al SAT. De hecho, el SAT acepta el envío de rectificatorias, que debe incluir la balanza completa en el caso del archivo de balanzas y pólizas, todas las cuentas y movimientos registrados. Así que en cualquier momento es posible re ejecutar los archivos enviados al SAT. Cada vez que se re-ejecuta el archivo, se reflejará la situación contable actual (es decir, si se introdujeron cambios, etc.).

20.     ¿Esta aplicación puede utilizarse para periodos cerrados? Por ejemplo ya tenemos cerrado Julio, ¿se puede generar la balanza de ese mes?

Sí, de hecho el período debe estar cerrado para poder generar el archivo de balanzas o pólizas, ya que de otra forma, sería incompleto. Esto no quita que si es necesario abrir un período para ingresar una modificación, se pueda re-ejecutar.

21.     ¿Cómo se generan los XML, desde los módulos o desde el GL?

Desde ambos. El primero, que contiene el catálogo de cuentas, toma información del GL, obtiene todas las combinaciones, códigos agrupadores, tipo de cuenta, nivel, y de ahí sale la información.  El archivo de balanzas también sale de GL. El archivo de pólizas sale de ambos lados: hay un origen principal, que son las pólizas ingresadas en el módulo contable, y para cada póliza se busca la información disponible de cheques, transferencias y documentos.


22.    ¿La solución es compatible con SAP como sistema origen?

No, funciona sobre Oracle E-Bussines Suite.

23.   ¿Pueden profundizar en el tema de adjuntar los documentos adicionales?

Tanto las facturas de clientes y proveedores como los recibos de pago de nómina son comprobantes digitales por internet desde hace un tiempo (CFDI). Estos documentos se generan a través de un pack de un proveedor autorizado por la autoridad fiscal, que imprime la factura y envía la información en formato electrónico de cada documento, generalmente en formato XML. Ese archivo XML es el CFDI en sí mismo, que tiene todos los datos del comprobante – ej.  fecha, nombre, ítems, cantidades, impuestos, etc. La regulación requiere que se informen los identificadores únicos, los UUID, que es un código de 36 dígitos incluido en el folio fiscal de cada CFDI. Cada comprobante tiene un timbrado que incluye el UUID, que debe informarse en los archivos del SAT. Lo que proponemos es ingresarlo en un campo descriptivo en las cabeceras de documentos, asumiendo que su empresa trabaja con AP y AR. Y respecto a los recibos de nómina, dejamos previsto una tabla de interfaz donde informar los códigos UUID para poder cruzarlos con la póliza para generar el archivo de pólizas requerido. La integración entre los códigos y la nómina va a ser particular para cada empresa.

24.    Las pólizas contables requieren incluir el detalle de la información del cheque o pago electrónico, incluyendo Cuenta origen, RFC, núm. cheque emitido, etc. Dicho detalle actualmente no fluye a la contabilidad ¿La solución contempla también incluirlo?

Estos datos se obtienen directamente de los subledgers, o sea, de los módulos de Accounts Payables y Accounts Receivables.

25.    ¿Qué sucede si el SAT modifica algún segmento de cuentas una vez instalada la solución? ¿Tendría costos adicionales?

No hay costos ni servicios adicionales necesarios. La solución brinda la posibilidad de ingresar/modificar las cuentas de acuerdo a un potencial nuevo listado que publique el SAT, y de efectuar sus correspondientes mapeos.

26.    Utilizamos el Sistema Tress para el cálculo de  la nómina, que genera pólizas contables que se cargan manualmente en Oracle. El timbrado lo hace el sistema Tress. ¿Cómo se hará la interface entre esos sistemas para subir el soporte de los CFDI?

Nuestra solución provee una tabla de interface en donde debe incluirse el RFC de cada empleado, el UUID del recibo de nómina, el importe, e información que permita relacionar el recibo con la póliza (por ejemplo, periodo, número de asiento, categoría, etc.). Este criterio de vinculación de datos entre la póliza y la tabla de interface puede ajustarse durante la implementación.

27.    ¿Su solución contempla una conciliación entre las facturas en el Validador de XMLs y las facturas en AP? Ya que puede suceder que las facturas en AP no tengan correspondencia en XML o viceversa

Los datos a informar deben corresponderse con los registros contables y el soporte en los subdiarios. Nuestra solución utiliza esa información la cual se asume es correcta.
Tal vez la pregunta no sea lo suficientemente clara. Si es así, por favor comuníquese con nosotros para discutir en detalle.

28.    En caso de que se mantenga sólo la última versión, al momento de generar balanzas anteriores al último cambio, ¿qué códigos agrupadores serán tomados en cuenta?

Actualmente no hay indicios sobre la forma en que el SAT requeriría manejar esta situación, por lo tanto no es parte de la regulación actual manejar distintas versiones del listado de códigos agrupadores, y por lo tanto nuestra solución no lo hace.

29.    ¿Cómo se llena el UUID en las facturas en su solución, automáticamente mediante algún proceso concurrente o de interface; o manualmente por el usuario?

Dentro del alcance básico, nuestra solución implementa atributos descriptivos en los flexfields en la cabecera de facturas de clientes y proveedores para que los códigos se carguen manualmente. Como servicio adicional puede analizarse la posibilidad de automatizar esa carga desde la fuente en que se disponga (por ejemplo, archivos XML adjuntos a los registros de facturas, o archivos XML para cada comprobante almacenado en un servidor accesible desde la aplicación.

30.    Para el caso de los reembolsos de gastos, ¿cómo se hace la carga de CFDIs, siendo que el pago es a un empleado con varias facturas de diferentes proveedores?

La solución no contempla esta situación y a tal efecto se sugiere utilizar la posibilidad de enviar un Reporte auxiliar complementario tal como lo indica la resolución en la sección I.2.8.6 punto III.

Si desea conocer más sobre los servicios Oracle de IT Convergence para América Latina, visite nuestro sitio web o contáctenos hoy   para descubrir cómo podemos ayudarlo a cumplir con las nuevas obligaciones fiscales de México.