Libro SISTEMAS AUTOMATIZADOS DE CONTABILIDAD

SISTEMAS AUTOMATIZADOS
DE CONTABILIDAD
Dr. Jorge Barrera Ortega

…….
…….
Octubre 2014
1
2
CONTENIDO
1 Introducción ................................................................................................................................ 7
2 El ciclo contable manual.............................................................................................................. 9
2.1 Contenido del ciclo contable ............................................................................................... 9
2.2 La recepción del documento primario .............................................................................. 10
2.3 La definición de las cuentas a afectar ............................................................................... 11
2.4 El registro en el libro diario ............................................................................................... 13
2.5 El archivo del documento primario ................................................................................... 14
2.6 La gestión de activos y pasivos pendientes ....................................................................... 15
2.7 El registro de los asientos en los libros mayores .............................................................. 16
2.8 La conciliación de los estados de cuenta .......................................................................... 16
2.9 El balance de comprobación ............................................................................................. 17
2.10 La depuración de errores .................................................................................................. 18
2.11 La emisión de los estados financieros ............................................................................... 18
3 Niveles de automatización de los SAC ...................................................................................... 19
3.1 Producir un diario en soporte electrónico ........................................................................ 19
3.2 Transaccional..................................................................................................................... 20
3.3 Recepción de documentos primarios en soportes electrónicos ....................................... 21
3.4 Integración del SAC en un ERP .......................................................................................... 22
3.5 Interacción con otros sistemas automatizados................................................................. 23
4 Principales hitos en el desarrollo de los ERP o SAC................................................................... 27
4.1 Surgimiento de la contabilidad actual............................................................................... 27
4.2 Los equipos de tarjetas perforadas ................................................................................... 28
4.3 Las computadoras ............................................................................................................. 34
4.4 Las redes de terminales..................................................................................................... 40
4.5 Las minicomputadoras, las bases de datos y UNIX ........................................................... 41
4.6 Las PC, las fibras ópticas, Internet y los celulares ............................................................. 42
4.7 El futuro inmediato ........................................................................................................... 47
5 Componentes de los ERP o SAC ................................................................................................ 51
5.1 Los componentes .............................................................................................................. 51
5.2 Las computadoras ............................................................................................................. 52
5.3 Las telecomunicaciones .................................................................................................... 57
3
5.4 La información................................................................................................................... 62
5.5 Los programas informáticos .............................................................................................. 72
5.6 Los recursos humanos ....................................................................................................... 76
5.7 Los aspectos metodológicos ............................................................................................. 77
5.8 Los aspectos legales .......................................................................................................... 78
5.9 La organización .................................................................................................................. 79
5.10 La seguridad y protección ................................................................................................. 80
6 Clasificación y tipos de ERP o SAC ............................................................................................. 87
6.1 Características Funcionales ............................................................................................... 87
6.2 Características del software utilizado para el ERP o SAC .................................................. 91
7 Principales características de los ERP ........................................................................................ 95
7.1 Principales módulos .......................................................................................................... 96
7.2 Integración ........................................................................................................................ 97
7.3 Otras características .......................................................................................................... 99
7.4 La selección e implantación de un ERP, los riesgos ........................................................ 101
8 Principales ERP o SAC en uso .................................................................................................. 105
8.1 SAP R/3 – Business Suite ................................................................................................. 107
8.1.1 Introducción ............................................................................................................ 107
8.1.2 Características principales del R/3 .......................................................................... 110
8.1.3 Módulos del R/3 ...................................................................................................... 111
8.1.4 Ambiente de desarrollo del R/3 .............................................................................. 114
8.1.5 SAP Business Suite ................................................................................................... 116
8.1.6 Ambiente de desarrollo para el SAP Business Suite ............................................... 119
8.1.7 Anexo 1. Lista de módulos del SAP R/3 en el 2007 ................................................. 122
8.2 SABIC ............................................................................................................................... 125
8.2.1 Aspectos históricos y principales características del SABIC .................................... 125
8.2.2 Principales servicios que brinda el SABIC ................................................................ 132
8.2.3 Principales elementos arquitectónicos del SABIC ................................................... 136
8.2.4 Base de clientes ....................................................................................................... 140
8.2.5 Tecnologías utilizadas.............................................................................................. 141
8.2.6 Requerimientos ....................................................................................................... 142
8.3 Odoo (OpenERP).............................................................................................................. 143
4
8.3.1 Aspectos generales.................................................................................................. 143
8.3.2 Módulos funcionales ............................................................................................... 145
8.3.3 Presentación de los resultados ............................................................................... 154
8.3.4 Metodología para el desarrollo de una aplicación .................................................. 158
8.3.5 Aspectos financieros del uso de Odoo .................................................................... 159
8.4 SISCONT ........................................................................................................................... 161
8.4.1 INTRODUCCIÓN ....................................................................................................... 161
8.4.2 Módulos que lo componen ..................................................................................... 162
8.4.3 Tecnología ............................................................................................................... 166
8.4.4 Requerimientos mínimos de software y hardware ................................................. 168
8.4.5 Interfaces con otros productos ............................................................................... 168
8.4.6 Instalación y Componentes de entrega................................................................... 169
8.4.7 Soporte y Mantenimiento ....................................................................................... 169
Bibliografía ...................................................................................................................................... 171
5
PAGINA DEJADA INTENCIONALMENTE EN BLANCO
6
1 Introducción
A principios del 2011 fue necesario revisar y modificar, con cierta urgencia, el contenido de la
asignatura Sistemas Automatizados de Contabilidad (SAC), que se imparte en el cuarto año de la
carrera de Contabilidad y Finanzas, de la facultad con igual nombre, de la Universidad de la
Habana.
El principal cambio en el contenido del curso consistió en revisar el tema desde la perspectiva de
los sistemas de planificación de recursos empresariales (ERP por su nombre en inglés), ya que los
mismos han absorbidos los anteriores SAC, en un proceso similar a lo sucedido con los transistores
y diodos que se incorporaron a los circuitos integrados o microprocesadores. De elementos per se,
han pasado a ser meros componentes.
Las notas para el ciclo de conferencias que se impartieron con el nuevo perfil de la asignatura,
dieron pie a la confección del presente libro, cuya primera versión deberá estar disponible para el
curso del 2015 – 2016.
Este libro consta, además de esta introducción, de los siguientes capítulos:
 El ciclo contable manual
 Niveles de automatización de los SAC
 Principales hitos en el desarrollo de los ERP o SAC
 Componentes de los ERP o SAC
 Clasificación y tipos de ERP o SAC
 Principales características de los ERP
 Descripción de ERPs o SACs en uso
El capítulo del ciclo contable manual describe los principales procesos, que tradicionalmente
forman parte de ese ciclo, y presenta un diagrama de bloques con el ciclo en su conjunto y
esquemas de cada proceso cuando se entiende conveniente.
Los niveles de automatización de los SAC se describen en el segundo capítulo, en un orden
cronológico, a partir de que se fueron creando las condiciones requeridas.
En los principales hitos en el desarrollo de los ERP o SAC se comentan los cambios tecnológicos, y
los personajes que estuvieron involucrados en los mismos, que propiciaron este proceso;
comenzando por los inicios de la contabilidad y recorriendo los últimos 60 año, etapa sin
precedentes en el desarrollo de los medios técnicos, las comunicaciones y, naturalmente, el
software.
El capítulo de componentes de los ERP o SAC contiene una explicación de los aspectos a considerar
en cada uno de ellos (los recursos humanos, las computadoras, las telecomunicaciones, los
programas informáticos, la información, los aspectos metodológicos, organizativos y legales, y la
seguridad y protección), incluyendo, cuando procede, el estado del arte, y sus principales
interrelaciones.
7
La clasificación y tipos de ERP o SAC describen principalmente los aspectos a tener en cuenta a la
hora de seleccionar uno de estos sistemas.
Las principales características de los ERP discuten los objetivos de estos sistemas, las tecnologías
que emplean, los pasos que deben cubrirse para introducir uno de ellos, y los principales retos a
manejar durante ese proceso.
Por último la Descripción de ERPs o SACs en uso, presenta una síntesis sobre el Open ERP, el
Sabic, el Siscom, y el SAP.
Teniendo en cuenta la velocidad actual de los cambios tecnológicos en las disciplinas que tienen
que ver con el tema de este libro, el autor consideran que el mismo deberá ser revisado y
actualizado el menos cada tres años.
8
2 El ciclo contable manual
2.1 Contenido del ciclo contable

El registro contable de una actividad cualquiera se lleva a cabo a través de la ejecución de un
grupo de procesos de forma iterativa.
Los principales procesos que conforman el ciclo contable son:
 Recepción del documento primario

 Definición de las cuentas a afectar
 Registro de los asientos contables en el libro diario
 Archivo del documento primario
 Gestión de los activos y pasivos pendientes
 Registro en los libros mayores de los asientos contables
 Conciliación de los estados de cuenta
 Emisión del balance de comprobación
 Depuración de errores
 Emisión de los estados financieros
Los primeros cuatro procesos se realizan en el momento que lo demande la llegada del
documento primario, según las exigencias de las normas contables en general y de la institución
en particular.
Las pequeñas empresas con pocos movimientos contables pueden permitirse acumular
documentos de varios días, antes de registrarlos en el libro diario. Otras entidades, como los
bancos, al tener que tomar decisiones operativas de su gestión a partir de los saldos contables, se
ven obligadas a registrar de forma inmediata al menos algunos tipos de documentos primarios.
Una buena práctica, aceptada de forma universal, es registrar en el libro diario todos los
documentos primarios durante el mismo día que se reciben en la unidad organizativa encargada
de la contabilidad.
Los restantes procesos del ciclo contable se realizan cada ciertos períodos, que van desde un día
hasta un mes, en dependencia también de las normas contables vigentes y de las exigencias de la
institución.
La conciliación de los estados de cuenta y la emisión del Balance de Comprobación permiten la
detección de ciertos errores en el registro del diario y de los mayores. Cuando esto ocurre, es
necesario depurarlos.
El cuadro 2.1 muestra esquemáticamente la realización del ciclo contable.
Los procesos expuestos como parte del ciclo contable son los propios de la contabilidad clásica, en
la que una unidad de contabilidad recibe los documentos generados en las restantes áreas de la
entidad con el fin de realizar el registro contable. Como se explicará más adelante, la
introducción del procesamiento electrónico de datos ha modificado sustancialmente este ciclo, al
extremo de que algunos procesos han desaparecido.
9
REGISTRO
DOCUMENTOS Recepción documento primario DE
REGIS
ENTRADA
PRIMARIOS
Definición de cuentas a afectar
DIARO
REGIS
Registro en el diario Gestión de carteras
Archivo de documento CARTERAS
DOCUMENTOS
PRIMARIOS
NO
FIN PERIODO
SI
Depuración de errores Registro en mayor MAYOR

REGIS
Conciliación de estados de cuenta

SI
ERRORES
BALANCE
Emisión balance de comprobación DE
REGIS
COMPROBACION
SI
ERRORES
BALANCE
ESTADO
REGIS DE
Emisión de estados financieros RESULTADOS
Cuadro 2.1 Esquema del flujo contable Elaboración propia
2.2 La recepción del documento primario

La recepción del documento primario (ver cuadro 2.2) es un proceso que en muchos casos se
menosprecia. Cuando esto ocurre, muchos de los errores en los registros contables se deben a un
procedimiento inadecuado o incompleto para la recepción de esos documentos. En una oficina, el
extravío de un documento, ya sea porque fue a parar a un sitio al que no corresponde (“se
traspapeló”), o porque incluso se destruyó o botó, es, desafortunadamente, un hecho bastante
frecuente.
10
Recepción de documento primario
Almacenes
Contabilidad
Producción
DOCUMENTO PRIMARIO REGISTRO DE ENTRADA
Ventas
Recursos Humanos
Cuadro 2.2 Recepción de documento primario. Elaboración propia
Llevar un registro de entrada de los documentos primarios recibidos, en el que se le dé un número

único a cada documento, se anoten sus fechas de confección y recepción, la persona que lo
entregó y la que lo recibió, así como los principales datos del documento que faciliten su
localización y el posterior tratamiento que se le vaya dando al mismo, es una medida práctica que
permite disminuir los riesgos de extravíos, o al menos detectarlos de forma oportuna.
El archivo temporal de los documentos a procesar es también de gran importancia. Hay quienes
afirman que los documentos que deben ser procesados no se deben guardar nunca en gavetas,
que siempre deben estar a la vista, lo cual puede ser una buena medida para volúmenes pequeños
y medios.
En todos los casos alguien debe ser responsable de, al menos una vez al día, revisar los
documentos pendientes contra el registro de entrada y explicar, si corresponde, porque aún no se
han procesado.
2.3 La definición de las cuentas a afectar

La definición de las cuentas a afectar (ver cuadro 2.3) para el registro de un documento es una
tarea que debe realizarse por el personal de mayor calificación contable. Esta definición se realiza
a partir del tipo de documento, el plan contable vigente y los procedimientos generales
establecidos, y debe quedar debidamente documentada.
11
Definición de cuentas a afectar
DOCUMENTO PRIMARIO
Maqueta de Transacción
Escaque x -> Cuenta 1 / Signo

Escaque y -> Cuenta 2 / Signo
Escaque z -> Cuenta 3 / Signo
Plan de cuentas
.
.
Escaque w -> Cuenta n / Signo
Procedimientos
Cuadro 2.3 Definición de las cuentas a afectar. Elaboración propia
Los tipos de documentos que se reciben para su contabilización son por lo general uniformes,
aunque no siempre iguales. Así, por ejemplo, una factura comercial debe contener todos los datos
que se requieren para su registro en el diario, pero no siempre con el mismo formato ni con el
mismo detalle. (Ver cuadro 2.4)
Conceptos contables
Db cuentas por cobrar Fecha valor Contraparte Importe
Cr ingresos por ventas
FACTURA
Fecha: Cliente:
Producto Cantidad Precio Valor
Total
Conceptos contables
Cr Productos terminados Contraparte 1 Contraparte 2 Fecha valor Importe
Db Prod. entregados a cliente
Cuadro 2.4 Maqueta de contabilización de una factura. Elaboración propia
12
El plan contable de una entidad, o clasificador de cuentas, debe partir de lo orientado por las
autoridades del país, pero puede ser más detallado con el fin de cubrir requerimientos internos.
En los casos en que el plan contable requiera ser más detallado que el establecido por las
autoridades, debe garantizarse que las cuentas que se añaden sean siempre un desglose de las
obligatorias, con el fin de poder obtener los saldos y movimientos de estas últimas por simple
agregación.
Los procedimientos generales existentes deben definir el flujo de los documentos, qué
información de cada uno debe registrarse contablemente, y cual debe llevarse eventualmente a
otros registros operativos.
El resultado de este proceso es la definición de una maqueta de la transacción1 que se registrará
en el diario a partir del documento primario.
Una buena definición de las cuentas a afectar, por cada tipo de documento que se recibe para su
contabilización, facilita posteriormente la automatización del registro contable. Obviamente,
siempre existirán excepciones que deben ser tratadas caso a caso por personal con suficiente
calificación.
2.4 El registro en el libro diario

El registro en el libro diario de los datos de un documento primario (ver cuadro 2.5) es una labor
rutinaria, en esencia de transcripción, cuando existe una maqueta de la transacción. Esta tarea
requiere, no obstante, un especial cuidado con el fin de que no se produzcan errores. En este
proceso se genera por cada transacción, adicionalmente, un comprobante que da fe de la
contabilización efectuada.
En ciertos casos, el documento primario a registrar en el diario constituye de por si un registro de
varias transacciones, que debe verse como un desglose del diario. Este es el caso, por ejemplo, de
las cintas de papel producidas por las terminales de puntos de venta, que contienen el detalle de
lo vendido y constituyen un documento primario, del cual se registra sólo el valor total.
1
En el presente trabajo se utilizará el término transacción para definir el conjunto de asientos contables (partidas de
débitos o créditos) que deben registrarse de forma integral en el diario para que este mantenga su consistencia. Como
mínimo una transacción deberá estar integrada por dos asientos, uno débito y uno crédito, y siempre su saldo total
deberá ser igual a cero.
13
Registrar en el diario
Diario general
DOCUMENTO PRIMARIO Fecha Cuenta/Observaciones Referencia Débitos Créditos
1/1/2012 Cuentas por cobrar Factura 1 10000

Ingresos por ventas 10000
Venta a empresa XXX
Maqueta de Transacción
Comprobante
Escaque x -> Cuenta 1 / Signo
Referencia Factura 1
Escaque y -> Cuenta 2 / Signo Fecha 1/1/2012
Escaque z -> Cuenta 3 / Signo
. Cuenta Débito Crédito
. Cuenta por cobrar 10000
Escaque w -> Cuenta n / Signo Ingresos por ventas 10000
Observaciones
Venta a empresa XXX
Cuadro 2.5 Registrar en el diario. Elaboración propia
2.5 El archivo del documento primario

El archivo del documento primario (ver cuadro 2.5) debe realizarse utilizando un criterio uniforme,
que permita con posterioridad su rápida localización. La existencia de un registro de entrada, que
le otorgue un número secuencial único a cada documento, proporciona un criterio simple de
archivo de los documentos primarios y sus correspondientes comprobantes de contabilización.
En lugares con un gran volumen de documentos es a veces conveniente estratificar el archivo, por
ejemplo, con carpetas por cada día contable.
No se recomienda utilizar otros criterios de archivo de los documentos primarios, como clientes,
suministradores, dependencias organizativas, etc. Cuando se emplea alguno de esos criterios,
cualquier error en el archivo de un documento es de muy difícil detección. Por otra parte, los
datos contenidos en el registro de entrada deben permitir clasificar de forma simple los
documentos primarios por cualquiera de esos criterios, con el fin de facilitar su localización.
Cuando el documento primario contabilizado deba ser objeto de algún proceso posterior, se
requiere, adicionalmente a su archivo secuencial, el archivo de una copia del documento en un
orden cronológico ascendente de las fechas en que esos documentos deben ser tratados. A este
archivo cronológico de los documentos sobre activos o pasivos pendientes (follow up en inglés)
también se le da el nombre de cartera.
14
Archivo de documentos primarios
POR NUMERO DE
REGISTRO DE ENTRADA
DOCUMENTO PRIMARIO
DOCUMENTOS
PRIMARIOS Y
COMPROBANTES
DE
CONTABILIZACION
Comprobante
Referencia TPV 12
EN ORDEN CRONOLÓGICO
Fecha 1/1/2012 DE VENCIMIENTO
Cuenta Débito Crédito (EVENTUAL)
Efectivo 5432.34
Ingresos por ventas 5432.34
Observaciones CARTERAS
Ventas TPV 12 COPIA
DOCUMENTO
PRIMARIO
Cuadro 2.6 Archivo de documentos primarios. Elaboración propia
2.6 La gestión de activos y pasivos pendientes

La gestión de activos y pasivos pendientes tiene una gran importancia para la actividad financiera
de la institución, y no es más que la revisión periódica de las carteras que se conformaron con
copias de los documentos primarios procesados que requerían un posterior tratamiento, junto con
la ejecución de las acciones que sea necesario realizar en dependencia de las características del
documento, por ejemplo, enviar un recordatorio a un cliente con una cuenta por pagar.
En general, este proceso debe realizarse diariamente y, para todos los documentos que estén
vencidos o venzan ese día, se deberá: o ejecutar una acción, o decidir una fecha posterior en la
que se deberá actuar.
De modificarse la fecha de vencimiento, se reubicará el documento dentro de la cartera.
Si la demora en la ejecución del activo o pasivo implica un cambio en el concepto contable, se
modificará la cuenta y se registrará este cambio en el diario.
Así, por ejemplo, una cuenta por cobrar que tenga más de 30 días debe pasarse, según las normas
vigentes en la actualidad, de cuentas por cobrar a cuentas por cobrar vencidas, a través de su
registro en el diario.
Algo similar ocurre cuando un hecho provoca el cambio del concepto contable de una cartera. Por
ejemplo, cuando se recibe una letra como garantía del pago de una cuenta por cobrar, el
documento en cuestión, junto con la letra, deben pasar de las cuentas por cobrar a los efectos por
cobrar. Este cambio, obviamente, debe registrarse también en el diario.
15
2.7 El registro de los asientos en los libros mayores
El registro de los asientos en los libros mayores (ver cuadro 2.7) se hace a partir del libro diario,
permite calcular para cada cuenta su saldo y deja una traza de todos los movimientos que lo
alteraron. En un ambiente clásico de contabilidad, donde los mayores se llevan manualmente, esta
tarea es, al igual que el registro en el diario, rutinaria y básicamente de transcripción y suma,
aunque no por ello exenta de errores.
Registrar en mayores
Diario general
Fecha Cuenta/Observaciones Referencia Débitos Créditos
1/1/2012 Efectivo TPV 12 5432.34

Ingresos por ventas 5432.34
Ventas TPV 12
…..
……
1/1/2012 Cuentas por cobrar Factura 1 10000
Ingresos por ventas 10000
Ventas a Empresa XXX
Mayor Ingresos por ventas

Fecha Referencia Débitos Créditos Saldo
1/1/12 TPV 12 5432.34 5432.34
1/1/12 Factura 1 10000 15432.34
Mayor Efectivo
1/1/12 TPV 12 5432.34 5432.34
Mayor Cuentas por cobrar

1/1/12 Factura 1 10000 10000
Cuadro 2.7 Registro en mayores. Elaboración propia
2.8 La conciliación de los estados de cuenta

La conciliación de los estados de cuenta es uno de los procesos que mayor seguridad le da a los
registros contables. La probabilidad de que dos entidades cometan por separado el mismo error
en sus registros contables es extraordinariamente baja, por lo que comparar los saldos y
movimientos de cuentas comunes y garantizar que sean iguales, aumenta considerablemente la
confiabilidad de los datos.
Existen dos formas de conciliar los estados de cuenta: la activa y la pasiva.
La forma activa de conciliación consiste en solicitar un estado de cuenta a la contraparte, por lo
general un suministrador de productos o servicios de la entidad, y comparar ese estado de cuenta
con los registros propios.
La más utilizada de las conciliaciones activas, y una de las más importantes en general, es la
conciliación del estado de cuenta que emiten los bancos.
No es excepcional que entidades registren en el diario su cuenta de banco a partir del estado de
cuenta que este les envía. Esa práctica no es necesariamente la más sana. El estado de cuenta de
un banco no debe considerarse en todos los casos como un documento primario, sino como un
16
documento para la conciliación, sobre todo cuando el estado de cuenta no se recibe diariamente
sino, por ejemplo, una vez al mes.
Mover la cuenta de banco a partir de los propios documentos con que cuenta la empresa o a partir
de notas de débito o crédito solicitadas al banco, cuando estos documentos no existen2, dejando
el estado de cuentas para la conciliación, debe producir mejores resultados.
La forma pasiva de conciliación se utiliza normalmente con clientes de la entidad y consiste en
elaborar un estado de la cuenta del cliente y enviárselo, solicitándole que comunique sus
discrepancias o conformidad con el mismo en un plazo razonable.
2.9 El balance de comprobación

El balance de comprobación (ver cuadro 2.8) se emite a partir de los libros mayores.
Emitir Balance de Comprobación

Mayor Ingresos por ventas
Mayor Efectivo
1/1/12 TPV 12 5432.34 5432.34
1/1/12 TPV 12 5432.34 5432.34
1/1/12 Factura 1 10000 15432.34
Mayor Cuentas por cobrar

1/1/12 Factura 1 10000 10000
Balance de comprobación
Cuentas Saldo inicial Débitos Créditos Saldo final
Activos
Pasivos
Capital
Total 0 XXXXX XXXXX 0
Cuadro 2.8 Emitir balance de comprobación. Elaboración propia
Generalmente, el balance de comprobación contiene una lista de todas las cuentas de la entidad
con cuatro posibles valores: saldo inicial, que es el saldo del último balance de comprobación
cuadrado, débitos, con la suma de todos los débitos que se han registrado en la cuenta durante el
período, créditos, con la suma de todos los créditos que se han registrado en la cuenta durante el
período, y saldo final, con el saldo de la cuenta al momento de emitirse.
Si no se han producido errores en el registro del diario y de los mayores, la suma de las columnas
saldo inicial y final debe ser cero y el total de la columna débitos debe ser igual al de la columna de
2
Cuando un pago se realiza a través de una transferencia bancaria no siempre el pagador le envía un
documento al acreedor notificando ese hecho. En estos casos la nota de crédito que recibe el acreedor, o el
crédito en el estado de cuenta, representan de hecho el documento primario para la contabilización.
17
créditos. Cuando esto no es así, deben revisarse el diario, los mayores y en ciertos casos hasta los
documentos primarios, con el fin de localizar los errores y corregirlos.
2.10 La depuración de errores

La depuración de errores es un proceso que puede descomponerse básicamente en tres tareas: la
detección del error, la localización de las causas que lo provocaron y la corrección del mismo.
Las principales fuentes de detección de errores, como ya se ha explicado, son la conciliación de los
estados de cuenta y la emisión y cuadre del balance de comprobación.
La localización de las causas que provocaron un error determinado se logra normalmente con una
mezcla de conocimiento, experiencia, algo de arte y bastante esfuerzo.
En general, la mejor fórmula es ir acumulando información sobre los procesos que dieron origen a
los datos discrepantes, hasta que la causa del error se haga evidente.
En un sistema contable, cuando el error se origina en el registro del diario, la corrección debe
realizarse siempre reversando los asientos originales, a través de su registro con signo contrario, e
introduciendo nuevamente la transacción con los datos correctos.
2.11 La emisión de los estados financieros

La emisión de los estados financieros, básicamente el balance general y el estado de resultados, se
puede realizar a partir del balance de comprobación o de los libros mayores, una vez que se han
depurado los posibles errores.
Las normas de contabilidad vigentes condicionan el formato de los estados financieros que deben
ser entregados a la autoridad fiscal y que son objeto de auditoría. Frecuentemente las entidades
tienen otros formatos de estados financieros, más detallados y ajustados a sus requerimientos de
análisis y toma de decisiones.
18
3 Niveles de automatización de los SAC
3.1 Producir un diario en soporte electrónico

La automatización del ciclo contable en el marco de la elaboración de un Sistema Automatizado de
Contabilidad (SAC) ha pasado por diversos estadios y aun no puede darse por concluida
totalmente.
En una primera etapa (ver cuadro 3.1), a partir de las posibilidades de los medios de computación
existentes en aquel momento, el esfuerzo se concentró en producir un diario en soporte
electrónico que permitiera la automatización de algunos procesos posteriores. Ya con el uso de
equipos de tarjetas perforadas, a partir de los años 20 del pasado siglo, este nivel de
automatización era factible.
Los procesos que en este estadio quedaron totalmente automatizados fueron el registro en los
mayores, la emisión del balance de comprobación y la emisión de los estados financieros. La
gestión de las carteras en esta etapa sólo pudo automatizarse parcialmente, con la emisión de
reportes periódicos sobre las partidas vencidas.
El principal efecto de este primer paso de la automatización de la contabilidad fue la eliminación

de los errores de transcripción y suma que se cometían en la confección del balance de
comprobación, los mayores y los estados financieros, y la notable disminución del tiempo
requerido para realizar esas tareas.
REGISTRO
REGIS
ENTRADA
PRIMARIOS
Definición de cuentas a afectar Gestión de carteras
Registro en el
diario CARTERAS
LEYENDA
Archivo de documento DOCUMENTOS
AUTOMATIZADO
PRIMARIOS AUTOMATIZADO
DIARO NO PARCIALMENTE
FIN PERIODO
MANUAL
SI
Registro en mayor MAYORES

Depuración de errores

SI
ERRORES
BALANCE
REGIS
COMPROBACION
SI
ERRORES
BALANCE
ESTADO
REGIS DE
Cuadro 3.1 PRIMER NIVEL DE AUTOMATIZACIÓN. Elaboración propia
En este primer estadio de la automatización, el registro en el diario se continuaba haciendo

asiento por asiento, con lo que el cuadre total no estaba garantizado.
19
3.2 Transaccional
Con el desarrollo de los medios de computación y la ampliación de las posibilidades de su
programación, se pasó a un segundo estadio, en el que la maqueta de una transacción se incluye
en la lógica del programa de captación de los datos del documento primario. Utilizando esos
programas, una vez introducidos los datos y verificada su validez formal, se generan los asientos
contables correspondientes (ver cuadro 3.2).
REGISTRO
REGIS
ENTRADA
PRIMARIOS

(incluye la lógica de
las transacciones) CARTERAS
LEYENDA
Archivo de documento DOCUMENTOS AUTOMATIZADO
PRIMARIOS
AUTOMATIZADO
DIARO NO
FIN PERIODO PARCIALMENTE
MANUAL
SI
Depuración de errores Registro en mayor MAYORES

SI
ERRORES
BALANCE
REGIS
COMPROBACION
BALANCE
ESTADO
REGIS DE
Cuadro 3.2 SEGUNDO NIVEL DE AUTOMATIZACIÓN. Elaboración propia
Debido a que el trabajo de una computadora puede interrumpirse en cualquier momento, para
que el fichero diario no quedara en ningún momento incoherente por la actualización parcial de
los asientos que componen una transacción, los medios de programación, y en particular las bases
de datos, tuvieron que evolucionar hasta el punto de garantizar que el conjunto de actualizaciones
de ficheros requeridas para registrar una transacción, o se hiciera en su totalidad o no se hiciera.
Esta característica de las bases de datos se le da el nombre de actualización atómica, por el hecho
de que la transacción se considera como un átomo indivisible.
Un segundo aspecto a resolver por las bases de datos fue que la transacción garantizara el
cumplimiento de un grupo de reglas formales definidas previamente. Por ejemplo, el código de un
cliente al que se le quiere registrar una cuenta por cobrar debe existir en la tabla de clientes, en la
que se encuentran todos los datos necesarios sobre el mismo.
Para garantizar esta consistencia en la base de datos, es necesario que cuando una transacción
incumpla alguna de las reglas formales definidas, la misma sea rechazada en su totalidad, en
correspondencia con la característica de atomicidad explicada previamente.
20
Con la inclusión de la maqueta de la transacción en los programas para la actualización del diario,
fue posible garantizar totalmente el cuadre contable y otros aspectos formales desde un inicio de
este, obviamente siempre y cuando estos programas no tuvieran errores.
Una consecuencia de este avance es que la emisión del balance de comprobación para la
detección de posibles errores de cuadre se hace innecesaria3, ya que el conjunto de los saldos de
las cuentas del mayor se conforma sumando los asientos de las transacciones a la cuenta que
corresponda, y si cada transacción está cuadrada, la suma de ellas tiene que estarlo también
forzosamente.
3.3 Recepción de documentos primarios en soportes electrónicos

El siguiente paso en la automatización de los registros contables de una entidad se produjo con la
recepción de los documentos primarios en soportes electrónicos (ver cuadro 3.3).
Existen múltiples alternativas técnicas para lograr este objetivo, que van desde utilizar soportes
externos (cintas magnéticas y discos flexibles en un inicio, DVDs, memorias flash, etc. en la
actualidad) que se entregan manualmente, hasta que los clientes internos y externos de la
entidad, que realizan las operaciones que deben registrarse contablemente, interactúen
directamente a través de redes informáticas con el sistema contable.
DOCUMENTOS
Recepción documento primario REGISTRO
DE
PRIMARIOS
ENTRADA

(incluye la lógica de
las transacciones) CARTERAS
LEYENDA
Archivo de documento AUTOMATIZADO
DOCUMENTOS
PRIMARIOS AUTOMATIZADO
DIARO PARCIALMENTE
NO
FIN PERIODO
MANUAL
SI
Registro en mayor MAYORES

Depuración de errores

SI
ERRORES
BALANCE
REGIS
COMPROBACION
BALANCE
ESTADO
REGIS DE
Cuadro 3.3 TERCER NIVEL DE AUTOMATIZACIÓN. Elaboración propia
3
El balance de comprobación, además de su objetivo original de detectar posibles descuadres, que en un
sistema automatizado que funcione correctamente es innecesario, cumple también otras funciones
informativas y de análisis, por lo que normalmente se emite de forma sistemática
21
El acceso simultáneo al sistema contable por múltiples usuarios introdujo la necesidad de que los
sistemas de bases de datos garantizaran que no se produjeran interferencias entre las
transacciones que en un mismo momento se estaban ejecutando. A esta característica de las
bases de datos se le da el nombre de aislamiento (isolation en inglés). La misma garantiza que las
diferentes transacciones se ejecuten finalmente siempre de forma secuencial, una tras la otra.
Por último, para que las bases de datos pudieran ser el soporte de las operaciones vitales de una
entidad las mismas tuvieron que garantizar que en ningún momento se perdieran datos ya
registrados (durabilidad de las actualizaciones). Esta característica se logra de múltiples formas,
entre las que se destacan las salvas totales de ciertos estados de la base de datos y las bitácoras de
todo lo hecho, almacenadas en medios físicos diferentes.
Con las posibilidades actuales de la comunicación y las computadoras no es raro que, para
aplicaciones importantes, se actualice en paralelo y en tiempo real una copia de la base de datos,
ubicada físicamente en otra localidad, con lo que se logra una seguridad casi total.
Cuando un sistema de gestión de bases de datos cumple los cuatro requisitos explicados
anteriormente se dice que el mismo pasa la prueba A.C.I.D., por el nombre de esas características
en inglés (Atomicity, Consistency, Isolation y Durability) (ver 1).
3.4 Integración del SAC en un ERP

El siguiente estadio en la automatización del ciclo contable está dado por la integración del
sistema contable en el sistema automatizado de toda la actividad de la entidad en cuestión.
Este cuarto nivel de automatización de los sistemas contables se caracteriza porque no se
entregan documentos en la entidad de contabilidad, sino que los subsistemas que funcionan en las
diferentes áreas de la empresa producen como un subproducto los datos contables, y los envían
de forma automática, a través de las redes de computadoras, al subsistema de contabilidad y
finanzas.
El surgimiento de sistemas para la planificación de los recursos de una empresa (ERP por sus siglas
en inglés, Enterprise Resource Planning) es el resultado de esta etapa de la automatización, no ya
del sistema contable, sino de toda la actividad empresarial.
El cuadro 3.4 muestra el esquema del ERP SAP R/3, que mantiene un liderazgo indiscutible en este
tipo de aplicación.
22
ERP SAP R/3
Integración en Extensa
SD FI
tiempo real Comercial Gestión funcionalidad
financiera
MM CO
Materiales Control
Abierto y
flexible
PP
Producción
R/3 TR
Tesorería
Arquitectura
modular
QM Client/Server PS
Proyectos
Arquitectura
Cliente/Servidor
Calidad
PM ABAP/4 WF
Mantenimiento
Flujo de
trabajo
HR IS
Recursos Soluciones
humanos sectoriales
Modelo de Multi...
gestión
Cuadro 3.4 ESQUEMA DE SAP/R3. (tomado de 43)
En SAP, las funciones que pudieran considerarse propias de un sistema de contabilidad, son parte
de cuatro módulos (Gestión financiera, Control, Tesorería y Proyectos), todos integrados entre sí y
con los demás módulos automatizados de la empresa.
Los ERP garantizan, entre otros aspectos, que toda la información de una entidad tenga una
fuente única definida, con lo que se elimina la redundancia en los datos, que siempre es el primer
paso hacia las contradicciones entre los mismos.
3.5 Interacción con otros sistemas automatizados

Por último los sistemas automatizados, ya sean sólo de contabilidad o ERP, son en la actualidad
capaces de interactuar con sistemas automatizados de otras entidades, con el fin de ejecutar
operaciones de forma automática, o enviar y recibir datos requeridos para sus procesos.
La generalización de estas posibilidades pasa por la existencia de normas detalladas que definan
formalmente la interacción entre sistemas automatizados para resolver ciertas tareas.
A diferencia de los humanos, los sistemas automatizados no tienen, al menos por el momento, la
capacidad de improvisar, por lo que todas las posibles acciones a realizar y los datos a
intercambiar en una interacción entre ellos, tienen que estar totalmente previstos y formalizados.
Se le da el nombre de protocolo al conjunto de definiciones que permite que dos equipos de
computación o comunicación intercambien información de forma ordenada.
Con las posibilidades que brinda la interacción entre sistemas automatizados es factible eliminar
en gran medida la gestión de las carteras, así como la conciliación de los estados de cuenta del
23
flujo contable explicado al inicio (ver cuadro 3.5), con lo que se logra el quinto nivel de
automatización de los sistemas contables.
REGISTRO Recepción documento primario DOCUMENTOS

PRIMARIOS
DE
ENTRADA OTROS

S
(incluye la lógica de I
las transacciones) CARTERAS S
T
Archivo de documento E
DOCUMENTOS
PRIMARIOS M
DIARO
NO
FIN PERIODO
A
S
SI
Depuración de errores Registro en mayor MAYORES AUTO-

MATIZA-
Conciliación de estados de cuenta DOS
SI
ERRORES
BALANCE LEYENDA
REGIS AUTOMATIZADO
COMPROBACION
OTROS SISTEMAS
BALANCE
ESTADO
REGIS DE MANUAL
cuadro 3.5 QUINTO NIVEL AUTOMATIZACIÓN. Elaboración propia
En la realidad actual de Cuba, la mayor parte de los sistemas contables automatizados,

representan una mezcla del segundo y tercer nivel de automatización explicados anteriormente.
La tendencia, cada vez más fuerte a nivel mundial, es sin embargo que en las entidades se utilicen
ERP, donde el sistema automatizado contable es, como ya se comentó, un módulo del ERP o
partes de distintos módulos de este.
De igual forma se impone, en una marcha sin retrocesos, la interacción de los sistemas
automatizados de diferentes entidades. Este proceso se ha potenciado en los últimos años por el
vertiginoso desarrollo de INTERNET.
En los últimos 30 años ha surgido un grupo importante de entidades, a niveles regional y mundial,
que definen formalmente las posibles interacciones entre sistemas automatizados en diferentes
ramas, y otras que brindan el servicio de pasarelas de datos entre estos. A continuación algunos
ejemplos.
 La sociedad mundial para las telecomunicaciones financieras interbancarias (SWIFT por las
siglas de su nombre en inglés, Society for Worldwide Interbank Financial
Telecommunications), creada a inicios de la década de los 70 del pasado siglo. SWIFT se
constituyó como una compañía sin ánimos de lucro, en la que los usuarios de sus servicios
(bancos exclusivamente en un inicio) estaban obligados a comprar acciones de la misma, y
eran por lo tanto también sus dueños.
24
Los servicios que ofertó SWIFT desde el principio fueron: la estandarización de los formatos de
mensajes a intercambiarse entre bancos para distintas operaciones (transferencia de fondos,
cartas de crédito, etc.), lo que permitió que los sistemas automatizados pudieran tratar
directamente los mensajes recibidos; y una plataforma de comunicaciones con las debidas
medidas de seguridad y protocolos de acceso bien definidos, para el intercambio de esos
mensajes entre los bancos asociados.
En la actualidad a SWIFT están conectados más de 10000 bancos en 212 países, y a través de
sus redes de comunicación se intercambian unos 26 millones de mensajes financieros diarios
(ver 20).
 Los sistemas de liquidación bruta en tiempo real (SLBTR), que normalmente existen en cada
