Una RFC (Remote Function Call) nos permite hacer el llamado a un segmento de código realizado en ABAP. Este segmento de código está diseñado para ser disparado por alguna aplicación externa utilizando el protocolo TCP/IP, es decir, en pocas palabras, vamos a llamar una función realizada en ABAP desde nuestra aplicación de .NET.
Un punto importante a tomar en cuenta es que no es necesario conocer el código ABAP que se está ejecutando, nosotros simplemente lo llamamos y nos retornará los valores con los que trabajaremos.
Pasos para la Configuración de RFC en SAP
Para configurar una RFC en SAP, es necesario seguir una serie de pasos que aseguren la correcta comunicación entre sistemas:
-
Declaración de objeto RfcDestination: Como propiedad de la clase declaramos un objeto de la clase RfcDestination, que es el que nos ayudará a realizar la comunicación con SAP.
-
Asignación de parámetros de configuración: Como se observa, es necesario un objeto RfcConfigParameters para asignarle los parámetros de configuración y después con la función RfcDestinationManager.
Lea también: Pasos para el alta de tu empresa en el SAT
-
Establecer conexión: Con esto la conexión a SAP ya debería de llevarse a cabo y por ende se podría hacer el llamado a la RFC. Pero primeramente probemos que la conexión efectivamente se está realizando.
-
Creación de método CrearPersona: Ahora que tenemos la conexión funcionando procedemos a realizar un método que llamaremos CrearPersona.
-
Ejecución de la función: Como se puede ver, la función recibe primero el nombre que tiene asignado en SAP y posteriormente el valor.
-
Retorno de datos: Se puede observar que se regresa un diccionario el cual contiene los datos de salida.
Para probar la aplicación anteriormente explicada, esta podría estar ejecutándose correctamente pero siempre mandando mensaje de error.
Lea también: Aprende a crear tu cuenta virtual en el SAT
Consideraciones Adicionales sobre el RFC y el SAT
Hasta hace ya varios años, las empresas que tenían SAP podían emitir sus propias facturas y conectarse directamente a los servidores del SAT para obtener el timbre.
El objetivo de la autoridad es tener en sus sistemas toda la información necesaria para obtener el volumen de negocios de las empresas en México mediante cruces entre todos los entes relacionados. Por ejemplo, si una empresa reporta que ha ingresado en bancos x cantidad, debe asociarla con la factura emitida para saber de quién viene ese dinero.
Cada vez que se emite un documento de este tipo, los servidores de la autoridad los timbran. Se genera un número que es conocido como UUID. Este es un número de 36 caracteres que no puede repetirse de ninguna manera, por ello es “Único”.
Adicionalmente, cada uno de esos documentos debe contener el registro del contribuyente que emite el documento y el destinatario del mismo. Este código es llamado RFC.
Obligaciones Fiscales y SAP
Al primer mes de envío y cada vez que haya una nueva cuenta, se debe enviar un archivo xml que contiene todas las cuentas contables del cliente asociadas con su código agrupador. Cada mes se debe enviar al SAT la balanza de comprobación que contiene las cuentas y saldos del mes en un formato predefinido por el SAT.
Lea también: Proceso paso a paso para crear tu RFC
Sólo cuando la autoridad lo requiera, el contribuyente debe enviar las pólizas contables en un formato xml. Dependiendo del tipo de póliza es el tipo de registro en xml.
Afortunadamente para los contribuyentes existen muchas alternativas de paquetes de software que permiten cumplir con estas obligaciones. Lo único que se necesita es dar de alta las cuentas y generar las operaciones de acuerdo a lo especificado en el manual.
Frecuentemente la autoridad cambia de formatos y requerimientos de información, emitiendo los lineamientos respectivos. Los fabricantes de los paquetes de software locales son muy eficientes y rápidos en adaptar sus sistemas a esos cambios, por lo que para los usuarios es muy sencillo el proceso de actualización.
Incluso cuando hay un nuevo requerimiento, como fue el caso del timbrado de recibos de nómina, los proveedores de los paquetes de software locales reaccionan muy rápido.
Los sistemas tipo ERP, tanto de Oracle como de SAP, son excelentes sistemas para lo que han sido diseñados y cubren bastante bien con la mayoría de los requerimientos legales mexicanos.
Cuando han sido requeridos por las autoridades los formatos de contabilidad electrónica y facturación, SAP ha generado programas estándar que cumplen con lo mínimo requerido.
El sistema SAP es muy robusto en cuanto a la transferencia de información con sistemas externos. Siempre debe haber dos métodos, el de salida y el de regreso, ya que como se ha indicado previamente, el UUID debe ser incluido en los documentos de SAP por lo que necesitamos el regreso de la información.
En algunos casos el monitor de comunicación estándar no funciona con el método que hemos decidido usar por lo que se debe generar un monitor específico para el cliente.
Cada vez que se factura o se emite un recibo de nómina, se debe enviar al beneficiario el archivo xml y a veces también es deseable anexar una representación impresa en formato PDF.
La dificultad está en el diseño del camino que sea más ágil y modificable para que se comuniquen todos los componentes. Algunos clientes prefieren usar SAP PI, otros prefieren un PROXY ABAP.
Durante 2017 la autoridad nos pide que migremos a la facturación en versión 3.3. Nuestro objetivo es que el diseño sea lo más conveniente a sus necesidades, fácil de operar y sobre todo, económico.
La dificultad de la contabilidad electrónica en SAP está en la generación del archivo de pólizas. Se deben revisar nuevamente las notas y validar su correcta aplicación hasta que el validador acepte nuestro archivo.
Para el contenido de los archivos, se debe hacer un proyecto de manejo de datos, para definir por cada tipo de documento que se debe capturar y en que formato.
Los archivos de pólizas tienen la complejidad adicional de que dependiendo del tipo de registro es la información que deben de llevar.
Lo que nosotros sugerimos al implementar la contabilidad electrónica es implementar un paquete contable local que sirva de “middleware” o intermediario que convierta la información desde SAP a xml.
Nuestro enfoque consiste en tomar los programas estándar de SAP y copiarlos para hacer las mejoras necesarias en los 3 archivos, Catálogo, Balanza y Pólizas.
La ventaja de copiar los programas de SAP y adaptarlos es que podemos definir qué nivel de información se enviará al SAT en vez de tener que mandar todo.
Permítanos ayudarle con nuestra gran experiencia en este tema donde lograremos el objetivo que es cumplir con las disposiciones fiscales de una manera práctica, ágil y sobre todo económica.