aEn este capítulo se detalla la evolución de la ERP después de cada versión del producto. Por lo tanto, este capítulo se divide en varias secciones correspondientes a las versiones (release) del evolutivo, siendo el punto de partida la instantánea de 2018.1, en la medida que marca el inicio de la nueva tecnología de servidor Jetty.

1 Glosario y terminología

Cada bloque dedicado a una prioridad lista las propuestas de novedades y mejoras para el desarrollo de los productos. El orden de aparición determina la prioridad, aunque dependiendo de las necesidades del desarrollo, pueden realizarse cambios en la planificación del desarrollo.

Dentro de los módulos se distinguen los diferentes áreas, véase la siguiente tabla decodificadora:

Módulo Apartado
FI Finanzas
SRM Compras y gestión de relaciones con proveedores
SD Ventas y distribución
SCP Planificación y gestión del aprovisionamiento
MIM Gestión integrada de la producción
IEM Importaciones y exportaciones
CMMS Gestión del mantenimiento
RMS Gestión de venta al por menor
CONS Construcciones
EDI Intercambio electrónico de datos
TMS Gestión del transporte
CPUB Contabilidad pública
LOC Localizaciones por país
SAN Sanidad
WMS Gestión de almacenes
CRM Gestión de relación con clientes
HRM Administración de recursos humanos
APPS Aplicaciónes de movilidad
TERM Terminal y radiofrecuencia

En cuanto a la situación de la propuesta, tenemos los sigientes estados, véase la siguiente tabla:

Estado Significado
Aproved La propuesta de cambio está aprovada y esta pendiente de desarrollo.
Aproval Pending La propuesta de cambio se ha analizado y se va a ejecutar, pero falta la aprovación final
Proposed Cambio propuesto pero pendiente de analisis y aprovación

2 Registro de propuestas de cambios

El registro de versiones resume los cambios de características nuevas y mejoras, tanto de interfaz como de funcionalidad.

2.1 Prioridad alta


Fecha Módulo Cambio Descripción Tipo
06-11-2019 SD Acuerdos Convertir acuerdos de venta en condiciones promocionales Aproval Pending

Debenos entender un acuerdo como una condicion promocional en condiciones o importes que hacemos a un determinado cliente para una determinada cantidad o importe de la venta. Estas condiciones promocionales pueden afectar solamente a parte de los indicadores que determinan el precio del producto como los descuentos para unos productos concretos.

Detailed Description

Hay que entender que el acuerdo, indica que el cliente se compromete a comprar una cantidad o un importe total de unos determinados artículos con condiciones determinadas, y se compromete a hacerlo con una fecha máxima de vigencia del acuerdo.

Pero no es necesario pre-establecer TODAS las condiciones, ya que algunas de ellas pueden ser dinámicas. Por ejemplo, podemos determinar un descuento del 10% pero aplicado al precio de venta de la tarifa que corresponda en el momento de la venta.

Debemos considerar que los acuerdos son EXCLUSIVAMENTE documentos para pactar condiciones sobre una bolsa de productos.

Pongamos un ejemplo, Me comprometo a comprar durante este plazo de tiempo, 100 unidades de un determinado producto y me harás un descuento del 10% sea cual sea el precio vigente en el momento de la compra.

Las condiciones comerciales especiales por acuerdo, se empiezan a aplicar en el pedido. Otros documentos como ofertas, etc. no aplican condiciones de acuerdo.