país o área geográfica. Estos sistemas son operados por el Banco Central del país en cuestión,
o por una entidad subordinada a este, y les permiten a los bancos, utilizando mensajes
estandarizados, en muchos casos según las mismas normas de SWIFT, realizar de forma
automatizada las transacciones entre los bancos que pertenecen al sistema. Adicionalmente a
los servicios que brinda SWIFT, los SLBTR ofrecen también el servicio de actualizar las cuentas
de los bancos en el banco central correspondiente, cerrando así totalmente el ciclo del
movimiento de fondos (ver 19).
 EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport)

auspiciado por Naciones Unidas (ver 25) y ANSI X12 en EEUU (ver 38). Tanto EDIFACT como
ANSI X12 proponen los formatos de los documentos más utilizados en las relaciones
comerciales entre empresas (solicitud de oferta, oferta, contrato de compraventa, lista de
empaque, conocimiento de embarque, factura comercial, etc.), y representan un soporte del
comercio electrónico.
 Bolero (Bill of Lading Electronic Registry Organisation). Bolero se creó como compañía en
septiembre de 1999. Sus principales accionistas fueron la ya nombrada SWIFT, el TT-Club que
es una asociación de entidades que funcionan en el ámbito de la transportación marítima, a la
que pertenecen más de las dos terceras partes de estas, y un grupo de inversores privados.
Como su nombre lo indica el principal objetivo de Bolero es mantener un registro electrónico
de conocimientos de embarque (Bill of Lading), de tal forma que las operaciones relacionadas
con este importante documento del comercio internacional puedan realizarse de forma
automatizada. Entre sus resultados hasta el momento puede citarse la emisión de un libro de
reglas (Rule Book), que deben aceptar los que participen en Bolero y que, a partir de aplicar el
principio legal de la primacía de la voluntad de las partes, supera las posibles discrepancias
legales entre las legislaciones de los distintos países (ver 21). Por otra parte un grupo de
plataformas y aplicaciones se han puesto a punto y se ofertan para su uso (ver 22).
La propuesta de Bolero tiene sin dudas un alto potencial de éxito en el comercio internacional,
sin embargo, resulta significativo que, en sus ya más de trece años de existencia, no haya
25
alcanzado aún un volumen importante de transacciones, sin el cual su tecnología no podrá
imponerse.
26
4 Principales hitos en el desarrollo de los ERP o SAC
4.1 Surgimiento de la contabilidad actual

Generalmente se acepta que el inicio de la contabilidad moderna, y por lo tanto de los SAC, se
remonta al trabajo de Luca Pacioli, monje franciscano que nació en Sansepolcro, Italia, en 1445 y
falleció en el mismo lugar presumiblemente en 1517 (ver 2).
Pacioli fue en su época un hombre eminente, amigo de importantes intelectuales, entre otros,
Leonardo da Vinci, con el que compartió largos años de trabajo y que fue incluso quien realizó los
dibujos que ilustraron su obra “Divina proportione”, y de León Batista Alberti, en cuya casa vivió
algunos meses al llegar por primera vez a Roma.
Además del estudio de las matemáticas desde muy temprana edad, en su formación influyeron los
años que, a sus veinte, pasó en Venecia trabajando para el rico comerciante Rompiasi, como su
ayudante en los negocios y tutor de sus tres hijos.
Pacioli nunca pretendió que el contenido de sus escritos fuera original, el mismo decía que sus
libros eran básicamente una recopilación de los conocimientos y usos de la época.
Su principal obra, llamada “Summa de Arithmetica, Geometrica, Proportione et Proportionalita”,

fue publicada en italiano en 1494.
El tratado XI de este libro, que lleva el nombre de “Particularis de Computis et Scripturis” (ver 3),
presenta una descripción detallada de cómo registrar los hechos económicos de un negocio, según
las costumbres existentes en Venecia en esos años. El mismo contiene los principales elementos
formales de los sistemas de contabilidad que se utilizaban ya en esa época, y que son válidos hasta
el día de hoy, a saber:
• La ecuación fundamental de la contabilidad

Activos = Pasivos + Capital
• Las siguientes reglas
– No hay deudor sin acreedor
– La suma que se adeuda a una o varias cuentas, ha de ser igual a lo que se abona
– Todo el que recibe debe a la persona que da o entrega
– Todo valor que ingresa es deudor y todo valor que sale es acreedor
– Toda pérdida es deudora y toda ganancia acreedora
27
Durante siglos, los registros contables se llevaron de forma manual, siguiendo normas que fueron
perfeccionándose en cada país4, pero que en esencia mantuvieron la construcción formal
explicada por Pacioli.
4.2 Los equipos de tarjetas perforadas

Ya desde inicios del siglo XIX se utilizaban tarjetas perforadas para el control de telares, (ver figura
4.1 telar de Jacquard). En los años 30 de ese mismo siglo hubo dos intentos de utilizar las tarjetas
perforadas para el procesamiento de datos.
Figura 4.1 Telar de Jacquard. Tomado de

http://www.myrevision.info/Revision/technology/computing/images_cs/jacquard
Por una parte el inglés Charles Babbage comenzó en 1833 la construcción de la así llamada
máquina analítica, primera versión de las actuales computadoras, que utilizaba tarjetas perforadas
para almacenar el programa que debería dirigir los cálculos. Las limitaciones técnicas de la época
impidieron que este equipo funcionara finalmente.
4
El hecho de que cada país defina las normas contables, que deben ser respetadas por todos las entidades que actúan
en el ámbito económico tiene como causa, desde tiempos inmemorables, poder garantizar un soporte documental, que
pueda ser inspeccionado, para el cobro de los impuestos que se deben pagar.
28
La figura 4.2 presenta una foto de las tarjetas propuestas por Babbage para su máquina analítica,
como se puede apreciar las tarjetas estaban unidas a través de cordeles para mantener la
secuencia, al igual que las utilizadas por Jacquard.
Figura 4.2 Tarjetas propuestas por Babbage. Tomado de

http://www.flickr.com/photos/cogdog/4905713747/?rb=1
Por otra parte, en Rusia en 1832, Semen Korsakov le presentó a la Academia Imperial de Ciencias
la descripción de una ¨Máquina para comparar ideas¨ que se basaba en el registro de ideas en
tarjetas perforadas. Este proyecto tampoco logró su realización.
El primer paso decisivo en el uso masivo de este medio para el procesamiento de datos se produjo
con el procesamiento del censo de los Estados Unidos en 1890, utilizando tarjetas cuya
codificación había sido diseñada por Herman Hollerith. En 1896 Hollerith, que también participó
activamente en el desarrollo de los primeros equipos de procesamiento de tarjetas, funda la
Tabulating Machine Company que posteriormente se convertiría en la actual IBM, principal
empresa a nivel mundial de equipos de procesamiento de datos durante muchos años (ver 4).
No fue sin embargo hasta finales de la década del 20 del pasado siglo cuando se produjeron
cambios importantes en el tratamiento de los datos contables. En aquellos años se comenzó a
generalizar el uso de los equipos de tarjetas perforadas con este fin (ver recuadro “Los sistemas de
tarjetas perforadas”).
29
Los sistemas de tarjetas perforadas
Un sistema de tarjetas perforadas estaba compuesto normalmente por los siguientes equipos:
Perforadora. Equipo que reproducía la información que se introdujera a través de un teclado, en una tarjeta
con 80 columnas. Cada columna podía tener hasta 12 perforaciones que permitían, utilizando un codificación
específica, representar o un número o cualquiera de las 26 letras del alfabeto.
Verificadora. Equipo similar a la perforadora pero que comparaba lo que se tecleaba con el contenido de una
tarjeta ya perforada. Si detectaba alguna diferencia la señalaba y rechazaba la tarjeta.
Clasificadora. La clasificadora procesaba un lote de tarjetas y colocaba en diferentes bolsillos las tarjetas que
en determinadas filas tuvieran igual valor. Las tarjetas que habían caído en los diferentes bolsillos se
fusionaban posteriormente de forma manual y en orden. A través del trabajo de la clasificadora y con la
participación de un operador, un lote de tarjetas, en principio de cualquier tamaño, podía clasificarse de
forma ascendente o descendente según el contenido de varias filas, dándole un pase en la clasificadora al lote
completo por cada fila.
Intercaladora. La intercaladora procesaba dos lotes de tarjetas ya clasificados y los mezclaba según el
contenido de varias filas. Este proceso servía por ejemplo para intercalar en un lote de tarjetas con los
movimientos (compras, ventas) de los clientes, al inicio de cada cliente, su nombre que estaba registrado en
otro lote de tarjetas von un formato distinto al de los movimientos.
Calculadora. La calculadora era capaz de realizar operaciones aritméticas entre cifras que estuvieran
codificadas en una tarjeta, perforando en las columnas que se le indicaran el resultado.
Tabuladora. La tabuladora era una impresora especializada, que podía, además de imprimir el contenido de
una tarjeta con un formato preestablecido, calcular totales a distintos niveles, a partir del contenido de ciertos
campos, e imprimirlos al final de cada nivel.
Entre las décadas de los 30 y los 50 del pasado siglo, se introducen y utilizan ampliamente los
equipos de tarjetas perforadas para apoyar los sistemas de contabilidad, así como los llamados
equipos de saldo directo y las calculadoras mecánicas y eléctricas.
Los equipos de tarjetas perforadas permitían ya en aquellos años lograr el primer nivel de
automatización antes esbozado, debido a que, una vez que los asientos contables hubieran sido
registrados en tarjetas (lo que equivalía a hacer las anotaciones en el diario), la emisión de los
mayores, balances de comprobación y estados financieros, así como la revisión de los
vencimientos de las carteras, podía hacerse de forma automatizada, utilizando procedimientos
diseñados y “programados”5 en los diferentes equipos que componen los sistemas de tarjetas
perforadas.
La figura 4.3 muestra una perforadora de tarjetas IBM modelo 029.
5
Cada uno de los equipos de tarjetas perforadas tenía una pizarra con una matriz de contactos. La
programación de un equipo determinado se hacía conectando los diferentes contactos, con cables
diseñados para eso, según las funciones que les correspondían ver figura 4.6. Cada equipo podía tener varias
pizarras que se utilizaban, en dependencia del proceso que se estuviera realizando, en un momento
determinado. Para cada proceso existía un diagrama de flujo que especificaba el movimiento de los lotes de
tarjetas (ficheros) a través de los diferentes equipos y las pizarras a utilizar.
30
Figura 4.3 Perforadora IBM modelo 029. Tomado de http://en.wikipedia.org/wiki/keypunch
La figura 4.4 muestra una tabuladora, equipo capaz de calcular totales a diferentes niveles e
imprimir los resultados finales de un procesamiento.
Figura 4.4. Tabuladora IBM 402, tomado de

https://www.scitechenergy.files.wordpress.com/2013/04/402-labels.jpg
31
La figura 4.5 muestra una calculadora de sistemas de procesamiento de tarjetas, la IBM 602.
Figura 4.5 Calculadora IBM 602. Tomado de http://www.columbia.edu
Figura 4.6 cableado de una tabuladora IBM. Tomado de

https://www.cs.auckland.ac.nz/historydisplays/FirstFloor/PunchedCardDataProcessing/PCDPImag
es/TabulatorWiringDiagramExample.jpg
32
El cuadro 4.1 muestra un procedimiento para obtener un balance a partir del diario.
Flujo de procesamiento para obtener un balance
Diario
Clasificación por cuenta
Cuentas
Diario balance
Clasificado
por Cuentas
Intercalación
Cuentas balance +
Diario Clasificado por cuentas
Tabulación
Balance
Cuadro 4.1 Flujo para obtener un balance. Elaboración propia.
Los equipos de saldo directo automatizaban, hasta cierto punto, la mecanografía del pase a los
mayores, a partir de los documentos primarios o los comprobantes de registro en el diario. Con
estos equipos los mayores quedaban en cartulinas, que detallaban todos los movimientos e
incluían el cálculo de los saldos después de cada partida. Ver figura 4.7.
Figura 4.7 Equipo de saldo directo Burroughs. Tomado de

http://upload.wikimedia.org/wikipedia/commons/9/92/Burroughs_Accounting_Machine.jpg
33
Las calculadoras se utilizaban fundamentalmente para realizar la suma de muchas partidas con
gran seguridad, ya que producían un listín con todas las cifras introducidas y los totales calculados,
el cual facilitaba posteriormente la comprobación de las operaciones realizadas6.
4.3 Las computadoras

Las primeras computadoras con los elementos que las caracterizan como tales (memoria, registros
de trabajo, lenguaje de programación y unidad de procesamiento) surgen en la década del
cuarenta del pasado siglo utilizando tubos al vacío como elemento electrónico para realizar su
trabajo. Estos primeros equipos sirvieron fundamentalmente para la realización de ciertos cálculos
científicos. Los primeros eran realmente rudimentarios (ver figura 4.8).
Figura 4.8 ENIAC Tomado de http://www.puntogeek.com
Uno de los últimos equipos a clasificar en esta primera generación, por estar construido a partir de
tubos de rayos catódicos, se construyó por IBM en el año 1956 con el nombre de IBM 305 RAMAC.
Este equipo contaba, por primera vez en computadoras comerciales, con un disco duro con
cabezales movibles que tenía una capacidad de alrededor de 4,1 Mbytes y su principal objetivo era
facilitar el procesamiento de datos (ver figura 4.9). En Cuba IBM instaló uno de estos equipos
RAMAC y funcionó con carácter de laboratorio hasta inicios de los años 70.
6
Los ábacos, instrumentos que permiten realizar sumas a mano a una gran velocidad, y los cálculos
mentales, que eran las posibilidades que existían antes de las calculadoras con impresión, tienen la
desventaja de que cuando hay errores hay que rehacer totalmente la suma.
34
Figura 4.9 IBM 305 Ramac. Tomado de http://www.extremetech.com
Ya en la segunda mitad de la década de los 50 del pasado siglo, surgen computadoras de la

llamada segunda generación. Estas computadoras estaban especializadas o en el procesamiento
de datos o en la realización de cálculos científicos. Estados Unidos, Rusia y Francia fabricaron,
entre otros países, computadoras de este tipo.
Dentro de los sistemas de la segunda generación especializados en procesamiento de datos más

conocidos, puede nombrarse el IBM serie 1400 de Estados Unidos (ver figura 4.10), el equipo
Minsk 32 de la Unión Soviética y la computadora SEA 4000 producida por Francia. De esta última
Cuba adquirió dos unidades a finales de la década del 60.
Figura 4.10 Sistema 1400 de IBM. Tomado de http://www.clipper220.proboards.com
35
Todos estos equipos de la segunda generación, especializados en procesamiento de datos7, tenían
lectores de tarjetas perforadas, almacenamiento en cintas magnéticas, impresoras de alta
velocidad, compiladores para lenguajes de programación, en su mayoría muy elementales, y una
memoria interna del orden de los 16 kilobytes (una memoria flash actual tiene un millón de veces
la capacidad de aquellos pioneros).
En esta primera etapa del uso de las computadoras en los SAC, lo que fundamentalmente
permitían estas era realizar los mismos procesos que se ejecutaban hasta ese momento en
equipos de tarjetas perforadas, de una forma más eficiente y sin la manipulación física de las
tarjetas.
La actualización de los mayores y la emisión del balance de comprobación y los estados

financieros, a partir de un diario que existe en un soporte procesable por medios
electromecánicos o electrónicos, puede realizarse siempre con una combinación de procesos de
clasificación, fusión, cálculo y tabulación de los artículos que componen el diario. Como ya se
explicó, los sistemas de tarjetas perforadas tenían equipos especializados para estas funciones.
Uno de los primeros lenguajes de programación para computadoras desarrollado por IBM fue el
Report Program Generator RPG8 (Ver 5), que permitía describir un proceso sistematizado para
equipos de tarjetas perforadas y, a partir de esa descripción, generar programas para
computadoras que ejecutaban las mismas acciones.
A inicios de la década de los 60 del pasado siglo, surgen las computadoras de la tercera
generación, entre las que se destaca la línea de equipos IBM 360. (ver figura 4.11)
7
Las generaciones de computadoras se clasificaron en general a partir del componente electrónico utilizado
para su construcción. Así, las computadoras de la primera generación utilizaban tubos de rayos catódicos,
las de la segunda transistores, las de la tercera circuitos integrados y las actuales microprocesadores. Los
equipos de la segunda generación estaban especializados en cálculos científicos o procesamiento de datos.
8
Las dificultades que se generan cuando se quieren modificar sistemas automatizados de gran dimensión,
que están en funcionamiento, son de tal magnitud que el lenguaje RPG, con sus modernizaciones claro está,
se utiliza aun en algunas aplicaciones contables en computadoras IBM, que han venido arrastrando la
codificación original por más de 60 años.
36
Figura 4.11 IBM 360/50. Tomado de http://www.ibm360.info/ibm_360-50.jpg
Esta línea IBM 360 ofrecía compatibilidad entre todos los modelos, tanto para los programas,
como para los periféricos; contaba con un sistema de explotación que incorporaba los adelantos
del momento, un buen sistema de gestión de ficheros y compiladores para los lenguajes de
programación más avanzados en ese entonces (Cobol, Fortran, PL/1, etc.) , así como una gama de
periféricos con altos rendimientos para ese momento. (ver cuadro 4.12, 4.13 y 4.14)
Los modelos de la línea IBM 360 iban desde pequeñas computadoras, hasta los equipos más
potentes del momento. Los equipos de la tercera generación, y en particular la línea IBM 360,
provocaron la sustitución masiva de los sistemas de tarjetas perforadas9.
A partir de los inicios de los años 70 del pasado siglo, el entonces campo socialista desarrolló una
línea de computadoras bajo el nombre de SUMCE (sistema unificado de máquinas computadoras
electrónicas) que copiaban con todos sus detalles inicialmente la línea 360 de IBM y después la
línea 370. Estos equipos tenían sin embargo un atraso de más de 8 años en comparación con los
originales de IBM desarrollados en Estados Unidos.
9
IBM, además de ser el fabricante y comercializador único de las IBM 360, era el principal arrendador y
suministrador de equipos de procesamiento de tarjetas perforadas, por lo que lo que promovió fue sustituir
esos equipos con sus nuevas computadoras.
37
Cuadro 4.12 Disco duro intercambiable IBM 2311. Tomado de http://en.wikipedia.org
Cuadro 4.13 Lector grabador de bandas magnéticas de IBM 2401. Tomado de

http://hu.wikipedia.org
Cuadro 4.14 impresora IBM 1403. Tomado de http://www.comptermuseum.li
38
No obstante, debido a que al igual que con los sistemas de tarjetas perforadas y las computadoras
de la segunda generación, el procesamiento de los datos en esto equipos de la tercera generación
se realizaba enviando los documentos primarios a un centro de cálculos, donde se procesaban por
lotes (diarios, semanales, etc.) para obtener los resultados, que se entregaban normalmente uno o
varios días después, el nivel de automatización que ofrecían estos primeros equipos de la terecera
generación no se diferenció de lo alcanzado hasta ese momento por equipos menos sofisticados.
El procesamiento por lotes tiene la desventaja de que aísla totalmente el usuario del sistema de
procesamiento, básicamente con el objetivo de mantener una especialización y garantizar la
eficiencia y la delimitación de responsabilidades. La comunicación entre el centro de
procesamiento y el usuario se basa en este esquema en la entrega de documentos primarios y
resultados. (ver cuadro 4.2)
Procesamiento por lotes
CENTRO DE PROCESAMIENTO
Equipo de tarjetas perforadas
Clasificadora
Documentos Intercaladora
Calculadora
Tabuladora
Ó
T Computadora 3ra generación
Unidad central
Lectores de tarjetas
Bandas magnéticas
Tablas
Discos
Impresoras
Cuadro 4.2 Procesamiento por lotes. Elaboración propia
Antes de comenzar el procesamiento en sí, sólo para depurar los errores contenidos en los datos,
en un volumen de 10000 artículos y una tasa de errores del 1%, se requerían cinco intercambios
de documentos entre el centro de procesamiento y los usuarios (entrega de los documentos que
generan los 10000 artículos, devolución de lista de 100 errores, entrega de corrección de 100
errores, entrega de listado con un error, entrega de corrección del error).
Si debido a razones tecnológicas del centro de procesamiento, que por lo general no atendía un
sólo sistema, obtener los resultados requería de varias horas o incluso un día, se puede imaginar lo
dilatado que resultaba el proceso en su conjunto.
Debido a sus altos costos, las pequeñas y medianas empresas, salvo excepciones, no tenían acceso
aun a esta tecnología.
39
4.4 Las redes de terminales
A finales de la década de los 60 del pasado siglo los equipos de computación adquieren la
capacidad de atender redes de terminales. Hasta ese momento la interacción de las personas con
la computadora se realizaba exclusivamente a través de una consola para operarla.
La utilización de redes de terminales permitió que varias personas pudieran interactuar con la
computadora al mismo tiempo, resolviendo tareas independientes o colaborando en la solución
de una misma tarea. (ver figura 4.15)
Figura 4.15 terminal del sistema IBM 360. Tomado de http://www.beagle-ears.com

Para que un conjunto de terminales pudiera conectarse a una computadora era necesario utilizar
tecnologías de multiprocesamiento y tiempo real. Las altas velocidades que habían adquirido las
computadoras ya en ese momento, y el crecimiento de sus memorias operativas, les permitían ir
alternando en intervalos muy cortos la realización de varias tareas, dando la sensación de que
todas se ejecutaban al mismo tiempo en paralelo (multiprocesamiento). Por otra parte, la
capacidad de interrumpir un proceso a partir de un evento externo, permitía que las tareas que lo
requirieran tuvieran prioridad sobre otras y pudieran ejecutarse en los plazos requeridos (tiempo
real). Por razones psicológicas (ver 6), la respuesta de la computadora, al recibir una orden del
operador a través del teclado u otro periférico, no debe sobrepasar cierto tiempo10.
10
Estudios psicológicos realizados a finales de la década del 60 mostraban que el tiempo óptimo de
respuesta de una computadora a una persona que interactúa con ella, está entre 2 y 15 segundos en
dependencia de la tarea. Si el tiempo es menor que los 2 segundos puede confundir al operador, a partir de
los 15 segundos se genera ansiedad.
40
La utilización de estas tecnologías, junto con la conexión de múltiples terminales a una
computadora, permitió por primera vez llevar las capacidades de estos equipos a los puestos de
trabajo de los especialistas. Este paso de avance en la tecnología permitió eliminar el
procesamiento por lotes y les dio acceso directo al SAC a los empleados de las áreas de
contabilidad, para introducir los datos de los documentos primarios, y consultar ciertas tablas
desde sus puestos de trabajo.
Por otra parte, con la captación directa de los datos en tiempo real, se hizo posible formalizar en
un programa las maquetas de las transacciones, garantizando la validación formal de los datos en
el momento de su captación. Esta posibilidad, además de eliminar las iteraciones requeridas para
eliminar los errores en el procesamiento por lotes, acelerando extraordinariamente todo el
proceso, permitió que el registro en el diario estuviera siempre libre de errores formales,
incluyendo el cuadre.
4.5 Las minicomputadoras, las bases de datos y UNIX

La década de los años 70 del pasado siglo fue testigo de importantes desarrollos en los medios de
computación, el software y los medios de comunicación. (ver cuadro 4.16)
Figura 4.16 Minicomputadora pdp-11. Tomado de http://es.wikipedia.org/wiki/pdp-11
41
En este período vieron la luz las minicomputadoras que permitieron, por una parte, que las
medianas empresas y algunas pequeñas tuvieran acceso a medios de computación, y por otra, que
las grandes empresas pudieran construir sistemas a varios niveles. En estos sistemas, los niveles
inferiores se cubrían con minicomputadoras y redes de terminales, que recolectaban los datos y
los transmitían por medios electrónicos a centros con computadoras grandes, donde se realizaba
el procesamiento principal.
En junio de 1970 Edgar Frank Codd, científico de origen inglés que trabajaba en el Laboratorio de
Investigación de IBM en San José, California, publicó un artículo sobre el uso de la teoría
matemática relacional, aplicada a las bases de datos (Ver 7), que proporcionó el fundamento
teórico de los modernos sistemas de gestión de bases de datos.
Antes del trabajo de Codd, las dos estructuras más utilizadas en las bases de datos eran la
jerárquica y la de redes. Estas estructuras no garantizaban la recuperación de todas las
combinaciones posibles de los datos almacenados, requerían de una habilidad especial, cercana al
arte, para obtener ciertos resultados, no resolvían los problemas de posibles incoherencias que
provoca la redundancia de datos, y obligaban a que el que trabajaba con la base de datos
conociera exactamente la forma en que físicamente estos se encontraban almacenados.
El trabajo de Codd demostró que cualquier combinación posible de datos, almacenados en una
base de datos que utilizara una estructura relacional, podía ser recuperada de una forma
relativamente simple sin tener que conocer como físicamente estaban estos almacenados, y que,
sometiendo esas relaciones a un proceso que llamó de normalización, los problemas de
redundancia se podían resolver plenamente. Este artículo presentó, además, una primera
aproximación a un lenguaje universal para el tratamiento de datos que posteriormente evolucionó
hacia el actual Structured Query Language (SQL).
En este período de tiempo se desarrolló también el sistema de explotación UNIX (Ver 8).
Concebido para el trabajo en régimen de multiprogramación y tiempo real, fue utilizado
inicialmente de forma preponderante en las minicomputadoras y los ambientes universitarios y,
como se conoce, su arquitectura lidera hoy en sus distintas versiones el mundo del software libre.
4.6 Las PC, las fibras ópticas, Internet y los celulares

La década de los 80 del pasado siglo no fue menos prolífera que su antecesora. Ya en la segunda
mitad de la década del 70 se habían desarrollados varias computadoras para el uso personal. La
más conocida de estas, por los personajes que las desarrollaron y los resultados de la empresa que
con esos equipos se fundó, fue la Appel II. (ver figura 4.17)
42
Figura 4.17 Appel II. Tomado de http://en.wikipedia.org/wiki/apple_II_series
En 1981 IBM saca al mercado su primera computadora personal, la IBM/PC (Ver 9), que
revoluciona por completo el uso de las computadoras, llevándolas en pocos años, al puesto de
trabajo de cada empleado y al cuarto de cada estudiante en los países desarrollados. (ver figura
4.18)
Figura 4.18 IBM PC. Tomado de

http://upload.wikimedia.org/wikipedia/commons/6/69/IBM_PC_5150.jpg
IBM había sufrido una notable pérdida en su participación en el mercado de las computadoras en
la década anterior, al no vislumbrar a tiempo las posibilidades de las minicomputadoras. Cuando
43
los directivos de IBM analizaron las primeras computadoras personales desarrolladas a finales de
la década del 70, no quisieron que les sucediera lo mismo que con las minicomputadoras y,
rompiendo buena parte de los paradigmas11 y esquemas que hasta ese momento habían
dominado la empresa, organizaron el desarrollo de la IBM/PC, la cual se anunció
aproximadamente un año después de haberse decidido su fabricación y obtuvo un éxito
indudable.
La publicación de la documentación técnica y el uso de componentes fabricados por terceros en
las IBM/PC, junto con el surgimiento de programas compatibles con el único elemento registrado
por IBM, el sistema básico de entradas y salidas (BIOS por su nombre en inglés), que no violaban
los derechos de propiedad de ese producto, propiciaron que numerosas empresas comenzaran la
producción de equipos compatibles con prestaciones similares.
A inicios de los años 80 Apple trató de competir con el fenómeno IBM/PC y sacó en 1984 un nuevo
modelo, llamado MacIntoch (ver figura 4.19), pero aunque tuvo ventas importantes, no pudo
competir con la IBM/PC y la larga lista de IBM/PC compatibles que inundaban el mercado a precios
realmente competitivos.
Figura 4.19 Apple macintoch . Tomado de http://ahmnet.com/wp-

content/uploads/2014/01/52elcbb7a88ba_012342.jpg
11
Con la IBM/PC IBM por primera vez: En el plano organizativo, creó una unidad de negocios totalmente
independiente, hasta ese momento IBM se caracterizaba por ser una empresa con una alta integración
vertical. En el plano técnico utilizó componentes que no habían sido desarrollados por sus laboratorios, en
particular el procesador central de la firma INTEL, incluyó varios elementos de software desarrollados
también por terceros, siendo el más famoso el sistema de explotación MS-DOS de la en ese entonces
pequeña empresa Microsoft, y publicó toda la documentación técnica, registrando sólo el BIOS (basic imput
output system) como de su propiedad. Con estos pasos invitaba a toda la comunidad de desarrolladores de
periféricos y software a que sus diseños fueran compatibles con la IBM/PC, lo cual logró, desencadenando
una progresión geométrica en el uso de estos equipos.
44
En 1980 el departamento de defensa de Estados Unidos adopta el protocolo TCP/IP, para usarlo en
sus redes de computadoras, después de un largo proceso de perfeccionamiento del mismo, que
tenía sus orígenes en 197312 con la publicación de un artículo llamado “Una especificación parcial
de un protocolo Internacional de transmisión”. Ya en ese momento se había desarrollado la
recomendación de OSI13 sobre un modelo de siete niveles14 (ver cuadro 4.3) para la interconexión
entre computadoras (ver 23).
MODELO OSI DE 7 CAPAS

USUARIO USUARIO
EQUIPO 1 EQUIPO 2
APLICACIÓN N7 PROTOCOLO N7 APLICACIÓN N7
PRESENTACION N6 PROTOCOLO N6 PRESENTACION N6
SESION N5 PROTOCOLO N5 SESION N5
TRANSPORTE N4 PROTOCOLO N4 TRANSPORTE N4
RED N3 PROTOCOLO N3 RED N3
ENLACE N2 PROTOCOLO N2 ENLACE N2
FISICO N1 PROTOCOLO N1 FISICO N1
MEDIO FISICO
DE COMUNICACION
cuadro 4.3 Elaboración propia
TCP/IP puede verse como una versión del modelo OSI, que mostró su eficiencia y se fue
generalizando cada vez más. La actual INTERNET utilizó prácticamente desde el inicio el protocolo
TCP/IP y en buena medida debe su éxito a las bondades del mismo.
12
En 1977 utilizando la versión 2 de TCP, en aquel entonces como un solo protocolo, se conectaron 3 redes
de computadoras que intercambiaron información a través de una distancia de más de 150000 kilómetros.
En 1978 se publica la versión 3 del protocolo que ya se separaba en dos: TCP para dividir en y unir los
paquetes, controlar los errores, y eventualmente retransmitir, e IP para enrutar los paquetes a través de la
red.
13
Open Systems Interconnection (OSI) es una agencia de Ia International Standards Organization (ISO)..
14
Los niveles en un protocolo de comunicaciones no son más que conjuntos de programas que resuelven
tareas específicas, y que en su funcionamiento existen para atender las necesidades del nivel inmediato
superior, y se sirven de los servicios del nivel inmediato inferior. Por otra parte, cada nivel en uno de los
equipos se comunica virtualmente con su igual en el del otro equipo, cumpliendo un protocolo e ignorando
lo que pasa en los niveles inferiores. Con la aplicación de estos principios, el problema de la comunicación
entre computadoras se puede descomponer en tareas, que van desde lo más general que es atender a un
usuario, hasta lo más detallado que es generar o interpretar los pulsos eléctricos o luminiscentes
45
También en el campo de los medios técnicos la década de los 80 del pasado siglo marcó un
importante hito con el desarrollo e instalación de las primeras redes de comunicación que
utilizaban fibra óptica (Ver 11), como soporte de la transmisión de datos.
Con este avance se lograban velocidades inalcanzables con las anteriores tecnologías (cobre y
ondas de radio), y se resolvían también dos importantes problemas: uno, de seguridad, al ser
prácticamente imposible interceptar los datos que se transmiten a través de una fibra óptica, y
otro, de robustez, ya que el funcionamiento de la fibra óptica no se altera con condiciones
adversas en la atmósfera (truenos, lluvias, nubosidad, etc.), como sucede con el cobre y la
transmisión por ondas radiales.
La década de los años 90 del pasado siglo fue testigo de la maduración y empleo masivo de un
grupo de tecnologías de computación y comunicaciones que se habían desarrollado en los 20 años
que le precedieron.
Siguiendo un pronóstico realizado a inicios de los años 70 por uno de los fundadores de INTEL
Gordon Moore (ver 12), conocido posteriormente como ley de Moore, la cantidad de transistores
que puede contener un microprocesador se había duplicado cada dos años, permitiendo que los
equipos de computación y en particular las computadoras personales pudieran aumentar su
potencia de cálculo y capacidad de almacenamiento a valores nunca antes imaginados.
En estos años 90 se produjo la instalación masiva de fibra óptica entre nodos de comunicación, a
nivel nacional e internacional. INTERNET que había comenzado a funcionar a principios de los 90,
creció desde 0 a 250 millones de usuarios en esta década.
También en estos años comienza el desarrollo masivo de la telefonía celular que, unida al resto de
las tecnologías ya descritas, cambiaría en poco tiempo la forma en que las personas se comunican
y trabajan.
Durante la primera década del presente siglo no han cesado los desarrollos tecnológicos que de
una u otra forma influyen en la evolución de los SAC. Los principales son:
 La integración de los SAC en los ERP. Este proceso que comenzó a mediados de los 80 del
pasado siglo se ha consolidado de forma definitiva en la primera década del siglo XXI. Hoy en
día es totalmente anacrónico hablar de un sistema automatizado de contabilidad,
independiente del sistema general de la empresa.
 La introducción del comercio electrónico, tanto en la modalidad entidad – entidad, como en

la de entidad – persona natural.
El comercio electrónico entre entidades facilita llegar al último nivel de automatización antes
descrito, al permitirle a sistemas automatizados interactuar entre ellos e intercambiar toda la
información requerida para sus registros, la gestión de carteras y la conciliación de cuentas.
Una forma particular de este comercio electrónico es la Banca a distancia, que permite
ordenar transacciones directamente desde el sistema automatizado de la entidad al banco, así
como recibir las notas de débito y crédito y los estados de cuenta de forma automática.
46
El comercio electrónico entidad – persona natural, además de facilitar la adquisición de bienes
y servicios por parte de las personas, elimina totalmente la necesidad de captar documentos
en esas transacciones, ya que la propia información requerida para realizar la operación
comercial, que es introducida en el sistema por el propio cliente, es la fuente del registro
contable.
 La tecnología web en los sistemas automatizados. La presencia universal de INTERNET y la
evolución de las tecnologías que le son propias, ha permitido que el acceso a los ERP, y como
parte de estos a los SAC, se haga más sencillo desde prácticamente cualquier localidad. Esta
posibilidad de acceso remoto a través de internet resuelve varios problemas de los SAC, en
particular la replicación de datos y programas, requerida para esquemas de varios niveles, y la
posibilidad de aumentar la seguridad del sistema al concentrarse los medios técnicos en un
solo punto.
 Un último desarrollo a nombrar, y no por ello el menos importante, es el uso masivo de la
tecnología de teléfonos celulares para acceder a los SAC.
Los actuales teléfonos inteligentes superan sin dudas la capacidad de procesamiento de las
primeras computadoras de la tercera generación. Las velocidades de transmisión de datos
entre estos teléfonos y los sistemas automatizados han venido creciendo sistemáticamente. La
tecnología de red Long Term Evolution (LTE), que utiliza el Iphone-6 de Appel, proporciona
velocidades de 300 Mbps desde la red hacia el teléfono y de 75 Mbps desde el teléfono hacia
la red. Estas capacidades permiten que un ERP pueda utilizarse en cualquier momento y en
cualquier lugar, algo que desafortunadamente atenta frecuentemente contra el equilibrio
psicológico del personal que las emplea.
4.7 El futuro inmediato

En cuanto al futuro, cualquier predicción corre el riesgo de no tomar en cuenta desarrollos no
divulgados masivamente que aún se encuentran en un estado embrionario, pero que pudieran
revolucionar los sistemas automatizados, como ha ocurrido con algunas tecnologías durante los
últimos 40 años.
Muchos analistas, e importantes firmas de equipos de computación y comunicaciones, así como
de software (ver 13, 14, 15, 16, 17 y 18) coinciden total o parcialmente, sin embargo, en que las
siguientes tecnologías marcarán el rumbo en el desarrollo de los próximos años:
 El así llamado procesamiento en la nube (cloud computing), que plantea que el tratamiento de
los datos se brinde como un servicio, al que se tiene acceso a través de Internet. Esta
alternativa apuesta por la total centralización, y en buena medida tercerización, de los
servicios informáticos, con lo que los usuarios particulares no dispondrán de un software que
se ejecute en su computadora, sino utilizando un navegador tendrán acceso a sitios Web
donde se pueda interactuar con los diferentes sistemas.
Así, no se tendrá una versión del Office en la PC, sino que Microsoft brindará el uso de
servidores ubicados en cualquier lugar del mundo, que realizarán las mismas funciones. Este
47
esquema fue puesto en explotación en junio del 2011 por Microsoft, con el producto Office
365.
De igual forma los sistemas ERP pudieran ejecutarse en servidores de la propia compañía que
desarrolló el software (SAP brinda este servicio hace ya algunos años) y sólo se instalarán de
forma física en los servidores de las compañías más poderosas, que brindarán a sus empleados
el uso de los mismos también a través de Internet.
Si bien esta alternativa promete ventajas considerables, los problemas de seguridad y

privacidad deberán resolverse de forma convincente, tanto desde el punto de vista
tecnológico como legal, antes de que esta sea una solución universal.
 El procesamiento en memoria (in memory computing) es otra de las tendencias que
potencialmente puede cambiar radicalmente la forma en que los sistemas automatizados
actuales trabajan. Los discos duros han sido durante décadas el principal soporte para el
procesamiento de grandes volúmenes de datos. La capacidad actual y la que se vislumbra para
las memorias electrónicas permiten que buena parte del procesamiento se realice
directamente sobre estas, sin la participación de los discos duros.
Muchos programas y en particular los sistemas de gestión de base de datos han basado sus
algoritmos en optimizar el uso de las características y restricciones de los discos duros.
Además del aumento de velocidad en la lectura de un dato, al eliminar las memorias
electrónicas el tiempo requerido para moverse de cualquier dato a cualquier otro, no
despreciable en los discos duros, los algoritmos y procedimientos de estos programas deberán
ser revisados y rediseñados, y las posibilidades de los mismos podrán crecer en varias
magnitudes.
 La movilidad es otra de las características que marcará el rumbo de los sistemas
automatizados de los próximos años.
Ya hoy en día existen unos 5000 millones de conexiones de celulares en el mundo y se

mantiene una alta tasa de crecimiento. Los teléfonos inteligentes tienen las mismas
capacidades de las PC de hace algunos años y las redes inalámbricas crecen por día en
velocidad y cubrimiento de área.
 Por último cabe señalar la explosión de datos como una de las características de los sistemas
