- Este debate está vacío.
-
Entradas
-
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
Buenas,
Justamente hoy estuvimos viendo ese tema para el reporte de Cuenta Corriente. Revisión 825.
Saludos,
FedericoBuenisimo!!!!
Lo pudieron solucionar???
Puedo levantar el código y probarlo?
Los puedo ayudar? Muchas gracias!!
Tenés que actualizar la función invoiceOpen según los cambios del archivo preinstall_from_13.01.sql de la revisión 825.
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 AdempiereBEGIN
— 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
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!
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
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!
FedericoEstimados. 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
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
- Debes estar registrado para responder a este debate.
