Reprocesando ( y renegando) Bienes de Uso

Está entre las cosas que más trabajo me dio …

Había implementado el módulo por mi cuenta, sin tener ninguna idea, en el año 2002 y de ahí gran parte de los problemas.

A continuación un Resumen de los puntos a tener en cuenta:

Carga de Saldos Iniciales

Tenía Bienes con amortizaciones acumuladas. Mi error fue cargar dichas amortizaciones en campos de usuario y el valor remanente como valor de Origen.

Ej. :

• Bien de $ 1000 .
• vida útil: 10 años
• años acumulados : 2
• amortizaciones acumuladas: $ 200
• Cargado como : valor de origen$ 800, años de vida útil: 8. Vida útil y valor de origen Original, en campos de Usuario.
• Desventajas: Complejidad en los reportes. Al dar de baja el bien, el sistema genera el asiento por las amortizaciones acumuladas, y por supuesto no tiene en cuenta las cargadas en los campos de usuario. Había que hacer un asiento complementario.

Caso análogo para los ajustes.

La solución: cargar los saldos iniciales como movimientos en la RVRMVI. Ésto de hace por tablas. Trabajo efectuado por Rafael Pont Lezica, de Penta Consulting .
Ésto obligó a hacer un reproceso del proceso de amortización, desde el momento de puesta en marcha del módulo hasta la fecha, y de ahí la serie de errores que empezó a arrojar el sistema.

Errores en el Reproceso

1. Divition by zero: Se da cuando no hay coherencia entre la fecha de puesta en marcha y las amortizaciones registradas. Ej: un bien con fecha de puesta en marcha 31/12/95 , con vida útil 10 años y con criterio de amortización Mes o Año de Alta, debería terminar de amortizar en el 2004. Si para esa fecha ésto no sucede y el sistema intenta amortizarlo en el 2005 arroja el “divition by zero”. Explicación: En el sistema anterior estaba cargada erroneamente la fecha de puesta en marcha como la fecha de compra, y no la fecha en que empezó a amortizar. Por ej: fecha de compra: 20/12/94, fecha de puesta en marcha : 01/01/95.
2. Amortizaciones no efectuadas en reproceso: Ésto sucede porque al terminar de amortizar, el sistema le pone el check de amortizado al maestro de Bienes ( campos RVMBIE_AMCADO para el revalúo Contable y RVMBIE_AMIADO para el Impositivo ). Para ver cuales son ésto casos, correr las siguientes consultas(.rar). Cuando esté todo bien, no deberían arrojar registros. Caso contrario hay que sacarle el check de amortizado a los bienes listados, para reprocesar.
3. Error al grabar rvrmvd. Posteado aqui. Sucede cuando hay movimiento de bajas en periodos posteriores al del reproceso. Se soluciona cambiando transitoriamente el número de otros.

Otros Errores detectados

Al reprocesar y empezar a hacer controles, me percaté que el sistema no hace el asiento de baja para los bienes que ya están totalmente amortizados, situación posteada aquí . La solución( gracias a Rafael, de Penta ).

• Sacarle el check de amoprtizado al bien
• grabar el la RVRMVI, para el periodo anterior, un movimiento al debe y al haber con el campo RVRMVI_AMORTI en cero. El Stored Procedure, aqui(.rar)

La siguiente es una consulta para detectar las bajas no tamadas por el proceso( correrla luego del proceso de revalúo): aqui(.rar)
Resumen de los Asientos Contables

Para lograr comprender el porque es un error que el sistema no genere al asiento de baja para el caso anterior, un resumen de los asientos involucrados en las operaciones que involucren Bienes de Uso.

Compras

Bienes de Uso xxxx

Proveedores xxxx

se contabiliza por : módulo PV ( factura del proveedor )

A mortizaciones

Amortizaciones Bienes de Uso xxx

Amortizaciones acum bs de uso xxx

se contabiliza por : RV

V enta

Deudores por ventas xxx

ventas bs de uso xxx

se contabiliza por : VT ( en éste caso venta en cta cte )

y,

Amortizaciones Acum de Uso xxx 1)

Costo Bienes de Uso xxx 2)

bs de uso valor de origen xxxx 3)

Se contabiliza por: RV

1) Importe correspondiente a RVRMVI_AMOACU del periodo anterior

2) Importe correspondiente a RVRMVI_VARESA del periodo anterior

3) Importe correspondiente a RVRMVI_ORIGEC ( para el revalúo contable) del periodo anterior .

En el caso de que un bien esté totalmente amortizado el concepto 2) debe generarse en cero.

Listados

Necesitaba un listado que dado un periodo dado, emita un detalle de todos los bienes que no estén dados de baja, con el detalle del revalúo para ese año. No encontré ninguno que viniera con el sistema. El detalle del revalúo basado en la rvrmvi no emite los bienes ya amortizados ( para los cuales no se generan movimientos a partir de la fecha en que dejan de amortizar), y si se intenta sacar desde el maestro de bienes no se puede, ya que los checks como RVMBIE_AMCADO ( amortizado contable ) son estáticos, no tienen en cuenta fechas.

Además, ví que tratar de emitir dicho listado genera muchas consultas correladas , lo cual es bastante ineficiente.

La solución, un reporte basado en una vista. La vistas( usr_v_rvinve y usr_v_rvperi ) involucradas aqui y aqui, la tabla con las vistas involucradas y el reporte aqui

Explicación de la Vista

USR_V_RVPERI A, usado en el join , trae todos los periodos posibles desde que se puso en marcha el módulo RV hasta la fecha.

USR_V_RVINVE_PERIOD es es periodo buscado, y es el que aceptará como parámetro el ReportEditor.

El objetivo es, dado un USR_V_RVINVE_PERIOD, buscar en la RVRMVI el último registro que contenga los datos del bien. Ésto lo logro con el JOIN :
JOIN USR_V_RVPERI ON
( RVRMVI.RVRMVI_PERIOD <= USR_V_RVPERI_PERIOD )

y con el Tiebreaker:

AND (CAST(rvrmvi_period AS VARCHAR(7))+RVRMVI_TIPMOV) =
( select top 1 (CAST(I.rvrmvi_period AS VARCHAR(7))+I.RVRMVI_TIPMOV)
from rvrmvi i
where

I.RVRMVI_TIPREV = RVRMVI.RVRMVI_TIPREV AND
I.RVRMVI_TIPPRO = RVRMVI.RVRMVI_TIPPRO AND
I.RVRMVI_ARTCOD = RVRMVI.RVRMVI_ARTCOD AND
I.RVRMVI_NSERIE = RVRMVI.RVRMVI_NSERIE AND
I.RVRMVI_NDESPA = RVRMVI.RVRMVI_NDESPA AND
I.RVRMVI_NOTROS = RVRMVI.RVRMVI_NOTROS and
i.rvrmvi_period <= USR_V_RVPERI_period AND
ISNULL(I.RVRMVI_AJUIMP,”) = ”
order by i.rvrmvi_period desc)

El campo USR_RUBRO es una campo de Usuario creado en la tabla tipo de productos ( STTTPH). Si el bien es principal se tomará directamente, en cambio si es mejora se mtomará del bien principal a que afecta.

Correccion( 16/02/2007) : Estaba trayendo mal el campo AMORTI. La corrección aqui(.rar)