Database programa contabilidad

[Alessio Pesce]

Para un programa de contabilidad, ¿cómo administra las tablas de los diferentes ejercicios contables?
En el pasado creé tablas para cada año con una indicación del año en el interior. Ej: piaconti18.

Solución faragaginosa.
¿Qué solución usas?

[mapner]

1)
Si usas DBFs, un directorio/carpeta por ejercicio
2)
Si usas un motor SQL C/S, un solo juego de tablas con un campo ejercicio AAAA

...
DBFs, hace tiempo ya desaconsejadas

[Carlos Miguel FARIAS]

En un sistema de contabilidad necesitas:

Una tabla para el plan de cuentas. Numero de cuenta (codificación numérica jerárquica), nombre de cuenta, si es cuenta sumaria o contenedora (debe tener otras cuentas de jerarquía menor incluidas), nombre de cuenta, cualquier otra información que se use por ejemplo para ayudar al tenedor de libros (registrador).

Una tabla para las cabeceras de asiento, allí se guarda la fecha, el número de asiento (los asientos numerados, consecutivos, no pueden saltear números). Además del número va la fecha, que siempre debe ser igual o mayor que la anterior (la hora en principio no es necesaria, pero no sería mala idea incluir). Condición del asiento, abierto o cerrado. En principio, no debería haber más de un asiento abierto. Otros datos del asiento como origen del asiento (documento asociado), y otras observaciones que se consideren de interés.

Recuerden que los asientos no se borran, si a un asiento se le asignó número, el mismo debe guardarse y anularse con un contraasiento.