automatizados de los próximos años.
Algunos analistas plantean que la cantidad de datos almacenados en los sistemas llegará a
duplicarse cada 18 meses. Este hecho, sin duda, propiciará el desarrollo de nuevos equipos
48
que soporten ese crecimiento y el perfeccionamiento de las tecnologías de minería de datos15,
(Data mining) imprescindibles para manejar eficientemente tales volúmenes (ver 24).
15
Se le llama minería de datos al proceso de analizar grandes volúmenes de datos desde distintas
perspectivas, interrelacionadas entre ellas, con el fin de resumirlos de una forma útil para la toma de
decisiones.
49
PAGINA DEJADA EN BLANCO
50
5 Componentes de los ERP o SAC
5.1 Los componentes

Los sistemas automatizados en general, y los ERP o SAC en particular, no pueden verse sólo como
un conjunto de programas y procedimientos. Para que un ERP o SAC funcione correctamente
tienen que acoplarse, y trabajar como un todo, un grupo de componentes de características muy
disímiles.
Ya en los años 80 algunas metodologías para el desarrollo de los sistemas automatizados de
procesamiento de datos (SAPD), definían a estos como un conjunto de subsistemas funcionales,
que resuelven las tareas como tal, y un conjunto de subsistemas de aseguramiento, que se
encargan de que los subsistemas funcionales trabajen adecuadamente (ver 33 y 35). Esta división
sigue teniendo total validez, y de hecho constituye un enfoque metodológico útil para introducir y
explotar un SAPD.
No obstante, con el objetivo de utilizar una fraseología más acorde con el argot actual, en lo
adelante se utilizará la denominación de componentes de los ERP o SAC16, en sustitución del
término subsistemas de aseguramiento de aquel enfoque metodológico.
El cuadro 5.1 muestra un esquema con una agrupación generalmente aceptada de esos
componentes.
COMPONENTES
DE LOS ERP o SAC SEGURIDAD Y PROTECCIÓN
COMPU-
TADORAS
INFORMACIÓN
TELECOMU-
NICACIONES
PROGRAMAS RECURSOS
INFORMÁTICOS HUMANOS
ASPECTOS
METODO- ORGANIZACIÓN
GICOS
ASPECTOS
LEGALES
cuadro 5.1 Componentes de los ERP o SAC. Elaboración propia
16
La agrupación de componentes utilizada en este trabajo difiere de la utilizada en los años 80 para los
subsistemas de aseguramiento en los siguientes aspectos: el aseguramiento técnico se separó en los
componentes computadoras y telecomunicaciones, el aseguramiento tecnológico, que se ocupaba de definir
la tecnología de trabajo de un centro de cálculos se elimina, ya que en su mayoría esas funciones o no
existen o se han automatizado.
51
5.2 Las computadoras
En la actualidad las computadoras requeridas para un ERP o SAC pueden agruparse en las
siguientes categorías:
 Servidores
 Puestos fijos de trabajo
 Equipos móviles
Los servidores no sólo ejecutan los programas principales de la aplicación como tal, sino que sirven
también para realizar servicios, sin los cuales el sistema no trabajaría adecuadamente. Los más
importantes de estos servicios son:
 Almacenamiento de respaldo (backup) de los datos.
 Gestión de la red de computadoras (controlador de dominio).
 Gestión del correo electrónico.
 Gestión de las bases de datos.
 Cortafuegos para proteger las conexiones externas.
 Hospedaje y suministro de servicios WEB.
Para cumplir estas tareas los actuales servidores cuentan con inmensas capacidades de
procesamiento (ver figura 5.1). El trabajo conjunto de múltiples servidores en la solución de
determinadas tareas permite además potenciar el rendimiento de los mismos.
Figura 5.1 CPU Intel xeon E5-2600 con 18 procesadores. Tomado de

http://www.muycomputer.com/2014/09/
52
La instalación de cientos y en algunos casos miles de servidores en determinados centros de
procesamiento, conocidos como fábricas de servidores (servers factories) no es un fenómeno
aislado en la actualidad.
Los puestos de trabajo que tienen acceso al sistema están constituidos por PCs (de mesa o
portátiles) o equipos móviles (tabletas o teléfonos inteligentes) que están conectados a la red con
acceso a los servicios del ERP o SAC y, en general, pueden realizar otras tareas de oficina, como
elaborar documentos, tablas de cálculo, acceder al correo electrónico o a Internet, etc.
En ciertos ambientes, donde la información del sistema es confidencial o muy sensible, los puestos
de trabajo conectados al ERP o SAC no deben tener acceso a Internet, con el fin de proteger
físicamente el sistema de ataques externos.
En los últimos años ha venido ganando cada vez más popularidad el acceso, a los sistemas
automatizados en general, y a los ERP o SAC en particular, desde equipos móviles.
Como ya se comentó anteriormente los actuales teléfonos inteligentes tienen capacidades de
memoria y procesamiento muy similares a las de las PCs.
El iPhone 6s, anunciado por Apple en septiembre del 2015, tiene, por ejemplo, las siguientes
características en su versión más potente (ver 26):
 Pantalla de 5,5 pulgadas en la diagonal,
 Memoria para datos de hasta 128 Gbytes,
 Procesador A8 dual-core, con procesador M8 para gráficos incorporado (20 000 000 000 de
transistores) 1 Gbyte ram incorporada (ver figura5.2)
Figura 5.2 Procesador A8. Tomado de http://argyllfreepress.com/wp-

content/uploads/2014/09/Apple-A8-mockup.jpg
53
 Cámara de 8 megapixels,
 GPS (Global Position System), giróscopo, censor de movimiento y presión,
 Reconocimiento de huella dactilar,
 Posibilidad de conexión a redes Wi-Fi, en particular a la red inalámbrica de transmisión de
datos LTE (Long Term Evolution), que tiene velocidades de 300 Mbps bajando datos desde la
red y 75 Mbps subiendo datos a la red
 Conexión NFC (near field communication)
Ver figura 5.3
Figura 5.3 iphone 6. Tomado de http://images.apple.com/iphone-

6/overview/images/pay_large.png
Por otra parte, encabezados por Apple, los fabricantes de computadoras han inundado el mercado
en los últimos años con las llamadas tabletas (tablets en inglés), que no son más que una pantalla
táctil17, un poco más pequeña que una hoja de papel normal de 8 ½” X 11”, con procesador,
memoria, cámara de televisión, en ocasiones disco duro, y acceso a redes inalámbricas.
El iPad de Apple tiene, en la versión disponible en el mercado en septiembre del 2014, las
siguientes características (ver 27):
 Tamaño del equipo 7,31 x 9,5 x 0,37 pulgadas
 Pantalla de 9,7 pulgadas en la diagonal
 Procesador A5X dual-core, con quad-core para gráficos
 1 Gbyte ram
17
Pantallas táctiles son aquellas que detectan los movimientos de los dedos sobre su superficie y los
interpretan de manera similar, aunque mucho más sofisticada, que los desplazamiento de un ratón en la
pantalla normal.
54
 Memoria para datos de hasta 64 Gbytes
 Cámara de 5 megapixels
 Posibilidad de conexión a redes Wi-Fi, incluyendo LTE
 Posibilidad de funcionar como un teléfono
Ver figura 5.4
Figura 5.4 Ipad de Apple. Tomado de

http://files1.coloribus.com/files/adsarchive/part_1403/14032655/apple-ipad-ipad-is-electric-600-
50472.jpg
Con estas capacidades, las únicas diferencias significativas actuales entre una PC y un teléfono
inteligente o una tableta, son: el teclado, que indiscutiblemente sigue siendo el medio más
productivo para la introducción masiva de información alfabética o numérica, y el tamaño de la
pantalla, que en ciertas aplicaciones requiere dimensiones mayores a las que se pueden alcanzar
con las tecnologías hoy disponibles, para las tabletas y teléfonos inteligentes18.
Además de las computadoras en sí, al diseñar o perfeccionar un SAC, es necesario tener en cuenta
los requisitos sobre otros medios muebles e inmuebles, imprescindibles para que las
computadoras funcionen adecuadamente y que, por conveniencia, se incluyen en este acápite19.
Los más importantes son:
18
Existen investigaciones para el desarrollo de teclados virtuales que funcionan sobre cualquier superficie
con un haz luz láser y un escáner que detecta los movimientos de los dedos sobre las diferentes posiciones
del teclado. También se investiga sobre pantallas que puedan plegarse, de tal forma que sin perder el
carácter de portable puedan alcanzar, una vez desplegadas, los tamaños requeridos para las aplicaciones
más exigentes.
19
No se incluyen aquí los equipos de comunicación, que por su importancia se tratan de forma
independiente.
55
• Los equipos periféricos (impresoras, escáneres, lectores de códigos de barra, lectores de
tarjetas con bandas magnéticas, lectores de tarjetas inteligentes, equipos especiales de
medición20, etc.).
• Los armarios para los servidores. No es una excepción que el SAC o el ERP de una entidad
mediana o grande tenga que explotar decenas de servidores (y en algunos casos centenas),
interconectados entre ellos y con los medios de comunicación, con actualizaciones bastante
frecuentes. El gestionar físicamente esas fábricas de servidores (servers factories), sin los
muebles adecuados se puede convertir, y desafortunadamente se convierte con frecuencia, en
una maraña de cables impenetrable, origen de múltiples interrupciones.
• Los locales donde se instalarán los armarios de servidores tienen también que seleccionarse y
prepararse adecuadamente. Aun cuando con la tecnología actual no se requiere un monitor y
un teclado para cada servidor, sino que un monitor y un teclado puede conectarse a varios
servidores, el espacio para desplazarse en el local de los servidores, con el fin de sustituir o
incorporar nuevos equipos, debe ser lo suficientemente amplio para no provocar dificultades
en su gestión.
Por otra parte el acceso y las condiciones del ambiente (temperatura y humedad) en esos
locales tienen que estar bajo control, con el fin de que no se produzcan interrupciones
indeseadas.
20
Los SAC o ERP que manejan la facturación de servicios públicos, como la electricidad, el gas y el agua
pueden tener como periféricos equipos especiales para medir mensualmente, casa a casa el consumo, y
después en un acceso a la red local, o por redes inalámbricas, transmitir la información al sistema central.
56
5.3 Las telecomunicaciones
Como ya se habrá podido apreciar, el tema de las telecomunicaciones es vital en los actuales ERP o
SAC.
El componente telecomunicaciones puede desglosarse en los siguientes elementos:
 Los enlaces entre locales en distintas ubicaciones geográficas

 Las redes de área local
 Los equipos que permiten que las redes se comuniquen entre ellas
 Los elementos de seguridad y protección
Los enlaces entre locales en distintas ubicaciones geográficas pueden ser propios, o
suministrados por una red pública de transmisión de datos (RPTD).
Los enlaces propios pueden ser la única opción en aplicaciones donde la protección de la
información sea de vital importancia. La utilización de las RPTD tiene siempre un riesgo sobre la
confidencialidad de los datos que se transmiten y los posibles ataques desde el exterior21.
Cuando las distancias no son muy grandes, los puntos geográficos a conectar no son muchos, y el
grueso del tráfico es interno, la instalación de enlaces propios, ya sea con fibras ópticas, o con
transmisión por radio22, pueden representar una alternativa con ventajas económicas. Claro está,
estas ventajas económicas dependen en primer lugar de las tarifas que apliquen las compañías
que brinden los servicios de RPTD.
La instalación de una red propia de datos entre locales debe tomar en cuenta, adicionalmente a
los costos de la inversión inicial, los costos de mantenimiento, que en muchos casos no son
despreciables. Si esta es la alternativa que se adopta, las capacidades de los enlaces requeridos
deben ser determinadas y proyectadas para una perspectiva de no menos de 3 años.
Los parámetros fundamentales de los enlaces a distancia son:
Tipo de conexión: radio enlace, fibra óptica propia, línea de RPTD arrendada, que a su vez puede
ser: frame relay, dirección IP, transmisión de datos sobre líneas de celulares, etc. Cada uno de
estos tipos de conexión tiene sus ventajas, limitaciones y costos. El análisis para la selección de
uno de ellos debe basarse en los volúmenes, la frecuencia de uso, el tamaño de los paquetes, los
requisitos de confidencialidad y, obviamente, el presupuesto disponible.
El ancho de banda requerido es uno de los elementos que más frecuentemente se subvalora. Si el
sistema sólo transmite y recibe datos alfanuméricos, los requisitos no serán muy altos para las
tecnologías existentes en la actualidad. En cuanto se requiera transmitir imágenes y sonidos, el
ancho de banda necesario puede tener que multiplicarse al menos por 10.
21
Existen equipos que permiten simular una red privada dentro de una red pública (VPN por su nombre en
inglés, virtual private network), pero su uso no es recomendable en aplicaciones de mucha importancia.
22
No se incluye la posibilidad de enlaces por cobre entre locales ya que, aunque posible, es muy vulnerable
a las descargas eléctricas de la atmósfera, causando no pocas averías cuando se producen.
57
Los protocolos de comunicación a emplear fueron en un tiempo tema de análisis y toma de
decisiones. En la actualidad con la presencia casi universal de TCP/IP, es poco probable que se
seleccione otra opción.
Por último en los enlaces a distancia debe revisarse con detenimiento los equipos a instalar en los
extremos (módems, enrutadores, etc.). Si el enlace se le contrata a una empresa proveedora del
servicio, las características de ese equipamiento y las responsabilidades de mantenimiento y
reparación, deben quedar claras en el contrato que se firme con esta. Si los equipos son propios,
debe preverse la existencia de repuestos suficientes para no tener que suspender el servicio por
mucho tiempo en casos de roturas.
Las redes de área local deben diseñarse cuidadosamente, sobre todo en el tendido de los cables.
Existen en la actualidad tecnologías de cableado estructurado, que facilitan la asimilación de los
cambios de ubicación física que frecuentemente se producen en un ambiente de oficinas.
Una buena práctica es proyectar el cableado de las redes de área local junto con las redes
requeridas para las conexiones de los teléfonos, los equipos contra intrusos, y otros equipos
señalizadores, de tal forma que no se duplique esa infraestructura. Al conjunto de estas redes se le
da el nombre de redes de corrientes débiles.
En los últimos años se han venido introduciendo, cada vez con más fuerza, las redes inalámbricas,
que eliminan todos los problemas que, con los movimientos físicos de los puestos de trabajo, se
crean con las redes con cables. El principal problema de las redes inalámbricas es el de la
protección de los datos, algo que con ese medio no tiene ni tendrá una solución total.
Los equipos básicos de una red de área local son los concentradores, los conmutadores y los
puentes23 (hubs, switchs, y bridges respectivamente en inglés) y las tarjetas de red que se
conectan a las computadoras.
Los concentradores, conmutadores y puentes se conocen como equipos de nivel 2, porque
trabajan en el nivel de enlace (nivel 2 del modelo OSI).
Los concentradores son equipos a los que se conectan un grupo de computadoras, y permiten el
intercambio de información entre estas, al reenviar cada paquete que recibe a todas las demás.
Los concentradores se utilizan en redes que no tengan más de 16 computadoras conectadas entre
sí y que en general no requieran conectarse con otras.
Los conmutadores tienen básicamente las mismas funciones que los concentradores, pero realizan
su trabajo de una forma más eficiente, ya que mantienen actualizada una tabla con las direcciones
de todas las máquinas que se le conectan y cuando reciben un paquete para una de ellas sólo se lo
mandan a estas y no a las restantes. Los conmutadores permiten normalmente la conexión entre
23
La La clasificación dada aquí para los equipos de redes es la clásica, algunos fabricantes suministran
modelos de equipos para redes que reúnen varias de las capacidades que en lo adelante se describen para
los equipos básicos, incluyendo los enrutadores explicados en el siguiente acápite.
58
varios de ellos, para crear así redes de área local con cientos, o incluso miles, de puestos de
trabajo (ver cuadro 5.2).
Los puentes son equipos muy similares a los conmutadores, pero que se especializan en unir dos o
más redes entre ellas, funcionan básicamente utilizando software y están limitados a 16 puertos.
Las tarjetas de red vienen en la actualidad incluidas en la configuración de prácticamente todas las
computadoras personales, y en general no son ya tarjetas en sí, sino microprocesadores
especializados incorporados a la tarjeta madre de la computadora, o incluso a otros
microprocesadores.
En cuanto al protocolo a utilizar a nivel de red de área local, el de Ethernet, por su universalidad
no parece tener rival en estos momentos, aunque también se utiliza otro llamado Token Ring.
Las velocidades de transmisión a nivel del último segmento de la red son normalmente de 10 o
100 Mbps, aunque pueden ser de 1 Gbps. Los enlaces entre conmutadores deben tener como
mínimo una velocidad de 1 Gbps.
RED DE ÁREA LOCAL
CONMUTADOR
LEYENDA
CONMUTADOR FIBRA ÓPTICA
UTP-6
PUESTO DE
TRABAJO
CONMUTADOR
Cuadro 5.2 Red de área local. Elaboración propia
El cable a utilizar para los enlaces entre las computadoras y los concentradores o conmutadores es
normalmente UTP-624, para los enlaces entre conmutadores se utiliza con mayor frecuencia fibra
óptica.
24
UTP (unshielded twisted par) es un cable no protegido que tiene 8 hilos trenzados de dos en dos. Existen
para varias categorías que definen sus características. En las redes actuales se utiliza mayormente la
categoría 6 (UTP-6).
59
El largo del cable entre la computadora y el concentrador o conmutador está restringido a 100
metros. La fibra óptica para la conexión entre conmutadores puede alcanzar por lo general una
distancia de 400 metros.
Existe también la posibilidad de establecer una red de área local sin cableado, utilizando las ondas
de radio para el transporte de las señales, básicamente a través del protocolo Wi-Fi. Para
aplicaciones con ciertos requisitos de protección, esta alternativa no es recomendable como ya se
comentó anteriormente.
Los equipos que permiten que las redes se comuniquen entre ellas, son conocidos como
enrutadores, (routers en inglés).
Los enrutadores son equipos que trabajan en el nivel de red (nivel 3 del modelo OSI), y se ocupan
de enviar los paquetes que reciben a la red que corresponda (ver cuadro 5.3).
ENRUTADORES
CONMUTADOR
RED 1
ENRUTADOR R1 LEYENDA
OTROS CONMUTADORES
Y PUESTOS DE TRABAJO RED 1 FIBRA ÓPTICA
INTERNET O
ENLACE EXTERNO
INTRANET
UTP-6
OTROS CONMUTADORES PUESTO DE

TRABAJO
Y PUESTOS DE TRABAJO RED 2
ENRUTADOR R2
CONMUTADOR
RED 2
Cuadro 5.3 EnRutadores. Elaboración propia
Para garantizar los enlaces entre redes, los enrutadores utilizan el protocolo IP, que es
prácticamente universal para este nivel en la actualidad, tanto en los accesos a nodos de Internet,
como en la interconexión de redes privadas, conocidas también como “intranets”.
El principal adelanto en la transmisión de datos se produjo cuando se pasó de conmutación de
circuitos a conmutación de paquetes.
En la conmutación de circuitos cada extremo debe estar unido por un enlace físico, que puede
tener n segmentos, y cada segmento con su tecnología (cable de cobre, fibra óptica, ondas de
radio), pero unidos físicamente durante todo el tiempo que dure la comunicación. La velocidad de
transmisión en este esquema depende del segmento con menor capacidad, y las capacidades de
cualquier otro segmento que sean superiores se subutilizan.
60
En la conmutación de paquetes, por el contrario, la información a transmitir, ya sean datos,
sonidos o imágenes, se divide en pedazos (paquetes) que se envían uno a uno a la red, y toman
por el camino que en ese momento esté disponible y sea más eficiente. Los paquetes así
transportados a su destino, son ensamblados nuevamente allí y se entregan al usuario como si
hubieran viajado juntos.
Los posibles caminos de un punto a otro en una red cuyos nodos tienen varias conexiones con
otros nodos, son múltiples, y utilizando sofisticados algoritmos de enrutamiento dinámico, se
puede optimizar tanto el camino de cada paquete, como el uso de las capacidades de los
diferentes enlaces.
Los enrutadores son computadoras especializadas que aplican esos algoritmos, por lo que tienen
que tener una gran potencia en nodos con muchos enlaces.
61
5.4 La información
La información constituye la materia prima, el principal activo fijo intangible, la herramienta, y el
producto final de todo ERP o SAC.
Como materia prima la información está contenida en formularios (en papel o electrónicos),
mensajes y ficheros que recibe el sistema.
Como producto final la información se materializa en reportes (también en papel o electrónicos),
en mensajes y en ficheros que entrega el sistema.
La documentación de todos los elementos del sistema representa la herramienta más utilizada en
su explotación.
Las bases de datos que se crean y actualizan, constituyen el principal activo fijo intangible que se
produce y utiliza con los ERP o SAC.
En los últimos años se ha introducido el concepto de almacén de datos (data warehouse), como
colecciones de bases de datos, que se actualizan de forma diferida, para apoyar la inteligencia
empresarial, a través de la así llamada minería de datos (data mining).
Todos estos elementos deben ser diseñados y actualizados con el debido cuidado. A continuación
se comentan algunos aspectos a tener en cuenta para cada uno de ellos.
Los formularios, tanto los que se imprimen en papel, como los que se llenan en la pantalla de una
computadora, deben diseñarse buscando que sean fáciles de completar, y que garanticen la
máxima calidad de los datos que se capten. Algunas reglas generales son:
• El orden de los campos debe seguir una secuencia lógica.
• Los nombres de los campos a llenar deben ser lo suficientemente explícitos para que no surjan
confusiones. Una explicación de cada campo en el propio formulario en papel, o la posibilidad
de acceder a una ayuda en el caso de las computadoras, pueden ser de gran utilidad.
• Si el formulario es en papel, los campos deben tener el tamaño adecuado para que quepa toda
la información que se solicita. En los formularios a cumplimentar a través de computadoras,
puede mostrarse una ventana para introducir la información aun cuando esta vaya
corriéndose hacia la izquierda en la medida que se teclea (scrolling).
• En los casos en que un campo solo pueda tomar el valor de algunas pocas alternativas, es
preferible enumerarlas y pedir que se marque la que corresponda. Esta posibilidad se potencia
cuando el formulario debe llenarse de forma electrónica, ya que se puede mostrar una lista de
nombres y captar el código asociado al que se seleccione. En este caso debe cuidarse que la
lista de elementos a seleccionar no sea demasiado grande y que, si el que está completando el
formulario conoce el valor a introducir, lo pueda hacer sin tener que consultar la lista. De ser la
lista muy grande y preferirse esta alternativa, el programa deberá avanzar en la lista en la
medida que se tecleen las primeras letras de la palabra que se quiere seleccionar, de tal forma
que la localización de la alternativa sea rápida.
62
• La redundancia entre campos debe evitarse, ya que puede producir errores innecesarios. Sólo
cuando la redundancia se utilice para comprobar la validez de vario campos introducidos
manualmente, como es el caso de las cifras de cuadre, esta es aceptable. Así por ejemplo, si se
pide la fecha de nacimiento no hay porque solicitar la edad, o si se pide un código de algún
objeto registrado en el sistema, no hay porque solicitar su nombre.
• Debe quedar explícito que campos son de obligatorio cumplimiento y cuales son opcionales.
• La fecha en que se capta la información y la persona que lo cumplimenta debe aparecer en
todos los casos y ser de obligatorio llenado en los formularios en papel, exceptuando claro
está cuando se capte una encuesta que requiera ser anónima. Cuando el formulario se capta
por una pantalla, la fecha del sistema y la identificación del operador deben ser campos de la
tabla donde se registren los datos del formulario.
• No deben solicitarse datos para los que su uso no está claro, mientras menos información se
pida, mejor será la calidad del proceso de captación.
• En los formularios que se captan por pantallas, la validación de los datos debe hacerse, cuando
sea posible, dato a dato. Los errores que se detecten deben informarse de inmediato, con una
explicación clara de la causa del error y permitirse su rectificación.
Además del formato del formulario, debe diseñarse su flujo, desde que se confecciona hasta que
se archiva. Para cada paso del flujo se deberá definir el responsable y las acciones a realizar sobre
el formulario.
El intercambio de mensajes entre sistemas automatizados es la forma más utilizada para procesar
transacciones que tienen que ver con más de un sistema.
Así, por ejemplo, si un cajero automático está procesando una solicitud de efectivo, le envía un
mensaje al ente autorizador, el cual trata el mensaje recibido como una transacción en sus
registros contables y envía la respuesta correspondiente. El cajero finalmente al recibir la
autorización (o rechazo) de la solicitud, completa o aborta, en dependencia de la respuesta
recibida, la transacción solicitada por el cliente.
Los mensajes entre sistemas automatizados están altamente estandarizados. Para mensajes
financieros existe, por ejemplo, la norma ISO-8583, que define los mensajes a intercambiar en
transacciones financieras.
ANSI X12 y EDIFACT son otros ejemplos de normas sobre mensajes a intercambiar entre sistemas
automatizados, en este caso fundamentalmente para la compra – venta de productos entre las
empresas, incluyendo la transportación de los mismos.
Los estándares para intercambio de mensajes deben definir para cada uno de ellos, entre otros
aspectos: las posibles respuestas, los códigos a emplear, los formatos de los campos, el alfabeto
admisible, los campos que son obligatorios y la forma de comprobar la integridad del mensaje.
Lamentablemente, a pesar de la estandarización existente, muchos sistemas automatizados, sobre
todo de entidades que tienen un amplio dominio de su mercado, tienen sus propios mensajes que,
63
frecuentemente, no son más que modificaciones de las normas existentes, pero que obligan a
quienes quieran conectarse a elaborar programas específicos para garantizar las particularidades.
El uso del formato XML25 para los mensajes y ficheros a intercambiar, representa un paso
importante en la estandarización y se impone cada vez más.
El diseño de los reportes debe hacerse con una activa participación de los usuarios finales de los
mismos.
Esto no quiere decir que se acepten, sin razonarlos, todos los detalles que se soliciten.
Frecuentemente, sobre todo cuando se está diseñando un nuevo sistema, los usuarios no tienen
toda la información sobre como cambiará su contenido de trabajo, y tienden a solicitar los mismos
reportes que utilizaban antes de existir el nuevo sistema, algo que en muchas ocasiones no es
necesario y en algunos casos puede ser incluso imposible.
Las sesiones de trabajo con los usuarios para definir los reportes deben utilizarse, por esta razón,
para que los diseñadores comprendan los detalles del trabajo específico de la entidad que se
automatiza, y los usuarios reciban información sobre las características del nuevo sistema.
La definición detallada de los reportes que deben emitirse, permite detectar errores de diseño en
el nuevo sistema, por lo que no debe dejarse para el último momento26.
El diseño final de los reportes va a depender en buena medida de las herramientas que estén
disponibles para su programación.
Algunas recomendaciones específicas para los reportes son las siguientes:
 La fecha de confección y la persona que lo solicitó debe aparecer siempre en el reporte.
 Todas las páginas deben estar numeradas.

 El final del reporte debe informarse explícitamente en la última página.
 Debe permitirse seleccionar el soporte en el que se emitirá el reporte que se solicita. En
general las alternativas son: pantalla, impresoras gráficas, impresoras de matriz de puntos,
tabla Excel, documento (Word o Pdf), XML.
 El reporte emitido en cualquiera de esos formatos, o los elementos que posibiliten su nueva
emisión, con los mismos datos originales, deben guardarse en la base de datos por un período,
con el fin de facilitar su reimpresión. Recuérdese que muchos reportes se hacen con una
fotografía instantánea de la base de datos, que momentos después puede haber cambiado.
25
XML por su nombre en inglés (Extended Markup Lenguage), es un formato que permite intercambiar
informaciones utilizando maquetas genéricas que pueden obtenerse desde tablas o ficheros específicos de
lenguajes o sistemas de gestión de bases de datos, y ser convertidas después a otros lenguajes o sistemas de
gestión de bases de datos. XML permite por lo tanto eliminar el tratamiento detallado de las especificidades
de cada sistema cuando se intercambia información entre estos.
26
Algunas metodologías de diseño de sistemas parten de los reportes que se requieren, y definen “hacia
adentro” el resto de las características del nuevo sistema. Debido a que un nuevo sistema automatizado no
debe por lo general mimetizar el existente, sino realizar una verdadera reingeniería de los procesos, estas
metodologías son sólo válidas en casos muy particulares.
64
 Cuando un mismo reporte puede emitirse para varios subconjuntos de datos, los criterios para
seleccionar el subconjunto que se desee, deben definirse como parte del diálogo que se
establezca para solicitarlo. Ejemplos: la definición de las fechas de inicio y fin para la emisión
de reportes sobre cierto período, la definición de uno, varios o todos los componentes de un
conjunto que forma parte de un reporte, etc.
 Si el conjunto de datos para emitir un reporte está vacío por cualquier razón, debe informarse
este hecho de forma explícita.
 Los reportes que se emiten en papel deben poder reimprimirse en cualquier intervalo de
páginas.
Los ficheros a intercambiar con otros sistemas están en muchos casos estandarizados, por lo que
no siempre es necesario su diseño.
A diferencia de los mensajes, que se utilizan normalmente para realizar, en tiempo real,
transacciones que involucran varios sistemas, el intercambio de ficheros se utiliza para enviar
conjuntos de datos que pueden ser tratados de forma diferida, como lotes.
Cuando el intercambio de ficheros enfrenta un caso particular, para el que no se tiene un
estándar, el diseño tiene que ser muy meticuloso, ya que se trata de una interacción entre
sistemas automatizados que, como ya se dijo, no admite improvisaciones.
Los códigos a emplear, los formatos de los campos, el alfabeto admisible, los campos que son
obligatorios y, en algunos casos, los lenguajes de programación que se utilizarán en ambos
extremos, deben definirse con precisión.
En todos los casos, el sistema que recibe un fichero deberá comprobar que las reglas acordadas en
su diseño se cumplen con exactitud, antes de proceder a su aceptación y procesamiento.
El nombre de los ficheros, o algún campo de su contenido, debe permitir que se controle que no
se cometan errores de omisión o repetición de ficheros en su tratamiento.
La inclusión de campos redundantes con elementos de criptografía, códigos hash por ejemplo, que
permitan controlar que no se afectó la integridad del fichero, es una práctica saludable en el
intercambio de estos.
Cuando la entrega del soporte que contiene los ficheros es manual, se deberá emitir un
comprobante escrito sobre su recepción. Este comprobante debe contener, como mínimo, los
nombres de quien entrega y quien recibe, el nombre del fichero, la fecha y hora en que se produce
la entrega, y el propio campo que permite comprobar la integridad del fichero comentado en el
párrafo anterior.
A la documentación de todos los elementos del sistema debe prestársele la mayor atención
posible. Una buena documentación se caracteriza por ser exhaustiva, estar actualizada y ser de
simple utilización.
Todo elemento del ERP o SAC que no esté correctamente documentado, representa un riesgo
potencial para el correcto funcionamiento del mismo.
65
La selección del momento para elaborar la primera versión de la documentación de un sistema es
de gran importancia. Si se decide comenzar a hacerla muy temprano, será necesario reelaborarla
varias veces, ya que durante el diseño y realización de un sistema se modifican frecuentemente
aspectos que deben ser documentados. Esperar al final de la puesta a punto del sistema para
elaborar la documentación tiene, por otra parte, la desventaja de añadir un período de tiempo al
total necesario para la introducción del sistema.
La documentación inicial no es suficiente. Los sistemas y sus elementos están sujetos a constantes
actualizaciones, las mismas deben reflejarse en la documentación correspondiente, o está última
se volverá muy rápidamente obsoleta. Al personal responsable del mantenimiento al sistema debe
exigírsele que cumpla con este requisito.
Lograr que una documentación sea simple y completa es una tarea que requiere un gran esfuerzo.
La capacidad de expresarse por escrito con claridad, y el poder de síntesis, no son de las cualidades
más comunes y, desafortunadamente, normalmente escasas en el personal de diseño y
programación.
En entidades con gran complejidad y volúmenes, debe revisarse la posibilidad de especializar
personal en esta tarea, tanto para la confección de alguna parte de la documentación, como para
exigir la calidad de los documentos que obligatoriamente tendrán que elaborar otros especialistas.
Las bases de datos como ya se dijo constituyen el principal activo fijo intangible de los ERP o SAC.
Los sistemas de gestión de bases de datos que utilizan el modelo relacional (SGBDR ) representan
la tecnología más apropiada para los ERP o SAC, debido a su carácter eminentemente
transaccional y al alto grado de estructuración de la información que registran.
Una base de datos relacional (ver 28) está constituida por un conjunto de tablas, cada una con una
o varias columnas. Las tablas se pueblan con filas, cuya cantidad varía normalmente de forma
dinámica y, en un momento dado, puede ser cero.
El diseño de una base de datos es un trabajo que requiere, por una parte, una alta calificación
técnica en ese campo, y por otra, un profundo conocimiento de las organizaciones que serán
objeto de automatización.
El resultado final del diseño de una base de datos es un conjunto de tablas interrelacionadas. Para
cada tabla se deben definir las columnas que contiene, de ellas las que componen las llaves
primarias27 y externas; las relaciones con otras tablas y las reglas formales que deben cumplir
todas las filas.
En ciertos casos se pueden y deben definir, adicionalmente, las acciones a tomar cuando una tabla
se actualiza, ya sea insertando, modificando o eliminando una fila.
27
La llave primaria de una tabla está compuesta por el conjunto de columnas que identifican unívocamente
cada fila de la tabla. Por esta razón la combinación de valores de esas columnas no puede repetirse. Las
llaves externas son combinaciones de columnas que representan llaves primarias en otras tablas.
66
Existen herramientas para facilitar el diseño de las bases de datos, entre ellas, el modelo entidad
relación28. Este modelo fue propuesto por vez primera por Peter P. Chen en 1976 (ver 30), brinda
una metodología para definir la estructura de una base de datos y normalizarla (ver 31), y cuenta
con varias implementaciones en software para apoyar ese proceso.
El cuadro 5.4 muestra un esquema entidad relación de un subconjunto de tablas de la base de
datos del SABIC.
DIAGRAMA ENTIDAD – RELACIÓN DE LAS CUENTAS EN EL SABIC
0..n BANCOS
0..1
CONCEPTOS
Contraparte 0..1
1..n 0..n
Opera como 0..n
PERSONAS 0..n 0..n CUENTAS 0..n Forma parte 1
MONEDAS
1..n 0..n 0..n 0..n
Contraparte
CUENTAS/
1 SUBCUENTAS
0..1
0..n CLIENTES
1
TIPOS DE
CONTRAPARTIDA
Cuadro 5.4 Diagrama entidad – relación. Elaboración propia
En ese esquema los cuadros representan entidades, las líneas indican relaciones entre tablas y los
números en los extremos definen la cardinalidad de la relación.
Las relaciones persona – banco y persona – cliente, denominadas ¨Trabaja en¨ indican existe un
enlace entre las personas y los bancos o clientes que se caracteriza porque la persona es un
empleado del banco o del cliente en cuestión.
La relación persona – cuenta puede tener los significados de firmante o tramitador de una cuenta,
en su carácter de empleado de un cliente o de un banco, o de poseedor de cuentas en el caso de
cuentas de personas naturales.
La cardinalidad 0..n que está, por ejemplo, al lado de la entidad bancos, en la relación personas –
bancos, significa que una persona no tiene porqué ser empleada de un banco, o que puede ser
empleada de n bancos al mismo tiempo, algo factible por ejemplo en empleados de bufetes que
representan a varios bancos.
67
Un posible diseño del caso presentado en el cuadro 5.4, en una base de dato relacional, pudiera
ser definir una tabla por cada entidad, que contenga los datos específicos de esa entidad y los que
precisen sus relaciones.
Así, por ejemplo, la tabla de personas pudiera contener los siguientes campos:
 Nombre(s)
 Apellido(s)
 Dirección
 Número de identidad
 País que emite la identidad
 Código del banco 1
 …….
 Código del banco l
 Código del cliente 1
 …
 Código del cliente m
 Número de cuenta 1
 …
 Número de cuenta n
De hacerse así, habría que resolver el problema de cuantas columnas definir en esta tabla para
registrar los bancos, clientes y cuentas a los que está asociado, ya que para cada persona sólo
debe existir una fila, si no se quiere repetir el resto de la información que está asociada a cada una
de ellas (nombres, apellidos, dirección, etc.).
De forma similar, en las tablas clientes, bancos y cuentas, habría que definir la cantidad de
columnas que se reservarían para registrar las posibles personas que se le asocian.
Como se podrá entender con facilidad, esta solución corre el riesgo de definir insuficientes
columnas para una relación, con el peligro de tener que modificar su estructura en un futuro; o
demasiadas columnas para cubrir este riesgo, con lo que se desperdiciaría bastante espacio de
almacenamiento29.
Este tipo de problemas tiene que abordarse como parte del diseño de las bases de datos, y es uno
de los que se resuelven con la así llamada normalización de la base de datos (ver recuadro).
29
Con la tecnología actual el espacio que ocupen todas las columnas de una tabla debe reservarse en disco
para cada fila, contenga o no información.
68
NORMALIZACIÓN DE UNA BASE DE DATOS
Primera forma normal: Todas las filas de una tabla tienen que tener la misma cantidad de
columnas. Cada columna debe corresponderse con un solo atributo.
Segunda forma normal: Todos los campos que no son llave deben ser una función del campo llave.
Tercera forma normal: Ningún campo que no sea llave puede ser función de otro campo no llave.
Cuarta forma normal: Una fila no puede contener dos o más hechos independientes con múltiples
valores sobre una entidad.
Quinta forma normal: Un artículo no puede reconstruirse con varios tipos de artículos más
pequeños.
El cuadro 5.5 muestra una solución a esta dificultad. Como se puede apreciar en el mismo, se han
introducido 3 nuevas entidades, las personas por banco, las personas por cuenta y las personas
por cliente.
Con esta solución la cantidad de personas por banco, por ejemplo, serán 0 o n filas de la tabla
“personas por banco”, y en las tablas bancos y personas no tendrá que registrarse esa relación. Lo
mismo sucede con las tablas clientes y cuentas en su relación con la tabla de personas.
DIAGRAMA ENTIDAD – RELACIÓN DE LAS CUENTAS EN EL SABIC

