none
Mayorizacion Contable

    Pregunta

  • Esto realizando un sistema contable y me gustaria realizar el mayorizado cada vez que realize el comprobante contable adjunto la estructura de mis tablas para que me den una idea de como puedo armar la rutina mas eficiente para este proceso.

    utilizo VS2010 con Sql Server 2008

    Adjunto mis tablas

     CREATE TABLE [dbo].[TblDiarios](
     [IDDiario] [int] NOT NULL,
     [Cod_Emp] [nvarchar](2) NOT NULL,
     [COD_SUC] [nvarchar](2) NOT NULL,
     [COD_DIA] [nvarchar](8) NOT NULL,
     [NUM_MOV] [nvarchar](7) NOT NULL,
     [REFERENCIA] [nvarchar](60) NOT NULL,
     [VALOR] [float] NULL,
     [CONCEPTO] [ntext] NULL,
     [FECHA] [datetime] NOT NULL,
     [TOT_DEB] [float] NULL,
     [TOT_CRE] [float] NULL,
     [TIPO_CAMB] [float] NOT NULL,
     [MONEDA] [tinyint] NOT NULL,
     [Tipo] [tinyint] NOT NULL,
     [FEC_ING] [datetime] NULL
    )

     

    CREATE TABLE [dbo].[tblDetalle_Diario](
     [IDDiario] [int] NOT NULL,
     [COD_SUC] [nvarchar](2) NULL,
     [CUENTA] [nvarchar](25) NULL,
    [TOT_DEB] [float] NULL,
    [TOT_CRE] [float] NULL,
     [DESC_MOV] [nvarchar](60) NULL,
     [NUM_LIN] [smallint] NULL
     )

    Gracias

     


    lunes, 06 de febrero de 2012 0:01

Respuestas

  • denisenrique,

    No veo nada claro cómo resolver el problema con la estructura que tienes.

    Yo comenzaría por enfocarme en los conceptos más básicos: cuentas y apuntes.

    • Cuenta: es una clasificación contable que corresponde a un (y sólo un) concepto y refleja la situación de la empresa en relación a ese concepto. y que es objeto de operaciones llamadas apuntes contables.
    • Apunte: es una operación contable que ocurre en un momento determinado en el tiempo afecta a una o varias cuentas y que está sujeta a ciertas validaciones.
    • Libro de diario: Es una colección de todos los apuntes contables, ordenados de forma cronológica.
    • Libro de mayor: Es una colección de apuntes, organizados y agrupados por cuentas, aunque también se refiere a la fotografía de los saldos de las cuentas en un instante de tiempo.

    Desde una perspectiva purista de diseño de base de datos, tanto el libro de diario como el libro de mayor son vistas sobre los mismos datos.

    Un modelo (relacional) muy elemental podría ser así:


    Con esta estructura, tu tabla de apuntes sería así:

    Apunte

    • Id_Apunte
    • Fecha
    • ...otros datos del apunte...

    Cuenta

    • Id_Cuenta
    • Id_Cuenta_Padre
    • Saldo_Inicial

    Apunte_Cuenta

    • Id_Apunte 
    • Id_Cuenta
    • Afectación (Por el debe o por el haber)
    • Importe

    Con esta estructura, conocer el saldo en un instante determinado es muy fácil:

    SELECT Cuenta.Id_Cuenta, Saldo_Inicial + NVL(Acumulado,0)
    FROM Cuenta
    LEFT JOIN 
    (
       SELECT ID_Cuenta, 
       SUM(Importe * Signo(Afectación)) Acumulado
       FROM Apunte_Cuenta 
       GROUP BY ID_CUENTA
    ) AS X
    ON Cuenta.Id_Cuenta = X.Id_Cuenta

    En este momento tenemos el libro de mayor a nivel de cuentas de movimientos. ¿Cómo obtienes los saldos a nivel de todas las cuentas? Hay varias formas:

    1) Usando queries recursivos (funciona en la mayoría de los manejadores de bases de datos que soporte el estándar SQL:1999 (ISO/IEC 9075-2:1999) y otros como Oracle que tienen su propia sintaxis. No lo recomiendo porque la sintaxis de los queries recursivos es complicada (y más complicado entender los resultados de un query xD )

    2) Mediante código imperativo usando recursión (stored procedures, métodos o funciones en cualquier lenguaje): se implementa una función de totalización que hace lo siguiente:

    Para cada cuenta:

    - Si la cuenta tiene movimientos, obtener saldo sumando los apuntes que la afectan.

    - Si no: obtener su saldo sumando los saldos de las cuentas "hijas".

    Ojalá te sirvan de algo estas ideas.

    Saludos,

    Yván Ecarri Gómez



    logo osoft
    Si he contestado tu pregunta, por favor marca mi post como respuesta.
    ...Y si mi post te ha servido, márcalo como útil smile

    • Marcado como respuesta denisenrique viernes, 09 de marzo de 2012 6:52
    miércoles, 07 de marzo de 2012 9:44