Una tercera tabla incluir la relación entre cuentas y asientos (en un asiento, una cuenta puede figurar una sola vez, pero un asiento debe hacer referencia a 2 o más cuentas, además del id. cuenta e id. asiento debes tener el importe afectado a la cuenta, no hace falta dos columnas como he visto que se usa, con una sola columna de importe determinas débitos (valores positivos) o créditos (valores negativos). Facilita mucho el manejo y control. Los débitos y créditos de un asiento deben sumar lo mismo (o sea que débitos - créditos = cero), por lo que con una simple suma de los débitos y créditos detectas si el asiento "cuadra". La misma operación sobre la tabla te tiene que dar cero. Es el principio de control de la partida doble.

En el caso de que una cuenta tenga muchos movimientos, o necesite información adicional a la que es estándar para todas las cuentas, suele usarse lo que se llama un sub-diario. Que es como un sistema de contabilidad donde siempre en los débitos o créditos una cuenta interviene (por ejemplo caja: Se debita por ingresos de efectivo, débito automático, etc. y se acredita por pagos a terceros, vueltos, etc.). Luego periódicamente (al menos una vez al día) se transfieren los asientos al diario principal.

Eso es a grandes rasgos lo que necesitas para un sistema de contabilidad.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la fuerza te acompañe, si usas campos flotantes para los importes, estás en el lado oscuro de la contabilidad

[Newbie]

Si entiendo bien tu pregunta, creo que es mas sencillo que los colegas exponen.

1.- Si la contabilidad utilizada es multi-empresa, YO creo una DB completa por empresa.

2.- Si es para una sola empresa, lo YO hago es simple tengo una tabla de gestiones, que incluso te ayuda a BLOQUEAR periodos, donde uno de lo campos más importantes es, justo uno que puedes llamar GESTION o PERIODO contable

y en las tablas que usas para guardar los movimientos contables, le pones un identificador que te relaciones con tu tabla GESTION o PERIODO contable.

Creo que es eso lo que buscas.

No te olvides el feedback es importante para saber si lo que te dicen tus compañeros  es correcto.!

[Newbie]

MAPNER, el peligro de tener un solo juego (claro si estamos hablando de multi-empresas) es que si se te arruina la DB, se te van infierno todas las empresas.

[Carlos Miguel FARIAS]

Mapner dice que crea una bd por empresa (las pone en carpetas por separado, le permite agregar seguridad adicional de sistema operativo). O sea que si va al cuerno una bd, solo pierde una empresa.

En el modelo que planteo de 3 tablas, es lo mínimo que puedes tener normalizado. Como el asiento debe tener la fecha , sacas cada periodo por el año, no hace falta meter ninguna tabla de periodos.

En cuanto a los sistemas multiempresa, meter todo junto en una bd es un problema gravísimo. Porque si te cae una inspección del órgano fiscalizador (AFIP, SUNAT, etc.) porque están investigando una de las empresas, tienen el derecho de llevarse los datos de la empresa y si está con datos de otras empresas se llevan todo y las empresas no involucradas en la inspección, se someten a una inspección porque quedan expuestas sin tener nada que ver.

Saludos: Miguel

[Alessio Pesce]

Perdoname ma no entiendo Como lo hace. Puedes hacer un ejemplo?

[Carlos Miguel FARIAS]

Para quien es la pregunta?

[mapner]

Newbie, si lees lo que escribí, lo de poner todo en una misma BD lo sugiero para motores SQL C/S (cliente/servidor) que son BD robustas que no se "arruinan" fácilmente como los DBFs y a la vez, se supone que se cuenta con un buen backup.
Trabajo hace más de 20 años con esa modalidad y no he tenido problemas.

[alessio pesce]

Carlos y Marpner
   

[alessio pesce]

Poner todo in una carpeta, 
Se puede hacer, lo que pasa es que no puedo veer todo Los movimientos de mas anos. 

Si utilizo mas carpetas cada ves sierro El Db cose database... Set path distinto y apro diferentes Db. Justo?   

   

[mapner]

Miguel,

sobre lo de exponer una o varias empresas a una inspección. Lo que decís es que te pidan los soportes de BD para inspeccionar. Pues bien, he visto inspecciones donde secuestran el servidor completo con lo que tenga adentro, por lo cual ahí la teoría de una base o varias separadas no sirve para nada ya que se llevan hasta las fotos de las vacaciones en Cancún. O sea, según lo que decís se debería tener no solo BD separadas sino servidores separados y hasta en domicilios diferentes? Por otro lado, si las empresas llevan las cosas como corresponde, cual es el problema que se lleven una, dos o diez bases de datos, salvo que haya información non sancta, con lo cual ahí sí la empresa y el desarrollador que da soporte, están en graves problemas... Saludos.

[Carlos Miguel FARIAS]

Mapner, es cierto lo que dices, pero si el que audita las bases no interpreta bien el modelo puede estar mezclando transacciones de empresas.

Por supuesto que las empresas no inspeccionadas en principio si no son honestos debería pagar las consecuencias.

Pero igual entiendo que se le agrega una complejidad al sistema, porque tienes que aislar todos los datos (plan de cuentas, diarios, clientes, productos, documentos, etc.) Todos los datos deben diferenciarse. En cada tabla tienes que agregar una columna que indique de empresa es, a lo sumo safas de los datos públicos, (Códigos postales, ciudades, coeficientes varios) pero los otros datos no.

Si tu aplicación permite que el usuario arme consultas sobre la bd y hay un error u omisión de filtrar por empresa, podes llegar a tener problemas legales, porque una empresa está accediendo a los datos de otra (y a lo mejor sin querer, y produciendo reportes erróneos).

Si soy auditor de la empresa (tengo incumbencias), lo informo con un punto de inseguridad.

Saludos: Miguel

[mapner]

En realidad, todo ERP que se precie debe tener la condición MULTI (multi-empresa, multi-ejercicio, multi-almacén, multi-monedea, ...)

Empresa pasa a ser un atributo más de entidades y transacciones y obviamente hay que ser más que cuidados con el filtro en los SQL SELECT-WHERE  porque se puede meter la pata, pero es el mismo cuidado que se debe tener para montones de otros filtros como por ejemplo las cuentas, los clientes, proveedores, etc...

Para el caso de algunas entidades como ser Terceros (Clientes, Proveedores, Vendedores, etc...) la relación con Empresa no es 1 a 1, sino 1 a muchos (1:N), o sea un proveedor o cualquier entidad similar puede atender a más de una Empresa registrada.

Hay un ERP Open Source que ya tiene algunos años y del que han salido diferentes forks renombrados, ese ERP es Compiere y si lo estudian un poco verán como está planteado el diseño MULTI.

Saludos

[Antonio Meza]

En mis inicios cree un sistema multiempresa usando DBF y todas las empresas en un solo contenedor de tablas DBC, arrepentido totalmente !!! jajajaja 

Ahora uso MariaDb (antes Mysql) tengo una base de datos por empresa dentro del mismo servidor.

El principal motivo es el rendimiento, hay empresas que tienen muy pocos movimientos y tienes que filtrar registros de cientos de miles de otras empresas para poder mostrar unos pocos movimientos de la empresa mas pequeña, se me hizo absurdo totalmente y por eso y otras cosas mas separo las empresas por base de datos.

saludos

Antonio Meza

[Newbie]

Miguel, estos temas nunca son estandares, el tema tener una tabla GESTION es por que de por medio puedes habilitar a alguien para que entre y diga esta gestión no se mueve mas, sin tener que modificar codigo, para ir por las demas tablas a decir que x periodo esta "BLOQUEADO", y disculpa MAPNER no supe entender tu comentario.

[Carlos Miguel FARIAS]

Coincido con Antonio.

Mapner. Lo que dices es valedero si los datos sobre clientes y proveedores son públicos. Entonces si, re-aprovechas los datos de proveedores, etc. para todos, pero si alguna empresa quiere guardar propios o tiene clientes que no quiere que las otras empresas conozcan tienes que empezar a meter una tabla intermedia para que empresa puede ver o acceder a tal o cual o que datos.

Y entonces como tu mismo dices, comienzan los problemas de como limitas lo que cada empresa puede ver de los datos en una tabla común. Debes agregar filtros, que si en algún momento te olvidas de uno, zafarrancho.

No por algo todo junto va separado y separado todo junto

Saludos: Miguel

[Antonio Samper]

Buenas noches,

Puede utilizarse una sola base de datos y dentro de esta un schema para cada empresa, y dentro del schema tener varias empresas pero del mismo cliente, puedo tener sucursales asociadas a cada empresa dentro del schema.

--

Antonio Samper G.

Representante

SASYSTEMAS

Mail: sasys...@gmail.com

Tel  :  (57-5) 3584507Celular: 300 3974555

Barranquilla - Colombia

[Carlos Miguel FARIAS]

Una cosa son empresas (personas jurídicas independientes) y otras son sucursales, que es como "cajas" multi-cajón. Y no todas las bd manejan esquemas. Y si manejas esquemas separados, tienes la misma complejidad o  más, porque además de dar el nombre de la base de datos, tienes que indicar el esquema, y armar permisos por separado como en bd separadas.

Soluciones hay muchas, hay que ver en cada caso cual es la que mejor se adapta.

En lo personal, por razones de auditoria, no mezclaría nunca en una bd datos de diferentes empresas (jurídicamente separadas).

Cada empresa puede tener sus propios auditores internos (y externos) y cuando accedan a la bd no van a admitir que alguien les coloque un filtro que les oculte datos.

Saludos: Miguel

Saludos: Miguel

[Antonio Samper]

OK, Carlos cuando me referia a sucursales era por ejemplo a que el cliente A tiene una Empresa llamese EMPRESA 1. y esta empresa tenia ALMACENES en ciudades diferentes Almacen 1 y Almacen 2 entonces en el diseño del modelo entidad relacion tenia EMPRESA 1 - ALMACEN1, EMPRESA1 - ALMACEN2, siempre debo tener encuenta a la hora de filtrar la info la empresa y sucursal, pero dentro del mismo schema.

Saludos

[mapner]

Miguel, por eso dije que los Terceros (Clientes, Poveedores, etc..) no se conectan con las Empresas con relación tipo uno a uno (1:1), sino que se conectan con una tabla intermedia muchos a muchos (N:M). Un Proveedor puede atender a varias Empresas y una Empresa obviamente tiene varios Proveedores. Sobre son públicos o privados, es otra cosa. 

A su vez, a mi entender, esta subestimado la cantidad de tablas y la complejidad que puede adquirir una Base de Datos (lease un real SGBD C/S, no DBFs).

Quienes vienen de sistemas chicos manejados con DBFs tratarán de usar la menor cantidad de tablas posibles para mantener la complejidad del esquema en un grado manejable. Pero al pasar a un motor potente SQL C/S la cosa cambia. Cual es el problema de agregar tablas sin son necesarias y el motor lo soporta? aparte de que a la vez se puedan definir Vistas (querys predefinidos), Store Procedures y toda clase de herramientas que nos provee el SGBD?

La escala de esquemas de datos con DBFs por lo general es para pequeñas instalaciones (más allá de que alguien cuente hazañas de DBFs con millones de registros... lo que en si, es para nada recomendable). Un real SGBD no es DBFs más rápidas y más seguras. Es un software en si mismo con una capacidad y escalabilidad rara vez aprovechado en todo su potencial. Y ahí reitero, a quienes vienen directamente y sin escalas de manejar DBFs, les cuesta entender el concepto.

Saludos

[Carlos Miguel FARIAS]

Mapner: Estamos haciendo un enfoque diferente del problema. Lo que dices es correcto desde el punto de vista de normalización. No me importa en principio el tamaño de la BD (cantidad de tablas) si no que esté bien diseñada. Por lo que comentas eso lo has tenido en cuenta.

Preguntas:

La BD multi-empresa, es porque la bd está en la nube y varias empresas acceden a la misma? O es un estudio contable que lleva datos de varias empresas?

O es una empresa que lleva control sobre varias subsidiarias?

Lo que planteo desde mi punto de vista profesional (contador público) es que ante una situación de auditoria, cuando quiera analizar los datos de la empresa, y de alguna manera, al acceder a los datos, se me "niegan" datos de una base datos donde están los de la empresa que tengo que auditar, hace que ponga una nota mala en el ítem correspondiente de mi informe de auditoria.

Por eso, no cuestiono el diseño en cuanto a las buenas prácticas de análisis y programación si no desde el punto legal y la responsabilidad que le cae al ABD ante la factibilidad de que un error u omisión en los permisos de acceso de los usuarios (o aplicaciones) permita que datos "confidenciales o exclusivos" de una empresa sean accedidos por otra.

Saludos: Miguel

[mapner]

Miguel,
Tu observacion desde un punto de vista de auditoría contable me parece un poco arcaico. Hace años, una base de datos era un conjunto de archivos DBF, archivos físicos a la vista de casi todos sin ninguna protección de acceso. Luego con el auge de SGBD C/S los datos se almacenan en un esquema lógico, sin importar demasiado el soporte físico (cada motor tiene diferente forma de llevar la parte física), de hecho algunas BD permiten tener la info encriptada y solo se hace legible a quien tenga los accesos correspondientes. Ni hablar con BD almacenadas en la nube o directamente web servicios de datos en lo que no se sabe a ciencia cierta lo que hay detrás de la API. Con esto lo que quiero decir es que la forma de almacenar datos físicos, importa cada menos, ya que de eso se ocupa el motor o el servicio que toque. Por ejemplo SAP ofrece su sistema en la nube. Ante una inspección o auditoría, que se llevarían? Los servidores hosteados en Singapur?
En esto, las buenas prácticas de auditoría se deben agiornar a las tecnologias que existentes.
Saludos

[Carlos Miguel FARIAS]

No mapner. Lo que me dices de auditoria arcaica me es ofensivo. Ya en el año 2000 presente en Congreso de Contadores en Argentina la auditoria de bases de datos utilizando SQL, nada que ver con llevarme servidores, solo tener permisos de lectura de toda la base de datos (TODA LA BASE DE DATOS), y ni siquiera lo planteaba para tablas DBF. Las tablas DBF no pasan el mínimo de seguridad de auditoria. Desde el momento que puedo accederlas con cualquier aplicación (Excel XP, Libreoffice, openoffice, biblioteca python, etc.) y manipular su contenido ya pierde toda validez.

Y como auditor, justamente tengo que acceder a los datos por fuera de la aplicación (al menos si quiero hacer las cosas en serio), el acceso solo es de lectura, por lo que no afecto transacciones, pero necesito análisis de datos a bajo nivel. Cualquier cosa que se me oculte es responsabilidad de un solo tipo el Administrador de la Base de Datos.

Puede ser mi ignorancia, pero no he visto un comando GRANT que de permisos sobre parte de una tabla, y si en una tabla colocas datos de varias empresas, eso a mi criterio profesional, no sirve.

Dos cuestiones: Desde el punto de vista ético, no puede visualizar datos de una empresa que no es cliente mio. Y por ello, tampoco puedo permitir que otro profesional visualice datos de mis clientes.

No se como funciona SAP, pero no creo que tengan una BD con datos mezclados de distintas empresas. No me importa la ubicación física, si no la posibilidad de acceso lógico de los datos por parte de extraños no autorizados.

Las buenas prácticas de auditoria no tienen que agiornarse a la tecnología, la tecnología a aplicar debe ser admitida por las normas, las normas las elabora la profesión, y te puedo asegurar que están muy avanzadas.

Vos admitirías que tu mujer se acueste con medio pueblo porque es lo propone la liberación de la mujer?

Y no te excuses en que el esposo de Patricia Sosa no tiene problemas de que ella se acueste con media villa.

Saludos: Miguel

[mapner]

Miguel, para rebatir sobre si es arcaico, traes como ejemplo un congreso del año 2000? Me parece a mi, o estamos en 2018? O sea, hago las cuentas con una calculadora científica y me dan... 18 años... Arcaico... no para nada.
Si ofender, porque más allá de ponerle humor, trato de hablar con respeto.
Vos mismo lo decís, el acceso a los datos es por vía lògica, no física. Y en forma lógica vos podés estar consultando algo que no sabes si es una tabla o una vista ya prefiltrada...

[Carlos Miguel FARIAS]

Cuando lo presenté en el Congreso era casi una novedad a nivel mundial (ni te cuento en Argentina), de hecho luego aparece un lenguaje de auditoria como ACL (que usan en la Auditoria General de la Nación-Argentina). Que combina funcionalidades de SQL con planilla de cálculo. Tu computadora funciona con la técnica de "Programa almacenado", que introdujo von Neumann en la década del '40, entonces es arcaica, pero es lo que se está usando. No me descalifiques si no sabes. Y no califiques algo comparando cosas sin sentido. 18 años en informática es un aumento de 1000 veces en capacidad de proceso (1000 generaciones), en administración 18 años es media generación. Tu usas VFP y con mas de 10 años de sin evolucionar, estás arcaico más de 100 generaciones.

Un modelo mal normalizado (menos de 3ºFN), ya es motivo de "mala puntuación".

En cuanto al acceso a datos, si audito una BD, audito sobre metadatos y datos de la base de datos, y el acceso a los datos me lo deben habilitar a nivel de tablas. Si me dan acceso solo a través de vistas, ya es motivo de mala puntuación.

Si como agente de control fiscal accedo a la bd y veo datos de "varias" empresas, puedo implicar que las segundas empresas son "ficticias", usadas para ocultar operaciones ilegales (en negro como se dice en Argentina). Y la empresa inspeccionada debe salir a justificar que las otras transacciones o datos son de otra entidad jurídica, y si es otra entidad jurídica no puede acceder a la documentación para probar que las transacciones no le pertenecen.

Ten en cuenta que los organismos fiscales te meten las manos en los bolsillo de lo que declaras y en el colon como mínimo de lo que "te aparece" y no puedes probar que no es tuyo (lo hice sin querer queriendo diría Chispirito)

Te remito a https://www.errepar.com/resources/descargacontenido/CIBERCRIMEN.PDF para una introducción al tema de cibercrimen y otras llevars

Otro elemento a tener en cuenta.

Supon que tienes la bd multiempresa, una empresa se le ocurre almacenar ciertos datos (tipo, o forma) sobre sus clientes que le da una ventaja competitiva sobre otras. Y tu al adaptar las tablas, como evitas que las otras empresas aprovechen esa "idea", como evitas morirte de una sobredosis de plomo ingerida por la frente o te comes un juicio legal de acá hasta que vuelva el de los 20 siglos tan mentado.

Observa el articulo https://www.ibm.com/developerworks/ssa/webservices/library/ws-middleware/index.html, 

Saludos: Miguel, La Pampa (RA)

[mapner]

Miguel, por la extensión y virulencia de tu respuesta, te sugiero tomar un Garombol compuesto, ya que te ponés a dar cátedra extensiva e incomprobable sobre temas muy lejanos a este foro. A todo esto, si te pregunto la hora, harás una disertación sobre la historia de la relojería? Cómo dije, uso el humor para descomprimir pero sin faltar el respeto, por lo que te sugiero, cálmate y cuidá las arterias coronarias.
A todo esto, en un mensaje anterior dijiste que desconocías SAP o cómo funciona? Ok, tiempo bien invertido es ponerse a investigar cómo funciona el ERP mejor ranqueado a nivel internacional para tener un modelo de base de datos contable a gran escala.
Saludos.

[Carlos Miguel FARIAS]

Me parece que el que empezó a faltar el respeto fuistes vos. Me calificas como arcaico por un trabajo de vanguardia (en su momento). Y encima sugieres un medicamento que es más arcaico que el Chachacha. No rebates mis argumentos, solo tratas de descalificar a quien piensa distinto.

Me parece una falta de respeto al que hace una consulta elemental darle una solución compleja. Y si alguien consulta en este foro por un sistema de contabilidad, mi solución de tres tablas es suficiente, no quita que haya otras soluciones apropiadas (por supuesto, no multiempresa). 

Todos los ejemplos que dí tienen su fundamentación técnica, legal y de ética profesional (en lo que me corresponde como contador público).

Diseñe un ERP con capacidades multiempresa, pero cuando vi las implicaciones legales (como por ejemplo que ante una estafa ante la AFIP aprovechando las capacidades multiempresa del sistema podría quedar involucrado como partícipe necesario. Deseche continuar con el trabajo.

Que indiques que lo que digo es incomprobable, cuando hago referencia a documentos para que se constate

Este es un foro fox, con fox manejamos sistemas de datos relativamente pequeños, que traigas a colación el diseño de SAP me parece fuera de contexto. SAP es el nombre genérico que engloba soluciones para empresas que facturan millones de dólares por día. Donde los consultores que hacen funcionar esos sistemas, deben facturar por mes más que todos nosotros juntos.

Proponer un modelo SAP donde hay miles de personas analizando, codificando, testeando, y está considerado como muy complejo y caro. Y es algo más que un sistema de contabilidad o un ERP. Debe haber más programadores detrás del desarrollo de SAP que programadores Fox en latinoamérica.

Aprendí (o recordé) temas interesantes con este intercambio de ideas, espero que te haya sido de (buen) provecho.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, descalificar está del lado oscuro de la fuerza

[mapner]

Miguel, para finalizar este enriquecedor intercambio epistolar, te dejo el siguiente cuentito Zen.
Un alumno pregunta: "Maestro, cual es el secreto de la felicidad?" el maestro responde: "El secreto de la felicidad es no discutir con necios" a lo que el alumno réplica: "Maestro! yo no estoy de acuerdo con eso!" y el maestro le dice: "Tienes razón"

Saludos!

[Antonio Meza]

Se van a romper las medias!!! y se les va a correr el maquillaje!!! jajajajajajaja

Pónganse a trabajar!!! así como luego me dicen jajajajajajajaja

Ya dense un beso de amor y paz!!! 

saludos

[Carlos Miguel FARIAS]

Tienes razón, no puedo discutir con necios.

[Carlos Miguel FARIAS]

Antonio, no te metas, o no te presto más el lápiz labial.

Ah, pero hoy es jueves, entonces mañana no te lo presto.

[Antonio Meza]

Y el rojo es el que mas me gusta!!!! para los viernes por la noche, con mis medias!!!! jajajajaja

[Carlos Miguel FARIAS]

En algún momento se pensé como serían las Carmelitas descalzas, pero vi unas con calzas que invitan a dejarlas sin calzas.

En Perú hay cupo, en el convento, por si alguno le interesa.

[mapner]

Antonio, te ví estos días rasguñando a las chicas de Windev, eres el menos indicado...:))

[Antonio Meza]

como todavía no me pintaba las uñas!!! jajajajaja

Pero creo que te contagiaste jajajajaj

[Antonio Meza]

El jueves, 4 de octubre de 2018, 15:44:33 (UTC-5), mapner escribió:

[Carlos Miguel FARIAS]

Para la previa del viernes:

Diálogo matrimonio de 40 años

- José, mi hombre, no se que me pasa, pero ultimamente tus besos me dejan los labios ardiendo.

- Mujer, pasa que ya no me saco el pucho pa' besarte

Estoy realmente preocupado.

Le preste 20.000 dólares a un ciego

Me dijo: Te los devuelvo no bien cuando te vuelva a ver.

[mapner]

Catálogo de chistes de 1914, los contaba el archiduque Francisco Fernando de Austria... por chistes así se desató la primera guerra mundial...
Te enojas si te dicen arcaico? :))

[Carlos Miguel FARIAS]

No me enojo si me tratan de arcaico por mis chistes. Además es viernes

Pero un conocido me dijo que no discutiera con necios.

Saludos: Miguel

[Luis la Romana]

En mi sistema eliminé el arcaico uso de cierres y períodos, eso era de la época que la info no cambía en la pc y se guardaba cada mes en un disquete.

Solo tengo dos tables, Catalogo y Transacciones. En las transacciones están todas las operaciones de años.