NORMALIZADO
Casa Matriz
1
1
BANCOS 0..n
0..n
0..1
PERSONAS TRABAJAN
Contraparte
EN BANCOS CONCEPTOS
0..n 0..1
1 PERSONAS 0..n
0..n
1 0..n 0..n 1
PERSONAS OPERAN Forma parte CUENTAS MONEDAS
Forma parte 0..n 1
1
CUENTA 0..n 0..n 0..n
Forma parte
Contraparte
CUENTAS/
0..n 1
SUBCUENTAS
PERSONAS TRABAJAN
EN CLIENTE
0..n 0..1 1
TIPOS DE
1
CLIENTES
CONTRAPARTIDA
cuadro 5.5 Diagrama entidad – relación normalizado. Elaboración propia
En la actualidad existen múltiples SGBDR30, que garantizan el trabajo con transacciones y cumplen
con la prueba A.C.I.D. explicada en el capítulo 3 de este libro.
30
Entre los SGBDR más utilizados en la actualidad se encuentran ORACLE, SQL-server y Progres, este último
de código abierto.
69
El lenguaje de manipulación de datos que se ha impuesto es el SQL (Structured Query Language),
sobre todo a partir de 1984 cuando IBM anunció que pondría en explotación una base de datos
relacional que lo utilizaba (ver 29).
A los diseños iniciales de los SGBDR se le han añadido en los últimos 30 años un grupo importante
de mejoras, que les han permitido apoyar la solución de problemas cada vez más complejos. De
ellas, la más abarcadora parece ser la inclusión de código como parte de la base de datos, bajo la
forma de funciones definidas por los usuarios, procedimientos almacenados y procedimientos,
llamados disparadores, que se ejecutan cuando se produce una actualización de la tabla (user
defined functions, stored procedures y triggers, en inglés).
La mayor parte de los ERP o SAC que existen en la actualidad tienen una estructura de la base de
datos previamente definida, que sólo admite ciertas extensiones para incorporar nuevas tablas o
campos a tablas existentes. La comprensión del diseño de esas bases de datos es de vital
importancia para la correcta implementación y mantenimiento de esos sistemas.
Los lenguajes de programación modernos utilizan básicamente el paradigma de estar orientados a
objetos, entendiendo por tales cápsulas que no sólo representan estructuras de datos, sino que
incluyen también procedimientos que se aplican a esas estructuras. En estos lenguajes la
definición de nuevos objetos puede partir de ¨heredar¨ las estructuras y procedimientos de
objetos ya definidos, con lo que la reutilización de código se potencia extraordinariamente.
Con el fin de encubrir las diferencias entre los objetos y las tablas de las bases de datos
relacionales, la mayoría de los lenguajes de programación actuales utilizados para los SAC o ERP
vienen acompañados con lo que se conoce como mapeadores objetos – relaciones (ORM por su
nombre en inglés). Los ORM le permiten a los programadores pensar sólo en los objetos por él
definidos al momento de codificar los algoritmos, mientras que en el momento de ejecución es el
ORM el que se encarga de interactuar con las tablas de la base de datos que correspondan.
Los almacenes de datos han tenido en los últimos años una gran divulgación en los medios
especializados. Un almacén de datos no es más que una o varias bases de datos, que se
reestructuran con el objetivo de facilitar la búsqueda de información relevante para la toma de
decisiones.
Recuérdese que una base de datos normal para un ERP o SAC, debe priorizar la facilidad de su
actualización en tiempo real en modo transaccional y la emisión de reportes periódicos ya
establecidos, por lo que su estructura no necesariamente facilita la obtención de informaciones
interrelacionada sobre ciertas entidades, que están contenidas en la base de datos.
Tómese por ejemplo una tabla histórica sobre los registros contables que se han producido en una
base de datos de un SAC. Esa tabla debe contener toda la información contable que se ha
generado desde que se implantó el sistema, incluyendo lo ocurrido en el tiempo, con cada cliente,
en cada centro de costo, o con cualquier otro criterio en el que se detalle la contabilidad en
cuestión.
La tabla existe en la base de datos, pero su acceso, con el fin de establecer relaciones y análisis
estadísticos sobre esas entidades, no sería normalmente recomendable, debido a que por razones
70
de eficiencia esas tablas no incluyen muchos índices, ni se deben someter a recuperaciones que
consuman mucho tiempo, o produzcan un gran volumen de datos.
La solución idónea es crear un almacén de datos con esa y, eventualmente, otras tablas de la base
de datos del SAC, o de otros sistemas automatizados de la empresa, y estructurarlo de tal forma
que se facilite la recuperación de información para la toma de decisiones.
Los almacenes de datos no tienen obviamente que cumplir con los requisitos de actualización en
tiempo real en modo transaccional. Su actualización se realiza con una periodicidad nunca inferior
a un día, en procesos que corren de forma autónoma en los servidores, normalmente en horarios
de poca carga, y que pueden durar muchas horas.
La minería de datos abarca un conjunto de técnicas de exploración del contenido de los
almacenes de datos, para buscar correlaciones y patrones entre decenas de campos, con el fin de
elaborar información relevante para la toma de decisiones.
Estas técnicas permiten analizar los datos desde diferentes dimensiones o ángulos, categorizarlos,
y resumir las interrelaciones detectadas.
71
5.5 Los programas informáticos
Los programas informáticos que se requieren para el funcionamiento de un ERP o SAC pueden
agruparse en las siguientes categorías:
• Sistemas de explotación
• Sistemas de gestión de bases de datos relacionales (SGBDR)
• Programas del ERP o SAC
• Compiladores y otras herramientas de programación
• Otros programas utilitarios
Los ERP o SAC utilizan normalmente varios sistemas de explotación, especializados en el trabajo
de servidores, de puestos de trabajo, de equipos móviles y, eventualmente, de equipos de
comunicación.
Para los servidores y puestos de trabajo las opciones más utilizadas en la actualidad son Windows
y Linux. Ambos sistemas tienen sus ventajas y desventajas.
Windows tiene el aval de un gran número de programas con un alto nivel de prestaciones. Para los
ERP y SAC, el SGBDR SQL-server y el paquete de Office (Word, Excel, PowerPoint, Outlook,
InfoPath, etc.) son de gran utilidad y contienen lo más avanzado del mercado en sus
especialidades.
Windows es propiedad de Microsoft quien, al ser ese su negocio, exige el pago de licencias y no
publica el código fuente de sus programas.
El no poder conocer exactamente lo que ocurre dentro de esos programas y depender de las
decisiones de esa empresa, que persigue a toda costa aumentar sus ganancias totales, aun cuando
se afecte una parte de sus clientes, representan desventajas de esos programas.
Quizás la única ventaja que tiene el bloqueo económico de los Estados Unidos contra Cuba, es que
no se les paga las licencias por el uso del software. De hecho el software producido por empresas
de Estados Unidos no puede utilizarse en Cuba según las leyes de ese país. Sin embargo, los
canales de distribución del software para computadoras personales son tan amplios, que bloquear
su adquisición es prácticamente imposible.
El no tener acceso al código fuente del sistema de explotación y de los demás paquetes de
programas de Microsoft, le da a esa empresa una ventaja competitiva, a la hora de desarrollar
aplicaciones que los utilizan o se interrelacionan con ellos. La posibilidad de incluir en esos
programas rutinas que les permitan, a quienes las conozcan, entrar a las computadoras que los
utilizan de forma oculta es otra desventaja de los mismos.
Un ejemplo de la actitud de Microsoft de maximizar sus ganancias a toda costa, lo constituye el
abandono de VisualFoxpro como herramienta de desarrollo de aplicaciones, después de haberla
adquirido 5 o 6 años antes.
VisualFoxpro tenía una comunidad de usuarios nada despreciable en el campo de los ERP y SAC,
pero era una competencia directa de otros productos de Microsoft, por lo que lo descontinuaron.
72
Linux, que no es más que una versión de UNIX escrito nuevamente desde cero, con el fin de poder
publicar el código fuente, representa una buena alternativa y es el sistema de explotación que
encabeza el así llamado software libre31.
El módulo central (kernel en inglés) de Linux puede utilizarse en prácticamente todas las
computadoras, desde las supercomputadoras hasta los teléfonos inteligentes.
El servidor de servicios web más utilizado en el mundo (Apache) se programó inicialmente para
Linux. Prácticamente todos los SGBDR importantes funcionan también sobre Linux.
Odoo (antes Open-ERP) que se describe en uno de los capítulos de este libro, es un ERP completo
que funciona bajo el esquema de software libre y corre bajo Linux, aunque también en Windows.
Los paquetes de programas del tipo de Office en software libre son, sin embargo, según criterios
bastante comunes, inferiores al de Microsoft.
Las empresas que mantienen versiones de Linux en funcionamiento obtienen sus ingresos de
donaciones, fundamentalmente de gobiernos, y del cobro de servicios de consultoría asociados al
uso de ese sistema.
La discusión software libre contra propietario, a nivel de sistema de explotación de servidores y
puestos de trabajo no ha culminado. Las ventajas estratégicas del software libre parecen inclinar la
balanza a su favor. Sin embargo el nivel de negocio del software propietario es de tal magnitud
que las inversiones en ese campo han logrado, y pueden lograr en un futuro aun, productos que
por sus prestaciones sean los que se impongan.
En los equipos móviles la lucha en estos momentos es entre dos versiones del kernel de Unix, la de
Apple (IOS) totalmente propietaria y la que posee en la actualidad Google (Androide) que funciona
con un esquema de software abierto. Windows, aunque presente también en este mercado, tiene
una participación insignificante en el mismo.
Algo similar sucede con los sistemas de explotación de los equipos de comunicación, donde las
versiones propietarias que inicialmente desarrollaron los principales fabricantes de estos equipos,
se han venido sustituyendo por módulos centrales basados en Unix.
En el campo de los SGBDR, aun cuando la lista de productos sobrepasa la centena, el mercado
para los ERP y SAC está bastante concentrado en 6 productos (ver 32).
31
La corriente de software libre surgió con la Fundación de Software Libre (FSF por su nombre en inglés) y el
proyecto GNU a mediados de los 80 del pasado siglo. El principal objetivo de este proyecto era proveer un
conjunto de programas que permitieran realizar cualquier aplicación sin tener que utilizar programas cuyo
código fuente no era conocido. La idea original proclamaba cuatro libertades: la de estudiar el código
fuente, la de compartir el software con otras personas, la de modificar el comportamiento del software, y la
de publicar libremente el código modificado. GNU publicó posteriormente una licencia general pública (GPL
por su nombre en inglés). Esta licencia le da el derecho a los usuarios a utilizar, copiar, modificar y distribuir
los programas, mientras prohíbe imponer cualquier restricción sobre los que distribuyan. GPL se conoce
también como “copyleft” en contraposición al conocido copyright. Con posterioridad surgió una versión de
GPL conocida por AGPL que modifica algunas de las ideas básicas, manteniendo otras. En la actualidad
existen múltiples programas que utilizan software libre pero no son parte de la licencia GNU-GPL o de la
AGPL.
73
Oracle
Microsoft SQL-Server
IBM DB2
Sybase
MySQL
PostgreSQL
Los cuatro primeros productos son totalmente propietarios y es necesario pagar por su licencia.
Las prestaciones de estos productos son bastante similares y, en general, cuando alguno saca una
nueva funcionalidad los demás la incluyen en sus versiones en pocos meses.
Oracle fue la primera empresa en comercializar un SGBDR y mantiene un predominio en el
mercado, basado fundamentalmente en lo robusto de sus productos y el nivel de asistencia
técnica que brinda.
MySQL y PostgreSQL son del campo de software libre.
MySQL es un SGBDR pensado inicialmente para el desarrollo de aplicaciones en SQL. En la
actualidad ha crecido y contiene buena parte de las funcionalidades requeridas en un ERP o SAC.
Aunque Oracle compró hace un par de años los derechos de MySQL, hasta ahora ha respetado su
carácter se software libre y apoyado su desarrollo y utilización. Como negocio, Oracle se ha
concentrado en la venta de módulos que complementan las capacidades de MySQL.
PosgreSQL por su parte siempre ha sido de los SGBDR más potente, goza de un buen prestigio en
su utilización para grandes bases de datos, y tiene una comunidad bastante amplia que soporta su
desarrollo y asistencia técnica. La versión actual de PostgreSQL es la 9.2 que incorpora
importantes funcionalidades.
Al igual que en los sistemas de explotación la discusión entre productos propietarios y de software
libre está aún abierta y puede ser que se mantenga en los próximos años.
Los programas del ERP o SAC pueden ser propietarios o de software libre. A la hora de seleccionar
un ERP o SAC es importante tener en cuenta los siguientes criterios:
 Las funcionalidades que se requieren. Muchos ERP o SAC contienen funcionalidades que no
siempre se necesitan en una entidad determinada. Algunos las agrupan en módulos que se
pueden adquirir de forma independiente, otros obligan a adquirir la totalidad del sistema.
La adquisición del ERP o SAC debe partir en todos los casos de un análisis objetivo de los
requisitos y posibilidades de la entidad en cuestión.
 Correspondencia con la organización de la entidad. Algunos ERP o SAC se han diseñado a partir
de una organización determinada de la entidad donde se aplican. Este aspecto debe ser
revisado con cuidado, ya que si la organización existente no es compatible con la pensada para
el sistema, y no se tienen intenciones de modificarla, los beneficios de su utilización pueden
disminuir considerablemente.
74
 El proceso de carga inicial del sistema. La carga inicial de un sistema es un proceso que
requiere un extraordinario esfuerzo, ya que la entidad donde se implantará el mismo, tiene
que seguir funcionando de forma estable durante el período de implantación. Algunos
suministradores de ERP o SAC se desentienden de este paso, y solicitan que se les entregue un
conjunto de datos formalizados según los requerimientos del nuevo sistema. Requerimientos
de este tipo deben rechazarse. La carga inicial debe hacerse con la participación de
especialistas del nuevo sistema y de la entidad donde se implantará. Este proceso debe
utilizarse además como una primera etapa de formación del personal.
 La prueba del sistema antes de su implantación debe planificarse de forma cuidadosa. Su

realización debe estar a cargo del personal más calificado de la entidad donde se implantará.
En entidades de una alta complejidad es normalmente imposible, o muy costoso, realizar una
etapa de implantación en paralelo, duplicando todo el trabajo. Por esta razón, deberá
garantizarse que, antes de la implantación, todos los módulos a utilizar hayan funcionado con
datos reales y en distintas condiciones.
 La formación del personal propio es otra de los requisitos que se deben exigir en un ERP o SAC.
En general se necesitará personal propio para la explotación, el mantenimiento y la ampliación
del sistema. Los perfiles de los técnicos correspondientes y su formación es particular en cada
caso.
 Los servicios postventa tienen que garantizarse desde el contrato inicial. El tiempo de
respuesta ante solicitudes de solución de errores, de consultas sobre la evolución del sistema,
y añadir funcionalidades debe quedar explícito en el contrato inicial. Las condiciones del
suministro de versiones posteriores debe también preverse desde un inicio.
Los ERP o SAC son sistemas con un ciclo de desarrollo que obliga a su constante mantenimiento.
Los Compiladores y otras herramientas de programación sirven a este fin. La selección de estos
productos está totalmente condicionada por las tecnologías utilizadas en los programas del propio
ERP o SAC.
Algunos ERP, como SAP, incluyen su propio lenguaje de programación y compiladores para apoyar
el mantenimiento del sistema. Otros facilitan el trabajo con funciones definidas por usuarios o
procedimientos catalogados de la base de datos, así como subrutinas que permiten realizar ciertas
tareas.
En todos los casos contar con un ambiente de prueba, que simule las condiciones reales de
ejecución, es de suma importancia.
Por último, para que un ERP o SAC funcionen adecuadamente es necesario contar con otros
programas utilitarios que complementan el trabajo del sistema.
Paquetes del tipo de Microsoft Office, con procesadores de textos, programas de comunicación y
tableros electrónicos, entre otros, son imprescindibles. El acoplamiento de estos programas con el
ERP o SAC debe garantizarse.
75
5.6 Los recursos humanos
Ningún ERP o SAC puede funcionar correctamente, sin que los recursos humanos de la entidad
donde se utiliza tengan el talento, la pericia, la disciplina y la organización requerida.
Estas cualidades del personal no se alcanzan de un día para otro, por lo que la cultura existente en
la entidad puede ayudar o entorpecer la introducción de un nuevo sistema, optimizar sus
resultados o subutilizar sus potencialidades.
El talento, disciplina y organización de los recursos humanos de una entidad es el resultado de un
largo y constante proceso de selección, captación y adiestramiento, sobre el cual no se abundará
por no ser objeto de este libro.
La formación del personal en los requerimientos y características del nuevo sistema debe ser un
elemento de la mayor prioridad en su implantación.
Una buena fórmula para la formación del personal en la utilización del nuevo sistema, en
entidades con varias sucursales o agencias que desarrollan el mismo trabajo, pero en regiones
diferentes, es poner en explotación inicialmente el sistema en una o varias de estas agencias o
sucursales, y rotar por esas al personal de las sucursales o agencias que lo utilizarán
posteriormente.
La transmisión de información entre los propios usuarios del sistema durante su explotación es
una de las vías más efectivas para que logren la pericia requerida. Entre los usuarios del viejo
sistema, cualquiera que este fuera, existe un argot propio que ellos entienden perfectamente. La
explicación del nuevo sistema se basa, frecuentemente en estos casos, en mostrar cómo resolver
en las nuevas condiciones las tareas que se resolvían con el anterior.
Contar con aulas donde los futuros usuarios puedan interactuar con el sistema en condiciones
similares a las reales, auxiliados por instructores que los orienten y puedan despejar sus dudas, es
otra vía efectiva para el entrenamiento del personal que lo utilizará.
Para la formación del personal de diseño y programación, que se encargará posteriormente del
mantenimiento del ERP o SAC, la mejor alternativa es que participe en sus posibles adaptaciones y
en todo el proceso de carga inicial de los datos.
Obviamente, los cursos conceptuales sobre la arquitectura del sistema, la estructura de los datos,
las interfaces entre módulos y con otros sistemas y el contenido de la documentación, son
imprescindibles para el personal que se encargará de su mantenimiento.
Un último aspecto, pero quizás el más importante, sobre los recursos humanos de cara a un nuevo
ERP o SAC, es que la máxima dirección de la entidad debe estar totalmente involucrada en el
proceso de implantación del sistema, y exigir el riguroso cumplimiento del plan de trabajo que con
este fin se acuerde.
La tarea de implantación de un nuevo sistema es tan compleja, y tiene que superar normalmente
tantos obstáculos objetivos y subjetivos, que sólo con un plan correctamente elaborado y una
exigencia del máximo nivel sobre su cumplimiento es posible garantizarla en un tiempo razonable.
76
5.7 Los aspectos metodológicos
Los aspectos metodológicos incluyen tanto los procedimientos a tener en cuenta en el desarrollo,
mantenimiento y explotación de los ERP o SAC, como la definición detallada de los procesos a los
que se deben someter los datos que trata el sistema.
Existen múltiples enfoques metodológicos, y para cada uno de ellos varias metodologías para el
desarrollo e implantación de un nuevo ERP o SAC. La selección de la metodología a emplear con
este fin, va a depender básicamente del sistema que se pretenda desarrollar o implantar, de los
especialistas y demás recursos con que se cuente, y del grado de transformación de la entidad que
se pretenda alcanzar.
Ejemplos de procedimientos para el mantenimiento y explotación de un sistema, que deben
formar parte de su manual de explotación, son:
 Los pasos a dar para introducir una modificación al sistema, incluyendo los responsables de las
distintas tareas y los que las aprueban y revisan.
 Buena parte de las medidas de seguridad y protección de los datos y programas, reflejadas en
instrucciones que deben ser cumplidas por el personal que opera los servidores y que utiliza el
sistema.
 El procedimiento a utilizar para la sustitución de cualquier elemento que forme parte de las
computadoras o los medios de comunicación de un ERP o SAC.
 Los acciones a emprender ante errores en el funcionamiento del sistema, desde su detección,
hasta su total solución.
Con el aumento del nivel de automatización de los SAPD, muchos de los aspectos que
anteriormente tenían que describirse de forma detallada en los manuales de procedimientos, para
que se ejecutaran manualmente, han pasado a ejecutarse automáticamente, y los procedimientos
correspondientes están incorporados a los programas informáticos. La documentación de esos
programas debe incluir, de forma legible para los no informáticos, las decisiones del negocio que
se han incorporado a cada programa y su posible configuración.
Así, por ejemplo, cuando los sistemas no estaban automatizados, el manual de procedimientos
tenía que definir qué hacer cuando una cuenta de cliente en un banco se sobregira, si la operación
se debe aceptar o no, y, si se acepta, que interés cobrar por el importe sobregirado. En un sistema
automatizado todas estas opciones forman parte de los programas, por lo que su documentación
debe explicar que hacen y como particularizan cada caso.
La definición de los procesos a los que se someten los datos que trata el sistema, debe
concentrarse en los flujos de los documentos físicos que se reciben y emiten por el sistema, en las
diferentes alternativas que admite el tratamiento de los datos en el momento de su captación
manual, y en las alternativas para realizar diferentes procesamientos o emitir resultados. Todos
estos elementos deben incluirse en un manual del usuario del sistema.
77
5.8 Los aspectos legales
Los aspectos legales están constituidos por las leyes, los decretos, las resoluciones, los contratos, y
las reglas procesales existentes en el país y, en algunos casos, a nivel internacional, que atañen
directamente al funcionamiento del ERP o SAC.
Las disposiciones materializadas en leyes, decretos y resoluciones sobre los registros contables,
sobre el envío de información al fisco u a otros organismos que tengan autoridad para solicitarla,
sobre las medidas de seguridad y protección a incluir en el sistema, y sobre la fuerza laboral deben
revisarse en todos los casos con cuidado con el fin de cumplimentarlas, a la hora de elaborar e
implantar un ERP o SAC.
En los casos en que la entidad a automatizar realice operaciones de comercio internacional,
deberá revisarse la legislación vigente sobre los temas correspondientes. Esta legislación se
materializa mayoritariamente en reglamentos o acuerdos internacionales, a los que uno se
adhiere por voluntad propia, como el caso de las reglas y usos uniformes sobre las créditos
documentarios emitidas por la Cámara Internacional de Comercio.
Cada rama tiene adicionalmente instrumentos legales impuestos por entidades externas con la
autoridad requerida, o resoluciones de la propia entidad, que tienen que conocerse y tratarse
consecuentemente en el ERP o SAC.
Las resoluciones internas de la entidad deben revisarse con el fin de determinar si mantienen su
vigencia con el nuevo sistema, si deben ser modificadas, o incluso, si es necesario, emitir alguna
nueva para garantizar su correcto funcionamiento.
En cuanto a los contratos, es necesario conocer a tiempo el contenido de aquellos que pueden
tener incidencias en el diseño del sistema, tales como los contratos de cuentas corrientes con los
bancos o los contratos de comercio electrónico. El resto de los contratos con suministradores para
la procura de bienes o servicios, o con clientes para la venta de la producción de la entidad, deben
también ser estudiados, básicamente para garantizar que los formatos y períodos establecidos en
los mismos se cumplan adecuadamente por el ERP o SAC.
En los casos en que se exija una certificación determinada para la explotación del sistema, se
deberán tomar todas las medidas que se requieran para garantizar su obtención, o, si no es
posible de forma inmediata, solicitar una dispensa temporal y elaborar un plan detallado que lo
garantice en un tiempo prudencial.
78
5.9 La organización
La organización de una entidad se materializa en una estructura de mando de las áreas de trabajo
permanentes, y un conjunto de órganos colegiados que elaboran recomendaciones o toman
decisiones.
En general toda organización tiene al menos dos estructuras de mando: la que se presenta en los
organigramas y la que funciona en la vida real.
El funcionamiento de estructuras de mando, y con el tiempo la propia estructura, dependen en
buena medida de las características personales de quienes ocupan las distintas responsabilidades.
La estructura ideal, que no tiene en cuenta las características de las personas que la pondrán en
funcionamiento, presenta por lo general dificultades en su operatoria.
Debido a que las personas que ocupan los distintos puestos cambian con bastante frecuencia, con
el tiempo el funcionamiento real de una estructura se aleja de su diseño original.
Por otra parte, la mayoría de las entidades que utilizan o utilizarán un ERP o SAC, modifican en el
tiempo sus objetivos y funciones, y no siempre actualizan su organigrama, sino que quitan y
asignan funciones a unidades existentes, o crean unidades temporales o grupos de tarea que
funcionan frecuentemente por tiempo indefinido.
Conocer quien toma realmente las decisiones en cada área, es de vital importancia a la hora de
diseñar un nuevo sistema, con el fin de propiciar su apoyo al nuevo proyecto, y garantizar que sus
expectativas sobre el mismo sean cumplidas de forma racional.
Algunos ERP o SAC, y en particular el SAP, parten de una estructura general de la entidad a
automatizar, que debe cumplirse para que el sistema funcione adecuadamente. Este enfoque sólo
es válido para elementos estructurales muy generales, en entidades de producción de bienes o
servicios. En cualquier otro caso, adaptar la estructura organizativa a reglas que dicta el ERP o SAC
debe traer resultados desfavorables.
Los requerimientos de los órganos colegiados de una entidad, tanto de los que elaboran
recomendaciones, como de los que toman decisiones, deben tomarse en cuenta en el diseño del
nuevo sistema, sobre todo como consumidores importantes de la información que se procesa.
La periodicidad de las sesiones de esos órganos marca por lo general límites en el procesamiento
de las informaciones.
79
5.10 La seguridad y protección
La seguridad de un sistema puede definirse como el conjunto de medidas y medios que garantizan
su continuo funcionamiento durante los períodos requeridos por la actividad de la entidad que lo
utiliza.
La seguridad tiene que ver básicamente con la robustez de los componentes que se seleccionen
para el trabajo y la posible redundancia que se introduzca.
La protección de un sistema abarca el conjunto de medidas y medios que garantizan que el
sistema y sus componentes no podrán ser utilizados, o alterados, por personas que no estén
debidamente autorizadas para ello.
Aun cuando todos los componentes de un ERP o SAC tienen que ver de una u otra forma con las
medidas de seguridad y protección, en lo adelante se comentarán sólo las relacionadas con las
computadoras, las telecomunicaciones, la información y las personas, por ser los decisivos en
estos temas.
De forma general, hay que recordar que tanto la seguridad como la protección tienen que
analizarse desde una perspectiva de costo / beneficio, tomando en cuenta los aspectos financieros
y funcionales.
En un extremo un sistema sin protección ni seguridad puede ser el más barato y tener las mayores
funcionalidades, pero demasiado vulnerable ante los imprevistos y los ataques externos. En el otro
extremo el sistema más seguro y protegido puede costar mucho más que los fondos disponibles o
no ser nada funcional.32
Tanto para las computadoras como para las telecomunicaciones los elementos a tener en cuenta
en cuanto a la seguridad del sistema son los siguientes:
• El suministro ininterrumpido de energía, que debe preverse para los equipos de
telecomunicaciones, los servidores, las estaciones de trabajo, y los equipos vitales de
climatización.
Como se puede comprender fácilmente, garantizar un suministro de energía estable es
imprescindible en el caso de los equipos de telecomunicaciones, los servidores y sus locales.
En instalaciones de mucha importancia, es usual que exista un respaldo electrónico de energía
con la capacidad que requieran los servidores. Este respaldo electrónico garantiza que cuando
la corriente externa falle los servidores no se interrumpan. En esas instalaciones es también
usual que exista, adicionalmente, una planta eléctrica autónoma, que entra en
funcionamiento cuando el fallo del suministro externo es superior a cierto tiempo, siempre
menor que lo que pueden soportar los respaldos electrónicos. Estas plantas eléctricas
alimentan también a los equipos de telecomunicaciones y de climatización imprescindibles.
32
Muchas de las dificultades que tienen que enfrentar en la actualidad los sistemas tienen que ver con su
carácter de trabajo en tiempo real e interconectado. Si estas funcionalidades se eliminan, indiscutiblemente
aumentarán las posibilidades de protección y seguridad, pero no se podrán resolver algunas tareas con igual
eficiencia.
80
• Por muy robusto que sea un equipo siempre existe una probabilidad, mayor que cero, de que
en un momento determinado sufra una rotura. La instalación de equipos redundantes, que
puedan entrar en funcionamiento cuando se produce una rotura debe planificarse y
ejecutarse cuidadosamente.
Los equipos redundantes pueden sustituirse, cuando se rompen, en frio o en caliente.
Se considera que un equipo se sustituye en frio, cuando la tarea que venía realizando dentro
del sistema puede interrumpirse por un tiempo. Este es normalmente, por ejemplo, el caso de
las estaciones de trabajo, las impresoras, etc.
La sustitución en caliente de un equipo se realiza cuando el sistema tiene suficientes reservas
en funcionamiento del tipo de equipo en cuestión, para asimilar el trabajo del defectuoso,
hasta que se sustituya, sin que tenga que detenerse el funcionamiento del sistema.
Existen esquemas de almacenamiento de datos en discos duros redundantes, que permiten
seguir trabajando cuando uno de los discos se daña. Su sustitución y puesta en explotación se
realiza igualmente, cuando se utilizan estos esquemas, sin tener que detener el
funcionamiento del sistema.
Como se podrá comprender, la sustitución de un equipo en caliente requiere de un apoyo
importante de software, y provoca una baja de la confiabilidad del sistema en su conjunto
durante el intervalo de tiempo que se requiere para la sustitución.
Con las posibilidades de las fibras ópticas, es posible tener en la actualidad dos instalaciones
de servidores que sean totalmente redundantes y que funcionen en paralelo en locales
distantes entre ellos, algo imprescindible si se requiere que el trabajo no se interrumpa aun
cuando se produzcan daños físicos de magnitud (terremoto, incendio, etc.) en una de las
instalaciones de servidores33.
 Los conmutadores pueden y deben ser redundantes en redes locales de alta importancia, al
igual que los enrutadores.
 La seguridad de los enlaces con otros locales no es siempre simple de garantizar, sobre todo
cuando se utilizan los servicios de una RPTD. En redes de mucha importancia es necesario
exigirle a la empresa que suministra este servicio que las conexiones físicas, al menos del
último tramo sean distintas.34
En cuanto a la protección, las principales medidas a tomar, a nivel de medios técnicos, se
relacionan con la configuración de los enrutadores y los servidores especializados en funciones de
33
Al igual que para las restantes medidas de seguridad, la decisión del nivel de redundancia de las
computadoras debe tomarse sobre una base de costo / beneficio. En instalaciones muy importantes, el
costo de una interrupción, ya sea en activos físicos o financieros, en bienes intangibles como el prestigio, o
incluso en vidas humanas, puede ser tan alto, que valga la pena invertir en los medios técnicos más
sofisticados que existan, para reducir al máximo la probabilidad de que ocurra. Tal puede ser el caso, por
ejemplo, de los sistemas que llevan el control de los vuelos en un aeropuerto, o de los servidores que
autorizan millones de transacciones bancarias en un día.
34
En las RPTD existen frecuentemente tramos que tienen una alta velocidad y que son únicos.
81
cortafuegos, y a nivel informativo y de programas, con todos los temas de autenticación de las
personas, definición de sus atribuciones y registro de trazas. A continuación se comentan.
 En los enrutadores y cortafuegos se toman medidas activas para prohibir la conexión desde y
hacia ciertos enlaces, o permitir la conexión sólo desde y hacia ciertos enlaces. Estos equipos
confeccionan bitácoras con todos los intentos de conexión y conexiones efectivas, que
permiten revisar a posteriori lo que pasó, con el fin de poder diseñar y tomar medidas para
que en un futuro no se repitan los accesos indeseados que se detecten en esas bitácoras.
 Cuando una máquina local tiene una conexión hacia el exterior, a través de un modem, ese
punto se convierte en un lugar de alta vulnerabilidad, ya que, en principio, se puede leer y
escribir desde una máquina de la red local en cualquiera de las otras a las que esté conectada
y, en ese caso, la conexión externa no pasa a través del enrutador ni del servidor que funcione
como cortafuego para poder filtrarla.
Otro elemento a considerar en la actualidad, es la alta capacidad de las memorias flash que,
sin tener que acceder desde el exterior a la red, pueden extraer grandes volúmenes de
información sensible, sin dejar muchas evidencias.
En sistemas que tengan que mantener una alta protección de los datos, es recomendable
deshabilitar toda posibilidad de acceder a los puestos de trabajo, adicional al teclado, el
mouse, el monitor y la red de área local.
 Un sistema automatizado tiene que ser capaz de autenticar una persona u otro sistema
automatizado. En la práctica también las personas tienen que autenticar personas y sistemas,
pero estos casos no se tratarán por apartarse de los objetivos de este trabajo.
 De forma general la autenticación de una persona en el marco de un sistema automatizado se
basa en las posibles combinaciones de:
o Algo que sabe
o Algo que tiene
o Algo que es
o Algo que hace
El principal ejemplo de algo que sabe la persona es el número de identificación personal o PIN,
por sus siglas en inglés, que se utiliza como clave de acceso. Las claves de acceso tienen el
atractivo de que no se requieren equipos especializados para su comprobación, cualquier
teclado sirve para ello, aunque si medidas de criptografía que permitan la gestión y seguridad
de las propias claves.
En general las claves pueden utilizarse para:
 Autenticar directamente al que la conoce
 Encriptar cierta información, utilizando la clave y un procedimiento
Las claves llevan una gestión, normalmente compleja, y al menos una de ellas, como se verá
en lo adelante, tiene que ser conocida sólo por su titular.
82
La seguridad del proceso de encriptación y/o autenticación no puede depender de que el
procedimiento que se emplee sea secreto. Por lo general estos procedimientos son públicos, o
su divulgación es muy difícil de evitar.
Las claves pueden ser sincrónicas o asincrónicas.
Las claves sincrónicas son aquellas que tienen el mismo valor en los dos extremos. Con las
claves sincrónicas ambas partes pueden encriptar datos y autenticarse mutuamente, pero por
su naturaleza la relación tiene que ser uno a uno.
Las claves asincrónicas se componen de una clave pública que, como su nombre lo indica, no
tiene que ser resguardada, y una clave privada que sólo la conoce su titular.
La clave pública sirve para encriptar datos, que sólo puede desencriptar el que posee la clave
privada, mientras que la clave privada sirve para encriptar datos que se pueden desencriptar
con la llave pública correspondiente.
La autenticación utilizando llaves asincrónicas puede realizarse, entre otros, a través de los
siguientes pasos:
 En un primer momento el que debe autenticar a una persona, una vez recibido su nombre,
le envía una cadena de caracteres totalmente aleatoria y única para esa sesión.
 El que desea autenticarse encripta la cadena de caracteres recibida con su llave privada y
se la manda al que está autenticando
 Por último, el que está autenticando comprueba que, al desencriptar la cadena recibida
con la llave pública del que se quiere autenticar, esta coincide con la cadena enviada
inicialmente.
Las claves asincrónicas soportan adecuadamente las relaciones varios a uno.
Otra acción que se puede realizar con las claves asincrónicas es la firma de un documento.
Para esto se realizan normalmente los siguientes pasos:
 Se calcula con una función hash35 una cadena de caracteres que caracterice el documento
en su totalidad con la fecha y hora en que se realiza la acción al final.
 Se encripta la cadena de caracteres obtenida en el paso anterior utilizando la clave privada

del que firma el documento.
 La cadena de caracteres así obtenida es única para el documento con esa fecha y esa hora,
y puede constituir por lo tanto una firma electrónica del mismo, ya que quien recibe el
documento puede desencriptar esa firma electrónica utilizando la clave pública, y
35
Las funciones hash suministran una cadena de caracteres, normalmente con un tamaño de entre 8 y 32
bytes, cuyo contenido varía para cualquier modificación de la cadena de caracteres, de cualquier tamaño,
que representa el documento al que se le aplica. El código cíclico redundante, CRC por sus iniciales en inglés,
es un ejemplo de una función hash.
83
comprobar que la fecha y la hora son las requeridas y que el valor de la función hash se
corresponde con el contenido del documento.
Existen procedimientos de encriptación y autenticación que involucran ambos tipos de claves.
Sólo por citar un ejemplo, imagínese que una persona quiere recibir una información
encriptada y, obviamente, autenticada de alguien para el que sólo conoce la clave pública.
Para resolver esta necesidad, simplemente le envía una clave sincrónica a utilizar por una sola
vez en un mensaje encriptado con la clave pública, de tal forma que el receptor pueda
encriptar su mensaje con la clave recibida, debidamente firmado con su clave privada, y
enviárselo a quien lo solicitó, que será el único que podrá desencriptarlo.
Como se podrá haber apreciado con lo hasta aquí explicado sobre las claves para autenticar y
encriptar, el tema va mucho más allá de las aplicaciones comerciales en los ERP o SAC, por lo
que la mayoría de los Estados le dedican cuantiosos fondos y recursos humanos, de gran
talento y calificación, para estudiar y desarrollar procedimientos seguros y poder quebrar los
procedimientos elaborados por otros.
Las tarjetas con bandas magnéticas y las que tienen un chip incorporado, son ejemplos de algo
que tiene la persona que se quiere autenticar. En este caso, como en los dos siguientes, el
sistema que autentica tiene que poseer un dispositivo especial que permita leer las tarjetas.
Cuando la autenticación de la persona se realiza por medios automatizados (no cara a cara), es
normal que la posesión del medio de autenticación tenga que complementarse con otro
elemento, por ejemplo un PIN.
El ADN, las huellas dactilares, la retina de los ojos, el tamaño de los huesos de la mano, o los
rasgos de la cara, son todas características únicas de cada persona, o sea, algo que es.
La firma, el sonido de la voz, o la cadencia de escritura en un teclado, son ejemplos de
acciones de las personas que pueden identificarlas por algo que hace.
Los equipos que comprueban las características de las personas (lo que son o lo que hacen)36,
tienen, al menos con la tecnología actual, una probabilidad de error, tanto para aceptar un
caso que no se debía aceptar (un positivo falso), como para rechazar un caso que debía ser
aceptado (un negativo correcto). Normalmente para disminuir la probabilidad de los positivos
falsos es necesario aumentar la probabilidad de los negativos correctos, por lo que la
configuración del equipo debe hacerse en función de que es más importante en la aplicación
en cuestión.
 La autenticación entre sistemas automatizados debe realizarse normalmente en los dos

sentidos, ya que por lo general ambas partes deben estar seguras de con quien están
interactuando. Existen varios protocolos para la autenticación automática entre sistemas,
entre ellos:
36
Lo que aquí se afirma se refiere a la autenticación operativa, inmediata, que normalmente se realiza para
autorizar a una persona a utilizar ciertas funciones de un sistema, no a la forense, para la que se dispone de
un tiempo mucho mayor, de días o quizás semanas, y en la que en muchos casos se puede establecer la
identidad prácticamente sin errores.
84
 Kerberos
 Secure Socket Layer (SSL)
 IP SEC
En general todos estos protocolos utilizan varios intercambios de información entre los
sistemas que se están autenticando mutuamente y, en algunos casos como en el de Kerberos,
los servicios de servidores especializados en brindar claves temporales u otros servicios
criptográficos.
En las referencias bibliográficas 36 y 37 se encuentran breves descripciones de estos
protocolos y referencias a trabajos con explicaciones detalladas de los mismos.
Por último, aunque con la mayor importancia, es necesario tener en cuenta que los hombres, en
sus papeles de diseñadores, programadores, usuarios, administradores, etc., son siempre el
principal elemento dentro de los sistemas automatizados, y que para que estos funcionen, hay que
otorgarles facultades que, unidas a su ingenio e imperfección en la acción, les permiten quebrar
en ciertas circunstancias prácticamente cualquier medida de seguridad o protección, de forma mal
intencionada o accidental.
Por estas razones, todo plan de seguridad y protección tiene que tener como uno de sus
principales componentes la selección, el adiestramiento y el continuo control del personal que
opera el sistema.
85
86
6 Clasificación y tipos de ERP o SAC
En algún momento de la vida profesional de un contador, un economista, o un informático, es

