ot: AYUDA SOBRE COMO HACER ESTE DISEñO ?

Hola amigos,

Estoy disenando una nueva aplicacion de gestion y contabilidad para sql
server y tengo una gran confusion en lo siguiente:
El sistema manejara varios modulos auxiliares de la contabilidad
(inventario, cuentas por cobrar, cuentas por pagar, bancos, etc.) y esta

modulo de Mayor general que se alimenta en linea desde cada modulo.. En

modulo se generan o digitan diferentes tipos de transacciones o

El problema es que por requerimiento del cliente nos piden que cada
transaccion de cada modulo auxiliar genere o pida las cuentas contables

fines de postearse en linea al mayor general con su numero original de

que en cualquier momento se puedan consultar desde el modulo mayor general
todos los movimientos detallados con sus documentos origen (su numero) no
importa el modulo. Por ejemplo si se registra un debito en el modulo
auxiliar de CXC se generen los asientos contables en el mayor general
detallados, no en resumen como uno suele hacerlo.
El problema que veo es que como uno normalmente tiene tablas separadas

cada tipo de transaccion, ejemplo: una para cheques, otra para depositos,
otra para facturas de compra, otra para facturas de venta, otra para

de ingreso, otra para conduces de inventario, etc...etc.. la tabla de
asientos contables deberia entonces relacionarse a todas esas tablas y a

vez no relacionarse a ninguna lo cual como que no me cuadra mucho con un
diseño de BD por aquello de la integridad referencial. Incluso cuando en

mayor general se consulten los movimientos de una cuenta tendria que

varias tablas header para ver la informacion especial de cada documento.

He estado pensando algunas cosas como: a) tener una sola tabla encabezado
con todos los datos que usan todos los tipos de documentos (que pueden ser
muy disimiles entre si) y entonces tener la tabla general de asientos
contables relacionada a esta tabla. Esto haria crecer mucho en columnas

uso la tabla encabezado pues para cada tipo de doc. solo se llenaran las
columnas que utilice ese tipo.

b) Otra alternativa seria crear una tabla de asientos nueva para cada tipo
de transaccion de cada modulo y tener un par encabezado-detalle contable
para cada tipo de documento, sin embargo implicaria que para cuando en
contabilidad vayan a consultar los movimientos de una cuenta o listar las
transacciones entre fechas, tendria que hacer una UNION de todas estas
tablitas, locual pienso podria ser muy lento, o no serlo, realmente no se.
Pense tambien en vistas pero como no estoy muy claro.


Me podrian dar una opinion o recomendacion respecto a este diseño ? o si

visto alguno similar por alli referirme para ver como es una forma mas o
menos aceptable de manejarlo y que no degrade significativamente el
performance.


Muchas Gracias por la ayuda

Luis Nivar
CYC sistemas
Puerto Plata
Rep. Dom.

Hola:
Es mi opinion, que aun cuando un Cheque/Deposito genera un asiento, no
son lo mismo. O sea desde el punto de vista de diseno relacional esta bien
mantener una entidad independiente para cada uno de los documentos de los
diferentes modulos y luego mantener por separado la tabla de Asientos.
Dicho de otra forma este es un caso donde esta bien NO EVITAR LA
REDUNDANCIA que produce mantener la informacion en 2 tablas. Si los
documentos (Cheques, Depositos, Facturas, Recibos, etc.) producen
movimientos contables estos documentos son "independientes".
Es por supuesto un problema coordinar las transacciones para evitar

quede algun documento sin contabilizar o mal contabilizado, pero esto es
codigo que se puede manejar "facilmente" en procedimientos almacenados de
mantenimiento o incluso en triggers.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Luis Nivar" wrote in message
news:#
> Hola amigos,
>
> Estoy disenando una nueva aplicacion de gestion y contabilidad para sql
> server y tengo una gran confusion en lo siguiente:
> El sistema manejara varios modulos auxiliares de la contabilidad
> (inventario, cuentas por cobrar, cuentas por pagar, bancos, etc.) y esta
el
> modulo de Mayor general que se alimenta en linea desde cada modulo.. En
cada
> modulo se generan o digitan diferentes tipos de transacciones o
documentos.
> El problema es que por requerimiento del cliente nos piden que cada
> transaccion de cada modulo auxiliar genere o pida las cuentas contables
para
> fines de postearse en linea al mayor general con su numero original de
modo
> que en cualquier momento se puedan consultar desde el modulo mayor

