Error en Reporte Cuenta Corriente

Inicio Foros Foro principal Desarrolladores Error en Reporte Cuenta Corriente

  • Este debate está vacío.
Viendo 15 entradas - de la 1 a la 15 (de un total de 15)
  • Autor
    Entradas
  • #32624
    Gabriel Bocalandro
    Participante

    No se si le habrá pasado a alguien mas. Si tengo una factura que se debe pagar en cuotas (ej, 30,60, 90) correctamente el sistema me lo divide en 3 lineas. El importe queda dividido correctamente en 3, pero en las linea de DEBE o HABER me sale siempre el total, con lo cual se me triplica el saldo.

    En la versión ACTUAL (tomada del repositorio), no está corregido. Si está la opcion para mostrar agrupado o detallado, pero el debe – haber y saldo sigue calculandose mal.

    Me darían una mano con esto?

    Por otro lado en el mismo caso en el reporte de Estado de cuenta, me muestra bien el importe, pero en el pagado me muestra el total, quedando Importe 5000, pagado 15000

    Gracias

    #38159
    Federico Cristina
    Superadministrador

    Buenas,

    Justamente hoy estuvimos viendo ese tema para el reporte de Cuenta Corriente. Revisión 825.

    Saludos,
    Federico

    #38161
    Gabriel Bocalandro
    Participante

    Buenisimo!!!!

    Lo pudieron solucionar???

    Puedo levantar el código y probarlo?

    Los puedo ayudar? Muchas gracias!!

    #38162
    Gabriel Bocalandro
    Participante

    Muchas Gracias. Bajé la nueva versión y sigue dando el error.

    #38164
    Federico Cristina
    Superadministrador

    Tenés que actualizar la función invoiceOpen según los cambios del archivo preinstall_from_13.01.sql de la revisión 825.

    #38165
    Gabriel Bocalandro
    Participante

    Exacto. Hice eso

    Lo que actualicé fue…

    en SQL

    — 20140219-1235 Correccion en funcion para el calculo de facturas anuladas (signo negativo) y con c_invoicepayschedule
    CREATE OR REPLACE FUNCTION invoiceopen(p_c_invoice_id integer, p_c_invoicepayschedule_id integer)
    RETURNS numeric AS
    $BODY$
    /*************************************************************************
    * The contents of this file are subject to the Compiere License. You may
    * obtain a copy of the License at http://www.compiere.org/license.html
    * Software is on an “AS IS” basis, WITHOUT WARRANTY OF ANY KIND, either
    * express or implied. See the License for details. Code: Compiere ERP+CRM
    * Copyright (C) 1999-2001 Jorg Janke, ComPiere, Inc. All Rights Reserved.
    *
    * converted to postgreSQL by Karsten Thiemann (Schaeffer AG),
    * kthiemann@adempiere.org
    *************************************************************************
    ***
    * Title: Calculate Open Item Amount in Invoice Currency
    * Description:
    * Add up total amount open for C_Invoice_ID if no split payment.
    * Grand Total minus Sum of Allocations in Invoice Currency
    *
    * For Split Payments:
    * Allocate Payments starting from first schedule.
    * Cannot be used for IsPaid as mutating
    *
    * Test:
    * SELECT C_InvoicePaySchedule_ID, DueAmt FROM C_InvoicePaySchedule WHERE C_Invoice_ID=109 ORDER BY DueDate;
    * SELECT invoiceOpen (109, null) FROM AD_System; – converted to default client currency
    * SELECT invoiceOpen (109, 11) FROM AD_System; – converted to default client currency
    * SELECT invoiceOpen (109, 102) FROM AD_System;
    * SELECT invoiceOpen (109, 103) FROM AD_System;
    ***
    * Pasado a Libertya a partir de Adempiere 360LTS
    * – ids son de tipo integer, no numeric
    * – TODO : tema de las zonas en los timestamp
    * – Excepciones en SELECT INTO requieren modificador STRICT bajo PostGreSQL o usar
    * NOT FOUND
    * – Por ahora, el “ignore rounding” se hace como en libertya (-0.01,0.01),
    * en vez de usar la precisión de la moneda
    * – Se toma el tipo de conversion de la factura, auqneu esto es dudosamente correcto
    * ya que otras funciones , en particular currencyBase nunca tiene en cuenta
    * este valor
    * – Como en Libertya se tiene en cuenta tambien C_Invoice_Credit_ID para calcular
    * la cantidad alocada a una factura (aunque esto es medio dudoso….)
    * – No se soporta la fecha como 3er parametro (en realidad, tampoco se esta
    * usando actualmente, y se deberia poder resolver de otra manera)
    * – Libertya parece tener un bug al filtrar por C_InvoicePaySchedule_ID al calcular
    * el granTotal (el granTotal SIEMPRE es el total de la factura, tomada directamente
    * de C_Invoice.GranTotal o a partir de la suma de los DueAmt en C_InvoicePaySchedule);
    * se usa la sentencia como esta en Adempeire (esto es, solo se filtra por C_Invoice_ID)
    * – Nuevo enfoque: NO se usa ni la vista C_Invoice_V ni multiplicadores
    * se asume todo positivo…
    * – El resultado SIEMPRE deberia ser positivo y en el intervalo [0..GrandTotal]
    * – 03 julio: se pasa a usar getAllocatedAmt para hacer esta funcion consistente
    * con invoicePaid
    * – 03 julio: se pasa de usar STRICT a NOT FOUND; es mas eficiente
    ************************************************************************/
    DECLARE
    v_Currency_ID INTEGER;
    v_TotalOpenAmt NUMERIC := 0;
    v_PaidAmt NUMERIC := 0;
    v_Remaining NUMERIC := 0;
    v_Precision NUMERIC := 0;
    v_Min NUMERIC := 0.01; — en Adempiere inferido desde Currency
    s RECORD;
    v_ConversionType_ID INTEGER; — NO en Adempiere

    BEGIN
    — Get Currency, GranTotal, MulitplerAP , MutiplierCM, ConversionType, and precision
    SELECT C_Currency_ID, GrandTotal, C_ConversionType_ID,
    (SELECT StdPrecision FROM C_Currency C WHERE C.C_Currency_ID = I.C_Currency_ID)
    AS StdPrecision
    INTO v_Currency_ID, v_TotalOpenAmt, v_ConversionType_ID,v_Precision
    FROM C_Invoice I — NO se corrige por CM o SpliPayment; se usa directamente C_Inovoice y ningun multiplicador
    WHERE I.C_Invoice_ID = p_C_Invoice_ID;

    IF NOT FOUND THEN
    RAISE NOTICE ‘Invoice no econtrada – %’, p_C_Invoice_ID;
    RETURN NULL;
    END IF;

    — se saca lo siguiente para hacerlo tal como lo hace Libertya; igual tiene cierto sentido usar estos limites, sal vo que en Libertya
    — se usa 2 decimales en todos los montos….
    –SELECT 1/10^v_Precision INTO v_Min;

    — Calculate Allocated Amount : SIEMPRE 1 como multiplicador
    v_PaidAmt := getAllocatedAmt(p_C_Invoice_ID,v_Currency_ID,v_ConversionType_ID,1);

    — Do we have a Payment Schedule ?
    IF (p_C_InvoicePaySchedule_ID > 0) THEN — if not valid = lists invoice amount
    v_Remaining := v_PaidAmt;
    FOR s IN
    SELECT C_InvoicePaySchedule_ID, DueAmt, sign(DueAmt) as signo
    FROM C_InvoicePaySchedule
    WHERE C_Invoice_ID = p_C_Invoice_ID
    AND IsValid=’Y’
    ORDER BY DueDate
    LOOP
    IF (s.C_InvoicePaySchedule_ID = p_C_InvoicePaySchedule_ID) THEN
    v_TotalOpenAmt := abs(s.DueAmt) – v_Remaining;
    IF (v_TotalOpenAmt < 0) THEN
    v_TotalOpenAmt := 0; — Pagado totalmente
    END IF;
    v_TotalOpenAmt := s.signo * v_TotalOpenAmt;
    EXIT; — se sale del loop, ya que ya se encontro
    ELSE — calculate amount, which can be allocated to next schedule
    v_Remaining := v_Remaining – abs(s.DueAmt);
    IF (v_Remaining < 0) THEN
    v_Remaining := 0;
    END IF;
    END IF;
    END LOOP;
    ELSE
    v_TotalOpenAmt := v_TotalOpenAmt – v_PaidAmt;
    END IF;
    — RAISE NOTICE ”== Total=” || v_TotalOpenAmt;

    — Ignore Rounding
    IF (v_TotalOpenAmt >= -v_Min AND v_TotalOpenAmt <= v_Min) THEN
    v_TotalOpenAmt := 0;
    END IF;

    — Round to currency precision
    v_TotalOpenAmt := ROUND(COALESCE(v_TotalOpenAmt,0), v_Precision);
    RETURN v_TotalOpenAmt;
    END;

    $BODY$
    LANGUAGE plpgsql VOLATILE
    COST 100;
    ALTER FUNCTION invoiceopen(integer, integer)
    OWNER TO libertya;

    En Libertya, el archivo CurrentAccountReport.java

    Aun así me sigue dando el error.

    Les puedo mandar algo o quieren que haga alguna prueba para mostrarles?

    Muchas gracias

    #38166
    Gabriel Bocalandro
    Participante

    Aporto un DATO IMPORTANTE, por si sirve.

    Adjunte al final de la consulta esto: invoiceOpen(d.document_id, coalesce(d.c_invoicepayschedule_id,0))

    Y en los casos donde falla me devuelve 0, es decir, que está COBRADA!

    #38160
    Gabriel Bocalandro
    Participante

    Bueno, seguí analizando el tema. No le encuentro una solución simple. La forma de reproducirlo, por ejemplo, es hacer una factura en 3 pagos, Luego una nota de credito en 3 pagos para anular la factura y aplicar una con la otra.

    Asi van a poder reproducirlo

    El tema es que en la tabla C_AllocationLine, no hay referencia al c_invoicepayschedule_id, lo que hace que no pueda determinar del monto aplicado, a que pago corresponde.

    Si saben donde está le esstare muy agradecido..

    Gracias

    #38167
    Federico Cristina
    Superadministrador

    Buenas,

    Gracias por el feedback.

    Hemos podido reproducir el problema. La revisión r830 debería corregirlo. Hay que actualizar la clase Java y aplicar los cambios a nivel base de datos según lo indicado en el archivo preinstall.

    Slds!
    Federico

    #38178
    Gabriel Bocalandro
    Participante

    Excelente. Ya lo estoy probando. Muchísimas gracias.

    #38179
    Federico Cristina
    Superadministrador

    Bárbaro. Esperamos novedades al respecto.

    Saludos!

    #38180
    Gabriel Bocalandro
    Participante

    Excelente!!!!

    Funciona perfecto. Un milón de gracias!!!

    #38181
    Gabriel Bocalandro
    Participante

    Excelente!!!!

    Funciona perfecto. Un millón de gracias!!!

    #38182
    Gabriel Bocalandro
    Participante

    Estimados. Revisando el reporte de saldos, me encontré que tampoco coincide con el de la cuenta corriente y el estado de cuenta.

    Ejemplo, si hago una reversión, o cancelación, o si elimino deuda pendiente, el listado de saldo la sigue reflejando.

    No llegué a determinar bien en que casos no funciona, pero si quieren sigo investigando.

    NOTA: El reporte este es el de la versión 13.01. Si quieren que actualice me avisan

    Gracias

    #38183
    Gabriel Bocalandro
    Participante

    Encontré un error en el listado de cuenta corriente. No está tomando el tipo de cambio del momento que se hace el comprobante, sino que lo está convirtiendo al tipo de cambio del día que se consulta, y cuando un cliente tiene saldo 0, de golpe pasa a tener un montón de saldo. Esto es en la nueva versión.

    Gracias

Viendo 15 entradas - de la 1 a la 15 (de un total de 15)
  • Debes estar registrado para responder a este debate.