probable que tenga que participar en la selección de un ERP o SAC para una entidad determinada.
Un proceso de selección de este tipo requiere el análisis detallado de las alternativas disponibles
con el fin de contrastarlas con los requerimientos reales de la entidad, tomando en cuenta, claro
está, el presupuesto disponible.
El presente capítulo tiene por fin brindar una guía para la clasificación de los ERP o SAC, de tal
forma que la comparación con los requisitos de la entidad en cuestión pueda ser más objetiva.
Los ERP o SAC pueden clasificarse utilizando múltiples criterios. A continuación se agruparan los
criterios de clasificación de los SAC según:
 Sus características funcionales

 Los volúmenes que puedan procesar
 Las características del software utilizado para su desarrollo
6.1 Características Funcionales

Según las características funcionales del sistema los criterios de clasificación de los ERP o SAC
pueden ser:
 El conjunto de módulos funcionales que abarca. Prácticamente todos los ERP o SAC permiten
registrar contablemente cualquier operación, sobre la base de definir explícitamente todos los
asientos contables que la componen.
El principal aporte de estos sistemas es, sin embargo, la tipificación de operaciones de tal
forma que: en algunos casos se puedan ejecutar automáticamente, como por ejemplo el
cálculo de intereses y su cobro o pago, o que la captación de las transacciones
correspondientes sea sencilla y garantice que no se cometan errores formales.
Tanto la captación de las transacciones tipificadas, como los procesos que se ejecutan
automáticamente, y la captación de información de referencia requerida, se agrupan
normalmente en módulos, funcionales.
Una lista de módulos para el SAC de una empresa productiva normal, pudiera ser:
o Activos líquidos (depósitos en bancos y efectivo)
o Cuentas por cobrar
o Medios básicos
o Medios de rotación
o Cuentas por pagar
o Nómina
o Clientes
o Ingresos y egresos
o Tesorería
87
o Emisión de estados financieros
Si la selección tiene que hacerse de un ERP, a esa lista de módulos deben agregarse como
mínimo los siguientes:
o Recursos humanos
o Comercial
o Materiales (compra, inventarios, etc.)
o Producción (planificación, órdenes de producción o servicio, etc.)
o Mantenimiento
o Gestión de proyectos
La cantidad de módulos que tenga un ERP o SAC particular, y el alcance de cada uno de estos,
es una de las principales características a comparar con los requerimientos de la entidad, a la
hora de decidir una adquisición.
Los aspectos requeridos que no se cubran por el sistema seleccionado, tendrán que
ejecutarse, o por procedimientos no muy productivos, como el de registrar uno a uno todos
los asientos de una transacción con todos sus datos, como se señaló anteriormente, o por
otros sistemas que se acoplen al ERP o SAC seleccionado, lo que siempre implica esfuerzos y
costos adicionales.
Por otra parte, si el ERP o SAC seleccionado tiene módulos que no se requieren en la entidad
que lo selecciona, puede ser que se incurra en un gasto innecesario, y/o que se pierda
eficiencia a la hora de explotarlo.
 Desglose por moneda de los registros contables. En algunas entidades, en especial las del
sector financiero, es recomendable que los registros contables se realicen en la moneda real
en que se produce el hecho económico. Esta característica de los sistemas contables no es
muy común, por lo que, cuando se requiere, deberá investigarse a fondo la solución que le da
el ERP o SAC a seleccionar.
 Recepción de documentos primarios generados dentro de la entidad en soporte electrónico.
En el caso en que se esté analizando un SAC para la solución contable solamente, es necesario
tomar en cuenta que buena parte de los documentos primarios, que se reciben para realizar el
registro contable, se generan dentro de la propia entidad.
Permitir que los datos correspondientes lleguen al SAC en un formato electrónico, que se
produzca como subproducto de su confección primaria, puede ser de gran utilidad en ciertas
aplicaciones. De hecho esta es la solución que brindan los ERP.
 Interfaces con otros sistemas. Toda entidad tiene intercambios de datos con otras. Como se
explicó en el capítulo II, el mayor nivel de automatización se alcanza cuando el sistema de una
entidad puede interactuar con otros sistemas automatizados.
En particular una interface con el (los) banco(s) de la entidad es siempre importante. En la
medida que exista comercio electrónico, tanto entidad – entidad, como entidad – personas,
88
contar con las interfaces para apoyarlo puede ser un requisito decisivo a la hora de seleccionar
un ERP o SAC.
 Registros centralizados o descentralizados. En entidades con varios establecimientos surge

siempre la interrogante de cómo llevar el registro de los datos: de forma centralizada en un
solo lugar, o en cada uno de los establecimientos.
Cuando todo se llevaba a mano y en papeles, el registro en cada establecimiento era la única
alternativa viable en entidades que, como los bancos, requerían que los mayores, de al menos
algunas cuentas, estuvieran actualizados prácticamente de inmediato37.
El envío de documentos desde los establecimientos al centro para su registro, corre siempre
un peligro de extravío o excesiva demora, y tiene adicionalmente la desventaja que, si al
momento del registro se detecta alguna incoherencia, dilucidar su solución se hace complejo
por la no presencia del que lo confeccionó originalmente.
Como en general los establecimientos de una entidad tienen relaciones entre ellos, que deben
registrarse por el sistema, si el registro se lleva en cada establecimiento, es necesario
formalizar ese intercambio de información para los datos contables. Lo usual es establecer las
así llamadas cuentas de tránsito, que permiten registrar por partida doble toda transacción
inter-establecimiento en los dos extremos.
Las cuentas de tránsito deben obviamente irse a cero, en el momento que se consolidan los
balances, cuando el registro contable se realiza correctamente en los dos extremos. Cuando
los volúmenes de transacciones inter - establecimientos son muy grandes y frecuentes, es
normal que el consolidado de las cuentas de tránsito tengan un saldo. En esos casos, la
conciliación de las cuentas de tránsito se convierte en un problema de primera importancia.
Desde otro ángulo, la obtención de estados financieros de la entidad, así como de otras
informaciones operativas y estadísticas, se dificulta con la existencia de registros
descentralizados.
El tener el registro de los datos en cada establecimiento tiene, por último, consecuencias
negativas en los costos y en los temas de seguridad y protección del sistema en su conjunto.
Desde el punto de vista de costos, cuando el registro de los datos es descentralizado, se
necesita tener personal calificado y los medios técnicos requeridos en cada establecimiento.
En cuanto a la seguridad y protección, siempre será más sencillo y eficiente tomar todas las
medidas requeridas en un solo punto, que en varios.
Por lo hasta aquí expuesto, se podrá coincidir en que, con las posibilidades actuales de los
medios de computación y las comunicaciones, es siempre preferible evitar la descentralización
del registro de los datos.
37
El saldo de la cuenta de un cliente es una información imprescindible para decidir operativamente si una
extracción de efectivo pude autorizarse o no. Todos los registros que alteren ese saldo deben por lo tanto
realizarse lo antes posible.
89
La centralización de los registros, para que sea realmente efectiva, requiere que en cada
establecimiento existan módulos que permitan la interacción con el sistema central, tanto
para el registro de las operaciones, como para realizar las consultas que se requieran.
El problema técnico que tiene que enfrentar un sistema centralizado con muchos
establecimientos no debe menospreciarse. Las capacidades y estabilidad de los medios de
comunicación son aún, al menos en nuestro país, bajas, por lo que los sistemas tienen que
estar preparados para enfrentar interrupciones y optimizar las capacidades.
Por otra parte, cuando la gestión de los establecimientos depende del registro de los datos, es
necesario tomar medidas que permitan que continúen funcionando al menos parcialmente
cuando las comunicaciones se interrumpen.
En cuanto a los volúmenes a procesar, las pruebas de los sistemas que se quieren adquirir deben
hacerse siempre con las cargas máximas previsibles en un horizonte de no menos de 5 años.
Las capacidades de los medios técnicos crecen cada año y, en muchos casos, un aumento de la
carga de trabajo se puede compensar con equipos más potentes. Sin embargo, esto no siempre es
así.
Los picos de trabajo y los tiempos de respuesta necesarios deben ser considerados
cuidadosamente. En algunos casos existe un tiempo máximo de respuesta que, de sobrepasarse,
invalida la transacción.
El efecto de alcanzar el límite de la capacidad del sistema no siempre es el mismo. En ocasiones el
resultado puede ser solamente que las respuestas se demoren algo más, pero no es inusual que el
sistema en su conjunto colapse cuando se sobrepasan los límites de su capacidad.
Baste el ejemplo de los procesos que hay que realizar diariamente en el horario en que las oficinas
no trabajan. Para estas tareas se dispone normalmente, como máximo, de unas 14 horas (de 18:00
a 08:00 del otro día). Si por el crecimiento del volumen de los datos, estos procesos requieren 16
horas diarias, el sistema es totalmente inutilizable.
Las pruebas deben hacerse no sólo en las computadoras centrales, sino también en los canales de
comunicación con estas.
La saturación de las capacidades de los canales de comunicación, por su uso simultáneo en la
transmisión de datos del ERP o SAC como tal, del correo electrónico, y de navegación en Internet,
ocurre frecuentemente cuando alguien envía o recibe correos con anexos muy voluminosos, o
descarga ficheros muy pesados desde internet. En la medida que sea posible, los canales de
transmisión de datos para el ERP o SAC deben ser independientes de los de otras aplicaciones.
Al igual que para otros criterios de selección, los volúmenes que deba soportar el sistema,
teniendo en cuenta tanto el software como las computadoras y medios de comunicación, deben
ser lo más objetivos posibles, y la selección definitivaconsecuente con los mismos.
El sobredimensionamiento de los medios siempre implica gastos innecesarios, mientras que
explotar un sistema en el límite de sus capacidades es correr un riesgo innecesario.
90
6.2 Características del software utilizado para el ERP o SAC
En cuanto a las características del software utilizado para el desarrollo del ERP o SAC los aspectos a
tener en cuenta son:
 El nivel de adaptabilidad
 La transparencia
 La arquitectura del sistema
 La plataforma de explotación
El nivel de adaptabilidad de los ERP o SAC va desde sistemas que son totalmente rígidos, que
obligan a que las estructuras y procedimientos se adapten a ellos, hasta los que se desarrollan a la
medida de la entidad, pasando por una amplia gama de sistemas que pueden configurarse y
ampliarse con el fin de asimilar características específicas de la entidad donde se utilizarán.
Sobre los sistemas rígidos y hechos a la medida no es necesario abundar. Como sus nombres lo
indican el grado de adaptabilidad es, o nulo, o total.
En cuanto a los que se pueden configurar y ampliar, las técnicas para su desarrollo son varias,
teniendo cada una ventajas y desventajas. A continuación se comentan las principales:
 Una primera alternativa de configurar un sistema, es la de contar con un conjunto de datos

sobre la aplicación particular (parámetros o metadatos), que permiten desarrollar módulos
generales que se particularizan con el uso de esos parámetros.
Así, por ejemplo, si una aplicación necesita varias tablas, compuestas todas por un código y
varios atributos que se asocian al mismo, se pueden definir las características de cada uno de
los campos de cada una de esas tablas en una tabla de parámetros. Esa tabla de parámetros
permitirá desarrollar programas generales para la captación, consulta y listado de todas las
tablas que estén descritas en ella.
De igual forma, si la captación de los datos primarios se hace a partir de formularios, se puede
crear un modelo genérico de un formulario, definiendo que siempre tienen un encabezado
que contiene X campos, junto con un cuerpo que contiene Y filas, cada una con Z campos. Los
parámetros del formulario describirían, además de las características formales de cada campo,
si estos son obligatorios o no, las interrelaciones entre ellos, etc.
Al igual que en el caso anterior, esos parámetros permitirían elaborar programas generales
para la captación, consulta, e impresión de los formularios.
La principal ventaja de esta técnica es que los programas generales son normalmente muy
estables y que las modificaciones al sistema pueden hacerse de forma bastante ágil. Su
principal limitación está dada por los propios modelos de objetos que deben definirse, que en
general se convierten en una restricción importante para la solución de ciertas tareas.
Esta alternativa se utiliza frecuentemente para el desarrollo de los módulos centrales de la
tercera alternativa de arquitectura, que más adelante se explica.
91
 Una segunda alternativa es, utilizando también parámetros o metadatos, generar de forma
automática programas específicos para cada objeto particular. Esta solución tiene
prácticamente las mismas ventajas y desventajas que la de los programas generales.
La principal diferencia es que facilita la inclusión de tratamientos específicos, a través de
permitir incorporar código en ciertas partes de los programas generados.
Esta solución tiene sin embargo la desventaja de que los programas generados, a los que se les
añade código, no suelen ser tan estables en su funcionamiento como los de la primera
alternativa, que prácticamente no se modifican.
 La tercera alternativa, normalmente utilizada en los actuales ERP o SAC, consiste en un

módulo central, que contiene la funcionalidad general del sistema, parametrizable en cierta
medida con el uso de metadatos, y herramientas para, si es necesario, desarrollar módulos
específicos.
Esta es, por ejemplo, la arquitectura del SAP, del OpenERP y del SABIC.
El módulo central de estos sistemas contiene la lógica que normalmente es invariable.
Por ejemplo, la suma de los asientos de una transacción para cuentas reales y nominales tiene
que ser igual a cero, y, si el registro de las contingencias es por partida doble, la suma de sus
partidas tiene también que ser cero. Este cuadre tiene que cumplirse por fecha contable y
fecha valor, y, por último, si el sistema es multimoneda, el cuadre tiene que cumplirse también
por cada una de ellas.
La lógica requerida para controlar que estos cuadres se cumplan y, cuando no se detectan
errores, registrar los asientos contables en las tablas que corresponda, se encuentra
normalmente como parte de ese módulo central de estos sistemas.
Los procedimientos para calcular y aplicar los intereses, las acciones a tomar cuando llega el
vencimiento de una cartera, o cuando llegan las fechas contables o fechas valor, de registros
que se hicieron con antelación, son también normalmente acciones que están programadas
como parte del módulo central de esos sistemas.
En cuanto a las herramientas para desarrollar nuevos módulos, SAP proporciona un lenguaje
de programación específico para ese sistema (ABAP/4), que permite tanto programar nuevas
tablas de salida, como implementar procedimientos para el cálculo de indicadores o la
validación de datos.
Odoo (OpenERP), se basa en Python como lenguaje de programación y se apoya en un
ambiente de trabajo (framework): OpenObject para facilitar el desarrollo de nuevos módulos y
la ampliación de los existentes.
Aun cuando Odoo se basa en la filosofía de software libre, por lo que el código de los
programas que componen su módulo central puede revisarse y estudiarse, el mismo no debe
modificarse de forma aislada. Cualquier nueva funcionalidad o modificación de una existente,
tiene que realizarse por la vía de incorporar nuevo código.
92
Por su parte el SABIC, que en su versión actual se basa en VisualFoxpro como lenguaje de
programación, permite el uso de procedimientos catalogados en SQL, y proporciona un buen
número de funciones y subrutinas que facilitan el desarrollo de nuevas transacciones,
procesos independientes y reportes.
En todos los casos existen facilidades para la puesta a punto de los programas que se
desarrollen.
En cuanto a la transparencia, sólo los sistemas que se basan en los principios del software
libre son realmente transparentes, sin necesidad de tomar medidas adicionales.
Una de las condiciones que algunas empresas, normalmente muy poderosas, ponen para la
adquisición de un sistema, es que se entregue el código fuente de su módulo central,
obviamente con las debidas protecciones contractuales sobre no divulgación y uso indebido.
En la práctica, aun cuando no se tenga el código fuente del sistema a utilizar, la transparencia
del mismo puede suplirse con una adecuada documentación y un servicio eficiente de
consultoría para la solución de nuevas tareas.
La arquitectura del sistema juega un papel importante en aplicaciones para entidades con
muchos establecimientos.
Cuando la entidad radica en un solo local, la arquitectura cliente – servidor, que prácticamente
soportan todos los ERP o SAC modernos es suficiente.
Si la entidad cuenta con varios establecimientos, separados entre sí por distancias
importantes, es necesario revisar la arquitectura del sistema a seleccionar, y asegurarse que
funciona adecuadamente con las facilidades de comunicación y los medios técnicos con que se
contarán.
Las dos arquitecturas más utilizadas en la actualidad son las de puesto de trabajo (desktop), y
las aplicaciones WEB.
En las aplicaciones que funcionan en la arquitectura de puesto de trabajo, en la computadora
local debe residir una buena parte de los programas, fundamentalmente los que tienen que
ver con mostrar en pantalla los diferentes formularios y captar los datos. Esta arquitectura
simplifica por lo general el proceso de programación, pero tiene la dificultad de que es
necesario distribuir las nuevas versiones a todas las máquinas, y estas requieren algo más de
recursos.
En la arquitectura WEB, todos los procesos se realizan en los servidores centrales, y lo único
que funciona en las computadoras de los puestos de trabajo es un navegador. Aunque por lo
general esta arquitectura requiere un mayor esfuerzo de programación, la gestión de
mantenimiento de todo el sistema se simplifica, y su utilización puede realizarse desde
cualquier equipo que tenga acceso a través de internet, o de una intranet, a los servidores
correspondientes.
93
Para los ERP o SAC la plataforma de explotación está compuesta por el sistema de explotación
y el sistema de gestión de bases de datos (SGBD).
Los sistemas más desarrollados, como el SAP, funcionan sobre múltiples sistemas de
explotación y SGBD.
Al analizar la adquisición de un ERP o SAC, la correcta selección del sistema de explotación y
del SGBD puede tener implicaciones importantes en los costos totales y la eficiencia del
sistema.
Las licencias de los sistemas de explotación y de los SGBD pueden llegar a ser una parte
importante de la inversión total, aunque para ambos casos existen alternativas que se
suministran como software libre.
La formación de los especialistas en la alternativa que finalmente se seleccione debe incluirse
en las acciones necesarias para la implantación del sistema. En este sentido, la experiencia
acumulada en el uso de determinado sistema de explotación y SGBD, puede inclinar la balanza
a la hora de seleccionarlos.
94
7 Principales características de los ERP
La principal diferencia entre los ERP y los SAC tradicionales es que el ERP representa una
plataforma única38 para la automatización de todas las actividades de una empresa, que permita el
uso óptimo de los recursos (fuerza de trabajo, materiales, recursos financieros y activos fijos),
diseñada con el objetivo de integrar la información que se produce en sus distintas áreas, y
garantizar una fuente única para cada dato.
En este contexto el SAC deja de ser un sistema en sí, para convertirse en una funcionalidad más
del ERP.
Antes de que surgieran los ERP, los sistemas automatizados de una empresa estaban constituidos
por subsistemas independientes, que manejaban sus bases de datos con criterios y codificaciones
propias y que buscaban optimizar los procesos y recursos del área en que se aplicaban.
En esas condiciones, el resultado total de la actividad de la empresa era normalmente la suma de

los resultados de sus partes, sin aprovechar la sinergia existente cuando esos subsistemas
interactúan de forma efectiva39.
La principal área de aplicación de los ERP son las empresas de producción de bienes o servicios,
aunque buena parte de sus módulos, y los principios que sustentan su arquitectura, pueden
emplearse también en entidades de otro tipo, tales como órganos de la administración pública,
universidades, hospitales, etc.
38
Los ERP proponen una única base de datos, una sola aplicación y un interfaz con los usuarios uniforme
para todos los módulos.
39
De la física se conoce que el resultado de un sistema, solo es la suma de los resultados de sus partes, si
estas no interactúan entre sí. Cuando existe esa interacción entre sus elementos, el resultado final de todo
el sistema puede ser mayor o menor que la suma de los resultados de sus partes. La sinergia se obtiene
cuando la interacción de los elementos del sistema tiene por fin apoyar mutuamente su funcionamiento y
no entorpecerlo.
95
7.1 Principales módulos
Los ERP, para que sean catalogados como tales, deben tener módulos que apoyen como mínimo
las siguientes funciones de una empresa:
• Planificación de la producción
• Control de órdenes de producción o servicios
• Comercial
• Compra de materiales y partes
• Control de inventarios
• Mantenimiento
• Contabilidad y finanzas
• Gestión de las relaciones con los clientes
• Recursos humanos
• Gestión de proyectos
Los módulos de planificación de la producción, control de órdenes de producción o servicios y
comercial son por lo general, específicos para las distintas ramas de la producción.
Los diferentes sectores de la economía (industria, agricultura, construcción, transporte,
comunicaciones, comercio) tienen características propias en su ciclo de producción. Incluso dentro
de un mismo sector, las características del proceso productivo y su comercialización pueden ser
muy disímiles en sus diferentes ramas.
Tómese por ejemplo el sector industrial, que abarca desde la producción de bienes como la
electricidad, que se distribuye de forma ininterrumpida a centenas de miles, o millones, de
clientes, para los que es necesario realizar una medición periódica (normalmente cada mes) del
consumo, facturarlo y cobrarlo; hasta la construcción de buques o aviones, que requiere un
proceso productivo que puede demorar meses, o años, para obtener una unidad del producto
para un solo cliente.
La planificación de la producción, su control y comercialización, deben ser obviamente específicas
para cada uno de esos tipos de industrias.
Los restantes módulos de un ERP tienen prácticamente las mismas funcionalidades en cualquier
empresa, y sus estructuras de datos, aunque obviamente particularizadas para el tipo de
producción de que se trate, son mu y similares.
96
7.2 Integración
La integración de la información de la empresa era, antes del surgimiento de los ERP, una tarea
muy compleja, sino imposible en no pocos casos.
Un mismo dato se captaba por los diferentes subsistemas, en ocasiones a partir de identificaciones
incompatibles y no siempre con igual valor, por lo que frecuentemente era extraordinariamente
complejo dilucidar qué información era realmente veraz.
Todos los objetos que trate el ERP deben tener una codificación única, independiente del módulo
que los utilice en un momento determinado. La identificación única de los objetos que trata el
sistema es un requisito imprescindible para la integración de los datos.
La fuente de cada dato debe ser también única. Una vez que se capta un dato primario, el mismo
debe utilizarse en tantos módulos como se requiera, sin tener que ser captado nuevamente.
Así, por ejemplo, la información sobre la salida de un material, de un almacén interno hacia un
área de producción de la empresa debe utilizarse en:
 La actualización del inventario correspondiente,
 La entrada en el módulo de control de órdenes de producción,
 El registro en la contabilidad analítica de la empresa,
 La estadística requerida por el módulo de compras de materiales y partes.
Ambos problemas: la integración de toda la información y la existencia de “una sola fuente de la
verdad”, deben quedar resueltos con la introducción de un ERP.
La utilización más efectiva de un ERP se logra cuando buena parte de los procesos, que se realizan
en la empresa de forma manual, pueden ser automatizados.
No debe perderse de vista, sin embargo, que la automatización de los procesos implica
normalmente una pérdida de flexibilidad en la operación de la empresa, y requiere de una gran
disciplina por parte de todos los involucrados.
La pérdida de flexibilidad se debe a que si el sistema tiene que tomar ciertas decisiones, todas las
alternativas posibles tienen que definirse previamente y ser incorporadas a los programas, por lo
que cuando se presenta una situación especial no prevista, que por métodos manuales puede ser
objeto de una tratamiento particular, o se ajusta a las variantes predefinidas o se modifica el
sistema, algo que en normalmente requiere tiempo y recursos, ambos escasos.
El aumento de la disciplina requerida se relaciona principalmente con la necesidad de reflejar en el
sistema, de forma inmediata y veraz, cualquier acción que se realice que afecte los datos
existentes. Así por ejemplo, si el consumo interno o venta de un material, no se refleja
inmediatamente en el sistema, se pueden aceptar solicitudes de producción para un plazo que,
teniendo en cuenta la situación real de los inventarios, no debieran aceptarse; o puede dejarse de
hacer un pedido de materiales, imprescindible para culminar las ordenes de producciones en
proceso.
97
Las interfaces con los usuarios deben tener en los ERP un diseño uniforme, que facilite el
aprendizaje sobre el uso del sistema y su mantenimiento.
Debido a la complejidad que entraña el diseño y desarrollo de un ERP, la regla es que las empresas
no tengan la experiencia ni los recursos requeridos para elaborar uno propio, por lo que en
general deberán escoger alguna de las versiones que estén disponibles en el mercado e
implantarla.
Aunque en teoría es posible utilizar módulos de diferentes ERP para resolver distintas
funcionalidades, este camino no es recomendable, al menos con el actual estado del arte40.
La integración de módulos de diferentes ERP puede ser tan compleja como la integración de los
sistemas independientes que existían antes de los ERP.
40
En algunas actividades, como la bancaria por ejemplo, se desarrollan esfuerzos tendientes a estandarizar
de forma conceptual las estructuras y funciones de sus entidades, de tal forma que en los niveles operativos
existan servicios estandarizados, que puedan ser objeto de automatización por diferentes suministradores
de software sin perder la capacidad de integrarse con los restantes servicios. Ver 39, Banking Industry
Architecture Network (BIAN).
98
7.3 Otras características
Además de lo hasta aquí descrito, un ERP debe poseer las siguientes características:
 Apoyar los procesos de decisión y planificación estratégicos y operativos

 Apoyar la ejecución de las tareas y su control
 Flexible
 Modular
 Abierto
 Abarcador
 Incluir las mejores prácticas de la rama
 Multiplataforma, multimoneda, multientidad
 En el plano tecnológico: transaccional, en tiempo real, en línea y desde equipos móviles
Los procesos de decisión y planificación estratégica de una empresa tienen que ver,
fundamentalmente, con los pronósticos sobre el mercado de su cartera de productos o servicios,
y con el análisis de las capacidades y su renovación y ampliación, a través de procesos
inversionistas.
Una parte de este trabajo debe ser realizado por especialistas que se nutren de experiencias e
información que no está en el sistema, tales como: los planes, fortalezas y vulnerabilidades de los
posibles competidores; las nuevas tecnologías para el proceso productivo; y el desarrollo de
nuevos productos o servicios que pueden sustituir los de la cartera de la empresa.
Los ERP deben ser capaces de complementar esa información con datos objetivos sobre: cuellos
de botella en el proceso productivo, clientes confirmados para los productos y servicios de la
empresa y demandas previsibles, potenciales clientes, pronósticos de precios para los insumos y
los resultados de la producción, costos marginales para incrementos y decrementos de la
producción de ciertos productos, etc.
Por su característica integradora, un ERP cuenta con todos los elementos para facilitar la
ejecución de las órdenes de producción de manera eficiente y dejar en sus bases de datos todos
los elementos requeridos para monitorear y controlar el buen funcionamiento de los procesos.
Una empresa es un ente con vida propia, que requiere ajustar constantemente su forma de actuar,
tanto debido a cambios en su medio ambiente, como a innovaciones propias de los procesos
productivos. Esta característica de las empresas obliga a que los ERP sean lo suficientemente
flexibles como para adaptarse a esas condiciones siempre cambiantes.
El concepto de modularidad de los ERP está asociado a la posibilidad de utilizar un mismo sistema
en ambientes disímiles. Anteriormente se explicaban las enormes diferencias existentes en las
características de diferentes ramas de producción. Si los ERP se diseñaran e implantaran como
trajes hechos totalmente a la medida, habría que rehacer todo el trabajo para cada aplicación. La
división del sistema en módulos que son capaces de interactuar entre ellos, junto con la
posibilidad de configurarlos en cada caso, permite seleccionar la composición adecuada de estos
para cada aplicación, sin tener que rehacer todo el trabajo.
99
Cada vez con mayor frecuencia los ERP de las empresas tienen que interactuar con sistemas de
otras entidades con las que esta se relaciona. La característica de abierto es la que le permite al
ERP adaptarse a las diferentes interfaces de esos sistemas. Como ya se explicó, el desarrollo en
este ámbito pasa por la elaboración y aceptación de estándares para las diferentes interfaces y el
surgimiento de entidades que sirvan de pasarelas para los mensajes correspondientes.
Para que las ventajas de los ERP puedan materializarse, los mismos deben abarcar la totalidad de
las actividades de una empresa, ya que como norma existen interrelaciones entre estas que, de no
formar parte del sistema pueden distorsionar sus resultados.
Los ERP representan una oportunidad única para incluir las mejores prácticas de la rama, lo cual
no quiere decir que en todos los casos lo hagan. El tema de utilizar las mejores prácticas se enlaza
con la voluntad de modificar no sólo el sistema de procesamiento de datos, sino también, y quizás
en primer plano, los procedimientos existentes en una empresa. Este tema y sus consecuencias se
comentarán más adelante cuando se revisen los retos que debe enfrentar la implantación de un
ERP.
Debido a que por las razones explicadas, los ERP no se construyen para una aplicación
determinada, sino para múltiples ambientes, el prefijo “multi” está presente en varias de sus
características.
Con el fin de no obligar a la dependencia de un solo suministrador de equipos y sistemas de
explotación o de gestión de bases de datos, el sistema debe ser multiplataforma. Esta
característica permite utilizar de la forma más racional posible no sólo los recursos financieros
requeridos para la adquisición de esos elementos, sino también la cultura informática existente en
la entidad.
En el mundo actual las operaciones internacionales son muy frecuentes, y en ciertos ambientes
como el de Cuba sin tener operaciones de comercio exterior, las empresas tienen que trabajar su
contabilidad, al menos hasta el momento, con más de una moneda. El tratamiento multimoneda
que le dé el ERP a toda la información financiera es en este contexto de vital importancia.
La existencia de organizaciones económicas que abarquen varias empresas, cada una con
personalidad jurídica propia, es común en el mundo y también en nuestro país. La característica de
multientidad es la que le permite a los ERP trabajar en cada una de esas empresas y brindar
información consolidada sobre el total de las mismas.
En el plano tecnológico la mejor definición de las características de un ERP es que contenga las
tecnologías más avanzadas del momento para resolver sus tareas. Este como se comprenderá, es
un blanco móvil, que cambia constantemente.
Con el desarrollo tecnológico actual puede afirmarse que los ERP tienen que ser como mínimo
transaccionales y funcionar en tiempo real y en línea. El apoyo al acceso al sistema desde equipos
móviles es otra característica tecnológica, que ya en las condiciones actuales de las redes de
telefonía inalámbricas, debe ser tomada en cuenta a la hora de seleccionar un ERP.
100
7.4 La selección e implantación de un ERP, los riesgos
La implantación de un ERP no es un proceso fácil. Puede afirmarse que sin excepciones el proyecto
correspondiente tropezará con obstáculos de gran magnitud durante su ejecución.
Para facilitar ese proceso es importante cumplir los siguientes pasos:
 Definir las necesidades reales de la entidad, partiendo de una proyección a mediano plazo de
su actividad y un análisis crítico sobre los procesos de la empresa y las posibilidades de su
entorno.
 Seleccionar un fabricante de ERP con suficiente aval de casos exitosos, módulos que se ajusten
lo más posible a las necesidades de la entidad, y capacidad para asesorar en el proceso de
implantación, explotación y mantenimiento.
 Definir las modificaciones a realizar en los procesos existentes (reingeniería de procesos), con
el fin de obtener los mejores resultados con la implantación del nuevo sistema.
 Elaborar un plan detallado de actividades para la implantación del sistema, que incluya:
o La adquisición e instalación del equipamiento y los medios de comunicación
requeridos por el sistema.
o La adquisición de los sistemas de explotación, sistemas de gestión de bases de datos,
cortafuegos y demás software general a utilizar en el nuevo sistema.
o La formación del personal para atender los nuevos equipos y software.
o La prueba del sistema en condiciones lo más cercanas posible a la futura realidad.
o La introducción de los posibles cambios organizativos y de procesos en
correspondencia con la utilización de los diferentes módulos del sistema.
o La formación del personal que utilizará el sistema, incluyendo los niveles gerenciales.
o La revisión y posible modificación de resoluciones y otros instrumentos legales
vigentes para la entidad.
o La elaboración de los nuevos procedimientos.
o La preparación de toda la información requerida para la carga inicial.
 Definir responsables a nivel ejecutivo para cada una de estas actividades.

 Controlar al mayor nivel de dirección de la entidad el cumplimiento de los planes elaborados,
tomando las medidas que se requieran en cada momento.
Garantizar que la implantación del sistema en el menor tiempo posible, sea un objetivo del mayor
nivel de dirección de la entidad, y que este se involucre en la gestión de los riesgos previsibles y
ocultos, es algo cuya importancia nunca podrá exagerarse.
Por muy bien concebido que esté el plan de trabajo, por muy racionales que sean los objetivos que
se persiguen, y por muy eficiente que sea el sistema a implantar, los procesos de este tipo chocan
siempre con un enemigo invisible: el miedo al cambio.
101
Este miedo al cambio tiene raíces objetivas, ya que las personas que trabajan en la entidad que ha
decidido implantar un ERP, estarán expuestas a riesgos reales.
En muchos casos, puestos de trabajo tradicionales dejarán de ser necesarios, en otros, el
contenido de ciertas ocupaciones cambiará radicalmente, y será necesario desarrollar habilidades
que hasta el momento no se requerían.
Por último, y no por esto con menor importancia, en la medida que el sistema elimine las barreras
tradicionalmente existentes entre elementos estructurales de una organización, y que la toma de
decisiones sea más transparente, y muchas de ellas totalmente automatizadas, el protagonismo
de la figura del gerente intermedio disminuirá.
Los cambios estructurales y de contenido de trabajo, provocados por la reingeniería de los
procesos y la aplicación de las mejores prácticas, no son los únicos riesgos que deben manejarse
con la implementación de un ERP.
Otros riesgos, más visibles y previsibles, pero no menos importantes de gestionar son:
 Concentración de puntos de fallo. Un viejo proverbio dice que no se deben poner todos los
huevos en una sola canasta. Por definición un ERP es un único sistema, con una única base de
datos y que abarca toda la actividad de la empresa. Para gestionar este riesgo evidente, deben
preverse las siguientes medidas:
o El sistema se deberá probar de forma exhaustiva y en condiciones extremas antes de
su implantación, con el fin de garantizar que durante la explotación del mismo no se
produzcan interrupciones imprevistas, ni que colapse por sobrecargas en los
diferentes elementos.
o Debe preverse la necesaria redundancia en los medios técnicos y de comunicación,
con el fin de garantizar la continuidad del funcionamiento del sistema y/o minimizar
los tiempos de interrupción por roturas en los mismos. En casos extremos deberá
duplicarse en localidades distintas los servidores que mantienen la vitalidad del
sistema.
o La información que procesa el sistema debe contar con un procedimiento de salvas,
que permita su recuperación en los plazos que racionalmente exija el sistema.
Como ya se comentó, todas estas medidas de seguridad deben decidirse desde una
perspectiva de costo beneficio, por lo que el elemento gestión cobra un significado especial.
La labor de los especialistas en informática es en este sentido de la mayor importancia, su
apreciación objetiva de la dimensión del riesgo, y su explicación en términos comprensibles
por parte de los directivos, es decisiva a la hora de tomar las decisiones finales.
 Múltiples vías de acceso a la información del sistema. Por su carácter de trabajo en línea, los
datos y las funcionalidades del sistema pueden ser utilizados desde diferentes puestos de
trabajo, incluso en algunos casos desde cualquier computadora conectada a Internet. Esta
realidad exige que las medidas de protección sean realmente eficiente y sean implantadas con
el mayor rigor.
102
 Por último repetir algo ya comentado, la necesidad de que todos los trabajadores que
interactúan con el ERP tengan una gran disciplina. Este es otro de los elementos que sólo con
una participación comprometida y consciente del mayor nivel de dirección de la entidad
puede garantizarse.
103
PAGINA DEJADA INTENCIONALMENTE EN BLANCO
104
8 Principales ERP o SAC en uso
En la actualidad existe un buen número de ERP que pueden adquirirse, algunos a precios bien
elevados, y otros basados en la licencia AGPL, u otro esquema de software libre, que pueden
utilizarse en teoría libremente, pero que normalmente tienen costos no despreciables de
consultoría y adaptación debido a la complejidad del problema.
La utilización efectiva de un ERP requiere de condiciones tecnológicas, de relaciones

interempresariales y organizativas, que no siempre están presentes en las actuales empresas
cubanas.
Es por esta razón que el uso de los ERP haya sido en Cuba bastante limitado hasta el momento, y
sean los SACs, en algunos casos con módulos adicionales, los que mayor distribución hayan
logrado.
En este capítulo se comentarán dos SACs de amplia utilización en Cuba: el Siscont desarrollado
por el antiguo ministerio de industrias básicas para sus empresas, pero con utilización también en
entidades de otros organismos, y el Sabic especializado en la contabilidad de entidades financieras
y bancarias, que funciona en más del 90% de esas entidades en Cuba; y dos ERP, el de la empresa
alemana SAP que mantiene el liderazgo a nivel mundial, y otro basado en software libre, el Odoo
antes OpenERP, que en su parte contable ha sido particularizado para las reglas cubanas y
certificado por las entidades encargadas de esta función y se encuentra en la actualidad en sus
primeras implantaciones.
Existen otras alternativas en utilización y/o en desarrollo y en la medida que se obtenga la

información requerida sobre ellas se incluirán en posteriores versiones de este libro.
105
106
8.1 SAP R/3 – Business Suite
8.1.1 Introducción
La información que se brinda en este capítulo ha sido tomada principalmente de libros, artículos y
manuales sobre SAP R/3 y SAP Business Suite (ver 42, 43, 44, 45,49 y 50).
La compañía SAP, Walldorf, Alemania, se fundó en 1972 por cinco antiguos programadores de
IBM41. La idea básica del negocio fue crear un programa que sirviera para varias compañías, en
lugar de escribir prácticamente los mismos programas para cada una que se automatizara.
Para cumplir este objetivo, el sistema que desarrollaron se abstraía de las necesidades de una
compañía específica, e implementaba los procesos de una compañía genérica.
El software SAP R/2 para equipos centrales de computación (mainframes) salió al mercado en
1979, en ese año SAP tenía 60 empleados, 50 clientes y sus ingresos fueron el equivalente a 5,1
millones de euros.
La implementación del sistema ERP de SAP, llamada R/3 y orientada hacia las computadoras
personales en un esquema cliente servidor, fue introducida en el mercado en 1992. En ese año
SAP alcanzó la cifra de 3.200 empleados, le suministraba sus productos a 2.800 clientes y estaba
presente en 36 países. Los ingresos totales fueron el equivalente a 424 millones de euros.
En general se acepta que la R del R/3 viene de “real time” (tiempo real en inglés). El 3 sin embargo
tiene distintas interpretaciones. Unos dicen que se refiere a la tercera gran versión del software,
aunque nunca existió una primera implementación42. Otros afirman que se refiere a que el sistema
está soportado por una arquitectura a 3 niveles.
En los años 1999/2000 SAP cambió el nombre comercial de su principal producto, junto con la
introducción de su ERP en la Web. El nombre nuevo adoptado fue “mySAP.com”. En esos años sus
empleados llegaron a 25.000, con una base de clientes de 15.000 y una presencia en 120 países.
Los ingresos de la compañía totalizaron 6.300 millones de euros.
En el año 2005 se produce una nueva evolución del ERP de SAP, esta vez con la introducción de
una tecnología: “NetWeaver” (tejedor de la red), que permite integrar no sólo los módulos de SAP,
sino también otros programas independientes, por la vía de brindar interfaces para los principales
lenguajes de programación de ese momento (Java EE, .Net), y brindar un grupo de servicios para el
desarrollo y explotación de sistemas integrados.
En este propio año 2005, al original R/3 se le añadieron otros módulos independientes que
ampliaban el alcance de sus funcionalidades, y al conjunto se le denominó “Business Suite”. SAP
llegó en el 2005 a 35.873 empleados, 32.000 clientes, 135 países con presencia y tuvo ingresos por
8.500 millones de euros.
A inicios del 2014 SAP contaba con 65.572 trabajadores, su base de clientes alcanzaba los
253.500 en más de 180 países. Sus ingresos anuales durante el 2013 alcanzaron la cifra de 16.815
millones de euros, de ellos 13.950 por venta de software y servicios asociados.
41
Hans-Werner Hector, Deitmar Hopp, Hasso Plattner, Klaus Tschira, y Claus Wellenreuther .
42
En los documentos actuales de SAP declara que su primer software fue el R/1, con lo que refuerza el
criterio de que el 3 viene de la tercera gran versión.
107
El siguiente gráfico muestra el crecimiento de los principales indicadores de esta compañía.
300
250
200
EMPLEADOS (miles)
150 CLIENTES (miles)

