Ayuda para un diseño

11/01/2005 - 00:01 por Ramon Zuluaga | Informe spam
Es un sistema de cuentas por cobrar:

Entidades: Clientes, Facturas, Debitos, Pagos, Creditos
(los 4 ultimos son tipos de documentos con atributos diferentes, que se le
registran a un cliente)

Las facturas y los debitos aumentan el balance del cliente. Los pagos y los
creditos lo rebajan.

El problema es que los documentos de rebaja (pagos y creditos) deben
aplicarse individualmente a los documentos de aumento (facturas y debitos).
Es decir: al registrar un pago este se debe aplicar a las facturas o los
debitos que se esten saldando o abonando y debe conservarse el balance
individual de cada factura o debito. Un mismo pago puede pagar tanto
facturas como debitos.
Igual al registrar un credito, este se puede aplicar tanto a facturas como a
debitos.

Eso implica que hay una tabla de aplicacion que debe relacionar los dos
tipos de documento involucrados.

No se bien como representar esto en un diseño relacional correctamente para
que sea facil sacar por ejemplo un estado de cuenta de un cliente tanto para
el cliente como tal como para saber el balance individual de cada factura y
cada debito.


He estado pensando en reunir en una misma tabla las facturas y los debitos.
Y por otro lado juntar en una sola tablas los pagos y los creditos pero he
estado viendo que tienen atributos diferentes y como que me complica
juntarlos.

Me pueden dar una idea de como diseñar esta pequeña base de datos pues soy
nuevo en esto ? Si han trabajado en algo similar y me pueden contar su
experiencia es mucho mejor.


Gracias

Ramon Zuluaga

Preguntas similare

Leer las respuestas

#1 Javier Loria
11/01/2005 - 03:21 | Informe spam
Hola:
Una alternativa, que asume que los documentos tienen los mismos
atributos.
CREATE TABLE Clientes(
CodigoCliente CHAR(8)
NOT NULL
PRIMARY KEY
CHECK (CodigoCliente LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, Nombre VARCHAR(35)
NOT NULL
UNIQUE
)
CREATE TABLE SaldosCxCobrar(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1,2))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaEmision SMALLDATETIME
NOT NULL
, CodigoCliente CHAR(8)
NOT NULL
FOREIGN KEY REFERENCES Clientes(CodigoCliente)
, MontoOriginal NUMERIC(18,4)
NOT NULL
CHECK(MontoOriginal>0)
, SaldoPendiente NUMERIC(18,4)
NOT NULL
CHECK(SaldoPendiente>0)
, CONSTRAINT PKSaldosCxCobrar
PRIMARY KEY(TipoDocumento, NumDocumento)
)

CREATE TABLE MovimientosCxC(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1, 2, 3, 4))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, TipoDocumentoAplica INT
NULL -- Permite Nulos
CHECK(TipoDocumentoAplica IN (1, 2))
, NumDocumentoAplica CHAR(8)
NULL -- Permite Nulos
CHECK (NumDocumentoAplica LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaRegistro SMALLDATETIME
NOT NULL
, MontoDocumento NUMERIC(18,4)
, CONSTRAINT PKMovimientosCxC
PRIMARY KEY(TipoDocumento, NumDocumento)
, CONSTRAINT FKMovimientosSaldosCxCobrar
FOREIGN KEY(TipoDocumentoAplica, NumDocumentoAplica)
REFERENCES SaldosCxCobrar(TipoDocumento, NumDocumento)
)
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

"Ramon Zuluaga" wrote in message
news:
Es un sistema de cuentas por cobrar:

Entidades: Clientes, Facturas, Debitos, Pagos, Creditos
(los 4 ultimos son tipos de documentos con atributos diferentes, que se le
registran a un cliente)

Las facturas y los debitos aumentan el balance del cliente. Los pagos y


los
creditos lo rebajan.

El problema es que los documentos de rebaja (pagos y creditos) deben
aplicarse individualmente a los documentos de aumento (facturas y


debitos).
Es decir: al registrar un pago este se debe aplicar a las facturas o los
debitos que se esten saldando o abonando y debe conservarse el balance
individual de cada factura o debito. Un mismo pago puede pagar tanto
facturas como debitos.
Igual al registrar un credito, este se puede aplicar tanto a facturas como


a
debitos.

Eso implica que hay una tabla de aplicacion que debe relacionar los dos
tipos de documento involucrados.

No se bien como representar esto en un diseño relacional correctamente


para
que sea facil sacar por ejemplo un estado de cuenta de un cliente tanto