Para saldos iniciales a un período con una función lo creo solo para el reporte, agrego las transacciones del rango de fechas y luego con otra funcion creo saldo final.

Lo que cuesta un poco es ir acumulando eso para las cuentas de agrupacion.

[alessio pesce]

Yo tambien habia pensado de hacer asi.

Però haber 3 tablas no necesita mucho trabajo y tiene una comodità.
 

[mapner]

Luis,

Ya he planteado el uso simplificado de tablas contables en un mensaje anterior, pero lo ponía en el contexto de usar un real motor SGDB Cliente/Servidor, no hacerlo con DBFs dado que con enormes tablas es un soporte inestable.

Por otro lado, más allá de guardar todos los ejercicios contables en las tablas de Asientos Contables de la misma BD en forma contigua, el Proceso de Cierre SI hay que hacerlo ya que ahí se generan los Asientos de Cierre del ejercicio anterior y el Asiento de Apertura del ejercicio nuevo.

Obviamente al tener todo en una misma BD requiere más filtros en los Querys (en cuanto a con que Ejercicio Activo se trabaja) y más control de restricciones sobre modificación de datos (un Ejercicio Cerrado no debe poder modificarse)

Saludos

[Carlos Miguel FARIAS]

Correcto. Si coloca todos movimientos en una única tabla puede utilizar un índice que solo indexe los registros de cada ejercicio y luego crear una vista que utilice como filtro la misma expresión con la que se creo el índice.

En cuanto el uso de los DBFs, a lo mejor en un entorno de ejecución apropiado puede funcionar bien. Pero si yo fuese el auditor, puntos para abajo porque un oficinista que sepa usar el Base de la suite LibreOffice u OpenOffice puede entrar directamente y hacer estropicios.

Saludos: Miguel