En un pedido/albaran/factura tendremos lineas que pueden heredar condiciones de lineas de distintos acuerdos. P.E. un pedido de articulos A y B, el A tiene un descuento de un acuerdo y el B tiene un descuento de otro acuerdo distinto.

  1. Permitir en un acuerdo que la forma de pago, el tipo de efecto sean nulos. Esto indicará que se mantienen las condiciones originales pactadas con el cliente.
  2. Los campos de descuentos a nivel de cabecera, deben permitir nulos o elminarse. Esto indicará que el acuerdo no modifica las condiciones de descuentos generales del documento, o que se aplican las definidas para el cliente.
  3. A Nivel de lineas, el precio y los % de descuento deben ser nulables, a lo mejor solamente pactamos un precio, con el descuento que tenga la promocion en el momento de la venta, o solo pactamos un descuento, o ambos.
  4. En lineas el campo generar pedidos indica si el acuerdo generará automáticamente pedidos en el momento del vencimiento del acuerdo o de la linea. Deberiamos tener una condicion general en la cabecera que se enviará a la linea si el usuario no la ha definido de forma partícular para la linea correspondiente (nullable en la linea, obligada en cabecera).
  5. En un pedido o albaran, las lineas pueden "heredar" condiciones comerciales de acuerdos y acumular sus importes y cantidades a la linea de acuerdo. No hace falta que todas las lineas de un pedido que obtengan condiciones de acuerdos, sean del mismo acuerdo. Dos lineas distintas del mismo pedido puede obtener condiciones de dos lineas de acuerdo de distintos acuerdos.
  6. En las lineas de acuerdo tenemos la cantidad y el importe objetivo/maximo y pondremos acumulados de pedidos, albaranes y facturas. Cuando hacemos un pedido de 100 unidades, acumulamos en la linea las 100 unidades en la cantidad pedida, cuando se hace un albaran de ese pedido por 20 unidades, se restan las 20 unidades de cantifdad pedida y se ponen en la servida. Si generamos un albaran directo sin pedido, acumula directamente en la cantidad servida. etc.

Cada documento tiene un linacu en donde se guarda la linea que tiene las condiciones que se han aplcado en la linea del documento. Pero el acumulado debe sumarse a mas de una linea de acuerdo: imaginemos el caso de cantidades por articulo y familia. Si el articulo pedido es de la familia, debe de acumular en la linea de acuerdo con el articulo y tambien en la linea del acuerdo con la familia. Debemos implementar un mecanismo para que despues, cualquier cambio en la cantidad o en el precio se pueda actualizar facilmente en las 2 lineas sin tener que volver a buscar matchings otra vez

.

¿Como?: Puff, guardando un campo varchar con los IDs de las lineas de acuerdo implicadas ? Un campo de tipo ROWSET? 2, 3, o hasta 4 campos de linacu independientes? Una tabla hija con los IDs de las lineas de acuerdo implicadas ? (lo que esta claro es que el trabajo lo tenemos que hacer una sola vez...)

Hablado con Xavi y es partidario de crear una tabla hija de enlaces.

Atención esto seguramente no debe ser asi, pero... Para las condiciones comerciales, no se deben mezclar familias y articulos ya que son dos problematicas totalmente distintas. Además, las condiciones por familias, no se pueden empujar ni estirar automaticamente como pedidos. Por lo tanto, Deberiamos partir la definición de condiciones de artículos en una tabla y otra tabla para las condiciones por familia (si es que es realmente necesario) y lo simplificatiamos todo.

Si queremos simplificar algoritmos o no ejecutar SELECTS en balde, podemos poner un indicador en los tipos de documento pedido, albaran o factura que indique si debe buscar condiciones comerciales en acuerdos o no. Y ya puestos, igual podemos indicar si solo por articulo o global (articulo + familia + lo que venga en el futuro).

06-11-2019 Fi Activos Permanentes Reestructuración modelo de datos Aproval Pending

Simplificación de la estructura de la tablas: Bien, Elemento,Componente

Detailed Description

Actualmente disponemos de una estructura piramidal de 3 niveles (prefijada) que se hace complicada cuando el registro de inmovilizado es simple en la empresa y se hace demasiado simple para determinados casos especiales. Los bienes de inmovilizado, pasarían a ser una tabla simple que registra el inmovilizado y tendria atributos, como dependencias, o agrupaciones.

