[Javier Ader]

Jajaja Federico, ya se que puedo ingresar el número de comprobante, es más te obliga a que ese numero se mayor que cero (lo mismo para el punto de venta). El punto es que esos valores no van a parar ni al libro de IVA, ni a la columna DocumentNo.
Hace una factura de compra,y despues hace el libro de iva de proveedores; vas a ver que te aparece en el numero de comprobante un número entero e interno (el número de secuencia).
A la afip no le podes mostrar eso, le tenes que mostrar el numero de documento real que te llega en la factura, esto es, A0001-00000021 y no digamos, 12332.
Aún cuando para la AFIP o para la exportación modfiques los informes de libro de iva para que tome NumeroDeDocumento en vez de DocumentNo, en la ventana Factura de Proveedores, no tiene mucho sentido mostrar 12332, ya que no sabes a que factura real de proveedor se esta refiriendo.

[Javier Ader]

No no, me estoy refiriendo a facturas de Compra, no de venta…
En las facturas de compra el numero de documento (digamos A0001-00000021) lo tenes que ingresar manualmente siempre, ya que ese numero no depende de vos, si no del proveedor.
El tema es que en la versión anterior, y en por lo que dice el codigo actual, uno ingresa manualmente este numero, pero lo hace indirectametne: la letra la define la ventanda (Facturas(Proveedores) ), el número de punto de venta (el 1 en el ejemplo) y el numero de comprobante (el 21 en ejemplo ), los tenes que ingresar.
Actualmente parece hacer esto, pero en algún punto, el DocumentNo es tomado desde alguna secuencia, en el valor ““, es pisado con el valor de esta secuencia.
Despues sigo debuggenado o mirando como funcionaba en la versión anterior.

OBS: el valor “” es salvado en dos columnas al parecer. DocumentNo, que es el que se muestra en la ventana y el que es el mostrado en los libros de IVA, y en otra columna llamada NumeroDeDocumento (pero esta no es mostrada en la ventana). En las facturas de venta, DocumentNo y NumeroDeDocumento terminan con el mismo valor, pero en las compra NumeroDeDocuemnto toma el valor correcto, mientras que DocumentNo, toma un numero de secuencia que no tiene mucho sentido.
Me parece que el tema viene por este lado….La unica diferencia que hay, en esta versión, entre las facturas de compra y la de ventas, es que el tipo de documento “Facturas de Proveedores” NO tiene asociada una secuencia (extrañanamente! la que no tiene asociada una secuencia termina pisando el valor DocumentNo con un valor de secuencia!!!!).
Lo que hay que tener en cuenta es que DocumentNo es un nombre de columna tratado de manera especial dentro del framework… pero antes era tratado correctamente!

[Javier Ader]

Bueno agrego:
Al parecer mi idea de que las facturas de proveedores el numero de documento (DocumentNo, NO DocumentoNumero) se genera automáticamente es correcta a nivel de codigo a partir de la letra, el numero de comprobante y el de punto de venta:
me puse a debuggear y en beforeSave de MInvocie efectivametne se calcula este valor y se lo guarda en en DocumentNo, e.d la siguiente sentencia se ejecuta realmente

Code:

setDocumentNo(CalloutInvoiceExt.GenerarNumeroDeDocumento(getPuntoDeVenta(), getNumeroComprobante(), getLetra(), IsSOTrx));

Ahora, algo debe pasar DESPUÉS del beforeSave() que de alguna manera resetea a algún tipo de numeración automática (algo a partir de PO.save() casi seguro…). El tema es que ahora estoy seguro que en la versión pre 10.03 esto andaba de manera correcta… Que paso?

[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…)

[Javier Ader]

Si te logueas con el mismo nombre de usuario y password que usaste para postear en este foro te debería permitir descargar… creo.

[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)

[Javier Ader]

Te estás logueando en algo que no es una compañia. Para loguearte en la real tenes que usar el Usuario AdminLibertya; password AdminLibertya. Los modulos que nombras estan asociados a los perfiles que escojas luego de ingresar nombre de usario y password.

[Javier Ader]

Buenas Federico, vi tu post después de postear el mio.
El tema de las cuentas contables preexistentes es que no se pueden eliminar (no solo porque la ventana no lo permite, sino porque ademas están en su mayoría reverenciadas desde muuuchos lados, por ej, desde las “combinaciones válidads” defaults), y tampoco veo muchas razones para hacerlo (son de utilidad real en casi todos los casos; el cliente puede a lo sumo querer cambiarle el nombre y/o su posición en la estructura). Mirando las cuentas que están en el archivo de importación dado en Libertya, las preexistentes están referenciadas, el tema es que el proceso de importación seguramente no “reparentea” las cuentas preexistentes, solo las nuevas.