> todos los movimientos detallados con sus documentos origen (su numero)

> importa el modulo. Por ejemplo si se registra un debito en el modulo
> auxiliar de CXC se generen los asientos contables en el mayor general
> detallados, no en resumen como uno suele hacerlo.
> El problema que veo es que como uno normalmente tiene tablas separadas
para
> cada tipo de transaccion, ejemplo: una para cheques, otra para

> otra para facturas de compra, otra para facturas de venta, otra para
recibos
> de ingreso, otra para conduces de inventario, etc...etc.. la tabla de
> asientos contables deberia entonces relacionarse a todas esas tablas y

la
> vez no relacionarse a ninguna lo cual como que no me cuadra mucho con un
> diseño de BD por aquello de la integridad referencial. Incluso cuando en
el
> mayor general se consulten los movimientos de una cuenta tendria que
accesar
> varias tablas header para ver la informacion especial de cada documento.
>
> He estado pensando algunas cosas como: a) tener una sola tabla

> con todos los datos que usan todos los tipos de documentos (que pueden

> muy disimiles entre si) y entonces tener la tabla general de asientos
> contables relacionada a esta tabla. Esto haria crecer mucho en columnas
sin
> uso la tabla encabezado pues para cada tipo de doc. solo se llenaran las
> columnas que utilice ese tipo.
>
> b) Otra alternativa seria crear una tabla de asientos nueva para cada

> de transaccion de cada modulo y tener un par encabezado-detalle contable
> para cada tipo de documento, sin embargo implicaria que para cuando en
> contabilidad vayan a consultar los movimientos de una cuenta o listar

> transacciones entre fechas, tendria que hacer una UNION de todas estas
> tablitas, locual pienso podria ser muy lento, o no serlo, realmente no

> Pense tambien en vistas pero como no estoy muy claro.
>
>
> Me podrian dar una opinion o recomendacion respecto a este diseño ? o si
han
> visto alguno similar por alli referirme para ver como es una forma mas o
> menos aceptable de manejarlo y que no degrade significativamente el
> performance.
>
>
> Muchas Gracias por la ayuda
>
> Luis Nivar
> CYC sistemas
> Puerto Plata
> Rep. Dom.
>
>

Hola y gracias por la respuesta.

A ver si entendi bien: Te refieres a la opcion de tener los headers de los
documentos en tablas separadas y una tabla unica para los asientos ? o

tanto una tabla de asientos para c/documento y una general (redundante) de
asientos ?


Saludos


"Javier Loria" wrote in message
news:
> Hola:
> Es mi opinion, que aun cuando un Cheque/Deposito genera un asiento,

> son lo mismo. O sea desde el punto de vista de diseno relacional esta

> mantener una entidad independiente para cada uno de los documentos de

> diferentes modulos y luego mantener por separado la tabla de Asientos.
> Dicho de otra forma este es un caso donde esta bien NO EVITAR LA
> REDUNDANCIA que produce mantener la informacion en 2 tablas. Si los
> documentos (Cheques, Depositos, Facturas, Recibos, etc.) producen
> movimientos contables estos documentos son "independientes".
> Es por supuesto un problema coordinar las transacciones para evitar
que
> quede algun documento sin contabilizar o mal contabilizado, pero esto es
> codigo que se puede manejar "facilmente" en procedimientos almacenados

> mantenimiento o incluso en triggers.
> Saludos,
>
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda
>
> "Luis Nivar" wrote in message
> news:#
> > Hola amigos,
> >
> > Estoy disenando una nueva aplicacion de gestion y contabilidad para

> > server y tengo una gran confusion en lo siguiente:
> > El sistema manejara varios modulos auxiliares de la contabilidad
> > (inventario, cuentas por cobrar, cuentas por pagar, bancos, etc.) y

> el
> > modulo de Mayor general que se alimenta en linea desde cada modulo..

> cada
> > modulo se generan o digitan diferentes tipos de transacciones o
> documentos.
> > El problema es que por requerimiento del cliente nos piden que cada
> > transaccion de cada modulo auxiliar genere o pida las cuentas

