En estos años trabajando con Dynamics NAV / Business Central he venido anotando ciertas carencias en diversos procesos de la aplicación. Carencias en funcionalidades generales que generan frustraciones a la empresa contratante.
En muchos casos, esas frustraciones vienen devenidas de que siempre hay, en el estándar, una alternativa a hacer las cosas aunque dicha alternativa pueda ser muy costosa en tiempo lo que conlleva que un nuevo cliente:
- Sienta que algunos temas particulares podrían haber sido concretados y comunicados en la fase de análisis en lugar de llevarse la sorpresa de la necesidad de desarrollo fuera de proyecto posterior.
- Sienta que debido a su generalidad la parte yuxtapuesta fuera conocedora del hecho y que decidiera omitirlo.
- Comience a preguntarse qué otras cosas faltan y si la razón del campo de procedimientos se deba a carestías nimias del programa y no a que hay diversas formas correctas de hacer las cosas.
Siempre he pensado que estas cuestiones, que son harto conocidas, deberían tener respuesta por parte de los partners ipsofacto y ofrecer ya el programa con varias de estas cuestiones resueltas y, apoyándose en tenerlas resueltas, poder decir abiertamente «Esto estándar no funciona como necesitas pero lo hemos modificado para que se ajuste a tus necesidades» sin necesidad de pasar por ese proceso de frustración en la negociación en una fase tan importante para el cliente como la implantación.
Siempre he considerado el proyecto de implantación como un proyecto que se debe vender en valor y no en horas, es decir, en lugar de decir que el proyecto son 30k y que modificar la facturación automática son 1k puedo decir que el proyecto son 31k porque vamos a resolver un problema que tiene el estándar en su caso porque la facturación automática que necesitan funciona de tal modo.
Mas allá del cambio de mentalidad «económica».
(No es el coste el que determina el precio sino que es el precio el que determina la producción, que existirá siempre y cuando el margen sea positivo y superior a alternativas)
Hoy en día, esta cuestión es condición sine quanon para poder competir dado que las extensiones han abierto la posibilidad de estandarización de soluciones y no tiene costes repetitivos para el implantador, así me consta que en muchos casos se trabaja.
Funcionalidades generales que para mi, merecen un cambio antes de la implantación a un cliente o ser realizadas:
Facturación automática
El proceso de facturación en el programa se basa en partir de pedidos de venta y, desde los mismos, registrar los envíos, es decir, los albaranes.
El proceso de facturación automática genera facturas basándose en los albaranes y ciertos criterios de ruptura (motivos por los que en lugar de incluirse mas líneas en la factura se genera una factura nueva) que son: cliente de venta y de facturación, moneda, y dimensión.
Eso implica que si tenemos dos pedidos del mismo cliente uno en dólares y otro en euros, se generarán dos facturas una en dólares y otra en euros.
El hecho de que esos campos sean los únicos que forman parte del criterio de ruptura implica que la facturación automática no respeta cuestiones importantes tales como, forma de pago, término de pago, grupo registro IVA negocio, grupo descuento de cliente, código descuento factura, vendedor…
Eso implica que todas las líneas de albarán devenidas de pedidos con distintas formas de pago y términos de pago formarán parte de una factura con la forma de pago y el término de pago que se indique en la ficha del cliente.
Está claro que para empresas cuya naturaleza de negocio es importante las formas y términos de pago, por ejemplo, o que trabajan mucho con descuentos esta facturación automática no se ajusta en nada a sus necesidades y será necesaria su modificación.
En la mayoría de casos con añadir como criterios forma de pago, término y grupo registro IVA negocio aglomeras al 80% de empresa que la facturación automática del estándar no les sirve y puedes añadir un campo código que devenga del cliente, por ejemplo y en el que se pueda establecer un nuevo criterio de ruptura para que tu solución estándar sirva para casi todos los casos que se te presenten.
Casos puede haber mil pero ya serán los menos. Sí que considero forma de pago y término de pago un básico.
Y si, en el estándar podría usarse la funcionalidad filtrando varias veces pero eso se escapa del concepto «Facturación automática».
Conciliación bancaria
La funcionalidad de la conciliación bancaria en Business Central tiene varios niveles como mostraré en una próxima entrada. Va desde controlar el saldo final del mes con el banco a poder cotejar cada apunte bancario y hasta poder registrar los pagos en base a un fichero bancario. Ahora bien, todo esto no está disponible y parte debiera. (La funcionalidad que me parece básica es la de poder cotejar los movimientos que se han ido registrado contra los movimientos de la cuenta bancaria)
Uno de los apartados que se nombra entre las funcionalidades es siempre la conciliación bancaria pero pocas veces se ofrece con ella directamente la posibilidad de importar la norma 43 de cualquier banco.
La norma 43 es un fichero que contiene todos los movimientos de nuestra cuenta bancaria y que los bancos permiten exportarla. Con ese fichero importado ya podría cotejarse uno a uno los movimientos de banco que se han ido registrando en el programa con los movimientos reales del banco o incluso usarlos para registrar los movimientos de banco.
Esta funcionalidad es general y realizarla sirve para absolutamente todos los clientes que utilicen Business Central. Es importante que las partes sepan que salvo indicación en contrario, la conciliación bancaria, sin desarrollo posterior, no te va a servir para nada.
El desarrollo es bastante simple, solo es importar un .txt en una tabla sin funcionalidad alguna, de toda la comparación y cotejo automático de datos ya se encarga la funcionalidad de Microsoft.
Borrado de histórico de documentos
La filosofía de Business Central se basa en que lo que registres queda registrado. Para deshacer un apunte contable hay que hacer el contra asiento, para cancelar una factura hay que realizar un abono… Pero hay un particular bastante peligroso.
En las páginas de documentos históricos, por ejemplo «Histórico de facturas de compra» se permite eliminar el registro. Este borrado únicamente implica la desaparición del documento pero no deshace todos sus apuntes asociados (movimientos de contabilidad, IVA…). Este hecho puede conllevar a incongruencias de datos sobre todo basadas en el análisis humano.
La filosofía detrás de esto es que como Microsoft permite el registro de facturas (en tanto que facturas como entidad) desde diario y que, de ese modo no generan histórico de facturas, pues por qué no permitir la eliminación en el histórico si no es obligatorio que en él aparezcan.
Los procesos de libro de facturas emitidas, por ejemplo, basan su funcionamiento en movimientos de IVA, otros lo basan en movimientos de cliente, ninguno lo basará en el histórico por esta cuestión, porque una factura no tiene por qué estar en el histórico.
Considero que cuesta poco, en caso de que no se requiera registrar facturas por diario, evitar el potencial problema que supone poder borrar el histórico de una factura. Es un desarrollo muy simple y 100% estandarizado cuyo coste es prácticamente nulo en origen y completamente nulo si se utiliza para distintos clientes.
Diarios generales
Todos los diarios son iguales, todos se basan en la misma tabla, lo único que cambia de uno a otro son los campos visibles… Que se unifiquen.
No hace falta que de normal se vaya a diario general, para pagos a diario de pagos, para generar efectos a diario de cartera… Está bien diferenciar pero no añadir complejidad a lo que no la tiene, la contabilidad.
Es una modificación del programa muy sencilla y coadyuva la sencillez en el uso para los usuarios. Yo, desde luego, siempre intento tener todos los campos para no ir cambiando de un lugar a otro.
Agrupar pagarés y desglosar
La localización española tiene un modulo adicional de gestión de «documentos a cobrar» y «documentos a pagar». Permite que una factura, con su registro, se divida en varios documentos a cobrar de forma que, por ejemplo, la mitad se pague a 30 días y la otra mitad del importe a 60 días desde fecha de emisión de la factura.
Este hecho, unido al SEPA, hace necesario en muchas ocasiones la necesidad de agrupar pagarés con el fin de facilitar la gestión de la deuda a proveedores.
Sería interesante la adición de una funcionalidad que permitiese seleccionar distintos pagarés para agruparlos en uno nuevo con su funcionamiento normal, sus series, su trazabilidad…
Retenciones fiscales
Dependiendo de la naturaleza del negocio y de la naturaleza de negocio de las contrapartes (clientes y proveedores) tendremos la obligación de practicar retenciones en facturas. Evidentemente, con el ERP esto podemos llevarlo a cabo en las líneas de la factura tan solo metiendo una línea de tipo cuenta a la 4751.
No obstante, es interesante el poder llevar un control sencillo de los importes retenidos, automatizar el cálculo del importe sobre el tipo de retención aplicable, la cuenta contable asociada, la no sujeción a IVA…
Consolidar saldos de clientes y proveedores
En BC21 se incluye funcionalidad para realizar esto, para poder relacionar un cliente con un proveedor (mediante un contacto) que representen a la misma empresa y consolidar su saldo de forma que sea netamente deudor o acreedor.
Bloqueo automático de clientes y clientes de dudoso cobro
La naturaleza de muchos negocios deviene en multiplicidad de clientes, son negocios que tratan con cliente final y minorista. En estos casos, puede resultar complicado gestionar, en base a los impagos, la idoneidad de seguir sirviendo a un cliente.
Podría realizarse una funcionalidad que en base al montante de la deuda vencido y los días vencidos de ese montante bloquee el cliente y su saldo adeudado sea traspasado a la cuenta de clientes de dudoso cobro a fin de que contablemente se refleje la imagen fiel de la empresa y que no se le vuelva a servir a ese cliente ni por error.
Para finalizar, creo que los puntos anteriores son los casos mas comunes, y de entidad, que he encontrado y que son mas generales para todas las empresas. Algunas requerirán una gestión personalizada de comisiones y comisionistas, otras la prorrata, producción, garantías… Pero las que he resumido son algunas de las que aplican a multiplicidad de empresas y son realmente fáciles de solucionar.
La principal ventaja de Business Central actualmente es su constante renovación y actualización, la inclusión de mejoras por parte de Microsoft y, por encima de todo eso, la capacidad actual de realizar modificaciones sobre el mismo.
Ahora ya no es necesaria una licencia de desarrollo para realizar modificaciones por lo que muchos de los cambios, pequeños, simples pero que otorgan mucho valor en cuanto a ahorro de tiempo (Cambiar accesos, añadir campos visibles, automatizar, informes…) pueden ser llevados a cabo con un coste menor al que tradicionalmente era necesario.
El retorno de tener en una empresa que pueda ser el canalizador de la mejora continua del programa pudiendo aglutinar todo el conocimiento acerca de los procesos de la empresa con el ERP y pudiendo llegar él mismo a mejorarlos es cada día mayor. Ya no existe el coste de la «Licencia de desarrollo», considero que hoy por hoy resulta muy barato tener una persona designada internamente para conocer los pormenores de toda la relación de la empresa con su sistema de gestión y también para poder llevar a cabo un análisis y seguimiento de los negocios con el partner de la empresa. No se debe externalizar completamente algo tan importante para la empresa como es la mejora de sus procesos.