INGRESOS (cientos de millones eur)
PAISES CON PRESENCIA
100
50
0
1972 1979 1992 2000 2005 2012 2013
Cuadro 8.1.1 Principales indicadores de SAP. Elaboración propia
A principios de los 90 del pasado siglo, en el momento en que se pone en explotación el R/3, el
panorama de los sistemas de gestión empresariales en los países desarrollados se caracterizaba
por una gran cantidad de sistemas, elaborados de forma específica para las diferentes áreas de la
empresa.
La compatibilidad entre esos sistemas era prácticamente nula, y los departamentos de informática
tenían que dedicar gran parte de su tiempo a escribir interfaces entre las diferentes aplicaciones.
Un director de una planta en España caracterizaba la situación existente en su empresa a
mediados de los años 90 con las siguientes palabras.
”Nuestra planta de 1.500 trabajadores está operando sobre una amalgama formada por
sistemas anticuados y modernos servidores. Estamos operando TCP/IP, IPX y Decnet en
nuestra Ethernet y tenemos concentradores de todo tipo. Algunos departamentos tienen
clientes ligeros y están formulando grandes demandas en la red ya que operan procesos
en el servidor y están reenviando datos de un sitio para otro.
Los sistemas de contabilidad e inventario que tiene la planta operan en mainframes de
arquitectura 370. Un desfasado sistema de planificación de recursos de fabricación (MRP)
opera en un VAX de gama alta. Y parte del software de gestión de la fabricación y de
transporte opera en un AS/400.
Prácticamente todo el código de cosecha propia que tiene la planta, está escrito en
COBOL. Aproximadamente la mitad de los operarios de la planta trabaja con una
diversidad de sistemas Windows. La otra mitad permanece conectada al mainframe IBM
con terminales no inteligentes tipo 3270.
Existe una red de área local que engloba a toda la planta y que opera Novell 3.11, así como
una pequeña cantidad de servidores NT no tan grandes pero en crecimiento.”
108
Esta situación obligaba a los departamentos de informática a incurrir en grandes costos, para
poder mantener en pie unos sistemas que ya no eran tan efectivos como antes. Se trataba de
programas que se habían diseñado para las necesidades específicas de la empresa durante los
años 80 y que, con la evolución que había experimentado la industria y la tecnología, se habían
quedado obsoletos.
La pregunta que se planteaba cualquier empresa en esta situación era la siguiente ¿Se debía ir
rehaciendo y adaptando el software, o se debía adquirir una solución estándar?
Las condiciones objetivas para la introducción de los ERP estaban dadas. Casi todas las grandes
empresas optaron durante los 90 por una solución estándar.
Las cifras de crecimiento de SAP muestran palpablemente este proceso.
Teniendo en cuenta el nivel de desarrollo que tienen los ERP en Cuba, en lo adelante se comentan
tanto el SAP R/3 en su versión de finales de los 90 del pasado siglo, que contiene ya los elementos
principales de un ERP moderno, y el SAP Business Suite, que es el producto que en la actualidad se
comercializa.
109
8.1.2 Características principales del R/3
Las principales ventajas del R/3 son las siguientes:

Exhaustivo. El sistema R/3 engloba prácticamente la totalidad de los procesos de gestión de la
empresa. Más adelante se detallarán los principales módulos que incluye.
Integrado. Los módulos del R/3 no aportarían demasiado valor añadido a la empresa si no fuera
por la integración existente entre ellos. Las interrelaciones entre los módulos del R/3 permiten
tener disponible en tiempo real y con exactitud los principales indicadores de gestión. Así, por
ejemplo, una entrada de mercancías puede producir una actualización del inventario de almacén,
una transacción en la contabilidad financiera, una actualización del sistema de información del
control de costos, y un aviso a producción de que hay nueva materia prima en almacén.
Abierto. Tecnológicamente R/3 es un sistema abierto. El mismo puede implantarse en una
variedad enorme de servidores diferentes y ser ejecutado sobre sistemas operativos y sistemas de
gestión de bases de datos de diversos fabricantes. Esto permite escalar el sistema, adecuándolo al
tamaño de la empresa, sin estar atados a ningún fabricante específico. La arquitectura del R/3
sigue varios de los estándares de sistemas abiertos como POSIX y X/OPEN.
Flexible. R/3 posee interfaces con otros productos de software de Microsoft, Oracle etc. R/3 posee
también un amplio menú de parametrización que permite adecuar el sistema a las necesidades de
una empresa particular, así como un completo sistema de desarrollo, para crear nuevos
programas que mantienen la integración con su módulo central.
Multientidad, multiidioma, multimoneda, multipaís. El sistema R/3 pude ser utilizado en varias
entidades de una misma empresa o en varias empresas de un mismo holding, soporta su
utilización en varios idiomas, la contabilización de documentos en cualquier moneda y tiene
recogidas las particularidades fiscales y de gestión de recursos humanos de un gran número de
países. Esta globalidad es el argumento de mayor peso en la decisión de una multinacional a la
hora de adquirir SAP.
Actualizado. La constante investigación llevada a cabo por SAP hace que su software esté al día,
incluyendo las últimas tecnologías disponibles, como EDI, Data Warehouse, clientes Java, comercio
electrónico. . . .
Arquitectura cliente servidor a tres niveles. La arquitectura cliente servidor del R/3 con sus tres
niveles (base de datos, lógica del negocio e interfaz usuario), permite organizar el desarrollo de las
aplicaciones y posibilita adecuar la configuración de las computadoras a utilizar a las necesidades
concretas de la entidad.
110
8.1.3 Módulos del R/3
Como ya se comentaba R/3 contiene un conjunto bastante exhaustivo de aplicaciones de gestión.
A cada uno de los componentes que sirven para gestionar cada una de las áreas de la empresa se
les denomina módulos, y se les nombra con dos letras correspondientes a las iniciales de su
nombre en inglés.
Los módulos principales del R/3 se dividen a su vez en submódulos.
La lista completa de módulos del R/3 en el 2007 se presenta en el anexo 1 (ver 44).
A continuación se comentan algunos de estos módulos.
Gestión Financiera FI (Financial Accounting) Centraliza los datos de la empresa relevantes para la
contabilidad financiera. Recibe todas las transacciones contables del resto de los módulos y las
registra en la base de datos en tiempo real. Esto permite conocer el estado contable de la
compañía (balance y estado de resultados) en todo momento.
Inversiones IM (Investment Management). Permite controlar el ciclo de vida completo de los
activos fijos, desde la inversión en proceso, pasando por la puesta en explotación, la
contabilización de las amortizaciones, y finalmente la baja.
Tesorería TR (Treasury). Contiene una solución para la gestión económico - financiera. Permite
gestionar la liquidez de la empresa y estructurar los activos financieros de la manera más lucrativa
posible.
Control de Gestión CO (Controlling). La contabilidad financiera no siempre puede proporcionar
información desde todos los puntos de vista que una gestión eficaz de costos requiere y es, en
este punto, donde actúa el módulo CO. Partiendo de los datos de FI, la contabilidad analítica
muestra los ingresos, gastos e inversiones desde vistas diferentes. Si esta visión se une al sistema
de planificación y previsión de costos, se obtiene un sistema de información completo que permite
comparar el plan contra el real, y que permite conocer si la ejecución hasta el momento está
ajustada al presupuesto y el porqué.
Logística LO (Logistics). Este módulo se ocupa de la gestión de los datos generales relacionados
con los procesos de logística.
Control empresarial EC (Enterprise Controlling) Este módulo permite llevar el control centralizado
de varias empresas de una misma unión o compañía holding. Permite agrupar las compañías en
centros de beneficio, así como establecer un plan de negocios y emitir información útil para el
nivel ejecutivo de todo el grupo.
Ventas y Distribución SD (Sales and Distribution). La cambiante realidad de los mercados actuales
es un reto para cualquier programa de gestión de ventas. SD es lo suficientemente flexible como
para poder adecuarlas a precios, condiciones de entrega, descuentos, comisiones y ofertas que a
veces cambian a diario.
Informar adecuadamente a los módulos financieros del estado de las ventas es una labor
imprescindible para poder conocer el estado económico y financiero actualizado de la empresa.
Gestión de proyectos PS (Project Schedule) Apoya la planificación y control de proyectos
requeridos para el mejoramiento de la entidad. Incluye los datos sobre costos de los componentes
del proyecto y contiene un sistema de información específico.
Gestión de Materiales MM (Materials Management). Optimiza todos los procesos de compra a
través de varias funciones disponibles. Por un lado permite automatizar las evaluaciones de
111
proveedores, mediante la entrada de ofertas y el mantenimiento de registros informativos y, por
otro, permite reducir los costos de aprovisionamiento y almacenamiento, gracias a la precisión de
la gestión de inventarios y de almacenes. Este es uno de los puntos donde más claramente se
puede apreciar el retorno de la inversión, porque los costos de almacenaje son una de las
principales preocupaciones de las empresas en la actualidad.
Un completo sistema de verificación de facturas proporciona la integración necesaria con los
módulos contables FI, CO y TR para tener la información actualizada en tiempo real.
Gestión de la calidad QM (Quality management) Este módulo contiene herramientas para la
planificación de la calidad, así como para las inspecciones, el control y la certificación de la calidad
de la producción de la empresa y sus insumos.
Planificación de la Producción PP (Production Planning). Proporciona procesos completos para
todos los tipos de fabricación: fabricación repetitiva, fabricación contra pedido, fabricación contra
catálogo, fabricación por procesos, fabricación por lotes y en serie, hasta la gestión integrada de
cadenas de suministro con funciones MRP y Kanban. La integración con MM puede provocar la
solicitud automática de necesidades al lanzar la planificación de requerimientos de material.
Recursos Humanos HR (Human Resources). Tradicionalmente, la gestión de los recursos humanos
se ha considerado un área aislada del resto de los sistemas de gestión de la empresa. SAP, sin
embargo, ha llevado su máxima de integración hasta el punto de incluir la gestión de turnos y
plantillas, los horarios de fábricas, y el ausentismo laboral en los procesos de negocio de la
fabricación y el mantenimiento de planta entre otros. Los dos submódulos principales son los
relacionados con la nómina y el desarrollo del personal, que se explican más adelante, aunque
también existen soluciones menos usadas como la gestión de candidatos, el calendario de fábrica
y la gestión de viajes y gastos.
Ventas al por menor (IS-R) (Industry solutions Retail) Este módulo es específico para el comercio
al por menor. Contiene submódulos que permiten la planificación de los surtidos, el
reaprovisionamiento, tratar los productos en consigna, la transportación; y tiene un sistema de
información específico para los datos que procesa.
Nómina HR-PA-PAY (Payroll Accounting). Mantiene todos los datos de los empleados en unas
estructuras denominadas infotipos, que permiten calcular el pago de la nómina y contabilizarla
tanto en FI como CO de manera automática. Existen infotipos para todas las características de un
empleado, como datos personales, salario bruto, datos familiares, turnos, retenes, retenciones
fiscales. .
Este submódulo es posiblemente el más específico de cada país, debido a que las leyes que rigen
las relaciones laborales difieren mucho de unos países a otros. Es por ello que SAP proporciona
programas diferentes para cada país y un servicio de actualización para poder estar al día con los
cambios que se producen en materia de legislación laboral (aparición de nuevas modalidades de
contratación, cambios en la normativa fiscal, etc.).
Estructura Organizativa HR-PD-PD (Personnel Development). Este submódulo se encarga de
gestionar la estructura de la empresa organizando la misma en departamentos, áreas, grupos de
trabajo, etc. Permite la definición de tareas de puestos de trabajo, y la reorganización de los
mismos.
Mantenimiento de Planta PM (Plant Manteinance). Para una empresa industrial es fundamental
poder garantizar la disponibilidad de la planta y sus herramientas de producción, y de esto se
encarga el módulo de PM. Aplicaciones como la planificación de las revisiones, la programación de
112
órdenes de mantenimiento y la gestión de las notificaciones de aprobación, aseguran un
rendimiento óptimo de la fábrica. Integrando todo esto con PP, se pueden modificar las órdenes
de producción en función de la disponibilidad de los equipos. La integración con HR permite
planificar mejor los calendarios laborales, turnos, etc. y con MM garantiza que las solicitudes de
repuestos sean oportunas.
El siguiente cuadro resume lo hasta aquí comentado sobre el SAP R/3.
ERP SAP R/3

Integración en Extensa
SD FI
tiempo real Comercial Gestión funcionalidad
financiera
MM CO
Materiales Control
Abierto y
flexible
PP
Producción
R/3 TR
Tesorería
Arquitectura
modular
QM Client/Server PS
Proyectos
Arquitectura
Cliente/Servidor
Calidad
PM ABAP/4 WF
Mantenimiento
Flujo de
trabajo
HR IS
Recursos Soluciones
humanos sectoriales
Modelo de Multi...
gestión
Cuadro 8.1.2 ERP SAP R/3. Tomado de 43
113
8.1.4 Ambiente de desarrollo del R/3
Aunque la cantidad de aplicaciones desarrolladas por SAP es enorme, siempre existe la posibilidad
de que el cliente que compre R/3 tenga alguna necesidad tan específica de su negocio que no esté
contemplada en el estándar.
También puede darse el caso de que la funcionalidad que ofrece el estándar no se ajuste
completamente a las necesidades del cliente.
Para resolver estas situaciones existe un ambiente completo de desarrollo de nuevas aplicaciones
integradas en R/3. Este ambiente, que SAP denomina ABAP/4 Development Workbench, se
compone de una serie de herramientas integradas que permiten realizar desarrollos nuevos en
poco tiempo.
ABAP/4 El lenguaje de programación ABAP/4 se caracteriza por su total integración en el sistema
R/3. No en vano todo el software de aplicación (se calcula que más de treinta millones de líneas de
código) que el cliente recibe cuando compra R/3 está escrito en ABAP. Es una mezcla entre el
COBOL y el SQL, hay que tener en cuenta que se creó en los años 70, cuando el COBOL era el
lenguaje preferido para los desarrollos de aplicaciones de gestión. Es un lenguaje de muy alto
nivel, fácil de leer y se aprende rápidamente.
Diccionario de datos (Data Dictionary) Es el punto de referencia para los programadores ya que
permite aislarles del sistema de gestión de base de datos que se utilice por debajo. Desde una
misma pantalla se puede crear, modificar y borrar los objetos de bases de datos, entre los que se
incluyen tablas, estructuras, vistas, elementos de datos y dominios. Las definiciones de las tablas,
por ejemplo, pueden ser referenciadas directamente en los programas permitiendo modificar
posteriormente las tablas sin tener que cambiar los programas. Se tiene la posibilidad de gestionar
otros objetos del diccionario de datos como las ayudas de búsqueda, los objetos de bloqueo o los
objetos de autorización.
Editor de programas El editor ABAP/4, aparte de proveer las funciones básicas para la edición de
texto, tiene múltiples características que facilitan la programación. Permite efectuar una
verificación de sintaxis y aceptar las sugerencias del dispositivo de corrección automática que
tiene incluido.
También permite resaltar las palabras clave y tener una vista en forma de estructura jerárquica
que ofrece la posibilidad de ocultar o desglosar bloques sintácticos. De esta forma, el programador
obtiene una buena visión de conjunto de la estructura general del programa.
Dibujador de pantallas (Screen Painter) Con esta herramienta se pueden crear rápidamente
interfaces gráficas de usuario, incluyendo una amplia gama de elementos de control, como
botones de pulsación, botones de radio, listas de selección (checkboxes), etiquetas, campos de
entrada, listas de base de datos.
Las pantallas que se crean se denominan Dynpro y en ellas se incluye la definición de la pantalla y
sus campos, y la lógica de proceso de la misma.
Esta lógica de proceso está dirigida por eventos, como los lenguajes visuales modernos, aunque la
variedad de eventos posibles está bastante limitada.
Entorno de puesta a punto El modo de puesta a punto (debugging) de ABAP/4 es posiblemente la
herramienta más alabada por los programadores habituales de este lenguaje. Tiene todas las
ventajas de este tipo de ayudas a la programación (creación de puntos de ruptura, puntos de
114
observación, ejecución paso a paso, ejecución de bloques..), pero además permite hacer todo esto
viendo el código fuente del programa, por lo que la localización del lugar del error es exacta.
Otras herramientas. Existe una gran variedad de herramientas adicionales cuyo uso no es tan
frecuente, como el Dibujador de Menú (Menu Painter), el análisis del tiempo de ejecución, el
analizador de objetos, el sistema de pruebas asistido por ordenador (CATT), etc.
115
8.1.5 SAP Business Suite
Como se explicó al inicio, el SAP Business Suite surge en el 2005 con el fin de ampliar el alcance de
algunas de las funcionalidades que originalmente incluía el R/3. Este es un producto en constante
perfeccionamiento, por lo que la lista de sus componentes se modifica con frecuencia.
El siguiente cuadro muestra un esquema de los componentes del SAP Business Suite en su versión
original.
Cuadro 8.1.3 SAP Business Suiie. Tomado de 44
En su versión del 2010 el SAP Business Suite incluía el SAP ERP versión 6.0, y cinco nuevos
módulos.
El contenido del SAP ERP v6.0 se corresponde con lo explicado para el sistema R/3.
Los cinco nuevos módulos son en realidad, como ya se dijo, extensiones de funcionalidades ya
existentes en el R/3, que amplían el alcance de los módulos originales, facilitan el trabajo y, al
utilizar nuevas tecnologías de procesamiento de datos incorporadas en el nuevo ambiente de
trabajo de SAP (ver NetWeaber más adelante), permiten una mayor interacción con otras
aplicaciones.
Nótese que de los 5 nuevos módulos, tres tienen que ver con el tema suministros, uno con las
relaciones con los clientes, y uno con el ciclo de vida de los productos (ingeniería a producción), lo
que muestra la importancia que SAP le da a estos temas.
A continuación se comenta el contenido de cada uno de ellos.
Gestión de relaciones con suministradores SAP SRM (Supplier Relationship Management)
El módulo SAP SRM representa el corazón de toda la gestión de aprovisionamiento. Las principales
tareas que abarca son:
116
 Aprovisionamiento operacional. Facilita el tratamiento de las órdenes de compra, permite la
toma de decisiones por equipos de especialistas, la definición de plazos de aprovisionamiento,
el tratamiento de procesos complejos.
 Aprovisionamiento por autoservicio. Permite que ítems de poco costo y uso muy difundido
(insumos de oficina, insumos de limpieza, piezas de repuesto, etc.) puedan ser adquiridos
directamente por los usuarios finales dentro de la compañía cumpliendo con las reglas y
políticas de aprovisionamiento generales.
 Aprovisionamiento guiado por los planes. Una entidad genera requerimientos de materiales y
partes a través de diferentes planes (de producción, de mantenimiento, de inversiones, etc.).
Los requerimientos que surgen de esos planes se centralizan en el módulo de SRM con el fin
de satisfacerlos de forma adecuada.
 Aprovisionamiento de servicios. Para la gestión de contratación de los servicios requeridos
para el funcionamiento de una entidad.
 Gestión de catálogos. Facilita el tratamiento por medios electrónicos de los catálogos de los
suministradores.
 Centralización de compras. Apoya la gestión de análisis de la concurrencia y la selección de las
mejores ofertas.
 Centralización de contratos. Permite la definición y gestión centralizada de los contratos de
suministro.
 Evaluación de suministradores. Utilizando toda la información recogida en el sistema sobre
cada suministrador, facilita la evaluación de los mismos y su comparación.
Gestión de la cadena de suministros SAP SCM (Supply Chain Management)
Este módulo se llamaba anteriormente SAP APO –Planificación avanzada y optimizador (Advanced
Planning and Optimizer). Ayuda a realizar las siguientes tareas:
 Planificación de la demanda (SCM DP), a través de un pronóstico de las ventas futuras. Se
realiza periódicamente, en dependencia de las características de la compañía y el producto
(mensual, semanal, ..). Su objetivo es determinar que producto se requiere, para que cliente,
para que establecimiento del cliente, en que cantidad y en que fecha.
 Planificación de suministros en la red (SNP). Se determina las cantidades óptimas por producto
a distribuir en la red de la compañía y a partir de estas los movimientos necesarios entre las
existencias de los diferentes establecimientos.
 Plan de producción y calendarios detallados (PPDS). A partir del plan de suministros se deduce
el plan de producción ideal de cada fábrica. Su objetivo es determinar la cantidad óptima a
producir con el fin de satisfacer la demanda, limitar los excesos de inventario y los tiempos
requeridos para cambiar la producción de un producto a otro.
 Plan de abastecimientos (MRP). Finalmente el plan de producción se utiliza para determinar