> para
> > fines de postearse en linea al mayor general con su numero original de
> modo
> > que en cualquier momento se puedan consultar desde el modulo mayor
general
> > todos los movimientos detallados con sus documentos origen (su numero)
no
> > importa el modulo. Por ejemplo si se registra un debito en el modulo
> > auxiliar de CXC se generen los asientos contables en el mayor general
> > detallados, no en resumen como uno suele hacerlo.
> > El problema que veo es que como uno normalmente tiene tablas separadas
> para
> > cada tipo de transaccion, ejemplo: una para cheques, otra para
depositos,
> > otra para facturas de compra, otra para facturas de venta, otra para
> recibos
> > de ingreso, otra para conduces de inventario, etc...etc.. la tabla de
> > asientos contables deberia entonces relacionarse a todas esas tablas

a
> la
> > vez no relacionarse a ninguna lo cual como que no me cuadra mucho con

> > diseño de BD por aquello de la integridad referencial. Incluso cuando

> el
> > mayor general se consulten los movimientos de una cuenta tendria que
> accesar
> > varias tablas header para ver la informacion especial de cada

> >
> > He estado pensando algunas cosas como: a) tener una sola tabla
encabezado
> > con todos los datos que usan todos los tipos de documentos (que pueden
ser
> > muy disimiles entre si) y entonces tener la tabla general de asientos
> > contables relacionada a esta tabla. Esto haria crecer mucho en

> sin
> > uso la tabla encabezado pues para cada tipo de doc. solo se llenaran

> > columnas que utilice ese tipo.
> >
> > b) Otra alternativa seria crear una tabla de asientos nueva para cada
tipo
> > de transaccion de cada modulo y tener un par encabezado-detalle

> > para cada tipo de documento, sin embargo implicaria que para cuando en
> > contabilidad vayan a consultar los movimientos de una cuenta o listar
las
> > transacciones entre fechas, tendria que hacer una UNION de todas estas
> > tablitas, locual pienso podria ser muy lento, o no serlo, realmente no
se.
> > Pense tambien en vistas pero como no estoy muy claro.
> >
> >
> > Me podrian dar una opinion o recomendacion respecto a este diseño ? o

> han
> > visto alguno similar por alli referirme para ver como es una forma mas

> > menos aceptable de manejarlo y que no degrade significativamente el
> > performance.
> >
> >
> > Muchas Gracias por la ayuda
> >
> > Luis Nivar
> > CYC sistemas
> > Puerto Plata
> > Rep. Dom.
> >
> >
>
>

Hola:
Tal vez es es mas claro si escribo el SQL, pero me gustaria enfatizar
que este diseno no es mas una opinion:
=> CREATE TABLE AsientosContables(
CodigoAsiento CHAR(8) NOT NULL
PRIMARY KEY
, FechaAsiento SMALLDATETIME NOT NULL
, FechaRegistro SMALLDATETIME NOT NULL
Otras Columnas
)

CREATE TABLE DetalleAsientosContables(
CodigoAsiento CHAR(8) NOT NULL
FOREIGN KEY REFERENCES AsientosContables(CodigoAsiento)
, NumeroMovimiento INT NOT NULL
, CodigoCuentaContable CHAR(10) NOT NULL
FOREIGN KEY REFERENCES CatalogoContable(CodigoCuentaContable)
, TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1,2,3,4,5))
, NumeroDocumento VARCHAR(15) NOT NULL -- Puede ser nulo?
, MontoMovimiento DECIMAL(15,2) NOT NULL
, CONSTRAINT PKDetalleAsientosContables
PRIMARY KEY (CodigoAsiento, NumeroMovimiento)
)

CREATE TABLE Facturas( -- O cualquier otro Documento
NumeroFactura CHAR(8) NOT NULL
CHECK(NumeroFactura LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
PRIMARY KEY
, FechaFacturacion SMALLDATETIME NOT NULL
, MontoFacturado DECIMAL(15,2) NOT NULL -- Puede ser Nulol?
, AsientoContable CHAR(8) NOT NULL
FOREIGN KEY REFERENCES AsientosContables(CodigoAsiento)
)
==> Asientos Contables y Detalle de Asientos no tienen relacion con las
Tablas de Documentos (no por SQL), unicamente tienen una referencia del
origen del asiento en TipoDocumento, NumeroDocumento. En este caso asumi

en un solo asiento pueden contabilizarse multiples documentos por eso el
estas columnas estan en el detalle del asiento. Si decides hacer un

por cada documento entonces deben ir las columnas en la tabla de asientos
contables.
Por otra parte la tabla de documentos (en este caso facturas) SI tiene
relacion con Asientos Contables, en este caso la defini "floja", en el
sentido que no hace referencia exacta al movimiento donde fue registrada.
Si quieres hacerla "fuerte" me parece deberias hacer una tabla para

documento que detalle la forma en que fue contabilizado. Esta tabla NO

ser Detalle de Asientos, ya que lo Asientos NO deben "conocer" de los
documentos, los documentos si deben conocer de los asientos.
Espero haberme explicado y que espero te sirva,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Luis Nivar" wrote in message
news:
> Hola y gracias por la respuesta.
>
> A ver si entendi bien: Te refieres a la opcion de tener los headers de

> documentos en tablas separadas y una tabla unica para los asientos ? o
tener
> tanto una tabla de asientos para c/documento y una general (redundante)

> asientos ?
>
>
> Saludos
>
>
> "Javier Loria" wrote in message
> news:
> > Hola:
> > Es mi opinion, que aun cuando un Cheque/Deposito genera un

no
> > son lo mismo. O sea desde el punto de vista de diseno relacional esta
bien
> > mantener una entidad independiente para cada uno de los documentos de
los
> > diferentes modulos y luego mantener por separado la tabla de Asientos.
> > Dicho de otra forma este es un caso donde esta bien NO EVITAR LA
> > REDUNDANCIA que produce mantener la informacion en 2 tablas. Si los
> > documentos (Cheques, Depositos, Facturas, Recibos, etc.) producen
> > movimientos contables estos documentos son "independientes".
> > Es por supuesto un problema coordinar las transacciones para

> que
> > quede algun documento sin contabilizar o mal contabilizado, pero esto

> > codigo que se puede manejar "facilmente" en procedimientos almacenados
de
> > mantenimiento o incluso en triggers.
> > Saludos,
> >
> >
> > Javier Loria
> > Costa Rica
> > Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> > que pueda ser copiado y pegado al Query Analizer.
> > La version de SQL y Service Pack tambien ayuda
> >
> > "Luis Nivar" wrote in message
> > news:#
> > > Hola amigos,
> > >
> > > Estoy disenando una nueva aplicacion de gestion y contabilidad para
sql
> > > server y tengo una gran confusion en lo siguiente:
> > > El sistema manejara varios modulos auxiliares de la contabilidad
> > > (inventario, cuentas por cobrar, cuentas por pagar, bancos, etc.) y
esta
> > el
> > > modulo de Mayor general que se alimenta en linea desde cada modulo..
En
> > cada
> > > modulo se generan o digitan diferentes tipos de transacciones o
> > documentos.
> > > El problema es que por requerimiento del cliente nos piden que cada
> > > transaccion de cada modulo auxiliar genere o pida las cuentas
contables
> > para
> > > fines de postearse en linea al mayor general con su numero original

> > modo
> > > que en cualquier momento se puedan consultar desde el modulo mayor
> general
> > > todos los movimientos detallados con sus documentos origen (su

> no
> > > importa el modulo. Por ejemplo si se registra un debito en el

> > > auxiliar de CXC se generen los asientos contables en el mayor

> > > detallados, no en resumen como uno suele hacerlo.
> > > El problema que veo es que como uno normalmente tiene tablas

> > para
> > > cada tipo de transaccion, ejemplo: una para cheques, otra para
> depositos,
> > > otra para facturas de compra, otra para facturas de venta, otra para
> > recibos
> > > de ingreso, otra para conduces de inventario, etc...etc.. la tabla

> > > asientos contables deberia entonces relacionarse a todas esas

y
> a
> > la
> > > vez no relacionarse a ninguna lo cual como que no me cuadra mucho

un
> > > diseño de BD por aquello de la integridad referencial. Incluso

en
> > el
> > > mayor general se consulten los movimientos de una cuenta tendria que
> > accesar
> > > varias tablas header para ver la informacion especial de cada
documento.
> > >
> > > He estado pensando algunas cosas como: a) tener una sola tabla
> encabezado
> > > con todos los datos que usan todos los tipos de documentos (que

> ser
> > > muy disimiles entre si) y entonces tener la tabla general de

> > > contables relacionada a esta tabla. Esto haria crecer mucho en
columnas
> > sin
> > > uso la tabla encabezado pues para cada tipo de doc. solo se llenaran
las
> > > columnas que utilice ese tipo.
> > >
> > > b) Otra alternativa seria crear una tabla de asientos nueva para