En cuanto a “Cuentas Contables asociadas a cuentas Bancarias”: el pregunta no era referida a la importación; esto,pienso, se debe hacer siempre de manera manual. Mi pregunta es si es necesario o que implicaciones tiene especificar una cuenta contable como “Cuenta de Banco” (e.d, no solo asociarle a la cuenta bancaria su propia cuenta contable, si no que tambien la cuenta contable asociarle la cuenta bancaria… jaja no se si se entiende…). Después veo si a nivel de codigo en algun lado se referencia a este campo por el procesador contable (que muy bien no se por donde anda, pero en algun alguien tiene que referenciar a este campo, si es que lo usa claro…) y si puedo inferir su significado. El campo y columna en cuestión es el checkbox Cuenta De Banco que a nivel de columna va a parar a C_ElementValue.isbankaccount.

AGREGO: bueno jaja, tampoco vi tu último último post ; estamos casi chateando jajaj.
Si, me dieron toda la sensación de ser cuentas puentes; y seguro que la ubicación gráfica no tiene mayor importancia; el tema es si el tipo de las cuentas en cuestión es correcto (que dicho sea de paso, tampoco investigue en que influye el tipo de cuenta contable al procesador contable… tal vez, no tenga ninguna diferencia ponerle cualquier tipo, y sea solo para referencias de los usuarios…)

[Javier Ader]

Bueno, voy poniendo algunas soluciones que voy encontrando:

Importación: en realidad no tiene tanto que ver con la importación lo que planteo, sigo que el arbol contable asociado no queda bien (hay cuentas que no se ven en arbol despues de la importación; pero tampoco se veían antes).
Solución:
Diagramas de Arbol-> se selecciona “Libertya valor del Elemento (Cta, etc)” (que es el arbol asociado al plan de cuentas), y se presiona “Verificar Arbol” (cuyo nombre es bastante dudoso ya que el proceso asociado elimina e insertan nodos; e.d, el nombre podría ser “Arreglar Arbol” o algo por el estilo). Ese proceso por un lado elimina nodos del arbol que no apuntan a una cuenta contable y por el otro, crea nodos para cada una de aquellas cuentas contables (no importa si son o no “carpetas”) a las que no hay ningun nodo que la apunte; esto hace que estos cuentas contables “huerfanas” queden como “raices del arbol” (van aparecer en el primer nivel). En mi caso me elimino un nodo preexistente a la importación que no apuntaba a ninguna cuenta (Nodo_Id = 0) y que realidad no se porque estaba; y me creo uno nodo raiz por cada uno las cuentas preexistentes a la importación.
Este proceso, de cualquier manera NO AFECTA a las cuentas contables en si; lo tabla que se ve afectada es AD_Tree_Node, mientras que la que guarda las cuentas contables es C_ElememnentValue.
Depues de esto, bueno, hay que agarrar una por una las cuentas preexistentes y moverlas (ojo, es bastante “tramposo” el control gráfico del árbol) a las carpetas contables.

Aprovecho y planteo otra pregunta:

