Una forma en que los ERP mejoran la eficiencia de los procesos administrativos es corrigiendo las desviaciones de una buena práctica. Un ejemplo trivial es el siguiente: las ventas en general se hacen a 30 días por lo que no se ingresa la condición de pago. El módulo de ventas deberá forzar a que ese dato se ingrese, lo que permitirá probar cual es la fecha de vencimiento (al estar impresa en la factura) y además notificar automáticamente a los usuarios del vencimiento.

Cada sector funcional tiene sus propias buenas prácticas, y por lo tanto cada módulo tendrá sus requerimientos específicos. La mayoría de los roles de los trabajadores implica la interacción con varios módulos, los cuales son interdependientes. Como esta lista de requerimientos permite ver, muchos de los procesos comienzan en un módulo y atraviesan varios de ellos antes de finalizar.

Para establecer los aspectos funcionales de los requerimientos nos basamos esencialmente en dos ERPs, SAP R/3 4.6C y J.D. Edwards A7.3 por tratarse en el caso de SAP del líder del mercado y por tener experiencia directa con J.D.Edwards.

2.3.1 Ventas

La utilidad de mantener categorías de clientes es enorme: sirve por un lado para organizarse y por otro para explotar esa información de los clientes. Por ejemplo, la categorización por zonas sirve para optimizar los viajes de los corredores. Otro ejemplo es contar con una condición de pago por defecto para un cliente. Los códigos de actividad de los clientes y otra información de los mismos puede utilizarse para investigaciones de mercado. Mantener información de vendedores que atienden a los clientes sirve, junto con la rentabilidad de los clientes, para el cálculo de comisiones, etc.

El sistema de ventas así mismo debe poder permitir ingresar pedidos de los clientes. Cuando estos pedidos son generados automáticamente son la base del comercio electrónico. Debe ser posible generar automáticamente una factura a partir de un pedido.

La modalidad de facturación dependerá de la modalidad conque opere la empresa. Es deseable que sea lo más amplia posible, incluyendo facturación anticipada, entrega de mercadería con remito, etc.

El sistema deberá permitir el uso de varias listas de precios, las cuales deberán ser altamente configurables. Preferiblemente dependientes de parámetros como el costo de la compra y el lugar de la venta, para incluir gastos de flete. Por ejemplo, a partir del costo de reposición y un porcentaje de margen se genera una lista de precios base. Esa lista de precios se usa para generar otra correspondiente a las sucursales, que le suma al precio el costo del transporte a la sucursal. Existe la práctica de 'inflar' ese precio base para poder otorgar un descuento al pago. Existen muchos ejemplos de este tipo que hacen conveniente que la lista de precios se pueda configurar fácilmente, y que los precios se carguen en la factura automáticamente en función de la forma de pago y del tipo de cliente (si tiene una cuenta corriente o si compra al contado).

Los precios deben poder ser modificados manualmente cuando se decide hacer una rebaja especial. Pero también debe de poder establecerse márgenes, como ser el crédito en la cuenta corriente, y el margen de ganancia mínimo aceptable, de modo de no permitir hacer ventas que excedan esos parámetros.

El módulo de ventas es el más auditado por la DGI ya que es el que emite los comprobantes de venta y los correspondientes reportes. Obviamente, los porcentajes y los tipos de impuestos deberán ser configurables para adecuarse a la legislación impositiva vigente. Esto es especialmente útil en Uruguay donde hay varias peculiaridades, por ejemplo el COFIS.

2.3.2 Cuentas a cobrar (cuenta corriente de clientes)

Aunque hablamos de cuenta corriente de clientes y de proveedores como sistemas separados, puede ser de utilidad mantener un único identificador, tanto si se trata de cliente como de proveedor, porque evita información redundante y permite consolidar otra información.

Es fundamental que tengan un proceso muy ágil para ingresar los comprobantes (imputación) que permita por ejemplo, ingresar un recibo de cobranza a cuenta y después imputarlo a las facturas correspondientes. Los tipos de comprobantes a ingresar deberán ser por lo menos los mencionados arriba, aunque deberían poder configurarse.