> tipo
> > > de transaccion de cada modulo y tener un par encabezado-detalle
contable
> > > para cada tipo de documento, sin embargo implicaria que para cuando

> > > contabilidad vayan a consultar los movimientos de una cuenta o

> las
> > > transacciones entre fechas, tendria que hacer una UNION de todas

> > > tablitas, locual pienso podria ser muy lento, o no serlo, realmente

> se.
> > > Pense tambien en vistas pero como no estoy muy claro.
> > >
> > >
> > > Me podrian dar una opinion o recomendacion respecto a este diseño ?

si
> > han
> > > visto alguno similar por alli referirme para ver como es una forma

o
> > > menos aceptable de manejarlo y que no degrade significativamente el
> > > performance.
> > >
> > >
> > > Muchas Gracias por la ayuda
> > >
> > > Luis Nivar
> > > CYC sistemas
> > > Puerto Plata
> > > Rep. Dom.
> > >
> > >
> >
> >
>
>

Hola:
Tal vez es es mas claro si escribo el SQL, pero me gustaria enfatizar
que este diseno no es mas una opinion:
=> CREATE TABLE AsientosContables(
CodigoAsiento CHAR(8) NOT NULL
PRIMARY KEY
, FechaAsiento SMALLDATETIME NOT NULL
, FechaRegistro SMALLDATETIME NOT NULL
Otras Columnas
)

CREATE TABLE DetalleAsientosContables(
CodigoAsiento CHAR(8) NOT NULL
FOREIGN KEY REFERENCES AsientosContables(CodigoAsiento)
, NumeroMovimiento INT NOT NULL
, CodigoCuentaContable CHAR(10) NOT NULL
FOREIGN KEY REFERENCES CatalogoContable(CodigoCuentaContable)
, TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1,2,3,4,5))
, NumeroDocumento VARCHAR(15) NOT NULL -- Puede ser nulo?
, MontoMovimiento DECIMAL(15,2) NOT NULL
, CONSTRAINT PKDetalleAsientosContables
PRIMARY KEY (CodigoAsiento, NumeroMovimiento)
)