En las entradas, cada bien es un elemento y dispone de un identificador independiente. 20 sillas tendrian 20 registros con 20 codigos internos y 20 identificadores (codigos de barras)

Tambien permitiriamos un registro de inmovilizado de 20 sillas, con una tabla hija en la que se indica el código de barras único y su localización. De esta forma aunamos la simplicidad contable con el inventario unificado. Además en esta tabla hija, podemos almacenar la fecha y el usuario que ha escaneado el código por última vez (recuento de inventario)

Hay que decidir si simplificamos de cara al usuario y generamos una única tabla con 20 registros (más dificil de introducir, aunque preferido ya que al final la baja debe hacerse de una silla concreta) o un registro y una tabla hija con 20 registros (más complejo de cara al usuario final)

Debemos implementar una tabla de "movimientos" de inmovilizado en la que podemos generar incrementos de valor, devaluaciones/depreciaciones, ventas, bajas, cambios de centro de coste, etc. Cada uno de estos movimientos puede afectar a la valoración del elemento a partir de una fecha y recalcular la tabla de amortizaciones automaticamente. De esta forma, tenemos un registro historico de todas los incrementos y decrementos de valor y podemos tener una posición historica. Seria como si tuviermos apuntes de inmovilizado, el elemento sería la cuenta contable y tendriamos unos saldos. A todo esto añadiendo la caracteristica especifica del inmovilizado de la tabla de amortización/depreciación. Esta es la idea, pero hay que analizarlo al más bajo nivel posible.

Un bien de inmovilizado puede tener relaciones de dependencia con un padre. De esta forma, podemos definir estructuras piramidales de dependencia.

Está pendiente de analizar si los cambios en un elemento de inmovilizado afecta a todos sus elementos padre de forma explicita o no. O si un cambio en el padre afecta a todos su arbol de hijos. Desde un punto de vista economico tal vez no, pero hay que considerar cambios de ubicación, cambios de centro de coste, etc. A lo mejor lo podemos simplificar que sea el usuario quien lo decida, mediante la ejecución de un botón que actualice datos en los hijos, etc. De forma básica, sería como hacemos en los árboles de las partidas presupuestarias.

06-11-2019 Fi Activos Permanentes NIF 16, transacciones Aproval Pending

Incorporar transacciones contables

Detailed Description

Actualmente disponemos de contabilizaciones para:

  • Amortizaciones
  • Bajas / Bajas parciales
  • Ventas
  • Inversiones (enlace a facturas)

En todos los casos es necesario mejorar la visibilidad de las contabilizaciones ligadas a un activo. Además ampliariamos con:
  • Contabilización de deterioro de valor (impairment)
  • Cont. reversión de dererioro de valor
  • Ajustes de adquisición
  • Re-inversiones
  • Ajustes en mortizaciones
  • Reevaluaión
  • Reversión de reevaluación
  • Salida de activos NO venta
  • Provisiones de reserva
  • Transferencia de reserva
  • Amortización extraordinria
  • Amortizaciçon especial
  • Fondo de reversión

06-11-2019 FI Activos Permanentes Ficha de activoss Aproval Pending

Generar ficha de síntesis por activo

Detailed Description

No disponemos de una ficha informativa por activo. Además debería ser visible como sumario en pantalla.

06-11-2019 FI Activos Permanentes Métodos de amortización Aproval Pending

Reorganizar y ampliar cálculos

Detailed Description

Actualmente disponemos de :

  • Método lineal
  • Suma de dígitos
  • Especial

06-11-2019 FI Activos Permanentes Ficha de activoss Aproval Pending

Generar ficha de síntesis por activo

Detailed Description

No disponemos de una ficha informativa por activo. Además debería ser visible como sumario en pantalla.

06-11-2019 FI Activos Permanentes Traspasos y reclasificaciones Aproval Pending

Definir ambos procesos a nivel de elemento o componente

Detailed Description

Actualmente disponemos de un registro para reasignación de elementos

