[Javier Ader]

Buenas, tal vez ya lo vieron. La validación asociada al pago de la linea del extracto “C_Payment not in BankStatement” por un lado tiene un bug ya que referencia a una variable de entorno nunca seteada y por no otro lado, no parece hacer lo que dice el nombre. La sentencia sql asociada es

Code:

C_Payment.TenderType in(‘K’) AND
C_Payment.DocStatus in (‘CO’) AND
(@C_BankAccount_Filter_ID@ = 0 OR
C_Payment.C_BankAccount_ID = @C_BankAccount_Filter_ID@)
AND C_Payment.IsReceipt = ‘Y’
AND NOT EXISTS
(SELECT ba.C_BankAccount_ID FROM C_BankAccount ba
WHERE ba.IsChequesEnCartera = ‘N’ AND
ba.C_BankAccount_ID = C_Payment.C_BankAccount_ID)

La variable @C_BankAccount_Filter_ID@ no existe y no es seteada en ningún lado, lo que invalida todo el filtro (el resultado final es como si no si el filtro no estuviese, y el dialogo InfoPayment va a mostrar tooodos los pagos); en Errores genera un nivel de severo “Cannot parse context” en InfoPayment.. Se soluciona cambiandolo por

Code:

C_Payment.TenderType in(‘K’) AND C_Payment.DocStatus in (‘CO’) AND
(C_Payment.C_BankAccount_ID = @C_BankAccount_ID@)
AND C_Payment.IsReceipt = ‘Y’ AND NOT EXISTS
(SELECT ba.C_BankAccount_ID FROM C_BankAccount ba WHERE
ba.IsChequesEnCartera = ‘N’ AND
ba.C_BankAccount_ID = C_Payment.C_BankAccount_ID)

Ahora bien, esto es a nivel de metadatos (lo cual no es una validación muy confiable desde mi punto de vista). La misma validación se debería dar en el PrepareIt o CompleteIt; al menos, la validación de que cada C_Payment.C_BankAccount_ID asociada a cada uno de los lineas (si es que tienen asociado uno claro) sea igual que la cuenta bancaria asociada al extracto; esto último no se hace (esto es, se permite en el extracto de una cuenta que aparezcan pagos realizados usando otras cuentas). Esta validación la considero suficientemente general como para que en realidad este a nivel de código y no de metadatos.

Ok, volviendo al filtro corregido: es correcto? Porque no esta haciendo lo que dice: solo está filtrando pagos asociados a cuentas contables de cheques en cartera (el IsReceipt no lo tengo claro por ahora, pero parece también estar mal si la idea de este campo es “el pago” fue recibido) y que el pago haya sido un cheque (esto excluye a transferencias bancarias?) y que este en estado completo (este es el único que esto 100% de acuerdo)… Pero en ningún momento valida si el pago aparece asociado a alguna linea de algún extracto que es lo que debería hacer si fuese consistente con su nombre!
Me puedo imaginar cual debería ser el filtro correcto, pero pregunto por si alguien ya se topo con este tema y encontró la solución.

[Franco Bonafine]

Hola Javier:

Efectivamente el filtro es incorrecto. Investigando un poco el origen del mismo veo que ese filtro en realidad es el mismo que para un campo Payment en la pestaña de Línea de Boleta de Depósito (que tiene otra validación llamada “C_Paymento to BoletaDeposito”). Por algún error el código de esa última validación se ha “copiado” a la validación del campo Payment en la línea de extracto bancario (Validación “C_Payment not in BankStatement”).

Con lo cual, el código de la validación actual “C_Payment not in BankStatement” es totalmente erróneo y no amerita ni siquiera a una análisis del mismo. Me encargué de buscar en algunos backups el código original de la validación y ya lo he corregido para el próximo release.

A continuación copio el código original de esta validación:

Code:

NOT EXISTS
(SELECT *
FROM C_BankStatementLine bsl
INNER JOIN C_BankStatement bs ON (bsl.C_BankStatement_ID=bs.C_BankStatement_ID)
WHERE bsl.C_Payment_ID=C_Payment.C_Payment_ID
AND bs.DocStatus<>‘VO’)
AND C_Payment.DocStatus IN (‘CO’,’CL’,’RE’)
AND C_Payment.PayAmt<>0 AND C_Payment.IsReconciled=’N’

El tema ahora es analizar si este código es realmente correcto, o si podríamos mejorarlo. Pero eso ya es otro tema…

[Javier Ader]