Es deseable que se pueda manejar un espectro amplio de documentos: recibos, débitos financieros, notas de crédito, descuentos financieros en recibos, etc.

Sería ideal contar con un interfaz para una lectora de cheques, lo que automatizaría grandemente el ingreso de recibos, aunque esto tiene sentido únicamente cuando muchos pagos son efectuados de este modo.

Algunos requerimientos básicos son la información de los deudores en gestión, datos de empresas como límite de crédito, condiciones de pago, etc. Muchos de los datos de ventas se consultan para la gestión de cobranza, por ejemplo los diarios de ventas.

Es importante contar con consultas específicas que permitan detectar y planificar las cobranzas a realizar, por ejemplo el estados de cuenta por empresa, el resumen de saldos, control de remitos pendientes, vencimientos, días de cobranza, documentos vencidos, etc.

Es a partir de este módulo que se saca información para las comisiones, por ejemplo mediante reportes de remuneraciones y márgenes, y de las cobranzas por vendedor (ya que suele darse comisión no sobre las ventas sino sobre las cobranzas).

2.3.3 Stock

Si bien el stock deberá ser ajustado automáticamente por las ventas, las compras, transformaciones² y transferencias, deberán poder hacerse ajustes de mercadería por rotura, robo, etc. Una funcionalidad útil es la de emitir listados por rangos de artículos (a veces llamados ciclos de conteo), de modo de poder ser usados durante los balances para el conteo de la mercadería y eventualmente ingresar ajustes por balance (en caso que la cantidad física no coincida con la cantidad del sistema).

Las consultas deberán poder hacerse sobre los saldos, donde figuren además la cantidad comprometida de artículos en ordenes de venta y la cantidad a recibirse, en ordenes de compra, transferencias, etc. También deberá poder consultarse todos los movimientos de stock (ficha de stock o cardex), para saber como fue el flujo de la mercadería. Es de especial interés contar con la valoración del stock (existen tres métodos de valoración, LIFO, FIFO y promedio ponderado, siendo éste último el más conveniente por repercutir cualquier entrada de mercadería en el costo total, aunque cualquiera se considera válido).

Otros listados vinculados al stock, aunque podrían incluirse en ventas (y serán utilizados por el personal de ventas) son el stock mínimo, que genere automáticamente un pedido de compra de mercadería, y las ventas promedio. El sistema también, basándose en esos datos deberá poder hacer un pronóstico de ventas.

Debe permitir la creación de agrupaciones de artículos de modo de poder seleccionar distintos tipos de clasificaciones al momento de emitir un informe, p.ej. tener un grupo de artículos por materias primas, otro por productos en proceso y otros por productos terminados. Otro ejemplo es tener familias de productos, con distintos niveles de agrupamiento lo que permite consultas con distinta granularidad. Por ejemplo la familia vestimenta con los correspondientes niveles: Vestimenta/Hombre/Calzado/Deportivo. La necesidad de este tipo de clasificación se hace aparente cuando hay que diseñar estrategias relativas al stock mínimo del que ya se habló. Esto constituye un factor esencial para cualquier comercio o industria.

El sistema debe dar soporte a las transformaciones, p.ej. convertir un material del stock en otro (restando de un saldo y sumando en el otro). Dichas transformaciones pueden ser de n a m (no tienen por que ser de 1 a 1 o de 1 a n). En el caso de las fábricas, o empresas que arman productos (como puede ser un vendedor de hardware), son necesarias las transformaciones, a saber: poder convertir un conjunto de artículos de stock en otro y viceversa, o sea poder fraccionar un artículo en varias partes. La complejidad de la función de composición depende del tipo de empresa, estando las fábricas en el extremo de mayor necesidad.

Si el sistema permite además del código del artículo manejar un código de barras, se simplifican muchas tareas (desde la recepción, hasta la venta, pasando por los balances). Para ello el sistema deberá ser compatible con el hardware de lectura de código de barras.

2.3.4 Compras e importaciones