para
el cliente como tal como para saber el balance individual de cada factura


y
cada debito.


He estado pensando en reunir en una misma tabla las facturas y los


debitos.
Y por otro lado juntar en una sola tablas los pagos y los creditos pero he
estado viendo que tienen atributos diferentes y como que me complica
juntarlos.

Me pueden dar una idea de como diseñar esta pequeña base de datos pues soy
nuevo en esto ? Si han trabajado en algo similar y me pueden contar su
experiencia es mucho mejor.


Gracias

Ramon Zuluaga


Respuesta Responder a este mensaje
#2 Ramon Zuluaga
11/01/2005 - 04:42 | Informe spam
Hola,

Deduzco que me recomiendas que es mas conveniente tener todos los documentos
en una misma tabla no ?

Gracias


"Javier Loria" wrote in message
news:
Hola:
Una alternativa, que asume que los documentos tienen los mismos
atributos.
> CREATE TABLE Clientes(
CodigoCliente CHAR(8)
NOT NULL
PRIMARY KEY
CHECK (CodigoCliente LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, Nombre VARCHAR(35)
NOT NULL
UNIQUE
)
CREATE TABLE SaldosCxCobrar(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1,2))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaEmision SMALLDATETIME
NOT NULL
, CodigoCliente CHAR(8)
NOT NULL
FOREIGN KEY REFERENCES Clientes(CodigoCliente)
, MontoOriginal NUMERIC(18,4)
NOT NULL
CHECK(MontoOriginal>0)
, SaldoPendiente NUMERIC(18,4)
NOT NULL
CHECK(SaldoPendiente>0)
, CONSTRAINT PKSaldosCxCobrar
PRIMARY KEY(TipoDocumento, NumDocumento)
)

CREATE TABLE MovimientosCxC(
TipoDocumento INT
NOT NULL
CHECK(TipoDocumento IN (1, 2, 3, 4))
, NumDocumento CHAR(8)
NOT NULL
CHECK (NumDocumento LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, TipoDocumentoAplica INT
NULL -- Permite Nulos
CHECK(TipoDocumentoAplica IN (1, 2))
, NumDocumentoAplica CHAR(8)
NULL -- Permite Nulos
CHECK (NumDocumentoAplica LIKE


'[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
, FechaRegistro SMALLDATETIME
NOT NULL
, MontoDocumento NUMERIC(18,4)
, CONSTRAINT PKMovimientosCxC
PRIMARY KEY(TipoDocumento, NumDocumento)
, CONSTRAINT FKMovimientosSaldosCxCobrar
FOREIGN KEY(TipoDocumentoAplica, NumDocumentoAplica)
REFERENCES SaldosCxCobrar(TipoDocumento, NumDocumento)
)
> 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

"Ramon Zuluaga" wrote in message
news:
> Es un sistema de cuentas por cobrar:
>
> Entidades: Clientes, Facturas, Debitos, Pagos, Creditos
> (los 4 ultimos son tipos de documentos con atributos diferentes, que se


le
> registran a un cliente)
>
> Las facturas y los debitos aumentan el balance del cliente. Los pagos y
los
> creditos lo rebajan.
>
> El problema es que los documentos de rebaja (pagos y creditos) deben
> aplicarse individualmente a los documentos de aumento (facturas y
debitos).
> Es decir: al registrar un pago este se debe aplicar a las facturas o los
> debitos que se esten saldando o abonando y debe conservarse el balance
> individual de cada factura o debito. Un mismo pago puede pagar tanto
> facturas como debitos.
> Igual al registrar un credito, este se puede aplicar tanto a facturas


como
a
> debitos.
>
> Eso implica que hay una tabla de aplicacion que debe relacionar los dos
> tipos de documento involucrados.
>
> No se bien como representar esto en un diseño relacional correctamente
para
> que sea facil sacar por ejemplo un estado de cuenta de un cliente tanto
para
> el cliente como tal como para saber el balance individual de cada


factura
y
> cada debito.
>
>
> He estado pensando en reunir en una misma tabla las facturas y los
debitos.
> Y por otro lado juntar en una sola tablas los pagos y los creditos pero


he
> estado viendo que tienen atributos diferentes y como que me complica
> juntarlos.
>
> Me pueden dar una idea de como diseñar esta pequeña base de datos pues


soy
> nuevo en esto ? Si han trabajado en algo similar y me pueden contar su
> experiencia es mucho mejor.
>
>
> Gracias
>
> Ramon Zuluaga
>
>


email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida