La parte mas importante de un ERP es la configuración inicial que es la que asegura el funcionamiento correcto de todas las operaciones que con él se realicen.
Además, existe una serie de cuestiones que tienen que tenerse en cuenta para asegurar que ese configuración inicial y los cambios en las operaciones de la empresa no incidan en un resultado indeseable.
Configuración de grupos de registro (contables en NAV)
Los grupos de registro son los que establecen el resultado contable devenido del registro de los distintos documentos o diarios.
La modificación de la configuración de estos grupos de registro nunca debe llevarse a cabo sin un profundo análisis dado que:
- La configuración en un momento dado establece las cuentas contables a las que se realizan los registros.
- La aplicación no tiene memoria, es decir, ante un cambio en la configuración la aplicación no recuerda la configuración establecida con anterioridad.
De esta forma, por ejemplo, basándonos en los grupos registro de cliente:
Modificar la cta. clientes, por ejemplo, teniendo clientes con saldo pendiente con ese grupo de registro, haría que jamás pueda quedar a 0 la cuenta configurada con anterioridad (quedaría siempre positiva) y que la nueva cuenta presente siempre un saldo negativo (por el mismo importe que la configurada con anterioridad.
Esto se entiende de forma facil con un ejemplo. Si se registra una factura de 100 euros, exenta de IVA, el apunte irá a la cuenta 430. Si cambiamos la configuración, cuando registremos el pago de dicha factura, el apunte no abonará la cuenta 430 original sino a la que hayamos hecho el cambio.
Teniendo esto en mente es igual de claro que no se debe modificar el grupo contable de una ficha de cliente/banco/proveedor/producto por los mismos motivos ya que, implícitamente, supone modificar la cta. clientes a la que se realiza sus apuntes.
Mención especial requieren los grupos registro de IVA que no solo el cambio en su configuración implicaría unos datos de Movs. IVA inconsistentes sino que, además, al calcular y registrar la liquidación de IVA resultaría en que el saldo de las cuentas configuradas no se saldaría (El resultado 475 o 470 de la liquidación sería correcto pero no a nivel contable).
Calcular y registrar liquidación de IVA
El proceso de calcular y registrar IVA basa su funcionamiento en movimientos de IVA y no en apuntes contables. Para que al lanzar el proceso el reflejo contable sea correcto se requiere que la configuración de IVA no haya sido modificada entre la fecha de los apuntes y la fecha de ejecución del proceso. (Ver punto anterior)
El proceso de calcular y registrar liquidación de IVA nos requiere tanto fecha inicial como final:
El proceso, al marcar la opción de «Registrar», realiza un punteo de los movimientos de IVA de forma que controla que un mismo movimiento no pueda ser tenido en cuenta en el proceso varias veces.
Es muy importante este hecho ya que nos permite implementar la buena práctica de poner una fecha inicial anterior a la del periodo de declaración de forma que, si se ha registrado con posterioridad un movimiento con fecha anterior el proceso lo tenga en cuenta.
Por ejemplo: Hemos ejecutado y registrado el proceso para el primer trimestre del año. El cuatro de abril alguien realiza un registro con fecha de marzo. En la ejecución del proceso del segundo trimestre tendremos que:
- Si se registra con fecha inicial 01/04/2020 entonces el proceso no tendrá en cuenta ese apunte de marzo hecho con posterioridad.
- Si se registra con fecha inicial 01/04/1901 entonces el proceso tendrá en cuenta todos los movimientos de IVA que no hayan sido previamente liquidados por lo que el resultado sería el mismo que con la opción anterior pero incluyendo el movimiento realizado el 4 de abril con fecha de marzo.
Eliminar datos
El programa permite, en muchos casos, eliminar ciertos registros que pueden provocar inconsistencias en los datos. Algunos de estos datos son:
- Formas de pago utilizadas.
- Vendedores utilizados.
- Grupos contables utilizados.
- Cuentas contables utilizadas.
- Documentos históricos: facturas, albaranes, abonos…
- …
Al respecto de documentos históricos es muy importante señalar que, a diferencia de otros ERP, esos documentos son sagrados. En otros ERP, la eliminación de una factura realiza los apuntes contables contrarios a los que provocó el registro. Sin embargo, en BC o NAV el problema es que simplemente se eliminan y ya está, a nivel contable no se realiza contraapunte alguno.
En BC puede evitarse la eliminación tanto de documentos históricos como de cuentas contables desde la configuración de ventas y la configuración de contabilidad.
Cuando se hace referencia a la inconsistencia de datos me refiero a tener apuntes a un cliente que no existe, en una cuenta contable que no existe, acerca de documentos de venta que no existen… Pensando en la posibilidad de analisis de datos puede ser un problema dado que las relaciones tendrán que ser particularmente realizadas para el caso concreto sin suponer el funcionamiento corriente del programa.
Modificaciones para ahorrar unos segundos
El leit motiv de Business Central como ERP, a mi parecer, es la posibilidad de poder modificar completamente todo su funcionamiento. Estas modificaciones deben ir dirigidas a reafirmar los procedimientos de la empresa y obtener un impacto en la productividad de los recursos.
No obstante, esto tiene un coste económico que los usuarios no tienen conciencia directa. Por ello, es importante desde la empresa implantar un procedimiento que canalice todas las requisiciones de modificación. Además, deberá realizarse una criba de las mismas y puesta en común para encontrar el modo óptimo en el que realizarlas.
Se pueden realizar muchas modificaciones, algunas completamente recurrentes y que toda empresa requiere porque implica una ganancia de tiempo en sus procesos considerable. No óbice, no debe buscarse la automatización de todo proceso y tener presente siempre que todo aquello que un usuario realiza sin regla fija no puede ser automatizado.