Sí, me dio la sensación que en releases anterior debía estar bien, por alguna razón no investigue por ese lado.
En cuanto el sql que citas tiene toda la pinta de estar bien; lo unico dudoso es el “RE” (pago con estado “Revertido”?).
De cualquier manera repito que creo correcto que muchas de estas validaciones se deben repetir a nivel de código en el prepareIt o completeIt.
En cuanto a toda la ventana de extracto bancarios le he visto cosas bastantes dudosas en el release actual; si podes mirala un poco.
Por ej, no se puede asignar una boleta de deposito (el campo C_BoletaDeposito_ID directamente no se muestra en las lineas); el checkbox IsReconcilied a nivel de linea, por lo que vi jamás se setea, y la selección de la moneda a nivel de linea es bastante dudosa. El tema en especial de la moneda es que lo usa el procesador contable, pero este dato no se usa para calcular el total del extracto (por lo tanto, al contabilizar un extracto con una linea en otra moneda necesariamente va a generar un asiento desbalanceado)[ver MBankStatementLine.afterSave(); se hace una simple suma]. Pienso que la moneda de la linea debe ser siempre la moneda de cuenta bancaria (por lo tanto este campo en la linea debería ser solo lectura). No he visto muchos extractos bancarios en mi vida, pero me da la sensación que el dato que viene en las lineas del mismo trae el valor de la transacción en la moneda de la cuenta bancaria, que es el valor que realmente importa (si la transacción en realidad se realizo en otra moneda, este dato es solo informativo, ya que el banco va a hacer el deposito o la extracción en la moneda de la cuenta, previa conversión; la tasa conversión que use el banco obviamente no depende de Libertya…)

Ahora, otro tema relacionado, para no hacer otro thread: los extractos bancarios traen IVA y Sircreb (precalculados) que puede usarse como crédito fiscal (para IVA e IIBB), pero que me parece que no estan soportados (los cargos pueden tener IVA, pero me parece que el procesador contable mucho no mira esto). Pienso que se podría agregar esta info con relativa facilidad agregando una tabla al extracto similar a “Otros Impuestos” de la factura de Proveedores. Estos montos deberían ser cargados manualmente a priori (ya que no parece haber un standard en el que estos datos son informados por los bancos…) y afectarían el total del extracto.
A nivel contable creo que no trae muchas mas complicaciones: no solo se cargan las lineas del extracto como pases si no también los las lineas de impuesto (estas ultimas lineas van a parar la cuenta de Crédito Fiscal asociado con el impuesto; tal como se hace en las facturas de proveedor)

[Antonio Calviño]

Javier,
Respecto de la moneda, es correcto lo que indicas: el extracto tiene una sola moneda (la cuenta de banco es en una sola moneda)

Respecto del IVA, lo que se hace es crear un cargo (C_Charge) que tenga como cuenta contable la del IVA y eso hace que el registro se contabilice correctamente.
Lo que eso no tiene en cuenta es el informe de libro de IVA. Actualmente las empresas que lo tienen implementado, registran manualmente una factura por el concepto de IVA de bancos para que aparezca en el libro y hacen algun cambio en las cuentas contables del cargo para que cierren contra la de la factura (hoy es viernes y no es momento para ponerme a recordar como es exactamente… )

Saludos
Antonio.

[Javier Ader]

Buenas Antonio. Si se me había ocurrido también hacer algo parecido; básicamente crear un cargo que digamos “IVA Cuentas Bancarias” que acredite sobre la misma cuenta contable que los IVA normales (IVA- Crédito Fiscal, de activo). Por otro lado, el tema de crear una “pseudo factura” del banco teniendo en cuenta este iva, no se si va muy bien. Eso va a permitir que aparezca en el libro de IVA, pero fiscalmente no debe aparecer (por ej, cual es el número de comprobante fiscal asociado a ese crédito?…), ya que no esta realmente asociado a una factura.
De todas maneras, mi solución tampoco soluciona el tema totalmente; aunque pienso que tal vez asociandolo a un impuesto manual permitiría usar los mismo reportes generales asociados a impuestos (o recusarlos con leves modificaciones); por ej, utilizo el mismo impuesto asociado con la retenciones sufridas de IVA.
Bueno, igual tampoco lo veo muy necesario… uno no carga extractos bancarios todos los dias ni tampoco declara IVA… asi que ya con que por lo menos uno lo pueda registrar aunque sea como un cargo ya sirve bastante; el trabajo manual asoiado para recuperar estos créditos fiscales tampoco es tanto.

En cuanto al temas de las múltiples monedas; me puse mirar un poco el procesador contable para los extractos, y si no me equivoco no va a generar un asiento desbalanceado aún cuando haya lineas con distintas monedas: procesa cada linea del extracto por separado (los pases asociados a las mismas estan “siempre” balanceados) pero el monto total del extracto no lo usa en ningún momento cuando de generar los pases (Doc_Bank.createFact())… [pero ojo, este monto si lo usa para saber si esta balanceado! Doc_Bank.getBalance(), ahí la cantidad asociada a Doc.AMTTYPE_Gross la saco de la cabecera del extracto, que por como se crea el extracto es una simple suma que no tiene cuenta las monedas… el tema es que este método solo es llamado si el esquema contable esta configurado para no usar “balanceo en suspenso”,…. e.d el getBalance() puede respondería algo distinto de cero aún cuando el asiento que se generaría estaría balanceado necesariamente balanceado…)

[Autor]

Entradas