Todas las respuestas

  • pero el problema cual seria ? armar la estrucura del codigo, algun error en el diseño

    si es la estructura podria ser algo como esto

    [N-Tier] – Desarrollo en capas - Ejemplo Facturacion - parte 3

     

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    lunes, 06 de febrero de 2012 0:22
  • No me refiero al diseno,  sino como armar el proceso de mayorizacion para que me realize el calculo por cuentas y subcuenta , te dejo esta imagen

    si te fijas hay movimientos en dos cuentas que suman 20 este valor se refleja en la subcuenta con el valor de 20 , pero a la cuenta principal se suma 51 porque tiene activo fijo por el valor de 31, me explico? necesito ir realizando este tipo de calculo. necesito ideas para esto ya que no se me ocurre nada.

    gracias

     


    Guido.
    lunes, 06 de febrero de 2012 2:41
  • pero entonces no veo que las tablas que has creado reflejen esto que planteas

    porque aqui veo una jerarquia, no un maestro-detalle

    deberias crear dos tablas pero no tienes una de detalle, sino una que relaciones y arme la recursividad a la primera porque al subcuenta tambien es una cuenta solo que esta tiene un padre

    las cuentas sin padre serian las que defines como de primer nivel

    podria ser

    Cuesta (tabla)
    IdCuenta
    monto   (si es positivo es debe si es negativo un haber)
    tipo   (aqui registras si es activo o pasivo)
    
    RelacionCuenta (tabla)
    IdCuenta
    IdSubCuenta
    como veras esta segunda tabla se relaciona dos veces con la priemra para poder armar la jerarquia de cuentas

     

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    lunes, 06 de febrero de 2012 5:28
  • pero entonces no veo que las tablas que has creado reflejen esto que planteas

    porque aqui veo una jerarquia, no un maestro-detalle

    deberias crear dos tablas pero no tienes una de detalle, sino una que relaciones y arme la recursividad a la primera porque al subcuenta tambien es una cuenta solo que esta tiene un padre

    las cuentas sin padre serian las que defines como de primer nivel

    podria ser

    Cuesta (tabla)
    IdCuenta
    monto   (si es positivo es debe si es negativo un haber)
    tipo   (aqui registras si es activo o pasivo)
    
    RelacionCuenta (tabla)
    IdCuenta
    IdSubCuenta
    como veras esta segunda tabla se relaciona dos veces con la priemra para poder armar la jerarquia de cuentas

     

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    Leandro,

    La que tú propones es una solución desde el punto de vista técnico, pero funcionalmente no me parece apropiada, por muchas cosas:

    a) Además de Activo y Pasivo (cuentas de balance) puedes tener otros tipos de cuenta (ingresos, egresos, patrimonio, etc).

    b) Una cuenta siempre totaliza en una y sólo una cuenta. Por ejemplo, la Cuenta Corriente XXXXXXX totaliza  en Caja y Banco, ésta otaliza en Activo Corriente, y Activo Corriente totaliza en Activo; luego no necesitas una tabla de relación, te basta con tener una relación de cuenta consigo misma.

    Denisenrique:

    Muchos sistemas contables usan el número de cuenta de tamaño y estructura fijos. ¿Tu sistema permite múltiples niveles de agregación? ¿Los niveles de agregación son fijos, o puedes tener cuentas que se desagregan más que otras?

    Te hago la pregunta porque podrías establecer una relación jerárquica usando únicamente el código de cuenta. Por ejemplo:

    • ACTIVO: 100000
    • ACTIVO FIJO: 11000
    • BIENES INMUEBLES: 11100
    • NAVE INDUSTRIAL C2 NAVALCARNERO: 111111

    Si tienes una estructura variable, debes tener una tabla CUENTA parecida a esto, como propone Leandro:

    • IdCuenta varchar(6),
    • IdCuenta_Padre varchar(6)

     


    Si la respuesta te ha servido, márcala como útil.
    lunes, 06 de febrero de 2012 15:03
  • a-

    seria un campo tipo con un enum algo mas grande

    b-

    pero alli estas mencionado una jerarquia, ya que vas escalonando, en dodne uan cuanta hija tiene uan padre donde totaliza, lo de la jerarquia es justo lo que propuse

    ademas no entendi al principio parece que se cuestiona lo que planteo pero al final dices

    Si tienes una estructura variable, debes tener una tabla CUENTA parecida a esto, como propone Leandro

    entonces esta bien lo que planteo, o esta mal?

    despues si para armar la jeraquia se usan dos tablas o solo una, bueno eso se peude adpatar, lo importantes es entender que las cuantas tienen un padre, salvo las que se consideran como root

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    lunes, 06 de febrero de 2012 16:53
  • Hola Leandro,

    a) Sí... es una solución, pero tiene un problema de normalización pues el tipo de una cuenta no depende de la clave de la cuenta sino de la cuenta ancestro superior. 

    b) La idea de una jerarquía está bien, pero no me gusta la idea de tener dos tablas. Sólo las cuentas de primer nivel tendrían el campo ID_CUENTA_PADRE en null y generalmente son pocas (7-8 cuentas, dependiendo del plan de cuentas del país o de la empresa). Me parece mejor implementar la auto-relación en la tabla cuenta.

    :)

    Pero claro... todo esto es a gusto del diseñador.

    DENISENRIQUE:

    Dices "si es positivo es debe si es negativo un haber". ¿Estás hablando de los apuntes a las cuentas o estás hablando del saldo de las cuentas?

    El saldo de una cuenta no es "debe" o "haber". Los apuntes contables son por el debe o por el haber y siempre que se hace un apunte implica al menos dos cuentas: una por el debe y una por el haber. Esto se llama "partida doble".

    El saldo puede ser deudor (negativo) o acreedor (positivo).

    Saludos,

    Yván


    Si la respuesta te ha servido, márcala como útil.

    martes, 14 de febrero de 2012 16:14
  • si claro mi sistema es nNiveles esta es la estructura del plan de cuentas

    CREATE TABLE [dbo].[Plan Cuentas](
     [Cod_Emp] [nvarchar](2) NULL,
     [COD_SUC] [nvarchar](2) NULL,
     [CUENTA] [nvarchar](25) NOT NULL,
     [NOMBRE] [nvarchar](50) NOT NULL,
     [GRUPO] [tinyint] NOT NULL,
     [TIPO] [nvarchar](1) NOT NULL,
     [NIVEL] [tinyint] NOT NULL,
     [PADRE] [nvarchar](25) NULL,
     [FECHA] [datetime] NOT NULL)

    CREATE TABLE [dbo].[TblDiarios](
    [IDDiario] [int] NOT NULL,
    [Cod_Emp] [nvarchar](2) NOT NULL,
    [COD_SUC] [nvarchar](2) NOT NULL,
    [COD_DIA] [nvarchar](8) NOT NULL,
    [NUM_MOV] [nvarchar](7) NOT NULL,
    [REFERENCIA] [nvarchar](60) NOT NULL,
    [VALOR] [float] NULL,
    [CONCEPTO] [ntext] NULL,
    [FECHA] [datetime] NOT NULL,
    [TOT_DEB] [float] NULL,
    [TOT_CRE] [float] NULL,
    [TIPO_CAMB] [float] NOT NULL,
    [MONEDA] [tinyint] NOT NULL,
    [Tipo] [tinyint] NOT NULL,
    [FEC_ING] [datetime] NULL
    )

    CREATE TABLE [dbo].[tblDetalle_Diario](
    [IDDiario] [int] NOT NULL,
    [COD_SUC] [nvarchar](2) NULL,
    [CUENTA] [nvarchar](25) NULL,
    [TOT_DEB] [float] NULL,
    [TOT_CRE] [float] NULL,
    [DESC_MOV] [nvarchar](60) NULL,
    [NUM_LIN] [smallint] NULL
    )

    1 ACTIVOS 0 G 1 NULL
    11 ACTIVO CIRCULANTE 0 G 2   1
    111 CAJA 0 G 3   11
    111-02 OFICINA CENTRAL  0 G 4   111

    lo que ando buscando es realizar el proceso de mayorizacion de forma automaticamente , o sea cualquier comprobante que caiga ,En ese instante que me actaulize las cuentas, actualmente el proceso de mayorizacion tengo que generalo mes a mes desde una pantalla y es muy tardado, pienso que haciendo de la manera que les planteo sera mas rapido. quisiera saber como puedo hacer para realizar ese calculo que les plantee al inicio ???, lo de la recursion lo descarte.

    en espera de sus comentraios.


    Guido.




    viernes, 02 de marzo de 2012 5:52
  • denisenrique,

    No veo nada claro cómo resolver el problema con la estructura que tienes.

    Yo comenzaría por enfocarme en los conceptos más básicos: cuentas y apuntes.

    • Cuenta: es una clasificación contable que corresponde a un (y sólo un) concepto y refleja la situación de la empresa en relación a ese concepto. y que es objeto de operaciones llamadas apuntes contables.
    • Apunte: es una operación contable que ocurre en un momento determinado en el tiempo afecta a una o varias cuentas y que está sujeta a ciertas validaciones.
    • Libro de diario: Es una colección de todos los apuntes contables, ordenados de forma cronológica.
    • Libro de mayor: Es una colección de apuntes, organizados y agrupados por cuentas, aunque también se refiere a la fotografía de los saldos de las cuentas en un instante de tiempo.

    Desde una perspectiva purista de diseño de base de datos, tanto el libro de diario como el libro de mayor son vistas sobre los mismos datos.

    Un modelo (relacional) muy elemental podría ser así:


    Con esta estructura, tu tabla de apuntes sería así:

    Apunte

    • Id_Apunte
    • Fecha
    • ...otros datos del apunte...

    Cuenta

    • Id_Cuenta
    • Id_Cuenta_Padre
    • Saldo_Inicial

    Apunte_Cuenta

    • Id_Apunte 
    • Id_Cuenta
    • Afectación (Por el debe o por el haber)
    • Importe

    Con esta estructura, conocer el saldo en un instante determinado es muy fácil:

    SELECT Cuenta.Id_Cuenta, Saldo_Inicial + NVL(Acumulado,0)
    FROM Cuenta
    LEFT JOIN 
    (
       SELECT ID_Cuenta, 
       SUM(Importe * Signo(Afectación)) Acumulado
       FROM Apunte_Cuenta 
       GROUP BY ID_CUENTA
    ) AS X
    ON Cuenta.Id_Cuenta = X.Id_Cuenta

    En este momento tenemos el libro de mayor a nivel de cuentas de movimientos. ¿Cómo obtienes los saldos a nivel de todas las cuentas? Hay varias formas:

    1) Usando queries recursivos (funciona en la mayoría de los manejadores de bases de datos que soporte el estándar SQL:1999 (ISO/IEC 9075-2:1999) y otros como Oracle que tienen su propia sintaxis. No lo recomiendo porque la sintaxis de los queries recursivos es complicada (y más complicado entender los resultados de un query xD )

    2) Mediante código imperativo usando recursión (stored procedures, métodos o funciones en cualquier lenguaje): se implementa una función de totalización que hace lo siguiente:

    Para cada cuenta:

    - Si la cuenta tiene movimientos, obtener saldo sumando los apuntes que la afectan.

    - Si no: obtener su saldo sumando los saldos de las cuentas "hijas".

    Ojalá te sirvan de algo estas ideas.

    Saludos,

    Yván Ecarri Gómez



    logo osoft
    Si he contestado tu pregunta, por favor marca mi post como respuesta.
    ...Y si mi post te ha servido, márcalo como útil smile

    • Marcado como respuesta denisenrique viernes, 09 de marzo de 2012 6:52
    miércoles, 07 de marzo de 2012 9:44
  • la mayorizacion de partidas se realiza de menor a superior jerarquia
    miércoles, 09 de enero de 2013 22:28