Se debe poder generar y realizar el seguimiento de ordenes de compra, tanto de los insumos, de los consumos internos y de los artículos que se venden. En particular, puede resultar útil contar con herramientas para el seguimiento y el control de los planes de aprovisionamiento. Los comprobantes (las ordenes de compras) deben dividirse en ordenes de mercadería y de servicios, por ejemplo servicios de agua potable de OSE o los servicios de una empresa unipersonal.

Para el seguimiento es necesario registrar las etapas del proceso; por ejemplo, es bueno que la orden de compra se pueda emitir en papel para enviársela al proveedores por fax, y también que la pueda reimprimir el depósito donde se hace la recepción para controlar mejor.

Deberá habilitarse la creación de pedidos de compra tanto desde depósito (para reposición) como para ventas (de acuerdo a ventas negociadas). También se deberá poder pedir cotizaciones a los proveedores y cargar sus listas de precios con sus descuentos y la forma de pago. Deberá poder consultarse las listas de precios por proveedor de forma ágil, así como información histórica de los precios anteriores y los precios a los que se compró y a cual proveedor.

Cuando se hacen compras importantes, o importaciones, es bueno asegurarse de que son correctas, para lo cual se definen cadenas de aprobación basadas en el precio de compra y la jerarquía de las personas a integrarla. No debería permitirse la impresión de una orden de compra hasta no estar ésta aprobada. Naturalmente para compras inferiores a cierto umbral, no sería necesaria la aprobación. Estos umbrales y cadenas de aprobación deben ser configurables.

Es posible que parte de la mercadería llegue defectuosa, o no llegue o llegue de más. Por ejemplo en el caso de una partida que llegó defectuosa deberá emitirse un remito de entrega al proveedor, el cual podrá enviar mercadería en buenas condiciones o una nota de crédito por el valor de la diferencia. Por ello el sistema debe poder procesar las notas de crédito o débito de los proveedores. Otros ejemplos son: diferencia de precios, recargo por costos de fletes, reconocimiento de bonificaciones, intereses, cheques rechazados, etc. El sistema deberá poder reconocer cada tipo de nota de débito o crédito, para poder emitir listados distintos (además de que cada uno de estos comprobantes mueve cuentas distintas, y pueden generar distintos impuestos).

Respecto a las importaciones, se trata de un proceso similar al de las compras nacionales que venimos tratando, con la salvedad de que deben considerarse además los trámites aduaneros y el pago. Se llama provisión de importaciones a una estimación de cuanto dinero se deberá disponer para el pago de una importación.

Muy someramente, el proceso incluye el envío de un pedido al proveedor (p.ej. por fax). El proveedor envía la lista de los artículos que nos va a vender y su cotización (a la que se le llama proforma). Si se la acepta, hay que enviar el despacho (p.ej. el detalle de las cosas a importar) al despachante junto con otros documentos.

Es de esperarse que un software hecho en otro país no contemple las especificidades de las importaciones en Uruguay³ pero es importante poder implementarlas sin dificultad en el caso de una empresa que importe algún insumo o mercadería.

Sin embargo cabe esperar que el sistema permita almacenar la información para este tipo de transacciones. Recordamos que el proceso de importación requiere la participación de dos bancos, llamados los bancos corresponsales. Uno corresponde al exportador y otro al importador. Hay tres modalidades de pago, una es mediante carta de crédito, otra mediante cobranza y la última por giro (en orden creciente de confianza entre las partes).

Después de notificar la compra al exportador, el importador saca una carta de crédito en un banco local (que tiene un costo) para esa importación (la carta de crédito es un crédito específico para esa importación e incluye el detalle de la misma). El banco del importador la envía al banco del exportador, el exportador le da a su banco los documentos necesarios (packaging list, factura comercial, certificado de origen, conocimiento de embarque, etc.) y el banco le paga. Ahora bien, por un lado a Uruguay llegan los papeles (llegan al banco) y por otro la mercadería (a la aduana). Cuando llegan los papeles el banco notifica al importador, que le paga y recibe esos papeles los cuales le da a la empresa despachante que retira la mercadería de la aduana.

La cobranza funciona en forma similar, solo que no hay carta de crédito que comprometa al pago al importador y si este repudia la carga, deberá ser enviada de nuevo al exportador que pagará los costos. El giro es cuando el exportador envía mercadería y documentos y el importador envía un giro.

El pago entre los bancos es mediante movimientos de diario (o sea, no hay movimiento físico de dinero, sino que p.ej. ambos bancos tienen cuenta en un tercer banco internacional, donde se hacen transferencias de la cuenta de uno a la del otro).

2.3.5 Cuentas a pagar (cuenta corriente de proveedores)

El proceso básico es el siguiente: se genera un pedido de mercadería, se solicita cotizaciones a proveedores, se eligen los mejores precios, se emite la orden de compra, se recibe la mercadería, se ingresa la factura del proveedor al sistema, se genera el pago, se realiza el pago y se aplica el recibo.

Este sistema debería poder calcular la fecha de vencimiento de las facturas a partir de su fecha de origen y forma de pago, generando información para las previsiones de fondos futuros.

Para las importaciones vale hacer algunas puntualizaciones. El documento de divisa es el precio FOB⁴ que se deberá pagar al proveedor en general el pago es mediante una carta de crédito y hay varios bancos involucrados. El ingreso de gastos incluye el flete, el seguro y otros gastos como por ejemplo los concernientes al despachante. Después de ingresado el documento de divisa y los gastos de importación se obtiene el verdadero precio pagado por los artículos prorrateando esos gastos en el precio. Naturalmente, será éste el costo a considerar cuando se haga el costeo de los artículos.

2.3.6 Recursos humanos

Lo ideal sería que pudiera administrar distintos sindicatos, categorías de trabajadores, alternativas de liquidación (p.ej. Sueldos mensuales, liquidación por hora, tickets alimentación, etc) y calcular las retenciones por impuestos. También permitir la emisión de vales, etc.

El sistema tiene que tener una flexibilidad que permita agregar incentivos y partidas extraordinarias con y sin cálculo de aportes y retenciones, así como de comisiones mensuales manuales o automáticas.

Es de esperar que el sistema relacione a un trabajador con un tipo de remuneración; estos tipos de remuneraciones deberán poder definirse y aplicarse automáticamente en cada fecha de remuneración. Esto es, generarse pagos automáticos de haberes a través de bancos conque trabaja la empresa (esta es una modalidad de pago muy frecuente).

Es importante que se pueda contar con valores históricos y promedios de haberes cobrados, por ejemplo para indemnizaciones, aguinaldos, etc. Naturalmente, se espera que el sistema pueda imprimir registros de sueldos de acuerdo a la legislación vigente, con todos los datos identificatorios del trabajador y de las remuneraciones abonadas. También con los datos de donde se ha desempeñado un trabajador (por ejemplo, si trabaja en depósito, o ventas o en el sector de IT si lo hubiere), y conservar la historia si su rol va cambiando.

Es especialmente útil poder generar archivos automáticamente en el formato solicitado por los bancos mediante los cuales se hacen pagos, BPS y DGI (que emplea el software Alfa en Uruguay), o al menos contar con todos los datos necesarios para cargarlos.

Por último, deberá ser posible realizar un control de entradas y salidas mediante un reloj de control de horarios automático, usando tarjetas de marcar.

2.3.7 Contabilidad

La mayoría de los eventos registrados en los otros módulos tienen impactos contables, p.ej. son hechos contables⁵ y generan asientos. Estos asientos generados automáticamente deben poder consolidarse con otros asientos generados a mano. Ya se habló de la practicidad de tener asientos tipos, para ingreso de asientos estándar que permite simplificar tareas de rutina, para los que solamente se cargan los valores correspondientes a cada cuenta.

En el caso de empresas que vendan o compren en dólares (no es tan raro, por ejemplo, en el caso de empresas que vendan a turistas o que importen sus insumos o mercaderías), se deberá poder hacer la conversión adecuada a las distintas monedas extranjeras y generar los asientos por ajuste de tipo de cambio (en el caso de una compra o una venta en moneda extranjera que se hace en un cierto plazo, el importe en moneda nacional puede ir variando, para ello deberá ajustarse mediante asientos contables de diferencia de cambio).

Los asientos predefinidos proveen una forma estándar de representar un hecho contable frecuente. Por ejemplo, un asiento para liquidación de haberes en el que las cuentas a utilizar son las mismas (o tienen muchas cuentas en común). Este asiento se realiza todos los meses, por lo que es útil contar con un asiento tipo al que únicamente hay que modificar los importes.

El sistema deberá permitir la definición de un plan de cuentas y reglas de contabilización automáticas. Estas definiciones son especialmente delicadas. Además, ese plan de cuentas deberá permitir agrupar la cuentas y definirles un código abreviado para simplificar la búsqueda y la carga manual de asientos. También deberá poder definirse una jerarquía, una apertura de cuentas por auxiliares para permitir registrar los hechos contables con más detalle (se recomienda con 6 niveles) Un ejemplo podría ser el siguiente: Activo / Activo corriente / Disponibilidades / Fondo fijo / Fondo fijo para compras.

Suele ser conveniente poder definirse centros de costos (unidades de negocios); la granularidad del costeo tiene mucha relevancia. Por ejemplo, si una empresa cuenta con una sucursal, la mercadería tiene un costo de flete que deberá incorporarse. Si el costo está definido como único para toda la empresa, la precisión del costeo fallará.

Como las entradas se realizan a partir de eventos relacionados con ventas y producción y pagos, se postean (se ingresan en el libro mayor) en tiempo real, y el libro mayor refleja la situación real.

Este módulo debería permitir trabajar con dos o tres ejercicios consecutivos abiertos, de modo de no atrasar la carga de datos hasta que se termine el balance; es una funcionalidad muy importante.

2.3.8 Caja

La 'caja' es el sector por donde se mueve el dinero, por lo cual debe haber un comprobante impreso por cada movimiento de efectivo, para poder auditar la correctitud de dicho movimiento.

En particular, si la empresa hace pagos con cheques (lo cual es lo habitual, y con cheques diferidos que tendrán fondos después de vendido aquello que se pagó con el cheque) sería muy útil poder emitir impresiones de cheques a partir de pagos, y generar días en que se deberá depositar fondos.

A veces hace falta enviar fondos entre sucursales mediante remesas, por lo cual debe estar contemplado la emisión de comprobantes cuando se haga ese tipo de transferencia.

El armado y acreditación de depósitos bancarios también debería gestionarse desde este módulo. En particular, como a la caja llegan todos los comprobantes resultados (p.ej. Conformes, cheques canjeados, devueltos, etc.) debería poder procesarlos, generando asientos adecuados.

2.3.9 Activo Fijo

Es sabido que las posesiones de una empresa se van deteriorando, por envejecimiento, rotura, etc. y tienen una vida útil limitada, y hay que separar dinero para cambiar el bien depreciado. Para lidiar con la depreciación se generan un asiento al final del ejercicio, correspondiente a la amortización.

3La Nomenclatura Común Mercosur (NCM) es un manual con rubros asociados a distintos tipos de mercadería, empleado por la aduana para determinar el arancel (i.e. el porcentaje sobre CIF). También sirve para identificar mercaderías con descuentos al arancel porque exista un convenio. Antiguamente el CENCI proporcionaba un programa con la TGA (Tasa global arancelaria: se compone de recargo, hasta 10%, e IMADUNI, a partir del 10% el resto es IMADUNI). desglosada para cada NCM (dado un NCM daba la TGA). Actualmente este servicio es proporcionado vía una página web. Hay un convenio con Argentina y Brasil, con la factura llega el certificado Mercosur que exonera del recargo asociado al código NCM (para ciertos rubros).

5Los hechos contables son aquellos sucesos puntuales que hacen variar las cuentas de la empresa. Un hecho contable puede ser, por ejemplo, una venta, un pago, una compra, una devolución, etc. La contabilización de los hechos contables se realiza basándose en el método de la partida doble que nos dice que "todo hecho contable afecta como mínimo a dos cuentas". Los hechos contables se reflejan en la empresa en forma de asientos.

Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.

2.3 Requerimientos por módulo