Cuentas Contables asociadas a Impuestos (manuales):
Por ej, me llegan percepciones de IIBB en las facturas de Proveedor. Por lo que estuve investigando a nivel de código tengo que crear una Categoría de Impuesto Manual, sobre esta, un Impuesto (digamos IIBB). Ahora, en la solapa contable debería cambiar las entradas para IVA Repercutido y IVA Soportado (mal nombrados a mi parecer; supongo que el nombre debería ser Débito Fiscal y Crédito Fiscal, de última a nivel de descripción del campo poner “Débito/Crédito fiscal (por ej, IVA-Debito/Credito Fiscal”), no? Bueno, el impuesto esta pensado para Percepciones Sufridas de IIBB, que cuenta debería poner? Ok, esta pregunta no tiene mucho que ver con Libertya en si no con contabilidad general… asi que la pregunta es: cuando haga una factura de proveedor con este impuesto manual, contablemente, me va a afectar la cuenta que este relacionada con “IVA-Soportado” no? (Si fuese así, acá tendría que poner una cuenta del activo que represente este crédito no? Digamos, 1.01.03.23 PERCEPCION INGRESOS BRUTOS (si fuese así, supongo que el nombre de la cuenta quedararia más correcto como “PERCEPCIONES SUFRIDAS IIBB”.)

Pagos en Efectivo/Bancarios en Transito: esto no se si esta mal, pero por las dudas lo planteo. Estas dos cuentas son tipo Activo, cuando están el subarbol del Pasivo. Esta bien esto? No pasa lo mismo con sus contrapartidas “Cobros XXX en transito”; por ej Cobros bancarios en transito, es de tipo Activo y se encuentra en el subarbol Activo.

[Javier Ader]

A o C? Bueno, igual: las C sola la emitien los monotributistas (y lo hacen para todos los tipos de categorias del comprador). Estos es, si seleccionas Monotributista en tu definición de compania siempre va a ser C.
Ahora, si seleccionas Responsabe Inscripto, la letra depende de la categoría del comprador. En el TPV, no recuerdo bien, pero la categoría de IVA del “comprador desconocido” es siempre Consumidor Final (tiene todo el sentido que sea asi; por que de otra manerea necesitas saber el CUIT). La reglas es que un Responsable Inscripto debe emitir facturas B a un Consumidor Final (de ahí la letra B sea la escogida).
En el TPV, la unica forma que veo que te emita una factura A es teniendo el comprador previamente cargado en el sistema y con categoria Responsable Inscripto, y al momento de facturar en TPV, escoges este cliente (en vez del pseudocliente que usa el TPV por defecto).

[Javier Ader]

Si no estoy equivocado, las facturas C solo la emiten los monotributistas; no es una cuestión de elección.
Casi seguro que Libertya esta usando tu definición de categoría de IVA, la cual esta definida en la primer o segunda solapa de Compania (si ahi no sos monotributista, no te va a dejar emitir C). Con esta categoría y la de tu cliente, escoge automáticamente la letra de la factura.

[Javier Ader]

No necesitas desinstalar Postgres….

[Javier Ader]

agregando un comentario a la ultimo que dijo congnitiva:
No es estrictamente necesario eliminar la base de datos actual; simplemente antes de cargar el dump tenes que crear otra base de datos, digamos libertya2, con owner libertya (el usuario que te creo la instalación anterior) y encoding UTF8. Cuando cargas el dump, en vez de especificar libertya como la base de datos sobre la cual cargar, especificas libertya2 (lo mismo cuando configures pl/java).
Una vez hecho esto es como si tuvieses, no dos companias, si no dos instalaciones distintas. Ahora, tenes que configurar lo que sea necesario para que vez de acceder a la base de datos libertya, acceda a libertya2:
-detenes el servidor, vas a configurar.exe y nombre de base datos pones libertya2 (ojo, no te confundas con el nombre de usario). Guardas.
-cuando abris el cliente, vas la confirmación de conexión (el candito) y reejeuctas el testeo del servidor (lo tenes que iniciar previamente). Si todo va bien , el test te tiene que dar ok y ADEMAS te debería setear el campo de nombre de base de datos de libertya a libertya2.

Otra forma de hacer lo mismo es, sin necesidad de tener que andar cargando el dump manualmente es: desinstalas libertya; volves a correr el instalador automático y cuando te pide el nombre de la base de datos, cambia libertya a libertya2 (o lo que quieras). Creo que esto te va dejar la base de datos antigua, porque si no me equivoco, el deinstalador de libertya no elimina la base de datos creada en la instalación (creo…). Esto te va a crear la base de datos libertya2 y te va configurar todo lo necesario (el cliente puede que tengas que configurarlo de todas maneras).

Fijate que de esta manera vas a poder acceder (previa configuración) a cualquiera de las dos base de datos.

[Javier Ader]

lo que le debe haber faltado es “registrar” las clases Libertya que implementan las funciones definidss con pljava

Para hacer esto
1) abris pgAdmin (supongo que lo tenés, si no lo vas a tener que instalar o ver la forma de hacerlo desde la consola)
2) te loguea en el servidor escogiendo la base de datos Libertya. Verifica que exista el esquema sqlj ademas de libertya y public.
3) abris el edito sql y ejecutas las siguientes “consulta”:

Code:

SELECT sqlj.install_jar(‘file:///C:/sqlj.jar’, ‘sqlj’, false);
SELECT sqlj.set_classpath(‘public’, ‘sqlj’);

Esto asume que previamente copiaste el archivo sqlj.jar a la raiz del disco C (lo tenés que hacer obviamente).

Ahora, porque será que se complican usando el dump…. el instalador automático casi nunca trae problemas.

[Javier Ader]

Supongo que ya la encontraste, pero bueno, por las dudas el nombre completo de la clase es
net.sf.jasperreports.engine.JREmptyDataSource
Un ejemplo de clase que la usa es LauchOrdenPago (el informe de la orden de pago)

[Autor]

Entradas