CREATE TABLE Facturas( -- O cualquier otro Documento
NumeroFactura CHAR(8) NOT NULL
CHECK(NumeroFactura LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
PRIMARY KEY
, FechaFacturacion SMALLDATETIME NOT NULL
, MontoFacturado DECIMAL(15,2) NOT NULL -- Puede ser Nulol?
, AsientoContable CHAR(8) NOT NULL
FOREIGN KEY REFERENCES AsientosContables(CodigoAsiento)
)
==> Asientos Contables y Detalle de Asientos no tienen relacion con las
Tablas de Documentos (no por SQL), unicamente tienen una referencia del
origen del asiento en TipoDocumento, NumeroDocumento. En este caso asumi

en un solo asiento pueden contabilizarse multiples documentos por eso el
estas columnas estan en el detalle del asiento. Si decides hacer un

por cada documento entonces deben ir las columnas en la tabla de asientos
contables.
Por otra parte la tabla de documentos (en este caso facturas) SI tiene
relacion con Asientos Contables, en este caso la defini "floja", en el
sentido que no hace referencia exacta al movimiento donde fue registrada.
Si quieres hacerla "fuerte" me parece deberias hacer una tabla para

documento que detalle la forma en que fue contabilizado. Esta tabla NO

ser Detalle de Asientos, ya que lo Asientos NO deben "conocer" de los
documentos, los documentos si deben conocer de los asientos.
Espero haberme explicado y que espero te sirva,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Luis Nivar" wrote in message
news:
> Hola y gracias por la respuesta.
>
> A ver si entendi bien: Te refieres a la opcion de tener los headers de

> documentos en tablas separadas y una tabla unica para los asientos ? o
tener
> tanto una tabla de asientos para c/documento y una general (redundante)

> asientos ?
>
>
> Saludos
>
>
> "Javier Loria" wrote in message
> news:
> > Hola:
> > Es mi opinion, que aun cuando un Cheque/Deposito genera un

no
> > son lo mismo. O sea desde el punto de vista de diseno relacional esta
bien
> > mantener una entidad independiente para cada uno de los documentos de
los
> > diferentes modulos y luego mantener por separado la tabla de Asientos.
> > Dicho de otra forma este es un caso donde esta bien NO EVITAR LA
> > REDUNDANCIA que produce mantener la informacion en 2 tablas. Si los
> > documentos (Cheques, Depositos, Facturas, Recibos, etc.) producen
> > movimientos contables estos documentos son "independientes".
> > Es por supuesto un problema coordinar las transacciones para

> que
> > quede algun documento sin contabilizar o mal contabilizado, pero esto

> > codigo que se puede manejar "facilmente" en procedimientos almacenados
de
> > mantenimiento o incluso en triggers.
> > Saludos,
> >
> >
> > Javier Loria
> > Costa Rica
> > Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> > que pueda ser copiado y pegado al Query Analizer.
> > La version de SQL y Service Pack tambien ayuda
> >
> > "Luis Nivar" wrote in message
> > news:#
> > > Hola amigos,
> > >
> > > Estoy disenando una nueva aplicacion de gestion y contabilidad para
sql
> > > server y tengo una gran confusion en lo siguiente:
> > > El sistema manejara varios modulos auxiliares de la contabilidad
> > > (inventario, cuentas por cobrar, cuentas por pagar, bancos, etc.) y
esta
> > el
> > > modulo de Mayor general que se alimenta en linea desde cada modulo..
En
> > cada
> > > modulo se generan o digitan diferentes tipos de transacciones o
> > documentos.
> > > El problema es que por requerimiento del cliente nos piden que cada
> > > transaccion de cada modulo auxiliar genere o pida las cuentas
contables
> > para
> > > fines de postearse en linea al mayor general con su numero original

> > modo
> > > que en cualquier momento se puedan consultar desde el modulo mayor
> general
> > > todos los movimientos detallados con sus documentos origen (su

> no
> > > importa el modulo. Por ejemplo si se registra un debito en el

> > > auxiliar de CXC se generen los asientos contables en el mayor

> > > detallados, no en resumen como uno suele hacerlo.
> > > El problema que veo es que como uno normalmente tiene tablas

> > para
> > > cada tipo de transaccion, ejemplo: una para cheques, otra para
> depositos,
> > > otra para facturas de compra, otra para facturas de venta, otra para
> > recibos
> > > de ingreso, otra para conduces de inventario, etc...etc.. la tabla

> > > asientos contables deberia entonces relacionarse a todas esas

y
> a
> > la
> > > vez no relacionarse a ninguna lo cual como que no me cuadra mucho

un
> > > diseño de BD por aquello de la integridad referencial. Incluso

en
> > el
> > > mayor general se consulten los movimientos de una cuenta tendria que
> > accesar
> > > varias tablas header para ver la informacion especial de cada
documento.
> > >
> > > He estado pensando algunas cosas como: a) tener una sola tabla
> encabezado
> > > con todos los datos que usan todos los tipos de documentos (que

> ser
> > > muy disimiles entre si) y entonces tener la tabla general de

> > > contables relacionada a esta tabla. Esto haria crecer mucho en
columnas
> > sin
> > > uso la tabla encabezado pues para cada tipo de doc. solo se llenaran
las
> > > columnas que utilice ese tipo.
> > >
> > > b) Otra alternativa seria crear una tabla de asientos nueva para

> tipo
> > > de transaccion de cada modulo y tener un par encabezado-detalle
contable
> > > para cada tipo de documento, sin embargo implicaria que para cuando

> > > contabilidad vayan a consultar los movimientos de una cuenta o

> las
> > > transacciones entre fechas, tendria que hacer una UNION de todas

> > > tablitas, locual pienso podria ser muy lento, o no serlo, realmente

> se.
> > > Pense tambien en vistas pero como no estoy muy claro.
> > >
> > >
> > > Me podrian dar una opinion o recomendacion respecto a este diseño ?

si
> > han
> > > visto alguno similar por alli referirme para ver como es una forma

o
> > > menos aceptable de manejarlo y que no degrade significativamente el
> > > performance.
> > >
> > >
> > > Muchas Gracias por la ayuda
> > >
> > > Luis Nivar
> > > CYC sistemas
> > > Puerto Plata
> > > Rep. Dom.
> > >
> > >
> >
> >
>
>