06-11-2019 FI Activos Permanentes Soportes auxiliares Aproval Pending

Definir registros para cada categoria de activos

Detailed Description

Bienes Inmuebles, inversión permanente, intangibles, elementos de transporte,equipos para proceso de información, planta y equipo
Reorganizar que información va asociada a cada tipo de activo y preparar para informes y declaraciones

06-11-2019 FI Maestro de entidades Banacarias Actualización Aproval Pending

Definir entidades bancarias

Detailed Description

Actualmente disponen de ccc1 (obsoleto) pero no de código de tercero, dirección
Incorporar datos globales (v.g. tipo de ficheroa procesar n43, MT-940, ..) zbr/>

2.2 Prioridad media

Date Module Title Description Status
06-11-2019 SCP Recargos sobre costes Costes adicionales a compras y movimientos de stock proposed

Disponer de inductores de coste adicional al realizar transacciones de estoc

Detailed Description

Actualmente disponemos de un modelo de obtención del coste por artículo mediante la realización de los cierres de almacén. Este procedimiento calcula los costes según política FIFO, LIFO o precio medio, tomando como referencia los precios indicados en las tarifas o en las líneas de los documentos de recepción.

En algunos procesos operativos de recepción o de manipulación de materiales dentro de los almacenes se requiere aplicar costes adicionales por diferentes conceptos que han de incrementar el valor de estoc del producto, siendo en muchas ocasiones costes basados en un cálculo estadístico promedio del comportamiento que ha tenido ese concepto durante un periodo de tiempo.

La aplicación nos ofrece para este tipo de transacciones la posibilidad de definir descuentos especiales para añadir cargos o descuentos a las transacciones, pero son estructuras complejas de parametrizar y gestionar. Dentro del estándar disponemos de algunas opciones que nos podrían facilitar esta gestión, como la estructura definida en los costes estándar que permiten asociar recargos directos por un importe determinado ya se por familia o por artículo.

Sería conveniente analizar las mejores opciones para obtener de forma sencilla:

  • Incrementos de coste a aplicar a artículos en algunas transacciones
  • Obtención de estos incrementos/decrementos en base a información histórica de transacciones
  • Aplicación en los procesos de valoración de las transacciones
  • Integración de las previsiones de coste vs. costes reales obtenidos


Fecha Módulo Cambio Descripción Tipo
18-11-2019 SCP Recargos sobre costes Costes adicionales a compras y movimientos de stock Aproval Pending

Disponer de inductores de coste adicional al realizar transacciones de estoc

Detailed Description

Actualmente disponemos de un modelo de obtención del coste por artículo mediante la realización de los cierres de almacén. Este procedimiento calcula los costes según política FIFO, LIFO o precio medio, tomando como referencia los precios indicados en las tarifas o en las líneas de los documentos de recepción.

En algunos procesos operativos de recepción o de manipulación de materiales dentro de los almacenes se requiere aplicar costes adicionales por diferentes conceptos que han de incrementar el valor de estoc del producto, siendo en muchas ocasiones costes basados en un cálculo estadístico promedio del comportamiento que ha tenido ese concepto durante un periodo de tiempo.

La aplicación nos ofrece para este tipo de transacciones la posibilidad de definir descuentos especiales para añadir cargos o descuentos a las transacciones, pero son estructuras complejas de parametrizar y gestionar. Dentro del estándar disponemos de algunas opciones que nos podrían facilitar esta gestión, como la estructura definida en los costes estándar que permiten asociar recargos directos por un importe determinado ya se por familia o por artículo.

Sería conveniente analizar las mejores opciones para obtener de forma sencilla:

  • Incrementos de coste a aplicar a artículos en algunas transacciones
  • Obtención de estos incrementos/decrementos en base a información histórica de transacciones
  • Aplicación en los procesos de valoración de las transacciones
  • Integración de las previsiones de coste vs. costes reales obtenidos

2.3 Prioridad baja