los componentes que deben adquirirse para realizar la producción planificada en los tiempos
previstos.
Colaboración en la red de suministradores SAP SNC (Supply Network Collaboration)
SAP SNC permite automatizar la gestión de inventarios tanto con los suministradores, como con
los clientes.
117
Para la coordinación de los inventarios con los suministradores los módulos de SAP SNC permiten
acordar para cada ítem cantidades mínimas y máximas, que el suministrador se compromete a
mantener. Los niveles de inventario pueden ser monitoreados tanto por el suministrador como
por el propio cliente y se emiten alertas ante situaciones inusuales.
Para la coordinación de los inventarios con los clientes se elaboran planes de suministro a partir de
pronósticos basados en la información estadística y con la participación de los clientes. Estos
planes pueden ajustarse con el fin de optimizar los costos de transportación y almacenamiento,
definiendo las características permisibles para cada embarque (cantidad de paletas, tipo y tamaño
de las mismas, peso máximo, etc .
SAP SNC facilita adicionalmente el intercambio de informaciones por medios electrónicos entre
suministradores y receptores de los productos, tales como avisos de embarque, informes de
recepción, etc.
Gestión de relaciones con clientes SAP CRM (Customer Relationship Management)
Este módulo constituye un ambiente de trabajo para los especialistas en marketing y les brinda
ayudas a su trabajo que incluyen, entre otras:
 Organización del día de trabajo,
 Información sobre campañas de promoción de productos,
 Información sobre clientes existentes y potenciales,
 Información sobre las personas que trabajan en las diferentes compañías clientes.
Todos estos elementos están interconectados y pueden ser personalizados en dependencia de las
características de la empresa y sus clientes.
Gestión del ciclo de vida de los productos SAP PLM (Product Lifecycle Management)
El módulo PML permite registrar y controlar los cambios de todos los elementes necesarios para la
fabricación de un producto, desde sus características ingenieriles hasta los procesos de
producción.
Aspecto central de este módulo es el Registro Ingenieril (Engineering Record), que es un objeto de
datos sobre los productos, con todos los elementos necesarios para su fabricación; incluyendo sus
dibujos, listas de materiales, procesos productivos, control de calidad, etc.
Con la ayuda de PLM se pueden definir los flujos de trabajo requeridos para la modificación de
cualquiera de los elementos del Registro Ingenieril y llevar una traza de todas las modificaciones.
118
8.1.6 Ambiente de desarrollo para el SAP Business Suite
El siguiente cuadro presenta un esquema del SAP NetWeaber, ambiente de trabajo para el
desarrollo de nuevas aplicaciones, y para la integración de las aplicaciones del SAP Business suite
entre ellas y con módulos del exterior.
SAP NetWeaber
INTEGRACIÓN DE PERSONAS
Acceso Multicanal (SAP MI)
Ambiente para aplicaciones compuestas (SAP CAF)
Portal (SAP EP) Ges. de ident. (SAP IdM)
Gestión del ciclo de vida (SAP Solution Manager)

INTEGRACIÓN DE LA INFORMACIÓN
Int. de Neg. (SAP BI) Ges. del con. (SAP KM)
Gestión de datos maestros (SAP MDM)

WebSphere
INTEGRACIÓN DE PROCESOS
Agente de Gestión de proc.
Integración (SAP XI) de neg. (BPM)
Microsoft
PLATAFORMA DE APLICACIONES (SAP Web AS) .NET
J2EE ABAP
Abstracción de SGBD y Sist. Explot.
(Open SQL)
Cuadro 8.1.4 NetWeaber Tomado de 48
El SAP NetWeaber es un conjunto de herramientas que permiten:
 integrar diferentes módulos desarrollados por SAP

 desarrollar nuevas aplicaciones aprovechando todo el ambiente de SAP con la ayuda de Java
(J2EE) o ABAP.
 Desarrollar nuevas aplicaciones que interactúen con módulos de SAP utilizando plataformas
de desarrollo como Microsoft .NET o IBM WebSphere.
A continuación se comentan los principales componentes de SAP NetWeaber agrupados según sus
objetivos de ayuda al desarrollo o a la integración.
 Herramientas para el desarrollo de nuevas aplicaciones.

o SAP NetWeaver Developer Studio. Está basado en el producto Eclipse de IBM. Constituye
un ambiente (facilidades de edición, manejo del código fuente, puesta a punto, etc.) para
elaborar programas en Java, que pudiera extenderse a otros lenguajes de programación.
Contiene facilidades para la generación de programas que traten la interface con los
usuarios, así como un ambiente para la creación de interfaces con equipos móviles.
o SAP Visual Composer. Contiene el ambiente para modelar las interfaces de usuarios en
las aplicaciones compuestas.
119
o SAP Composite Application Framework (SAP CAF). Es un ambiente para modelar y crear
aplicaciones que se basan en servicios suministrados por componentes de SAP Business
Suite, o por otras aplicaciones desarrolladas de forma independiente. Para lograr este
objetivo mantiene un repositorio con metadata que describe los objetos, roles, interfaces
con usuarios, y las interrelaciones entre estos elementos. Esta metadata se utiliza para
generar el código que funciona en el SAP Web AS.
o SAP Solution Manager. Permite mantener el control de las versiones de los programas
instalados en cada sitio, incluyendo un enfoque sistemático de los parches y
ampliaciones. Proporciona una base para monitorear el funcionamiento de los diferentes
componentes y de los procesos que en ellos se desarrollan.
 Herramientas para apoyar la interconexión de módulos de SAP entre ellos y con aplicaciones
independientes
o SAP Enterprise Portal (SAP EP). Permite personalizar e incluir en una sola pantalla las
funciones que tiene que cumplir cada cual, según el rol que juegue en la empresa, aun
cuando estas funciones provengan de diferentes aplicaciones.
Permite también incorporar flujos de trabajo, de tal forma que el cumplimiento de una
tarea tenga que realizarse siempre a través de ejecutar los pasos previamente definidos.
Soporta la colaboración entre miembros de un grupo al incorporar carpetas compartidas,
fórums de discusión y listas de correo electrónico.
o SAP Mobile Infrastructure (SAP MI). Facilita el diseño de interfaces para teléfonos
móviles, tabletas y equipos similares, al no tener que personalizar cada una de ellas. Sólo
se necesita una descripción de la interface y en tiempo de ejecución SAP MI reconoce el
equipo con que está interactuando y envía los comandos que le corresponden.
o SAP Business Intelligence (SAP BI). Es la solución de SAP para los almacenes de datos
(Data Warenhouses). Al igual que el resto de las soluciones de almacenes de datos su
trabajo lo realiza en dos momentos: extracción, transformación y carga del almacén de
datos en un formato estandarizado, desde las bases de datos operativas; elaboración de
vistas y resúmenes de esos datos (InfoCubes) que permiten analizarlos desde distintos
ángulos y dar respuestas rápidas a consultas complejas. Como parte de SAP BI existen
también componentes para la elaboración de reportes y gráficos y un servicio de
distribución personalizada de resultados.
o SAP Master Data Management (SAP MDM). Los datos maestros en SAP son aquellos que
no están asociados a una transacción particular, como la información sobre clientes, la
descripción de productos y los planes de cuentas contables. SAP MDM es una
herramienta para construir un almacén de datos maestros, común para todos los
componentes y aplicaciones independientes, y poder consultarlos y modificarlos en
tiempo real. SAP MDM brinda adicionalmente algunas herramientas para detectar y
eliminar el uso de distintos nombres para un mismo objeto.
o SAP Exchange Infrastructure (SAP XI) Facilita la comunicación entre componentes y entre
estos y las aplicaciones independientes. Para lograr este objetivo convierte los mensajes
al formato XML, de tal forma que ambos extremos puedan conformarlos e interpretarlos
adecuadamente. Adicionalmente SAP XI permite crear reglas para generar mensajes a
120
partir de la detección de ciertos eventos, con lo que se puede automatizar interacciones
entre diferentes sistemas.
o SAP Aplication Server (SAP AS). Cumple las siguientes funciones:
 Gestiona las comunicaciones con Internet.
 Interpreta y ejecuta programas que utilizan ABAP, Java y las estructuras
especiales de SAP llamadas Dynapro.
 Sirve de infraestructura para los servicios Web.
 Contiene el Open SQL, que no es más que una abstracción de la base de datos de
tal forma que los programadores no tengan que modificar su código para que
corra en las bases de datos de diferentes fabricantes.
121
8.1.7 Anexo 1. Lista de módulos del SAP R/3 en el 2007
FI CONTABILIDAD FINANCIERA
FI-GL Cuentas de Mayor
FI-LC Consolidación Sociedades
FI-AR Cuentas a Cobrar
FI-AP Cuentas a Pagar
FI-AA Gestión de Activos
FI-SL Special Ledger
Cierres
IM INVERSIONES
Gestión de Inversiones
TR TESORERIA
Programa Conciliación
Provisiones Posicionamientos
Control de Fondos
CO CONTROL
CO-CCA Contabilidad por Centros Coste
Contabilidad Presupuestaria
CO-PC Control de Costes del Producto
CO-PA Análisis de Rentabilidad
CO-OPA Órdenes Internas
CO-ABC Costes Basados en Actividades
LO GESTION DATOS GENERALES DE LOGISTICA

LO-MD Datos Básicos
LO-VC Gestión Variantes de Productos
LO-PR Modelos Previsión y Comportamientos
LO-ECH Cambios Ingeniería Objetos SAP
EC CONTROL EMPRESARIAL
EC-PCA Contabilidad Centros Beneficio
EC-BP Planificación del Negocio
EC-MC Consolidación a Nivel Directivo
EC-EIS Sistema de información ejecutivo
SD VENTAS Y DISTRIBUCION
SD - MD Datos maestros
SD-SLS Gestión de Ventas
122
SD-GF Gestión Tarifas y Condiciones de Precio
SD-SHP Gestión de Expediciones
SD-BIL Facturación
SD-IS Sistemas de Información
SD-EDI Intercambio Electrónico de Datos
PS GESTION DE PROYECTOS
PS-BD Datos Básicos
PS-OS Planificación del proyecto
PS-PLN Plan de Costes
PS-APM Proceso de Aprobación
PS-EXE Seguimiento y Progreso del Proyecto
PS-IS Sistema de Información
MM GESTION DE MATERIALES
MM - MRP Planificación Necesidades Materiales
MM-PUR Gestión de Compras
MM-IM Gestión de Inventarios
MM-WM Gestión de Almacenes
MM-IV Verificación de Facturas
MM-IS Sistema de Información
MM-EDI Intercambio Electrónico de Datos
Sistema Clasificación
Gestión de Lotes
QM CALIDAD
QM-PT Herramientas de planificación
QM-IM Proceso de Inspección
QM-QC Control de Calidad
QM-CA Certificados de Calidad
QM-QN Notificaciones de Calidad
PP PRODUCCIÓN
PP-BD Datos Básicos
PP-SOP Gestión de la Demanda
PP-MP Plan Maestro
PP-CRP Plan de Capacidades
PP-MRP Plan de Materiales
PP-SFC Órdenes de Fabricación
PP-PC Costes de producto
PP-IS Sistema de Información
PP-PI Industria de procesos
123
PP-CFG Configuración de Producto
HR GESTION DEL PERSONAL

HR-PA-EMP Datos Maestros de Personal
HR-PA-PAY Nómina
HR-PA-TRV Gastos de Viaje
HR-PD-OM Organización y Planificación
HR-PD-PD Desarrollo de Personal
HR-PD-SCM Gestión de la Formación
HR-PA-APP Selección de Personal
HR-PA-TIM Gestión de Tiempos
IS-R SOLUCIÓN PARA EL COMERCIO MINORISTA

IS-R Planificación de Surtidos
IS-R Reaprovisionamiento
IS-R Formatos de presentación
IS-R Sales Retail
CP Inventario de proveedores
MM Compras Retail
SD Transporte
RIS Sistema de Información Retail
PM GESTION DEL MANTENIMIENTO

PM-EQM Identificación Descripción
PM-PRM Mantenimiento Preventivo
PM-WOC Órdenes de Mantenimiento
PM-PRO Proyectos de Mantenimiento
PM-SM Gestión del Servicio
124
8.2 SABIC
8.2.1 Aspectos históricos y principales características del SABIC

Los antecedentes del sistema SABIC se remontan al año 1985. A partir de ese momento se crea en
el entonces Banco Nacional de Cuba (BNC) un equipo de especialistas que, con conocimientos
sobre la programación de las computadoras y de la actividad bancaria, comienzan a realizar tareas
para sustituir con PCs los equipos de saldo directo que todavía funcionaban en las sucursales, y las
grandes computadoras del SUMCE43, demasiado costosas y obsoletas, que existían en las oficinas
centrales.
Los principales trabajos que se realizaron en esta etapa fueron:
• Desarrollo de un sistema sobre una PC para sustituir los equipos de saldo directo que aun
funcionaban, y eliminar el registro manual del diario y el mayor. Implantado en la mayoría de
las sucursales del BNC.
• Concepción, diseño y programación de un sistema parametrizado para el registro local de las
transacciones de la Sucursal Especial de Operaciones Internacionales (SEOI) del BNC, utilizando
PCs. Este sistema permitía contar con los datos requeridos para la gestión operativa de los
departamentos de la SEOI, y alimentaba en soportes magnéticos el sistema central de
contabilidad. Se implantó en todos los departamentos.
• Desarrollo e implantación de un sistema, que utilizaba PCs e impresoras rápidas, para la
contabilidad central de la SEOI, la que hasta ese momento se procesaba en una EC-1040 del
SUMCE.
• Elaboración de un software, utilizando PCs con MS-DOS44, para conectar al BNC a la red
bancaria internacional SWIFT. El BNC pertenecía a la red de SWIFT desde 1989, pero no podía
transmitir ni recibir mensajes porque el equipamiento y el software necesario tenían
componentes fabricados en EEUU que, por el bloqueo, no podían ser vendidos a Cuba. Este
software fue certificado por SWIFT en 1991 y comenzó a funcionar en el BNC en ese mismo
año.
En 1993 se decide crear el Banco Internacional de Comercio (BICSA), como banco comercial para
exportaciones, importaciones y operaciones domésticas en divisas; que debía funcionar con
procedimientos similares a bancos de su tipo en el mundo.
Junto con la creación del BCSA se decidió también elaborar un sistema automatizado para bancos
comerciales, que representó la primera versión del SABIC.
43
SUMCE Sistema Uniforme de Máquinas Computadoras Electrónicas. Línea de equipos desarrollados por el
campo socialista compatibles con las IBM 360 /370.
44
Swift suministraba toda la documentación requerida, pero era necesario desarrollar y poner a punto los
programas. El software debía abarcar los niveles del modelo OSI: Aplicación, Presentación, Sesión,
Transporte, y Enlace. El protocolo del nivel de enlace era una versión de BSC modificada por SWIFT, los
restantes niveles tenían protocolos propios. El principal problema a resolver al elaborar los programas, fue
garantizar que todo funcionara en los tiempos requeridos, sobre un sistema que no soportaba la ejecución
en paralelo de programas (MS-DOS). El nivel de enlace se programó en C, los restantes niveles en Foxpro.
125
Para definir la arquitectura del SABIC se revisaron varios sistemas automatizados de bancos y se
contrastaron con las experiencias acumuladas hasta ese momento.
Finalmente se decidió tomar como modelo un sistema inglés, que funcionaba con éxito para
bancos comerciales en varios países. Se estudiaron en detalle sus características y principales
elementos arquitectónicos.
La primera versión del SABIC se puso en funcionamiento en enero de 1994, junto con la apertura
del BICSA. Esta primera versión no tenía todas las características previstas en el diseño del sistema,
sino que dado el poco tiempo disponible se le incluyeron solo los elementos esenciales para
garantizar el registro contables de ese banco, que comenzaba a operar y que tenía aun pocas
transacciones. Esta primera versión respetó los principios arquitectónicos definidos previamente,
con el fin de poder garantizar su evolución ordenada.
Ya en enero de 1995 el SABIC que estaba en explotación en el BICSA contaba con las principales
funcionalidades concebidas en un inicio:
• Transaccional
• Tiempo real
• Multiusuario
• Multimoneda
Al ser transaccional el SABIC garantizaba que no se produjeran errores formales y
fundamentalmente de cuadre al actualizar las tablas con datos contables. Para el SABIC una
transacción es un conjunto de partidas contables que:
• Cuadran por moneda, fecha valor y fecha contable,
• No contienen errores formales,
• Provoca una actualización de todo o nada,
• Contiene una identificación unívoca.
Para garantizar las características de tiempo real y multiusuario se utilizó inicialmente la tecnología
de redes de computadoras de Novell. La programación desarrollada garantizaba que las
transacciones se ejecutaran de forma inmediata, lo que permitía que se realizara un control de la
disponibilidad de fondos antes de aceptar una transacción. Por otra parte, todos los usuarios del
sistema interactuaban con él al mismo tiempo, y los reportes (posición por monedas, balance,
estado de resultado, etc.) se podían confeccionar con la información actualizada hasta el
momento de su emisión.
Todas las cuentas estaban abiertas por moneda, y se introdujo una cuenta nominal especial que
podía utilizarse como contrapartida y permitía el cuadre por monedas, si existía más de una en
una transacción. El saldo de esta cuenta nominal de conversión de monedas, representa en todo
momento la posición del banco en la moneda en cuestión.
En el primer trimestre de 1995 se decide la extensión del SABIC a otros bancos e instituciones
financieras. Desde mayo del 1995 hasta diciembre del 1996 el SABIC se instala en el Banco
126
Metropolitano de ese momento, que contaba con una sola sucursal, y en 250 sucursales del
entonces BNC.
En el período 1997 a 2000, años en los que se ejecuta una amplia reorganización del sistema
bancario cubano, el SABIC se implanta además en:
• La oficina central del Banco de Crédito y Comercio

• La oficina central del Banco Central de Cuba
• La oficina central del Banco Nacional de Cuba
• El Banco de Inversiones
• El Banco Exterior de Cuba
• Varias instituciones financieras no bancarias
Durante este período se le agregan al SABIC las siguientes funcionalidades:
• Tránsito entre sucursales por medios electrónicos (ver cuadro 8.2.1). Hasta ese momento el
tránsito de operaciones contables entre sucursales se realizaba con papeles a través del correo
nacional.
TRANSFERENCIA DE FONDOS ENTRE CLIENTES DE DISTINTAS SUCURSALES

(DE CLIENTE X1 DE LA SUCURSAL X AL CLIENTE Y1 DE LA SUCURSAL Y)
SUCURSAL X SUCURSAL Y
CLIENTE X1
1000
TRANSITO RECIBIDO
1
1000
TRANSITO ENVIADO
1000 1000 RTD

2 CLIENTE Y1
3
1000
TRAN. ENV. RATIF.
1000
Cuadro 8.2.1 Transito entre sucursales. Elaboración propia
El movimiento de papeles a través del correo para actualizar la cuenta de tránsito traía, como
es fácil de imaginar, grandes dificultades que provocaban descuadres en la contabilidad y no
pocas oportunidades de fraude.
Para mejorar esta situación se desarrollaron módulos que, utilizando la red de transmisión de
datos que existía en esos momentos (X-25), intercambiaban mensajes entre los SABIC que
funcionaban en distintas sucursales, y sustituían el envío y recepción de los documentos.
127
• Centro de autorización de operaciones con tarjetas magnéticas (ver cuadro 8.2.2). En 1997 se
instalaron los primeros cajeros automáticos en el país y se comenzaron a emitir tarjetas
magnéticas de débito con la marca RED.
El SABIC se utilizó desde un inicio para la autorización de las transacciones que se ejecutaban
con las tarjetas emitidas por los bancos que tenían este sistema.
Debido a los grandes volúmenes de transacciones que tuvo que enfrentar el SABIC para
resolver esta tarea, fue necesario rediseñar el módulo central de tal forma que soportara la
ejecución paralela de varios hilos, para poder mantener los tiempos de respuestas requeridos
por el funcionamiento de los cajeros automáticos45 utilizando los servidores disponibles.
SISTEMA PARA TARJETAS MAGNÉTICAS

VISA
MASTERCARD
RED ETC
TPV TPV TPV
CENTRO CENTRO
AUTORIZADOR DE
CONTROL CONTROL
VISA
TRANSACCIONES MASTERCARD
CAJEROS TPV
SABIC AUTOMÁTICOS
RED VISA
Cuadro 8.2.2 Sistema para tarjetas magnéticas. Elaboración propia
• Para asimilar el trabajo con la red de cajeros automáticos, fue necesario desarrollar
adicionalmente otros módulos que permitieran la conciliación de las operaciones y el cuadre
físico de cada cajero (ver cuadro 8.2.3).
45
La respuesta a una transacción de un cajero automático no puede demorar más de 45 segundos,
independientemente de la distancia que tenga que recorrer el mensaje. Cuando en un mismo momento se
reciben varios cientos de solicitudes de autorización, o información, en el centro de emisión de las tarjetas,
la duración de la respuesta a cada uno de ellos no puede demorar más que fracciones de segundos, ya que
para garantizar que no se le autorice a una tarjeta un importe mayor al saldo que tiene, las transacciones
tienen que procesarse secuencialmente.
128
CONTROL DE CAJEROS AUTOMÁTICOS
BCC
LEYENDA
SLBTR
Autorización
Conciliación y
1 2
cuadre
CENTRO
CONTROL
SABIC CAJEROS SABIC
AUTOMÁTICOS
Cuadro 8.2.3 Control de cajeros automáticos. Elaboración propia
• El SABIC se utilizó también en estos años como soporte del Sistema de Liquidación Bruta en
Tiempo Real (SLBTR) que se implantó en el Banco Central de Cuba, a través del cual los bancos
comerciales intercambian por medios electrónicos sus transacciones (ver cuadro 8.2.4).
PAGOS INTERBANCARIOS ORDENADOS POR CLIENTES

CUENTAS EN DISTINTOS BANCOS
SLBTR BCC
(SABIC)
BANCO1 BANCO2
36.00 36.00
B2 2346560 Cr 36.00 B2 2346560 Cr 36.00
B1 B2
Orden de pago 36.00

Db 1843245
Cr 2346560 1843245
2346560
36.00
36.00
BCC
BCC
36.00
36.00
Cuadro 8.2.4 SLBTR. Elaboración propia
129
• El sistema bancario cubano decidió en el año 1998 aplicar el principio de truncamiento46 para
facilitar la automatización del procesamiento de los cheques. A partir de esta decisión se
estandarizó la identificación de los cheques emitidos por los diferentes bancos, que incluye el
código del banco, la moneda, el número de la cuenta y el número del cheque.
De las tecnologías disponibles para leer por medios electrónicos la información de cada
cheque (caracteres magnéticos, caracteres reconocibles y código de barras) se escogió e
implantó la del código de barras, debido a que, al ser utilizada de forma masiva en el comercio
minorista, el costo de los equipos requeridos para dotar cada mostrador e imprimir los
cheques era el más bajo.
Con estas medidas, de cada cheque que se presenta en una sucursal bancaria, para su cobro o
depósito, sólo es necesario captar manualmente la fecha de emisión y el importe. Una vez que
se han leídos los datos contenidos en el código de barra, y captados los que se introducen
manualmente, las transacciones del SABIC pueden procesar el cheque, debitando localmente
la cuenta de su emisor si esto es posible, o enviándolo por medios electrónicos a la entidad
bancaria que corresponda.
Adicionalmente, La imagen del cheque se escanea para archivarla en soporte digital.
A finales del año 2000, con el fin de proyectar su futura evolución, se analizaron las principales
deficiencias del SABIC en ese momento, y se consideró que las más significativas eran las
siguientes:
• El nivel de seguridad y protección del sistema era bajo. La tecnología que soportaba el sistema
(MS-DOS + Foxpro + Novell) era muy frágil, y el hecho de que en cada sucursal se actualizaban
y guardaban todos los datos, significaba que existían tantos puntos de vulnerabilidad como
sucursales tenía el banco.
• El esquema descentralizado en que se basaba el SABIC obligaba, además, al tránsito contable
entre sucursales, única solución con una tecnología basada en papeles como la que había
existido hasta el año 1995, pero superada en los grandes bancos a nivel internacional desde la
década del 70, cuando surgieron las posibilidades de teleprocesamiento.
Aun cuando el tránsito se había automatizado y funcionaba de una forma bastante eficiente,
no dejaba de representar un riesgo en la explotación del sistema, ya que para estar seguros de
que no había problemas, era necesario conciliar las cuentas de tránsito entre todas las
sucursales en los dos extremos.
• El sistema era, y lo sigue siendo en la actualidad, muy rígido en cuanto a la estructura de los
datos y los programas que deben desarrollarse para particularizar las transacciones, lo cual
obliga a realizar adaptaciones frecuentes para resolver problemas no previstos inicialmente.
46
El principio de truncamiento consiste en aceptar, entre las instituciones bancarias, que la información
sobre un cheque que emite un banco es tan válida como el cheque en sí, con lo que no es necesario enviar
físicamente este efecto, sino sólo la información sobre él captada en la sucursal.
130
• Por último, aunque no por esto menos importante, debido a la tecnología utilizada en su
programación, el mantenimiento del sistema requiere un gran esfuerzo, a pesar de que como
se verá más adelante su módulo central, que representa el cerebro del sistema, no ha
requerido modificaciones mayores desde su concepción inicial.
Durante el período 2001 – 2006 el SABIC evolucionó en los siguientes sentidos:
• Se migró de MS-DOS, como sistema de explotación de las terminales, y Novell, como sistema
de explotación de la red, a Windows para ambas funciones.
• Como principal lenguaje de programación se pasó de Foxpro a Visual Foxpro, y la gestión de la
base de datos se migró de Foxpro a SQL-Server.
• Se modificó el diseño de las tablas de la base de datos en lo que fue necesario para permitir la
contabilidad centralizada.
• Se aumentaron y consolidaron las medidas de seguridad y protección del sistema y de los
datos.
• A este conjunto de cambios se les dio el nombre de Nuevo Esquema Funcional (NEF) y se
Implantó en el Banco Metropolitano, que adquirió en la Ciudad de la Habana más de 100
sucursales que pertenecían anteriormente al BANDEC y al BPA.
Durante los últimos 8 años (2006-2014) el esfuerzo del grupo de especialistas que atienden el
SABIC se ha concentrado en estabilizar la versión implantada en el Banco Metropolitano y en
implantarla, aunque con un esquema descentralizado debido fundamentalmente a deficiencias en
los medios de comunicación, en el BANDEC que tiene unas 200 sucursales y en el BPA que cuenta
con 400 sucursales y cajas de ahorro en todo el país.
131
8.2.2 Principales servicios que brinda el SABIC
Los principales servicios que brinda el módulo central del SABIC en la actualidad son los siguientes:
• Seguridad y protección
La seguridad del SABIC se apoya fundamentalmente en la seguridad que brinda el software de
bases de datos SQL-SERVER, y consiste en la realización diaria de una copia total de la base de
datos (Backup), y en la actualización automática de una bitácora de todas las actualizaciones
de las tablas del sistema.
La copia diaria de la base de datos, la base de datos actualizada en cada momento, y el fichero
que contiene la bitácora de todo lo realizado, pueden guardarse físicamente en soportes
distintos, con lo que de producirse una rotura en el soporte de la base de datos más
actualizada, la misma puede recuperarse siempre desde los otros dos. De igual forma, si la
rotura es en el soporte que contiene la última salva o en el de la bitácora intermedia,
realizando una nueva salva de la base de datos más actualizada, se pueden reproducir las
condiciones de seguridad del sistema.
La protección del acceso sistema se garantiza, entre otras, con medidas en la red para limitar
interactuar con la base de datos, con la obligatoriedad de definir claves duras47 para cada
persona que tiene acceso al sistema, y con la confección de una bitácora lógica que registra
todas las acciones que sobre los datos se ejecutan y quien las ordenó.
Adicionalmente al final de cada día se comprueba la integridad contable de las principales
tablas del sistema.
• Cálculo y aplicación de intereses
En el SABIC los intereses se calculan todos los días como parte de las rutinas de inicio del día
contable. Para cada cuenta del mayor existe un campo llamado acumulado de intereses,
donde se van sumando diariamente los intereses calculados si corresponde. Para el cálculo de
los intereses de cada cuenta se define una tasa de interés, los días a considerar y los días base
(365 o 360 en ambos casos).
En el lenguaje del SABIC se le llama aplicación de intereses al registro contable del ingreso o
egreso de los intereses calculados hasta cierto momento, y del cobro o pago, o el registro en
cuentas por cobrar o pagar, de ese importe. Obviamente cuando se aplican los intereses el
campo de acumulado de intereses se lleva a cero.
La aplicación de los intereses puede hacerse a través de una transacción que se lance
manualmente, o de forma automática si se han definido los parámetros requeridos.
47
Se le da el nombre de clave dura a una clave de usuario que tenga no menos de 8 caracteres, que tienen
que contener mayúsculas, minúsculas, números y caracteres especiales y que debe ser modificada cada
cierto tiempo.
132
Una variante muy usada de la aplicación automática de los intereses es llevar, al final de cada
mes, los intereses acumulados hasta ese momento a una cuenta de “intereses por cobrar o
pagar devengados”.
• Registro anticipado de transacciones
Existen ciertas transacciones cuyo registro contable se conoce anticipadamente, como por
ejemplo la amortización de los activos fijos, que se debe realizar cada mes. En el SABIC estas
transacciones se pueden registrar en cualquier momento, señalando la fecha en que deben
contabilizarse realmente. Todos los días, cuando se inicia el sistema, programas del módulo
central revisan las transacciones que están pendientes y, si corresponde, las contabiliza.
• Saldo contable, saldo confirmado y saldo disponible
Para cada cuenta del mayor, el SABIC registra en todo momento un saldo contable y un saldo
confirmado. El saldo contable, conocido también como el saldo de los estados de cuenta,
incluye todos los movimientos registrados en el sistema con fecha contable menor o igual que
la fecha del día contable en curso. El saldo confirmado, conocido también como saldo para los
intereses, se calcula por la suma de todos los asientos que afectan una cuenta y que tienen
fecha valor igual o menor que la fecha del día contable en curso.
Adicionalmente el SABIC permite establecer relaciones de cuentas para calcular una
disponibilidad real de fondos. Así, por ejemplo, se puede definir una cuenta memorándum
para reservar fondos de la cuenta corriente de un cliente cuando a favor de este se emite un
aval o una garantía, o se recibe un cheque en depósito contra otro banco y no se tiene aún la
ratificación de su validez. De igual forma se pueden definir cuentas cuyo saldo se sume al saldo
confirmado de la cuenta, al momento de comprobar si existen fondos en la misma
(autorización de sobregiro).
• Cierre diario de posiciones en monedas extranjeras
Como parte del cierre contable diario, cada día se cierran las cuentas de conversión de
monedas, y cualquier otra cuenta nominal con monedas distintas a la moneda base del banco,
contra una cuenta de ingresos y egresos por tipo de cambio, utilizando el tipo de cambio del
día. Esta operación permite calcular cada día las ganancias o pérdidas que se producen por
tener posiciones abiertas en distintas monedas a la moneda base48 (ver 41).
• Emisión de estados de cuentas
Para todas las cuentas que se definan se puede emitir un estado de cuentas, con las reglas
propias de este tipo de reporte y con la periodicidad que se requiera. Los estados de cuentas
normalmente están numerados de forma secuencial, incluyen el saldo contable inicial y final,
así como todos los asientos que lo afectaron. En el SABIC, adicionalmente, se incluye en el
estado de cuentas el saldo confirmado y el disponible al final del período que se informa.
48
En un banco una operación aislada en cierta moneda no produce en general ni pérdidas ni ganancias por
tipo de cambio. Esas pérdidas o ganancias se producen por tener posiciones abiertas (activos distintos a
pasivos) en una moneda, y variar el tipo de cambio.
133
Los estados de cuenta pueden imprimirse o enviarse por correo electrónico.
• Consulta de maestros, clasificadores y operativos
Todas las tablas del sistema pueden consultarse a través de un interfaz homogéneo que
permite construir expresiones lógicas con todos los campos de la tabla. Para cada campo se
pueden usar las funciones igual, menor, mayor, incluido en, desigual, etc. y unirlas con otras,
para otros campos, a través de los operadores “Y” y “O”. Las expresiones para consultar una
tabla pueden guardarse, dándoles un nombre, lo que permite utilizarlas de forma repetitiva. El
resultado de la consulta puede verse en pantalla, o ser impreso si se desea.
• Actualización de clasificadores y operativos
Para todos los clasificadores y operativos existe también un interfaz estándar que permite
actualizarlos, fila a fila.
• Reportes por pantalla, en papel, en formatos Excel o PDF
Todos los reportes que se emiten a través del SABIC pueden mostrarse por pantalla o llevarse
a un formato determinado, que puede ser papel, tabla Excel, o PDF.
• Recuperación de lotes
Todos los reportes que se emiten se guardan en una tabla del sistema que lleva el nombre de
maestro de lotes. Para gestionar esta tabla, cada reporte que se emite, además de su nombre,
recibe un número, llamado número de lote.
Los lotes de impresión se guardan por el período que se defina en los parámetros del sistema,
y se pueden recuperar en cualquier momento, redefiniendo incluso su formato.
• Reverso de una transacción
Con el fin de simplificar la regla contable de que cuando una transacción contiene un error no
puede modificarse en ninguna de sus partes, sino reversarla completamente y volverla a
introducir con las correcciones, el SABIC contiene una transacción general que permite
reversar cualquier otra siempre y cuando no hayan sucedido hechos contables que no puedan
ser reversados49 automáticamente. Para reversar una transacción basta con dar los datos que
la identifican unívocamente.
• Interfaz para incorporar transacciones tipificadas
Una buena parte de los programas que hay que desarrollar para particularizar una aplicación
del SABIC tienen como objetivo captar los datos de una operación específica y, a partir de
estos, generar los asientos que se requieren para contabilizar la transacción correspondiente.
En el SABIC las tablas que contienen los datos contables sólo pueden actualizarse a través de
programas de su módulo central, por lo que las transacciones específicas tienen que preparar
49
Un caso común es cuando una transacción implica la inserción de un artículo en cartera, por ejemplo una
cuenta por pagar, y al momento de quererse reversar el asiento insertado ya no existe. Como es fácil de
comprender, una operación con estas características no puede reversarse de forma automática.
134
los datos de las partidas en un formato predefinido (interfaz de contabilización del SABIC) y
entregárselos al módulo central. El módulo central revisa formalmente las oartidas contables
que se le entregan y, si no detecta errores, actualiza las tablas con datos contables
garantizando que o se actualice totalmente la transacción o no se haga nada.
 Transacción general
La transacción general, permiten introducir los datos de cualquier transacción contable, y

garantiza que no se cometan errores formales, incluyendo el cuadre.
Como ya se explicó, la mayor parte de las transacciones del SABIC se ejecutan con programas
que particularizan las distintas operaciones o documentos primarios. Por muy exhaustiva que
haya sido la definición y programación de transacciones específicas, siempre se presentarán
casos que no se ajustan a lo tipificado, para los que se utiliza la transacción general.
• Interfaz para el tratamiento de mensajes financieros (ISO 8583)
Con el fin de permitir que el SABIC fungiera como sistema autorizador de las transacciones con
cajeros automáticos se desarrolló un interfaz basado en la norma ISO 8583, que permite
recibir mensajes basados en ese estándar, accionar según los mismos indican y enviar las
respuestas que correspondan.
• Interfaz con el SLBTR y tránsito entre sucursales
El BCC definió un interfaz para interactuar con el SLBTR que, en esencia, utiliza los formatos
definidos por SWIFT para similares mensajes, y canales propios de comunicación con el
estándar SNMTP de correo electrónico.
Desde la creación el SLBTR del BCC funciona con el SABIC y, obviamente, cualquier
implantación de este sistema en un banco puede intercambiar mensajes contables con él.
• Configuración del sistema
El SABIC cuenta con un mecanismo de definición de variables locales y generales que permite
particularizar cada implantación. Las direcciones físicas donde se encuentran los componentes
del sistema, el tipo de entidad en el que está funcionando (centro contable, centro
informativo, sucursal, o una combinación de estos), la moneda base, el código de la entidad,
etc., son todos aspectos que pueden definirse para cada instalación.
135
8.2.3 Principales elementos arquitectónicos del SABIC
Los registros contables del SABIC se hacen en todos los casos a nivel de la “cuenta del mayor”
definida por el sistema.
Las cuentas del mayor tienen la siguiente estructura
• Código de moneda según un clasificador previamente definido, con dos dígitos.
• Código de cuenta/subcuenta con cuatro dígitos. La cuenta/subcuenta en el SABIC representa
el concepto contable que se quiere registrar (Efectivo, Fondos libres en banco, Cuenta
corriente de cliente, etc.). Existe un clasificador de cuentas que contiene el conjunto de las
cuentas/subcuentas que se utilizan en una aplicación particular (plan contable).
La codificación de las cuentas/subcuentas debe respetar las siguientes reglas:
o El valor del primer dígito tiene el siguiente significado
– Cuentas reales de activo para los valores 1 y 2
– Cuentas reales de pasivo y capital para los valores 3 y 4
– Cuentas nominales para el valor 5
– Cuentas contingentes de activo para los valores 6 y 7
– Cuentas contingentes de pasivo para los valores 8 y 9
o Por otra parte, las cuentas contingentes en el SABIC se registran siempre por partida doble
y, entre ellas, tienen que cumplir las mismas reglas formales y de cuadre definidas para las
cuentas reales.
• Tipo de Contraparte. Todas las cuentas del SABIC se asocian a una contraparte. Los principales
tipos de contraparte, codificados sobre un dígito son:
o Persona jurídica como cliente, con el valor 1,

o Bancos o instituciones financieras no bancarias, con el valor 2,
o Concepto de ingresos o egresos, con el valor 3,
o Persona natural como cliente, con el valor 5.
• Contraparte y su posible desglose para lo que se reservan 7 dígitos. El contenido de la
contraparte depende de su tipo, y tiene la siguiente codificación:
o Las personas jurídicas como clientes se codifican sobre 5 dígitos y se asocian a un
clasificador de clientes, en el que se pueden definir distintos segmentos (con cuentas
corrientes en el banco, suministradores nacionales, suministradores extranjeros, etc.).
Cuando la contrapartida es un cliente, quedan dos dígitos, a los que se les da el nombre de
desglose, y sirven para identificar distintas cuentas de un cliente en la misma moneda.
o Los bancos o instituciones financieras no bancarias se codifican sobre cuatro dígitos y se
asocian a un clasificador de bancos. Cuando la contrapartida es un banco quedan tres
dígitos disponibles para el desglose, los que pueden utilizarse, por ejemplo, en
particularizar cada operación de crédito (otorgado o recibido) con esa entidad financiera.
136
o Las cuentas nominales tienen como contrapartida los conceptos de ingresos y egresos
codificados sobre cuatro dígitos, y que se detallan también en un clasificador. El desglose
de los conceptos de ingresos y egresos contiene el código del centro de costo que les dio
origen sobre tres dígitos.
o Cuando la contrapartida de una cuenta del SABIC es una persona natural se utilizan los 7
dígitos para su identificación. Existe además un clasificador de personas, donde para cada
código de 7 dígitos se recogen los principales datos de la misma, tales como tipo de
documento de identificación (pasaporte, carnet de identidad, etc.) número de
identificación, nombre, dirección, etc.
El clasificador de personas del SABIC no contiene sólo las personas que tienen cuentas
personales en la institución donde está implantado el sistema, sino también todas aquellas
que de una u otra forma se relacionan con el mismo, como empleados, firmantes de
cuentas, etc.
Los datos contables del SABIC se archivan en tres tablas con los siguientes nombres y contenidos:
 El Mayor que contiene para cada cuenta a catorce dígitos:

o El saldo contable
o El saldo confirmado
o Un acumulado de intereses
o Fecha de la última contabilización
o Fecha del último cálculo de intereses
Nótese que no existe un campo para el signo de los saldos (débito o crédito). El SABIC utiliza
para todos los importes la convención de que los valores positivos son deudores y los
negativos acreedores.
 El diario que contiene una copia de todos los asientos contables que tendrán que actualizar el
mayor en un futuro de una forma u otra. Cada asiento contable contiene, entre otros, los
siguientes datos:
o Cuenta a 14 dígitos
o Importe
o Tipo de asiento del diario
o Fecha de posteo
o Fecha contable
o Fecha valor
o Fecha de vencimiento
o Referencias e identificación de transacciones
Los tipos de asientos del diario identifican el tratamiento a darle al artículo en cuestión. Así,
un tipo de asiento del diario con valor 01 significa que ese asiento se registró con una fecha
valor mayor a la contable, que ya se actualizó el saldo contable, y que cuando llegue la fecha
valor, en la rutina de inicio del día, se deberá actualizar el saldo confirmado y eliminar el
artículo del diario.
137
Los tipos de asiento con valor 02 identifican los asientos que constituyen las carteras, para los
que obligatoriamente se define una fecha de vencimiento.
 Por último el histórico contiene una copia de todos los asientos contables que modificaron en
algún momento el diario y/o el mayor. Los principales datos contenidos en el histórico son:
o Cuenta a 14 dígitos
o Importe
o Fechas (todas las contenidas en el diario y la de actualización del histórico)
o Centro de costo y operador
o Referencia original
o Referencia corriente
o Referencia externa
o Número de transacción
o Número de asiento
o Número de transacción original
o Número de asiento original
Nótese que para cada asiento se guardan tres referencias, la corriente, la original y la externa.
La referencia corriente identifica cada transacción, la referencia original puede contener la
referencia corriente de una transacción que de alguna forma le sirvió de antecedente, Por
ejemplo, cuando se reversa una operación la transacción que reversa toma un número de
referencia corriente propio de ella y, como referencia original, la referencia corriente de la
transacción que se reversa.
La referencia externa sirve para identificar cualquier documento que haya servido de base
para la transacción que se contabiliza.
El cuadro 8.2.5 muestra los principales módulos del SABIC y la forma en que se relacionan. Como
se puede apreciar en el mismo todos los datos se almacenan en una base de datos relacional, en la
actualidad se utiliza SQL-Server en la versión del 2005.
El módulo central es el encargado de mantener la coherencia contable del sistema, garantizando

que las transacciones no tengan errores formales y que actualicen la base de datos a través de un
procedimiento de todo o nada. Adicionalmente el módulo central contiene los programas que se
corren en todos los casos en el cierre e inicio del día contable, y es el encargado de llamar a otros
programas, que se definan en una aplicación particular, para correr en esos momentos.
Por último el módulo central es el encargado de actualizar todos los datos relacionados con las
posibles configuraciones del sistema y controla el diálogo con los usuarios.
138
ARQUITECTURA DEL SABIC
SEGURIDAD Y PROTECCIÓN
T
R
A
N
S MAESTROS
A I S DE CONTABILIDAD
C G MAYOR
N C HISTORICO
C B
O DIARIO
T D
I N
O E T MÓDULO R
A
N R B CENTRAL E
E L
F L
S A
E
A C CLASIFICADORES
I OTROS MAESTROS
Z O
R C OPERATIVOS
E O N
P N A
Oy S L
R U PROCESADOR
T L MENSAJES
E T FINANCIEROS
S A
S
RTD OTROS
SISTEMAS
Cuadro 8.2.5 Arquitectura del SABIC. Elaboración propia
Las funciones de la interfaz contable se comentaron más arriba, así como las transacciones, los
reportes y consultas y el procesador de mensajes financieros.
Como muestra el cuadro 8.2.5 todo el acceso al sistema está controlado por las funciones de
seguridad y protección, que garantizan que sólo las personas autorizadas puedan interactuar con
el mismo y dejan trazas sobre lo ejecutado.
139
8.2.4 Base de clientes
El SABIC se encuentra implantado en los siguientes bancos:
Banco Central de Cuba
Banco de Crédito y Comercio
Banco Popular de Ahorro
Banco Metropolitano
Banco de Inversiones
Banco Exterior de Cuba
Banco Nacional de Cuba
Banco Industrial de Venezuela
Banco de Exportación y Comercio (Venezuela)
Y en las siguientes instituciones financieras no bancarias:
Fintur
Finatur
Fincopex
Fincomex
Rafin
Compañía Fiduciaria
Arcaz
Lo que en total representa unas 800 oficinas y más de 15000 puestos de trabajo.
Los volúmenes totales de transacciones mensuales que se ejecutan con el SABIC deben sumar algo
más de 10 millones, de las cuales el 60% tiene que ver con las operaciones de tarjetas magnéticas
y cajeros automáticos.
140
8.2.5 Tecnologías utilizadas
La versión actual del SABIC está soportada por:
WINDOWS
SQL-SERVER
Visual Foxpro
Lenguaje C++
Como se habrá podido apreciar de las explicaciones dadas anteriormente, la arquitectura del
sistema parte de tener un módulo central que realiza las funciones más generales de la
contabilización bancaria, incluyendo la actualización de todos los ficheros con datos contables.
A este módulo central se le agregan programas que permiten particularizar las transacciones de
una implantación específica, y emitir los reportes de salida específicos. La mayor parte de estos
programas están elaborados utilizando VisualFoxpro, aunque no es la única alternativa. Cualquier
lenguaje que pueda interactuar con el SQL-Server puede ser utilizado.
Los bancos universales que utilizan el SABIC tienen algo más de 400 transacciones tipificadas, para
las que existen programas específicos.
Esta arquitectura ha permitido emplear el SABIC tanto en instituciones financieras con algunos
trabajadores, como en bancos con miles de puestos de trabajo y cientos de oficinas.
141
8.2.6 Requerimientos
Además de los paquetes de software antes señalados, para implantar el SABIC se requiere como
mínimo una computadora que funcione como servidor y puesto de trabajo, aunque por las cargas
de trabajo lo normal es que exista al menos un equipo dedicado a servidor y tantos equipos como
puestos de trabajo se requieran.
Cuando existen sucursales, cada una de ellas debe tener disponible un servidor local,
adicionalmente a los puestos de trabajo.
Si el sistema funciona en un solo edificio debe estar disponible una red de área local (LAN) con
velocidades de al menos 100 Mbps.
Si las sucursales u otras oficinas que funcionan con el sistema se encuentran en locales ubicados
en distintos puntos geográficos, se requiere adicionalmente un enlace a distancia (WAN) con
velocidades no inferiores a los 64 Kbps.
En dependencia de los volúmenes de impresión se requieren impresoras en cada puesto de
trabajo o conectadas a la red. Las impresoras pueden ser de matriz de punto o con tecnología
laser, en todos los casos basta con que sean en blanco y negro.
Para las funciones de salva se requiere, adicionalmente, contar con una capacidad de
almacenamiento en otro equipo, preferiblemente ubicado en un local distinto al de los servidores
centrales. La capacidad de almacenamiento de las salvas depende obviamente de los volúmenes
de datos que trate el sistema.
142
8.3 Odoo (OpenERP)
8.3.1 Aspectos generales
Odoo es el tercer nombre que se le da por sus desarrolladores a un sistema ERP elaborado en el
ámbito del software libre. Inicialmente se llamó Tiny ERP y posteriormente OpenERP, el último
nombre (Odoo) lo adquiere en Junio del 2014. La mayor parte de los módulos de Odoo están bajo
la licencia AGPL, por lo que se puede tener acceso a todos los programas fuentes.
La información de este resumen se tomó básicamente de las fuentes bibliográficas 51, 52 y 53.
El desarrollo del sistema se coordina por una empresa (Odoo S.A.) que cuenta con algo más de 200
trabajadores y cuatro oficinas a nivel mundial. La oficina central se encuentra en Bélgica y es
dirigida por Fabien Pinckaers diseñador principal de este sistema desde sus inicios.
El sistema cuenta además con unos 500 socios a nivel mundial y unos 2000 desarrolladores
organizados en una comunidad bastante activa.
Desoft en Cuba ha personalizado el OpenERP versión 6.1, incluyendo las características propias de
la contabilidad aquí. Los módulos de la línea base de este sistema relacionados con la contabilidad
fueron certificado en agosto del 2014 y sus primeras implantaciones se encontraban en marcha al
momento de escribir este trabajo.
A continuación una tabla con la cronología de las versiones de este software, donde se muestra
también el nombre que tenía el sistema en cada momento:
Nombre Versión Fecha de emisión
Tiny ERP 1.0 2005

2.0
3.0
4.0 2007
OpenERP 4.2 9/2008
5.0 4/2009
6.0 1/2011
6.1 2/2012
7.0 12/2012
Odoo 8.0 9/2014
Tabla 8.2.1 Cronología de versiones de OpenERP (Tomado de Wikipedia, 19/9/2014)
Odoo utiliza una arquitectura orientada a servicios. Cuenta con un servidor donde se ejecuta toda
la lógica del negocio y un cliente que se encarga de resolver lo necesario para que el diálogo con
los usuarios se realice a través de un navegador. El servidor es quien interactúa con la base de
datos utilizando un ORM propietario llamado OpenObject. Inicialmente existía también un cliente
143
grueso (Thick-client) que permitía implementar versiones no web (desktop), pero en la actualidad
no está disponible.
El lenguaje de programación utilizado es Python, con la excepción del cliente que está hecho en
gran medida utilizando javascript. Buena parte del sistema, fundamentalmente la relacionada con
los formatos de salida de los datos, se basa en XML. La base de datos es Postgresql.
La conexión entre el servidor y el cliente web utiliza el protocolo xml-rpc o en su lugar el net-rpc.
El cuadro 8.3.1 muestra la arquitectura general de Odoo
ARQUITECTURA DE Odoo
https
https
Encripción internet
P. ej. Apache
http
Servidor de Servidor web

Base de datos Aplicaciones Odoo
Postgresql Odoo cliente
Open- xml-rpc
Object net-rpc http
intranet
http
Cuadro 8.3.1 ARQUITECTURA DE Odoo, elaboración propia
Odoo puede funcionar prácticamente en todos los sistemas de explotación utilizados en la

actualidad (Linux / Unix, Windows, Mac OSX, Solaris).
144
8.3.2 Módulos funcionales
Desde el punto de vista funcional Odoo está organizado en módulos que pueden irse incorporando
paulatinamente en cada aplicación. Los módulos se dividen en aquellos que son soportados
oficialmente por Odoo S.A. y otros (unos 4000) desarrollados por la comunidad y a los que se tiene
igualmente acceso gratuito.
Los módulos soportados oficialmente por Odoo S.A. incluyen:
 Gestión de ventas
 Gestión de compras
 Gestión de relaciones con clientes
 Gestión de proyectos
 Gestión de almacenes
 Contabilidad y finanzas
 Manufactura
 Comercio electrónico
 Gestión de contenidos
 Gestión de activos
 Gestión de recursos humanos
 Gestión de flota
 Gestión de eventos
 Redes sociales
 Puntos de venta (PdV)
 Gestión de conocimientos y documentación
 Calendarios
 Gestión de gastos
 Registro del tiempo
 Evaluación de empleados
 Planificación de los recursos para la manufactura
 Portal
 Directorio de empleados
 Libro de direcciones
 Proceso de reclutamiento
 Gestión de nóminas
A continuación se comenta el funcionamiento de algunos de estos módulos.
8.3.2.1 Gestión de ventas
Permite el control de todo el proceso de ventas desde las ofertas hasta el registro contable,
manteniendo siempre una visión sobre los aspectos que aún están pendientes.
145
La emisión de ofertas puede hacerse en PDFs o enviando mensajes de correo electrónico. En
ambos casos se puede controlar el flujo de esos elementos. Finalmente las ofertas pueden
convertirse en órdenes de trabajo con sólo un click del ratón. Como la información está
totalmente integrada, todos los datos requeridos se pueden recuperar en el lugar donde se
necesitan. Así, por ejemplo, la información sobre los clientes: antecedentes de ventas, preciso
específicos, formas de pago etc.; sobre los productos: existencias en almacén, tiempo necesario
para su producción, volumen y peso etc., puede recuperarse directamente durante el proceso de
elaboración de una oferta.
Todos los contratos de venta se gestionan, cuando durante al proceso de venta se detecta que
algún contrato debe ser actualizado, el vendedor correspondiente recibe automáticamente la
notificación.
Este módulo se puede interrelacionar con el módulo de Gestión de relaciones con los clientes,
resolviendo así tareas mucho más compleja de forma eficiente.
Toda la información registrada en el módulo puede ser procesada con el objetivo de estudiar
determinados comportamientos. Así, por ejemplo, la historia de cada cliente o de grupos de ellos
puede ser reflejada en tablas o gráficos que permitan su análisis.
8.3.2.2 Gestión de compras
El módulo de gestión de compras cubre desde la automatización de los requisitos de

abastecimiento, el seguimiento de las compras y la administración de las informaciones sobre los
suministradores, hasta el control de los productos que se reciben.
El módulo permite vincular las solicitudes de productos con las existencias en los almacenes
utilizando reglas logísticas de tal forma que se pueda lograr una alta eficiencia de los inventarios.
Los precios de compra pueden ser gestionados adecuadamente, comparando los de los diferrentes
suministradores. La información almacenada por el módulo permite el análisis integral de los
suministradores de una forma objetiva.
La comunicación con los suministradores puede realizarse totalmente a través del correo
electrónico.
Las solicitudes de compra pueden gestionarse totalmente lo que permite controlar las posiciones
aun pendientes con cada suministrador y tomar las acciones que correspondan.
Los precios de los productos pueden gestionarse utilizando los métodos tradicionales para la
gestión de costos: estándares o planificados, fifo (primero que entra primero que sale), lifo
(último que entra primero que sale), FEFO (primero que caduca primero que sale) y precios
promedios.
146
Las listas de precios de los suministradores pueden importarse para que formen parte de la base
de datos del sistema.
Toda la información del módulo está a la disposición de los usuarios para elaborar los estudios
estadísticos sobrte los suministradores, productos, existencias, precios, etc.
8.3.2.3 Gestión de relaciones con los clientes
Este módulo facilita la organización del proceso de ventas sin un gran esfuerzo. Las conversaciones
telefónicas, las reuniones y tros contactos con cada cliente pueden registrarse con el fin de
explotarlas de forma adecuada posteriormente .
El módulo permite mostrar todo el proceso de venta a partir del plan de ventas, utilizando las
vistas Kanban50 , con lo que se puede obtener información visual sobre los próximos pasos, así
como sobre los chances y las ventas esperadas.
Los procesos de venta pueden integrarse además con las redes sociales (Linkedln), obteniendo de
forma rápida contactos interesantes, cuyos datos pueden incorporarse de forma automática al
libro de direcciones.
Permite la integración con los principales softwares de mensajería electrónica (Outlook, Gmail
etc.) de tal forma que cada vendedor puede continuar utlizando el que mejor domine.
La gestión de oportunidades se apoya por este módulo a través del tratamiento de los mensajes
de correo electrónico que se reciben y su enrutamiento al personal de ventas correspondientes. La
información registrada permite el análisis de la eficiencia de las oportunidades en el marco de
campañas, relacionadas con planes de venta, etc.
La gestión de los chances de venta permite encontrar las mejores oportunidades. El módulo
permite que ante determinados hechos se envíen notificaciones sobre los chances de venta a los
vendedores interesados .
En los diferentes contactos de ventas se pueden comprobar los datos de contacto de los clientes
(dirección de correo, teléfonos, características de las reuniones, etc.) lo que permite garantizar en
todo momento un acceso fácil a los mismos.
El módulo contiene una agenda integrada, donde todos los vendedores planifican sus reuniones o
conferencias telefónicas con los clientes, de tal forma que se puede tener una idea global del
trabajo del equipo.
Las promociones de ventas y las campañas de marketing pueden hacerse de forma racional
asignando a cada vendedor la responsabilidad de los contactos telefónicos o por correo
electrónico con cada posible cliente.
50
Kanban es un método desarrollado por Toyota inicialmente que permite optimizar la gestión a partir de
señales que se intercambian entre los procesos.
147
Se pueden preparar tableros de mando que resumen la información sobre los procesos de venta
de tal forma que las decisiones se puedan tomar de forma más calificada.
8.3.2.4 Gestión de proyectos
Odoo cuenta con una gestión de proyectos colaborativa en tiempo real, que le permite al equipo
de trabajo del proyecto tener información sobre todas las facetas del proyecto, desde la visión
global hasta los menores detalles y desde los contratos con los suministradores hasta el registro
contable.
La organización de los proyectos, sus procesos y tareas, se puede realizar empleando las vistas
Kanban y los gráficos de Gant. Las vistas de calendarios facilitan el control de los plazos críticos.
La herramienta de chateo permite intercambiar con los integrantes del equipo, o con cualquiera
de los suministradores, con el fin de analizar la solución de los problemas que inevitablemente
surgen.
Existe una función llamada ¨Etherpad¨ que permite la confección conjunta de resúmenes de
reuniones u otros contactos, así como especificaciones complejas relacionados con el proyecto.
Cada participante en la confección del documento tiene su color y todos pueden ver la totalidad
del texto, lo que hace el proceso de redacción más eficiente.
Los proyectos se relacionan con los contratos de los suministradores y contratistas, de tal forma
que es posible sin muchos esfuerzos realizar cálculos sobre tiempo de ejecución, costo de
materiales y cantidad de trabajo invertido.
8.3.2.5 Gestión de almacenes
El sistema de almacenes de Odoo tiene las siguientes características:
 Al nivel de existencias de cada artículo en el almacén se les pueden definir reglas

configurables.
 Registro por partida doble automático para cada movimiento (fuente – destino).
 Los cambios de existencias generan automáticamente asientos para la contabilidad financiera.
 Elaboración automática de solicitudes de suministros.
 Propuestas automáticas de reubicación de existencias.
 Estructuras jerárquicas de almacenamiento.
 Almacenes encadenados.
 Estrategias de entrada y salida de los almacenes.
 Cada cliente y cada suministrador es visto por el sistema de forma automática como un
almacén.
 Apoya el uso de escáneres para la identificación de los productos.
 Control de los envíos, numeración de paquetes, envío directo a clientes (drop shipping),
completamiento.
148
 Tratamiento de medios auxiliares de carga (paquetes, paletas y contenedores).
 Precios estándares, LIFO, FIFO, FEFO o promedios.
 Tratamiento de números de series.
 Tratamiento de las pérdidas.
 Capacidad de registrar millones de datos.
En particular el registro de los productos de los almacenes por partida doble permite conocer no
sólo las existencia de cada ítem, sino controlar todo el flujo de los mismos, desde los
suministradores hasta las áreas de producción o los clientes.
En Odoo todos los procesos de los almacenes están automatizados según las reglas de logísticas
que se decidan (existencia mínima, reglas de empuje (push-regeln), reglas de halar (pull-regeln),
solicitud según requerimiento, etc. Los procesos manuales de solicitud de productos se minimizan
a través de las solicitudes automatizadas y la planificación de requerimientos optimizada.
El módulo de gestión de almacenes está directamente interrelacionado con los módulos de

compras, de ventas y el de contabilidad financiera. Todos los eventos que se originan en
cualquiera de estos módulos y tienen repercusión en otro generan intercambios de información
automáticos con los que lo requieran.
La gestión de los productos en los almacenes puede incluir información sobre los números de
serie, o sobre el medio en que llegó al almacén (número de contenedor, paquete, etc.), de tal
forma que posibles problemas en el ciclo de producción, o en las entregas a los clientes, pueden
ser rastreados hasta su origen.
El manejo de múltiples almacenes permite formar una estructura jerárquica de los mismos donde
se incluyan los almacenes propios, los de los suministradores y clientes, las áreas de entrega y de
producción.
Al igual que en otros módulos se pueden construir tableros de mando con la información
relevante sobre las existencias de productos y todo el proceso de aseguramiento material.
8.3.2.6 Contabilidad y finanzas
El módulo de contabilidad y finanzas de Odoo abarca la contabilidad financiera como tal, el análisis
de costos y la contabilidad de deudores y acreedores. Por otra parte permite el control completo
del presupuesto, el uso de la banca en línea, el control de toda la facturación, el cálculo de los
impuestos, el control del flujo de caja, y facilita los análisis financieros.
El plan de cuentas se puede particularizar según las necesidades de la entidad y cumpliendo con
las normas específicas del país.
La emisión de los estados financieros y la consolidación de la contabilidad de distintos centros de

costo o sociedades se realizan de forma simple con la ayuda de este módulo.
149
Los estados de cuenta bancarios se pueden importar en formato digital y, a partir de estos,
conciliar la cuenta de banco de forma sencilla. La conciliación de los cobros y pagos también se
facilita a través de la integración de este módulo con los de compras y ventas.
El término factura en Odoo abarca tanto las facturas de proveedores y para clientes, como las
notas de crédito recibidas de los proveedores o enviadas a los clientes. El control del flujo de todas
las facturas llega desde que se confecciona o recibe una prefactura, hasta que se cobran o pagan
las cuentas que esas facturas generan.
La mayoría de las veces las prefacturas son generadas de forma automática a partir de acciones
que se ejecutan en otros módulos, tales como:
 Cuando se aprueban las ordenes de los clientes o a los suministradores,

 A partir de que se entregan o reciben productos,
 Cuando se da por culminado un servicio a un cliente,
 Por cargos de comisiones y otros gastos.
Antes de ser aceptadas o enviadas a los clientes estas prefacturas tienen que ser validadas por
personal autorizado.
Por último, las facturas pueden también ser confeccionadas de forma manual, pero esto sucede
mayoritariamente cuando la personalización del sistema no se ha hecho correctamente, o cuando
se recibe un producto o servicio que no tuvo una orden previa.
El módulo de contabilidad y finanzas de Odoo permite controlar la ganancia, la estructura de

costos, el presupuesto y la contabilidad a varios niveles, al mismo tiempo que le brinda las
funciones requeridas para dirigir los procesos del negocio.
Entre las posibilidades de este módulo se encuentran: el uso de varias monedas, la existencia de
varios usuarios con diferentes niveles de acceso trabajando simultáneamente con el sistema, y la
consolidación de los estados financieros de varias compañías pertenecientes a un mismo holding
utilizando varios modelos.
La gestión de tesorería se apoya de forma decisiva por este módulo a través de los análisis de
flujos de caja y el control del presupuesto.
La integración con otros módulos puede tener también efectos operativos de gran importancia, así
por ejemplo si desde el módulo de contabilidad y finanzas se suspende el crédito de un cliente,
todas las demás operaciones con ese cliente (entrega de productos, ventas etc.) se bloquean de
forma automática.
150
8.3.2.7 Comercio electrónico
El módulo de comercio electrónico de Odoo permite confeccionar con poco esfuerzo catálogos de
productos, y páginas específicas para cada uno de ellos. Todas las funciones y técnicas requeridas
para el comercio electrónico están presentes en este sistema, en particular:
 Datos de los artículos a partir de los registros del sistema,

 Ajustes de precios y del texto directamente en las páginas de venta,
 Herramientas para destacar, agrandar o poner en promoción ciertos artículos,
 Generación automáticamente meta-textos y palabras claves para máquinas de búsqueda,
 Uso de precios tachados (precios en los que se muestra un precio anterior tachado y el precio
actual, normalmente inferior),
 Navegación a varios niveles,
 Técnicas de up-selling y cross-selling (up-selling se refiere a proponer modificar una compra
determinada aumentando la calidad, cambiando la marca etc, mientras que cross-selling se
refiere a vender algo adicional cuando un cliente está adquiriendo un producto, en ambos
casos con el fin de obtener mayores ganancias,
 Herramientas para la optimización de los motores de búsqueda (SEO).
La función inline-editing facilita la elaboración de precios, promociones o modificaciones de las

descripciones de los productos de forma sencilla.
El uso de varios lenguajes para abarcar diferentes mercados se facilita con Odoo. La traducción de
las páginas son guardadas por el sistema y tras la selección del idioma correspondiente toda la
operación se realiza en el mismo.
El módulo se puede conectar con servicios de traducción profesionales de tal forma que cuando se
modifiquen algunas páginas la traducción correspondiente se entregue en un plazo mínimo. De
igual forma puede interactuar de forma automática con portales de comercio electrónico
establecidos, así como pasarelas de pago existentes.
8.3.2.8 Puntos de venta (PdV)
La solución ´para PdV de Odoo está totalmente integrada con el módulo de almacenes y con el de
contabilidad y finanzas.
La figura 8.3.1 muestra los componentes de la solución de PdV de Odoo.
151
Figura 8.3.1 Punto de venta de Odoo. Tomado de 53
El módulo de PdV trabaja con cualquier equipo que tenga una pantalla táctil y un navegador, ya
sea una Pc normal, una laptop, una tableta o un teléfono inteligente. Al mismo se le pueden
conectar equipos especializados propios de los puntos de venta, tales como pesas, escáneres,
cajas para efectivo, impresoras, etc.
Los procesos y los pasos de cada proceso pueden ser determinados para cada aplicación según las
necesidades del usuario.
Un nuevo punto de venta se puede equipar de forma muy rápida, todo lo que se necesita es una
conexión de internet y los equipos que utilizará el punto de venta. Si la conexión se interrumpe
momentáneamente, la aplicación sigue funcionando y, cuando se restablece la comunicación, los
datos se sincronizan automáticamente.
El módulo de PdV está preparado para cualquier proceso de venta minorista, sea un restaurant o
una librería, los procesos básicos están incluidos y se pueden configurar según las necesidades. La
consulta en tiempo real sobre existencias en distintos canales de distribución (almacenes, puntos
de venta móviles, cadenas de tiendas, etc.) es parte del módulo, por lo que las oportunidades de
venta pueden aprovecharse adecuadamente. La elaboración de la cuenta (factura) para un cliente
es inmediata. El control de las ventas y el efectivo se realiza en tiempo real.La gestión de los temas
de garantía, reparación de equipos defectuosos y solución de otros problemas de los clientes se
apoyan eficientemente.
152
El módulo contiene soluciones para tiendas de autoservicio, lo que permite ahorrar cajeros y por
lo tanto brindar un servicio más económico.
Por otra parte permite, en los casos que se desee, registrar datos sobre los clientes de tal forma
que se puedan organizar campañas especializadas dirigidas a los mismos.
153
8.3.3 Presentación de los resultados
Desde el punto de vista de interfaz con los usuarios los módulos de Odoo permiten la presentación
de los documentos que trata utilizando las siguietes seis vistas:
 Calendario.
La vista calendario presenta los datos de un documento en una hoja de calendario mensual, en la
que se distribuyen los datos existentes en el documento, por ejemplo: vencimientos de pagos a
realizar o a recibir, actividades previstas en una campaña de promoción, reuniones a efectuar con
un cliente o por parte de un empleado, etc. (ver figura 8.3.2 vista calendario)
Figura 8.3.2 vista calendario tomado de 52
 Diagrama de Gantt.
Los documentos que contienen pasos a realizar programados en el tiempo pueden presentarse de
forma favorable utilizando la vista de diagramas de Gantt. (ver figura 8.3.3 vista diagrama de
Gantt)
154
Figura 8.3.3 vista diagrama de Gantt tomado de 52
 Tablero de mando con gráfico
Los tableros de mando permiten tener toda la información relevante para un directivo en un sólo
cuadro junto con la representación gráfica de los indicadores que se seleccionen. (ver figura
8.3.4vista tablero de mando)
Figura 8.3.4 vista tablero de mando tomado de 52
155
 Lista y búsqueda.
La vista de los documentos de lista y búsqueda presenta todos los items de un documento y
permite filtrarlos según los criterios que estén disponibles en el mismo con el objetivo de buscar
diferentes subgrupos de los datos del documento. (ver figura 8.3.5 vista de lista y búsqueda).
Figura 8.3.5 vista de lista y búsqueda tomado de 52
 Vista Kanban. La vista Kanban presenta los datos de un documento siguiendo los diagramas
propios de esa tecnología. (ver figura 8.3.6 vista Kanban)
Figura 8.3.6 vista Kanaban tomado de 52
 Vista de procesos.
156
La vista de procesos permite mostrar fljujos de trabajo que contienen procesos que se
interrelacionan. (ver Figura 8.3.7 vista de procesos).
Figura 8.3.7 Vista de procesos. Tomado de 52
157
8.3.4 Metodología para el desarrollo de una aplicación
Desde el punto de vista metodológico la tecnología utilizada por Odoo, basada funsamentalmente
en serviciso web, facilita realizar una aplicación determinada utilizando lo que se conoce como
metodología de espiral.
La metodología en espiral se basa en la realización de las etapas clásicas de la metodología de

cascada (levantamiento de requisitos, diseño, implementación, despliegue y mantenimiento) de
forma repetitiva, aumentando siempre los objetivos a cumplir en cada iteración de forma
incremental. (ver Cuadro 8.3.2 metodologías cascadaa y espiral).
METODOLOGÍA EN CASCADA METODOLOGÍA EN ESPIRAL
REQUISITOS
REQUISITOS REQUISITOS
DISEÑO
IMPLEMENTACIÓN REQUISITOS
MANTENIM. MANTENIM. DISEÑO
DESPLIEGUE DISEÑO
MANTENIMIENTO
DESPLIEGUE
IMPLEMENT.
DESPLIEGUE
IMPLEMENT.
Cuadro 8.3.2 metodologías en cascada y en espiral. Elaboración propia
Este enfoque metodológico permite acortar el plazo inicial de implantación, al lograr el

funcionamiento en una priimera etapa de los componentes básicos del sistema, los que se van
ampliando en iteraciones sucesivas, aumentando en cada paso el valor agregado del sistema.
Se estima que una implantación total de un ERP puede tomar entre 9 meses y 3 años. Con esta
metodología, si bien no necesariamente se disminuye el tiempo total de implantación, se pueden
ir obtenindo resultados intermedios desde muy temprano.
En los casos en que la implantación de un sistema demora varios años sin brindar resultados
prácticos, la probabilidad de que por múltiples razones, comenzando por el envejecimiento de los
requisitos definidos inicialemte, cuando se vaya a implantar no se obtengan los resultados
esperados es muy alta. El enfoque metodológico en espiral disminuye considerablemente este
riesgo, al brindar resultados de forma escalonada en plazos mucho más cortos.
158
8.3.5 Aspectos financieros del uso de Odoo
Muchos se preguntan de donde salen los fondos para que miles de personas altamente calificadas
trabajen en un proyecto como Odoo. La respuesta es que estas personas reciben pagos por sus
servicios de distintas fuentes.
En primer lugar tanto Odoo S.A., como el colectivo de diseñadores y realizadores que existe a nivel
mundial para el desarrollo de este proyecto, si bien no cobran una licencia por el uso del software,
si cobran los servicios de consultoría necesarios para que un sistema como este pueda entrar en
funcionamiento y mantenga su vitalidad en cualquier entidad.
El trabajo de consultoría requiere, por una parte, de un conocimiento profundo del software y la
tecnología que soporta a Odoo, y por otra, las habilidades propias de especialistas en gestión
empresarial y ventas de proyectos.
La formación de los usuarios del sistema, como parte de la consultoría para la implantación del
sistema o de forma independiente para otros desarrolladores o empresas que ya están
involucradas en el proyecto y demandan mayores conocimientos de su personal propio, es otra de
las fuentes de ingresos de estos colectivos.
Por último, la prestación de servicios integrales de desarrollo y procesamiento de datos, lo que se

conoce como venta de software como un servicio (Saas por sus siglas en ingles), ha ido ganando
fuerza para la empresa Odoo S.A. en los últimos años.
Desde el punto de vista de costo total de propiedad (TCO por sus siglas en inglés) se estima que un
proyecto completo, para empresas medianas con igualdad de requerimientos cuesta, utilizando
Odoo, en un período de 5 años, un 65% de lo que costaría utilizando SAP (ver xxx).
159
160
8.4 SISCONT
8.4.1 INTRODUCCIÓN
La historia del SISCONT comienza en el año 1985 cuando nace como un Sistema Uniforme de
Contabilidad Automatizado, el cual ha permitido durante todos estos años, que toda la
información contable que se desarrolla en el Ministerio de la Industria Básica se realice sobre una
base uniforme, posibilitando que los análisis a los distintos niveles se puedan realizar bajo los
mismos criterios de consolidación o desagregación, con la fortaleza además de mantener
actualizada la contabilidad con todos los cambios que durante los últimos 30 años se han operado
en la Economía Nacional.
SISCONT es el producto insigne de Tecnomática, y actualmente es usado por más de 800 centros
contables
SISCONT5 es la versión actual del producto que está debidamente certificado por la Agencia de
Control y Supervisión del MIC y el MEP según la resolución 02-08 del 2 de febrero del 2008
emitida por la citada agencia lo que permite su uso en el territorio nacional.
Este Software está orientado específicamente a la gestión de los procesos contables financieros
de una empresa u organización, y es capaz de integrarse con sistemas y aplicaciones de clientes
que requieran o procesen información contable.
El Sistema es altamente parametrizable, lo que facilita la adecuación del producto a las

necesidades específicas de cada usuario.
161
8.4.2 Módulos que lo componen
El SISCONT5 Está compuesto por los siguientes módulos funcionales:
• Módulo Superior: Este módulo es para entidades rectoras y permite definir los aspectos
mínimos que tienen que ser aplicados en todas las entidades subordinadas de su sistema que
por sus características, permitirán posteriormente consolidar información resumen a este
nivel.
• Módulo de Administración: Abarca las funciones de seguridad y auditoría que corresponden
al rol del Administrador del sistema.
• Módulo General: Contiene los datos generales de la entidad y los parámetros más generales
del sistema para su funcionamiento en la entidad.
• Contabilidad General: Incluye las funciones clásicas en la contabilidad financiera, tales como:
Definición del clasificador de cuentas, apertura de los saldos al inicio de la aplicación del
SISCONT, cuadre del Balance de Comprobación, captación de comprobantes y su tratamiento
posterior hasta tanto queden completamente listos para su posteo al Mayor y saldos de cada
una de las cuentas permanentemente actualizado en función de los comprobantes posteados.
Incluye un buen número de reportes impresos requeridos por los Principios Generalmente
Aceptados de la Contabilidad de Cuba.
• Contabilidad de Costo: Brinda la información de los gastos por subelementos de cada uno de
los objetos de costo, permite hacer los diferentes procesos de cierre de costo como son Costo
Conjunto, Distribución de Gastos Indirectos, Traspaso, Órdenes de Mantenimiento, de
Servicios y de Producción, Producción Equivalente, Terminada y Vendida. Incluye el cálculo de
los costos unitarios mostrándose los mismos en la Ficha de Costo.
• Estados Financieros: Prepara los Estados Financieros de la entidad, cuenta con un generador
de plantillas para la definición de modelos de Estados Financieros oficiales del país e internos
de la entidad, permite obtener información de los Balances o del mayor, de la forma y con la
periodicidad requerida. Incorpora el tratamiento de multimoneda, permitiendo obtener los
Balances y Estados Financieros en diferentes monedas.
• Activos Fijos Tangibles: Trata toda la información referida al Sub Mayor de Activos Fijos de la
entidad, garantizando el cuadre permanente con las respectivas cuentas de la Contabilidad
General. Calcula y aplica la depreciación mensual a los activos fijos y avisa cuando el medio ha
llegado al final de su vida útil de acuerdo con su valor residual contable.
• Cobros y Pagos: Muy vinculado con los módulos de Activos Fijos e Inventario en este módulo
se controlan los saldos a cobrar y pagar con clientes y suministradores en dos monedas (MLC y
CUP) y Multimoneda. También gestiona los Pagos Anticipados, los Cobros Anticipados,
Préstamos y la Conciliación Bancaria.
• Inventario: Opera toda la información referida al Sub mayor de Inventarios de la entidad,
garantizando el cuadre permanente con las respectivas cuentas de la Contabilidad General. El
sistema está preparado para controlar el saldo de cada material en dos monedas, a partir de
los procedimientos vigentes en el país en cuanto a política monetaria. Permite el tratamiento
de las contabilizaciones de forma transaccional, por resúmenes diarios o de forma
162
personalizada según se defina por parámetros. Incorpora tratamiento de lotes a los productos
y dos tipos de valoración de las cuentas FIFO y Promedio Ponderado.
• Útiles y Herramientas: Opera toda la información referida al Sub mayor de Útiles y
Herramientas. Permite el tratamiento de las contabilizaciones de forma transaccional así como
su control físico.
• Nómina: Permite la elaboración de las Nóminas de Salarios en sus diferentes formas de pagos:
a tiempo, destajo, vacaciones, subsidios, estimulación en divisas, salarios no reclamados tanto
en divisa como en moneda nacional, permite efectuar los descuentos por los diferentes
conceptos de retenciones, incluye el procesamiento de la información para el pago por Tarjeta
Magnética. Mantiene actualizado el Registro de Salarios y Tiempo de Servicios, así como los
SubMayores de Vacaciones y Salarios No Reclamados.
• Control de Almacén: Permite gestionar todos los procesos de operaciones en el almacén,
generando los documentos primarios para su posterior contabilización.
• Módulo Integrador de Nómina con sistemas de Recursos Humanos: Permite realizar el enlace
del sistema de recursos humanos existente en la entidad con los módulos de nómina del
Siscont5.
• Sispre: Sistema para el control del presupuesto y la generación de los planes.
• Módulo Gerencial: Sistema generador de reportes, totalmente parametrizable.
SISCONT5 con sus subsistemas posee otra característica importante; está preparado para
integrarse tributando o recibiendo información de otros sistemas realizados por Tecnomática,
otras empresas cubanas e incluso empresas extranjeras. Se han desarrollado herramientas para
facilitar la conversión de los datos a los clientes que migran de otros sistemas contables a
SISCONT5, así como otras que permiten cambios masivos de cuentas, clasificadores de productos,
etc. (ver figura 8.4.1)
163
Figura 8.4.1 Interrelaciones del SISCONT. Elaborado por Tecnomática.
Los sistemas que se integran a SISCONT5 son:
SIPOBAS: Sistema para el control y promoción de Productos Ociosos y de lento Movimiento.

Creado y comercializado por Tecnomática. SIPOBAS toma los datos de los productos declarados
ociosos dentro de SISCONT. Se brinda como servicio vía web o se puede comercializar a aquellas
entidades que desean hospedarlo en su red privada.
MISTRAL es un sistema especializado en control de almacén, importaciones, taller y otros aspectos

de interés para la gestión empresarial que fue creado y es comercializado en Cuba por una entidad
no cubana, está totalmente integrado al SISCONT evitando la duplicidad de datos. Tecnomática
brinda soporte técnico para este sistema en acuerdo con la empresa productora.
SGESTMAN: es un sistema especializado en la actividad de mantenimiento, es muy difundido en la
164
industria cubana y se integra con SISCONT a través de las órdenes de mantenimiento.
Igualmente ASSETS es un Sistemas de Gestión Económica no cubano pero de uso muy frecuente
en el país, SISCONT ha trabajado para que las empresas que lo utilicen interactúen sus datos con
él.
SIGERH y SAGREH son Sistema de Gestión de los Recursos Humanos, creados y comercializados
por UNE y SerConi de CubaNiquel, respectivamente, logrando la compatibilización con SISCONT5 a
través de una aplicación integradora desarrollada por Tecnomática.
165
8.4.3 Tecnología
SISCONT 5 es un sistema cliente servidor con base de datos de MS SQL 2000, cuenta con una
interface Windows con diseño estándar y un funcionamiento uniforme en los módulos.
La información se encuentra protegida ante acceso ilegal y cuenta con opciones de salva y
restaura, así como permite la creación de perfiles para el acceso a las diferentes funcionalidades
del sistema. Además cuenta con una bitácora donde se guardan todas las operaciones realizadas
en el sistema por cada usuario
SISCONT 5 – SEGURO
SEGURO: tendrá un control de acceso y asignación de derechos a
acciones por usuarios, también deberá garantizar la integridad,
disponibilidad y veracidad de los datos.
Figura 8.4.2 Esquema de seguridad del SISCONT5
166
SISCONT 5 – SEGURO
SEGURO: tendrá un control de acceso y asignación de derechos a
acciones por usuarios, también garantizará la integridad,
disponibilidad y veracidad de los datos.
CodAlmac CodAr Cantid Reserv

en CodProducto ea ad a CRC
999 732.1.04.0366 00000 199 0 1084.048403
999
CRC horizontal
732.1.04.0374 00000
=190fx(campos)
0 1059.251131
732.1.04.0374.
999 01 00000 296 0 1074.215368
999 732.1.04.0375 00000 200 0 1086.76873
999 732.1.04.0376 00000 200 0 1086.76873
999 732.1.04.0379 00000 195 0 1073.098139
999 732.1.04.0382 00000 200 0 1086.76873
999 732.1.04.0383 00000 195 0 1073.098139
CRC vertical = fx(columnas)
Figura 8.4.3 Control de acceso al SISCONT
SISCONT 5
REQUISITOS PRINCIPALES
• MODULAR
• SEGURO
• ABIERTO
• MULTIMONEDA
• DOBLE MONEDA
• PARAMETRIZABLE
• AMIGABLE Y FACIL DE USAR
• AUDITABLE
• CONSOLIDACIÓN DE LA INFORMACIÓN
Figura 8.4.4 Requisitos principales
167
8.4.4 Requerimientos mínimos de software y hardware
Cliente:
 Sistema Operativo Windows 2000, XP o Vista.

 Pentium 1.6 GHz, 512 MB RAM, 1 GB de HDD.
Servidor:
 Sistema Operativo Windows 2000 Server o cualquiera que soporte SQL 2000, 2005 y 2008.
 DBMS: MS SQL Server 2000.
 Pentium 1.8 GHz, 1 GB RAM, 20 GB de HDD, torre de CD.
8.4.5 Interfaces con otros productos
SISCONT 5 permite el intercambio de información con otros sistemas o aplicaciones a partir de la

importación y exportación de información, o a través de un conjunto de WebServices que tienen
dicha funcionalidad. Existen diferentes vías de exportación en el sistema que pueden ser utilizadas
por sistemas y aplicaciones externas, estas son:
 Se exporta toda la base de datos en formato de MS Access.

 Se exportan informaciones de los subsistemas en formato de MS Excel.
 Se exportan los Estados Financieros y los Balances en formato XML.
 Consumo de WebServices del sistema.
Además, de estas vías se puede acceder y leer información directamente utilizando el DSN llamado
S5F1, el cual da acceso de lectura a la base de datos.
La importación de información al sistema se realiza a través de ficheros en formato XML, entre las
importaciones que se admiten están:
 DPA: División Política Administrativa.

 CAE: Código de las Actividades Económicas de las entidades.
 REUP: Registro de Empresas.
 Subgrupos Contables
 Elementos del Gasto
 Nomenclador de Cuentas
 Comprobantes provenientes de sistemas externos.
 Información de Costo y Gastos.
 Balances de Comprobación y Estados Financieros para consolidar.
 Movimientos de Inventarios que provengan de un sistema de Control de Almacenes.
 Datos del Banco para el Pago por Tarjeta Magnética.
 Consumo de WebServices del sistema.
168
8.4.6 Instalación y Componentes de entrega
El SISCONT 5 se entrega en un CD, el cual contiene los siguientes elementos:
 Documentación:
o Manuales de Usuarios
o Demos.
o Instrucciones de instalación.
o Requerimientos del sistema.
 Instaladores:
o Asistente para la creación de la Base de Datos.
o Asistente para la creación del DSN y registro de dll.
o Asistente para el registro de la conexión a la base de datos.
o Asistente para la instalación local.
o Asistente para la instalación en red.
El SISCONT 5 acepta dos tipos de instalaciones:
o Instalación local: Es cuando en cada pc cliente se instala el sistema.

o Instalación en red: Es cuando se instala el sistema en un servidor de aplicaciones y todas
las pc clientes se sirven del servidor.
Para la instalación del sistema solo requiere que se tenga ya instalado el servidor SQL donde se
creará la base de datos.
8.4.7 Soporte y Mantenimiento
El Sistema consta con servicio de Consultoría y Soporte al Cliente tanto en la parte informática
como en la parte funcional del sistema.
La Consultoría es la encargada de realizar la parametrización del sistema según las características

de la entidad cliente.
El Soporte al Cliente cuenta entre sus funciones la capacitación al personal y la atención a los
problemas que se presenten por parte del cliente en la explotación del sistema.
SISCONT 5 es un sistema en constante desarrollo y mejora, la instalación de las mismas se logra a

través de un asistente que automáticamente actualiza los programas y la estructura de la base de
datos.
169
También como elemento de Soporte al Cliente se cuenta con un sitio web de trabajo, a través del
cual los clientes pueden acceder a noticias, elementos de capacitación, de actualización del
sistema, etc.
La dirección del sitio es http://siscont.tm.minbas.cu
170
Bibliografía
1. The A.C.I.D. Model

http://databases.about.com/od/specificproducts/a/acid.htm
2. Biography of Lucas Pacioli
Artículo de J J O'Connor y E F Robertson
http://www-groups.dcs.st-and.ac.uk/history/Biographies/Pacioli.html
3. Traducción de Particularis de Computis et Scripturis
http://archive.org/stream/ancientdoubleent00geijuoft/ancientdoubleent00geijuoft_djvu.txt
4. Herman Hollerith: Data Processing Pioneer
William R. Aul
Think, November 1972
http://www-03.ibm.com/ibm/history/exhibits/builders/builders_hollerith.html
5. Historia y características del RPG
http://en/wikipedia.org/wiki/IBM_RPG
6. Response time in man-computer conversational transactions
Robert B. Miller, IBM Poughkeepsie, New York
Fall Joint Computer Conference, 1968
http://theixdlibrary.com/pdf/Miller1968.pdf
7. A Relational Model of Data for Large Shared Data Banks –SEAS
E.F. Codd, IBM Research Laboratory, San Jose, California
Communications of the ACM,
Volume 12, Número 6, Junio 1970
www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
8. UNIX Past
http://www.unix.org/what_is_unix/history_timeline.html
9. The History of the IBM Personal Computer
Marzo 2011, John Koenig
http://computemagazine.com/the-history-of-the-ibm-personal-computer/
10. Desarrollo del protocolo TCP/IP
http://www.cs.utexas.edu/users/chris/think/Early_Days_Of_TCP/index.shtml
11. Desarrollo de las fibras ópticas
http://www.fiber-optics.info/history/history/
12. Ley de Moore
http://www.mooreslaw.org/
13. Carta de los jefes ejecutivos (CEOs) de SAP, Informe anual 2011
http://www.sapannualreport.com/2011/en
14. Carta a los accionistas, clientes, colaboradores y empleados. Informe anual 2011 de Microsoft
http://www.microsoft.com/investor/reports/ar11/index.html
15. Carta del presidente y jefe ejecutivo (CEO) de IBM, informe anual de 2011 IBM
http://www.ibm.com/investor/pdf/2011_ibm_annual.pdf
16. Infraestructura inteligente, artículo de HP
http://www.hpl.hp.com/research/intelligent_infrastructure.html
17. ACM seminario 2012, índice
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=6167332
171
18. Intel reporte anual 2011, riesgos
www.intc.com/intelAR2011
19. Medios de Pago
Dr. Jorge Barrera Ortega
Editorial UH
2013
20. SWIFT in figures
www.swift.com
21. The Bolero Rulebook
www.bolero.net/en/Newsdownloads/articlesordownloads.aspx
22. Bolero Solutions Overview
www.bolero.net/en/solutions/Overview.aspx
23. OSI Reference Model – The ISO Model of Architecture for Open System Interconection
Zimmermann, Hubert
IEEE Transactions on Communications 28 (4)
Abril 1980
Páginas 425 – 432
24. Data Mining: What is Data Mining ?
http://www.anderson.ucla.edu/faculty/jason.frand/teacher/technologies/palace/datamining.htm
25. UN/EDIFACT documentación
http://www.unece.org/trade/untdid/welcome.html
26. Especificaciones técnicas del iPhone 6
www.apple.com/iphone/specs
27. Especificaciones técnicas del iPad
www.apple.com/ipad/specs
28. Readings in Database Systems
4th edition
Joseph M. Hellerstein and Michael Stonebraker
The MIT Press
Cambridge, Massachusetts
29. The Entity-Relationship Model - Toward a Unified View of Data.
Peter P. Chen
ACM Transactions on Database Systems 1(1),
1976 Pag. 9-36
30. Logical Design and Schema Conversion for Relational and DBTG Databases.
Eugene Wong, R. H. Katz
Entity-Relationship Approach to System Analysis and Design
Proc. 1st International Conference on the Entity-Relationship Approach
North Holland, 1979 Pag. 311-322
31. Top 10 Enterprise Database Systems to Consider
Kenneth Hess, mayo 20 2010
http://www.serverwatch.com/trends/article.php/3883441/Top-10-Enterprise-Database-Systems-to-
Consider.htm
32. Aplicación del enfoque sistémico a la automatización de la elaboración del plan de la economía
nacional utilizando las técnicas de bancos de datos y el diálogo hombre – máquina.
172
Barrera J., Ortiz E. y Zamora V.
Ponencia al Seminario del Instituto de Matemática Aplicada y Computación de la Academia de
Ciencias de Cuba,.
La Habana, Marzo 1982
33. Una aplicación del modelo relacional en la base de datos del sistema unificado de
procesamiento del plan.
Barrera J., Ortiz E. y Hernández L.
Economía Planificada No. 2,
La Habana, Marzo 1980
34. SACP Sistema automatizado de cálculos del plan
Lebedinsky N.P. y otros
Editorial Económica,
Moscú 1980
35. An Overview of Different Authentication Methods and Protocols
Richard Duncan,
Octubre 23,2001
http://www.sans.org/reading_room/whitepapers/authentication/overview-authentication-
methods-protocols_118
36. Understanding and selecting authentication methods
Deb Shinder
Agosto 28, 2001
http://www.techrepublic.com/article/understanding-and-selecting-authentication-
METHODS/1060518
38. X12 EDI Transactions sets

www.x12.org/x12org/docs/EDITransactions.pdf
39. Banking Industry Architecture Network (BIAN)
www.bian.org
40. An overview of enterprise resource planning
The Institute of Chartered accountants of India
220.227.161.86/21489sm_finalnew_isca_vol2_cp7.pdf
41. Registro y análisis de los activos y pasivos que modifican su valor
Revista del Banco Central, La Habana
Año 9 No. 2 trimestre abril – junio 2006. ISSN 1560-795X
42. GESTIÓN DE SISTEMAS DE INFORMACIÓN
Universidad de Deusto - Facultad de Ingeniería
Antonio Toledo Carnicero y Pablo Pérez Pérez
Octubre de 2004
43. SAP R/3 HANDBOOK
Second edition
McGraw-Hill. 2000
José Antonio Hernández
44. Procesos de negocios en SAP V 1.0
Manuales y tutoriales
09/03/2007
www.mundosap.com
45. SAP Supplier Relationship Management (SAP SRM)
173
www.sap.com/srm
46. SAP Supply Network Collaboration (SAP SNC) Overview
www.sap.com/snc
47. SAP Supply Chain Management (SAP SCM)
www.sap.com/scm
48. SAP NetWeaver For Dummies
By Dan Woods and Jeffrey Word
John Wiley & Sons, 2004
49. SAP-2013-annual-report
global.sap.com/corporate-en/investors/pdf/sap-2013-annual-report.pdf
50. SAP integrated report
www.sapintegratedreport.com/
51. OpenERP, a modern approach to integrated business management Release 6.0.0
Fabien Pinckaers, Geoff Gardiner, Els Van Vossel
2011
es.slideshare.net/arcanetdeveloper/openerp-book-version-61
52. OpenERP evaluation with SAP as reference
Yves Delsart & Christelle Van Nieuwenhuysen
Feridis SA
2011
www.infostream.co.me/content/odoo_vs_sap.pdf
53. Odoo (OpenERP)
www.giordano.ch/Produkte/odoo.aspx
174

Libro SISTEMAS AUTOMATIZADOS DE CONTABILIDAD

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro SISTEMAS AUTOMATIZADOS DE CONTABILIDAD

Título original:

Cargado por

Copyright:

Formatos disponibles

SISTEMAS AUTOMATIZADOS

Dr. Jorge Barrera Ortega

2.1 Contenido del ciclo contable

 Recepción del documento primario

Definición de cuentas a afectar

Archivo de documento CARTERAS

Depuración de errores Registro en mayor MAYOR

Conciliación de estados de cuenta

Cuadro 2.1 Esquema del flujo contable Elaboración propia

2.2 La recepción del documento primario

Cuadro 2.2 Recepción de documento primario. Elaboración propia

Llevar un registro de entrada de los documentos primarios recibidos, en el que se le dé un número

2.3 La definición de las cuentas a afectar

Escaque x -> Cuenta 1 / Signo

Cuadro 2.3 Definición de las cuentas a afectar. Elaboración propia

Cuadro 2.4 Maqueta de contabilización de una factura. Elaboración propia

2.4 El registro en el libro diario

1/1/2012 Cuentas por cobrar Factura 1 10000

Cuadro 2.5 Registrar en el diario. Elaboración propia

2.5 El archivo del documento primario

Cuadro 2.6 Archivo de documentos primarios. Elaboración propia

2.6 La gestión de activos y pasivos pendientes

1/1/2012 Efectivo TPV 12 5432.34

Mayor Ingresos por ventas

Mayor Cuentas por cobrar

Cuadro 2.7 Registro en mayores. Elaboración propia

2.8 La conciliación de los estados de cuenta

2.9 El balance de comprobación

Emitir Balance de Comprobación

Mayor Cuentas por cobrar

Total 0 XXXXX XXXXX 0

Cuadro 2.8 Emitir balance de comprobación. Elaboración propia

2.10 La depuración de errores

2.11 La emisión de los estados financieros

3.1 Producir un diario en soporte electrónico

El principal efecto de este primer paso de la automatización de la contabilidad fue la eliminación

Definición de cuentas a afectar Gestión de carteras

Registro en mayor MAYORES

Conciliación de estados de cuenta

Cuadro 3.1 PRIMER NIVEL DE AUTOMATIZACIÓN. Elaboración propia

En este primer estadio de la automatización, el registro en el diario se continuaba haciendo

Registro en el diario Gestión de carteras

Depuración de errores Registro en mayor MAYORES

Conciliación de estados de cuenta

Cuadro 3.2 SEGUNDO NIVEL DE AUTOMATIZACIÓN. Elaboración propia

3.3 Recepción de documentos primarios en soportes electrónicos

Registro en el diario Gestión de carteras

Registro en mayor MAYORES

Conciliación de estados de cuenta

Cuadro 3.3 TERCER NIVEL DE AUTOMATIZACIÓN. Elaboración propia

3.4 Integración del SAC en un ERP

Cuadro 3.4 ESQUEMA DE SAP/R3. (tomado de 43)

3.5 Interacción con otros sistemas automatizados

REGISTRO Recepción documento primario DOCUMENTOS

Registro en el diario Gestión de carteras

Depuración de errores Registro en mayor MAYORES AUTO-

cuadro 3.5 QUINTO NIVEL AUTOMATIZACIÓN. Elaboración propia

En la realidad actual de Cuba, la mayor parte de los sistemas contables automatizados,

 EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport)

4.1 Surgimiento de la contabilidad actual

Su principal obra, llamada “Summa de Arithmetica, Geometrica, Proportione et Proportionalita”,

• La ecuación fundamental de la contabilidad