ot: AYUDA SOBRE COMO HACER ESTE DISEñO ?

Hola.

A mi tambien me interesa ese tema. Una pregunta ya a nivel educativo: Cual
serian los pros y contras de tener para cada entidad de tipo de documento

para de tablas encabezado y detalle(esta para las cuentas contables). Ej.
facturaE y facturaD, chequeE y chequeD, reciboE y reciboD, y asi por el
estilo ?

Mi opinion es que si es para fines contables cuando se quieran consultar

movimientos de una cuenta podria recorrerse cada tabla de detalles

la cuenta o haciendo una UNION ALL. O es que esto seria muy lento ?

aclararme, no es contradiciendo tu opinion es solo para aprender un poco

al respecto.

Gracias
Pedro Jose Caceres





"Javier Loria" wrote in message
news:%
> Hola:
> Tal vez es es mas claro si escribo el SQL, pero me gustaria

> 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
que
> en un solo asiento pueden contabilizarse multiples documentos por eso el
> estas columnas estan en el detalle del asiento. Si decides hacer un
asiento
> por cada documento entonces deben ir las columnas en la tabla de

> contables.
> Por otra parte la tabla de documentos (en este caso facturas) SI

> relacion con Asientos Contables, en este caso la defini "floja", en el
> sentido que no hace referencia exacta al movimiento donde fue

> Si quieres hacerla "fuerte" me parece deberias hacer una tabla para
cada
> documento que detalle la forma en que fue contabilizado. Esta tabla NO
puede
> 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
los
> > documentos en tablas separadas y una tabla unica para los asientos ? o
> tener
> > tanto una tabla de asientos para c/documento y una general

de
> > asientos ?
> >
> >
> > Saludos
> >
> >
> > "Javier Loria" wrote in message
> > news:
> > > 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

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

> los
> > > diferentes modulos y luego mantener por separado la tabla de

> > > 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

es
> > > codigo que se puede manejar "facilmente" en procedimientos

> 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

> 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.)

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

> En
> > > cada
> > > > modulo se generan o digitan diferentes tipos de transacciones o
> > > documentos.
> > > > El problema es que por requerimiento del cliente nos piden que

> > > > transaccion de cada modulo auxiliar genere o pida las cuentas
> contables
> > > para
> > > > fines de postearse en linea al mayor general con su numero

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

> > > recibos
> > > > de ingreso, otra para conduces de inventario, etc...etc.. la tabla
de
> > > > asientos contables deberia entonces relacionarse a todas esas
tablas
> y
> > a
> > > 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

> > > 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
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
> > > sin
> > > > uso la tabla encabezado pues para cada tipo de doc. solo se

> 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

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,

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
> > > han
> > > > visto alguno similar por alli referirme para ver como es una forma
mas
> o
> > > > menos aceptable de manejarlo y que no degrade significativamente

> > > > performance.
> > > >
> > > >
> > > > Muchas Gracias por la ayuda
> > > >
> > > > Luis Nivar
> > > > CYC sistemas
> > > > Puerto Plata
> > > > Rep. Dom.
> > > >
> > > >
> > >
> > >
> >
> >
>
>