Lanzamiento de GnuCash 5.9

 (gnucash.org)
2 puntos por GN⁺ 2024-10-02 | 1 comentarios | Compartir por WhatsApp
  • GnuCash 5.9 es la décima versión de la serie estable 5.x e incluye correcciones de errores detectados desde 5.8 junto con mejoras en el análisis de fechas CSV y en las cotizaciones en línea
  • Esta versión corrige 12 errores, incluidos problemas en la ventana de conciliación, mensajes de error del backend MySQL, copiar/pegar transacciones, cierres inesperados al eliminar cuentas y el error de configuración regional del separador decimal del teclado numérico en Windows
  • En las cotizaciones en línea se añadió la configuración de clave API de YH Finance(FINANCEAPI) y la fuente financeapi, mientras que la importación CSV maneja mejor fechas basadas en la configuración regional y nombres de meses en inglés
  • Se ofrecen paquetes para Windows 10 o superior, macOS 10.13 High Sierra o superior y flatpak en Flathub; para compilar manualmente se requieren las dependencias mínimas especificadas como Gtk+, Guile y Boost
  • Los usuarios alemanes de AQBanking usarán el AQBanking 6.5.4 incluido en el paquete, mientras que la nueva implementación beta de PIN/TAN solo está disponible en los nightly builds de GnuCash

Naturaleza de la versión GnuCash 5.9

  • GnuCash 5.9 es la décima versión de la serie estable 5.x
  • GnuCash es un programa de contabilidad gratuito y de código abierto distribuido bajo la GNU General Public License (GPL), y es compatible con GNU/Linux, *BSD, Solaris, macOS y Microsoft Windows
  • Su desarrollo comenzó en 1997 y la primera versión estable apareció en 1998

Principales problemas corregidos desde 5.8

  • Se resolvió el problema por el que las nuevas transacciones agregadas durante la conciliación (reconcile) no aparecían en la ventana de conciliación
  • El backend MySQL ahora reporta el error "access denied" en lugar de "bad or corrupt data" cuando las credenciales son incorrectas
  • Se corrigió el comportamiento de copiar/pegar y cortar/pegar transacciones
    • Esto incluye un problema por el que al cortar/pegar una transacción no se movía la transacción a la cuenta de destino
  • Se corrigió un problema por el que el script de ejemplo en Python mostraba un error al crear un archivo nuevo con el backend sqlite
  • Se corrigió un desajuste en la posición del cursor después de confirmar cambios en una transacción en la vista Transaction Journal
  • Se resolvieron fallas en el análisis de la fecha de conciliación, cierres inesperados al eliminar cuentas y un error en el cálculo trimestral de los offsets de fecha relativa
  • Se corrigió en Windows un problema por el que la entrada del separador decimal del teclado numérico no coincidía con la configuración regional
  • Se corrigieron el problema de la lista desplegable de cuentas demasiado pequeña en la pantalla de publicación de facturas y un problema intermitente con el precio de cotización

Mejoras en cotizaciones en línea e importación CSV

  • Se añadió a la infraestructura de cotizaciones en línea la configuración de clave API de YH Finance(FINANCEAPI)
    • La configuración relacionada puede gestionarse en la página Online Quotes
    • financeapi se agregó a las fuentes de cotización conocidas
  • El parser de fechas CSV fue mejorado para aprovechar ICU y Boost
    • Analiza fechas del formato Locale de ICU según la configuración regional actual
    • Puede procesar entradas como "3 May 2023" o "2024年9月13日" en LC_TIME=zh_TW.utf8
    • Los formatos d-m-y, m-d-y, y-m-d se reforzaron con los parsers UK/US/ISO de Boost
    • La importación CSV ahora también puede procesar fechas con nombres de meses en inglés como "30 Sep 2023", "May 4, 1978", "2023-Dec-25"
    • Como el parser de Boost no reconoce años de dos dígitos, "30 Sep 24" no es válido
  • Se mejoró la página introductoria del CSV Import Assistant

Limpieza interna y cambios orientados a desarrolladores

  • Se reorganizó la estructura de manejo de elementos copiados
    • copied_class y copied_leader_guid pasaron de variables estáticas a formar parte de la estructura copied_item
    • Quedó más claro que la llamada a clear_copied_item es necesaria antes de usar copied_item
  • Al abrir archivos desde el historial de archivos ahora se manejan correctamente las ediciones sin confirmar
  • gnc_difftime quedó marcado como deprecated porque convierte time64 a double, por lo que no debe usarse
  • Se eliminaron gnc_pricedb_substitute_commodity y gnc_pricedb_lookup_at_time64, que no se utilizaban

Cambios en traducciones y documentación

  • Las traducciones nuevas o actualizadas son Assamese, Chinese(Simplified), Chinese(Traditional), Croatian, Dutch, English(United Kingdom), Hebrew, Hungarian, Macedonian, Norwegian Bokmål, Portuguese(Brazil), Russian, Spanish, Swedish y Turkish
  • El cambio del lado de la documentación es una actualización de versiones de GitHub CI actions
  • En documentación, la traducción al German se agregó o actualizó
  • La participación en traducciones se guía desde el proyecto GnuCash en Weblate

Información relacionada con AQBanking

  • Se incluye una nota separada para los usuarios alemanes de AQBanking
  • El autor de AQBanking sigue trabajando en finalizar el código actualizado de PIN/TAN
  • Los paquetes Flatpak, macOS y Windows de esta versión incluyen la última versión estable, AQBanking 6.5.4
  • Si la versión estable de AQBanking no funciona, puede considerarse la nueva implementación beta incluida en los GnuCash nightly builds
  • La lista completa de errores abiertos puede consultarse en la lista de errores de GnuCash

Paquetes de distribución y requisitos de compilación

  • GnuCash 5.9 se ofrece como paquete all-in-one precompilado para Microsoft Windows 10 o superior y macOS 10.13 High Sierra o superior
    • En Windows se ofrece como instalador
    • El paquete de macOS es una imagen de disco que contiene un bundle de aplicación de arrastrar y soltar
  • También está disponible como flatpak en Flathub.org
  • Los archivos de descarga incluyen tarball, instalador de Windows, dmg para Apple Silicon, dmg para Intel Mac y tarball de documentación
  • El código fuente puede obtenerse desde SourceForge y GitHub en formato bzip2 o gzip, y también puede hacerse checkout directamente desde el repositorio Git
  • Para compilar manualmente se requieren las siguientes dependencias mínimas
  • Para la lista exacta de dependencias y versiones debe consultarse el archivo README.dependencies del código fuente

Documentación de GnuCash 5.9

  • La documentación de GnuCash 5.9 puede consultarse en la página Documentation del sitio web de GnuCash
  • Bajo GnuCash v5 (current stable release) se ofrece lectura en línea y descarga en varios idiomas
  • Los formatos de descarga incluyen pdf, epub, mobi
  • La documentación también está incluida en los bundles de aplicación para macOS y Windows
  • El código fuente de GnuCash Documentation 5.9 puede obtenerse desde SourceForge o GitHub, y también puede hacerse checkout directamente desde el repositorio Git

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-02
Opiniones de Hacker News

  • Uso GnuCash para la contabilidad de mi negocio y hace lo suficiente para lo que necesito.
    No uso QuickBooks, que los VC recomiendan en sus blogs; tiene funciones cómodas, pero no lo suficiente como para pagar ese precio, y no necesito financiamiento de VC ni un CPA.
    Nunca he usado GnuCash con SQLite, pero cuando tenga tiempo me gustaría experimentar, y me da curiosidad qué tan confiable es.
    Antes trabajé como ingeniero técnico/funcional de Oracle EBS, así que lidié con esquemas complejos entrelazados incluso hasta submayores, y siempre he tenido en mente la idea de agregar una función de reconocimiento de ingresos a GnuCash.
    Si miro el esquema de SQLite, quizá pueda intentarlo.

    • Si alguien que está migrando desde QuickBooks quiere ayudar a otros, el convertidor qb-escape de QuickBooks→GnuCash necesita ayuda: https://github.com/erikmack/qb-escape/
    • En GnuCash, SQLite es estable.
      Migré de XML a SQLite hace unos años y no tuve problemas.
    • Es excelente para uso personal o para negocios muy pequeños, pero si intentas operar una startup real con GnuCash, puedes meterte en un gran problema.
      Por experiencia propia, el fanatismo por GnuCash es dañino; el mundo de los negocios odia GnuCash y solo le importa QuickBooks.
      Llevo peleando esta batalla en organizaciones sin fines de lucro y startups desde principios de los 2000, y antes yo también era de los que decían “tenemos que usar GnuCash sí o sí”.
      En un mundo ideal, GnuCash o cualquier herramienta que no fuera QuickBooks sería una opción para la contabilidad de pequeñas empresas, pero en la realidad Intuit, mediante APIs y formatos de archivo, hizo difícil elegir algo que no sea QuickBooks.
      Si no usas QuickBooks, los bancos, inversionistas, sistemas de nómina, sistemas fiscales y contadores la pasan mal, y en algunos casos incluso pueden bloquearse subvenciones o auditorías.
      A menudo veo a defensores del open source, con buenas intenciones, exigir el uso de GnuCash; no deberías ser esa persona.
      El mundo eligió QuickBooks, y aunque esa elección se dio entre presiones y corretaje de poder corrupto, ya está decidida.
      Puede que existan opciones SaaS decentes, pero solo mientras Intuit lo permita, y competir con QuickBooks probablemente termine en que Intuit te adquiera y desaparezcas.
      En varias organizaciones sin fines de lucro y empresas eligieron GnuCash y luego tuvieron que cambiar de plataforma a toda prisa por cierres de financiamiento, requisitos bancarios, solicitudes de préstamos y postulaciones a subvenciones; al final, la persona encargada de contabilidad tuvo que rehacer todo trabajando semanas de más de 60 horas.
      GnuCash es un proyecto genial y ojalá todos pudieran usarlo, pero en negocios reales no se puede por razones arbitrarias y artificiales.
      Si la persona de contabilidad viniera y te obligara a usar NetBeans, no lo aceptarías, así que al elegir herramientas deberías mostrarle la misma cortesía.
    • Parece otro caso de éxito del software libre gracias a su característica de ser gratis como cerveza gratis

  • He probado mucho software de contabilidad personal, pero, salvo el antiguo Pocket Money para PalmOS, en todos era demasiado incómodo ingresar gastos.
    Si registras toda la visita a una tienda como una sola transacción, tipo “comestibles en Lidl”, es tolerable, pero si intentas ingresar cada renglón del recibo como un ítem separado de una transacción dividida, tienes que volver a escribirlo todo cada vez, sin buenas sugerencias basadas en el historial.
    Por ejemplo, si la contraparte es Lidl, con solo escribir “br” podría sugerir food:bread y el precio; y si la contraparte es Victoria Secret, sugerir clothing:bra y otro precio. Podría ser así de sofisticado, pero nada de lo que probé lo soportaba.
    El antiquísimo PalmOS 3.0 Pocket Money era muy cómodo, y todo lo demás, tanto de escritorio como móvil, es mucho peor en este aspecto.
    Si registras las transacciones con mucho detalle, creo que las categorías anidadas son mejores que las “cuentas” anidadas.
    Es casi una diferencia de apariencia, pero se siente raro que “efectivo” y “food:meat:pork” sean el mismo tipo de objeto.
    No transfieres dinero a “food:meat:pork”, sino que gastas en eso; y envías dinero a la tienda, no al producto.
    Hasta donde sé, los sistemas contables profesionales tampoco tienen una cuenta de activos de la empresa separada para cada monitor, laptop, computadora o mouse.
    Me pregunto si simplemente todavía no encontré algo así, o si hay algo recomendable.

    • Dudo que rastrear cada artículo de un recibo sea realmente tan útil.
      Puede servir para algunos tipos de compras, pero probablemente sea trabajo de detalle innecesario que no genera suficiente valor frente al esfuerzo que requiere.
    • En el pasado probé varias herramientas y, hacia 2009, harto del software propietario para OS X, en particular iBank, y sin que GNUCash ni KDEMoney me convencieran, terminé creando mi propia app de código abierto simple.
      Es una app nativa en Cocoa y, más recientemente, también tiene un port a Qt para Linux; la uso todos los días desde entonces.
      Antes dividía las categorías con muchísimo detalle, pero ahora no le veo mucho sentido; la app soporta transacciones divididas, aunque normalmente solo uso categorías como “comestibles”, “bebidas” y “artículos esenciales”.
      Eso sí, cosas como “café” las dejo como “Drinks:Coffee” para poder ver cuánto gasto en un ítem específico.
      Al final parece una cuestión de equilibrio entre el esfuerzo de registrar con ese nivel de precisión y el valor práctico que realmente se obtiene; lo mismo aplica a cosas como “Car:Fuel” y “Car:Service”.
    • Cuando empecé a hacer seguimiento de mis finanzas, las hojas de cálculo se me quedaron cortas rápidamente, y las opciones existentes no se ajustaban a lo que necesitaba.
      Para la mayoría de la gente, este nivel de seguimiento detallado puede ser excesivo, pero a mí no me toma mucho tiempo.
      Al final creé mi propia app: https://github.com/VMelnalksnis/Gnomeshade
      Sentía algo parecido respecto de las cuentas, así que dividí las transacciones en dos partes: transferencias y compras. Gracias a eso puedo manejar varias monedas y tratar las categorías por separado de las cuentas.
      No investigué las sugerencias automáticas que mencionas; me fui más por el lado de parsear recibos de cosas que compro con frecuencia.
    • Probablemente lo estás granularizando demasiado.
      Yo solo lo divido en algo como “comestibles”, “consumibles” y “ropa”.
      No entendí del todo qué necesitas exactamente, pero hace más de 10 años me pasé de GnuCash a KMyMoney.
      Si antes ingresaste los artículos de Walmart uno por uno, la próxima vez que vayas a Walmart y se importe el estado de cuenta de la tarjeta de crédito, te toma como punto de partida una transacción anterior de Walmart con un total parecido, lo que ayuda un poco.
      Además, KMyMoney usa categorías en lugar de cuentas, aunque el enfoque de cuentas encaja mejor con los principios contables.
    • Sería bueno que hubiera un formato de código QR para recibos con este uso.
      Podría incluir, a grandes rasgos, el nombre/ubicación de la tienda, el total, campos separados para impuestos, una categoría general si es una compra simple —como “combustible” o “comida” en un recibo de McDonald’s—, y agrupaciones de artículos para lugares como Costco, donde puedes comprar comestibles y ropa al mismo tiempo.
      Las categorías principales podrían tomar como referencia las que varios países usan para clasificar el índice de precios al consumidor.
      https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
      https://www.bls.gov/news.release/cpi.t01.htm
      https://www.stat.go.jp/english/data/cpi/158c.html
      https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...

  • No me gusta mucho el modelo de GNUCash.
    Es algo engorroso de usar y también bastante difícil extraer las estadísticas que quiero, así que en el pasado probé varios paquetes distintos antes de quedarme con uno.
    Aun así, cuando conseguí mi primer trabajo hace varias décadas, GNUCash ya existía, y sigue existiendo hoy.
    Parece que hay muy pocos paquetes que hayan demostrado ese nivel de continuidad.

    • Parte de su encanto es que tiene un diseño de utilidad de mediados de los 90.
      Al mismo tiempo, esa misma interfaz noventera es increíblemente frustrante.
      No he visto otra utilidad cuya interfaz haya evolucionado tan poco como la de GNUCash.
      Da la sensación de que hicieron un prototipo, dijeron “¡perfecto!”, ignoraron la opinión de los usuarios y pasaron a trabajar en el backend.
    • Esa continuidad tiene un valor enorme.
      Uso gnucash desde finales de los 90 y tengo todos mis archivos de datos desde el año 2000.

  • Lo probé hace unos años, pero al final me quedé con HLedger
    Como GnuCash, me permite poseer y controlar mis datos, pero en HLedger puedo editarlos directamente en Sublime Text para corregir o cambiar cosas en masa
    Claro que mi caso de uso es bastante básico y no es un sistema crítico de negocio, así que puede variar según la persona

    • Es una razón válida para no usar GnuCash
      Estoy de acuerdo en que el formato XML no es excelente, pero yo uso el formato SQLite, así que puedo escribir scripts encima de él
    • Uso Firefly III: https://firefly-iii.org
      Es una app web autoalojada, así que me viene bien porque la uso principalmente desde el teléfono
      Tiene una API bastante amplia y, aunque la edición masiva no sea tan fácil como con archivos de texto, debería ser relativamente simple
      También tiene un sistema de reglas que se puede aprovechar para ediciones masivas
    • Uso GnuCash, y es bastante molesto que no permita cambios masivos ni scripting sencillo
      Por ejemplo, especialmente cuando cometes un pequeño error al importar un CSV
    • He usado hledger y ledger durante varios años, en particular la función de lots
      Una de las cosas buenas de hledger es su sistema de reglas CSV, que es muy flexible
      Le agregué un script sencillo en Python para insertar la información adicional necesaria para registrar ganancias de capital
      Al final, los datos de entrada en bruto son archivos CSV con los registros, y la salida son reportes financieros con distintos niveles de detalle
    • De hecho ejecuto un pequeño script que convierte XML de gnucash a ledger, y hago seguimiento tanto del resultado de la conversión como del XML original con git
      Si lo ejecuto con bastante frecuencia mientras ingreso datos en la UI de gnucash, puedo ver los cambios en logs y diffs de git fáciles de leer
      Sin embargo, falta la capacidad de hacer “cambios masivos”
      Como gnucash es simplemente XML, también podría editarlo directamente, pero todavía no me he animado a intentarlo
      Basado en [0]: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • Uso GnuCash para la contabilidad de un hackerspace
    Las opciones eran usar esto o un sitio llamado “wave” que recomendó la persona encargada de la contabilidad de un makerspace cercano
    Me registré en wave y lo probé un poco, pero no me convenció; unas semanas después, cuando decidí usar wave, mi cuenta estaba bloqueada sin motivo alguno
    Así que me fui con GnuCash
    Es buen software y, al final, escribí código que enlaza dinámicamente con la biblioteca libgnucash para generar automáticamente las facturas mensuales de las cuotas de membresía

    • Me pregunto si no habrá una mejor forma de automatizar GnuCash, por ejemplo con scripts en Bash o Python
    • Interesante; me pregunto si podrías compartir el código

  • Analicé GnuCash en detalle antes de elegir Beancount o la contabilidad general en texto plano como software de finanzas personales
    Lo que terminó siendo decisivo fue el formato interno XML o SQLite de GnuCash
    No encaja muy bien para hacer scripting de captura de datos en bruto o generación de reportes, que es justamente el objetivo de herramientas de texto plano como Beancount o HLedger
    Comparado con las herramientas de texto plano, GnuCash se siente demasiado como un jardín cerrado
    El formato de texto plano requiere más trabajo al principio, pero si te acostumbras y tienes experiencia con scripting, es excelente

    • Será cuestión de gustos, pero mi experiencia es exactamente la opuesta
      El texto plano parece simple a la vista humana, pero es una pesadilla de parsear de forma estructurada, y automatizar la edición de texto plano con scripts también es sucio
      En cambio, las bases de datos están hechas para este tipo de uso
      Después de pasar mucho tiempo con quejas e intentos de mejorar la contabilidad en texto plano, ahora uso SQLite, y fue una mejora enorme
    • Si el esquema XML/DB está documentado, en realidad es mejor y más robusto que el formato de texto plano de Beancount/Ledger
      Yo uso el backend XML de KMyMoney y también tengo un script que convierte los datos al formato Ledger
      Precisamente porque no es texto de formato libre, ese script fue más fácil de escribir
    • La combinación Beancount + Fava se ve bastante buena; me pregunto si podrías contar tu experiencia usándola
    • Si SQLite no es suficiente, GnuCash también soporta backends SQL
      Yo llevo casi 10 años operando así

  • GnuCash tiene un lugar especial en mi corazón
    Durante los primeros años después de graduarme de la universidad, manejé un presupuesto muy ajustado con ingresos limitados, y cada vez que hacía las compras llevaba el recibo a casa y lo ingresaba diligentemente en el libro contable
    Siempre todo cuadraba, pero era muchísimo trabajo

  • Como consultor freelance en Suecia, he revisado GnuCash varias veces durante más de 10 años, pero siempre tuve el mismo problema
    No está adaptado a nuestra economía ni al sistema de la agencia tributaria
    En Suecia, si tus ventas son inferiores a 3 millones de SEK al año, puedes usar “förenklat årsbokslut”, algo así como un “cierre contable simplificado”
    En la práctica, basta con crear un programa muy básico para gestionar gastos e ingresos, generar las cifras necesarias e ingresarlas manualmente cada año en la app en línea de la agencia tributaria

    • Yo también soy freelance individual y uso la contabilidad simplificada
      La contabilidad de partida doble, una vez superada la curva de aprendizaje inicial, no me tomó más esfuerzo que la contabilidad de partida simple
      Porque ayuda a evitar automáticamente errores comunes
      Llevo 20 años usando GnuCash sin problemas, y no pienso volver a una hoja de cálculo frágil ni a una base de datos Access improvisada

  • Usé GnuCash durante un tiempo, pero terminé dedicando demasiado tiempo a ajustar la configuración de sincronización en línea
    En las cuentas que tenía que descargar e importar manualmente, la fricción hacía que postergara la importación
    Ahora pago por Quicken Classic, y es uno de los gastos anuales que más satisfacción me da
    Las conexiones con cuentas en línea funcionan de forma constante como espero y, en general, me resuelve todo con muchos menos dolores de cabeza

    • Tengo que ocuparme de cuentas en EE. UU., Canadá, dos países de la UE y México
      Me gustaría que existiera una opción de pago en la que las conexiones bancarias funcionaran de manera estable, como en Quicken Classic, pero parece que ni siquiera hay un solo producto que cubra al mismo tiempo EE. UU. y una de las principales economías de la UE, mucho menos todas las regiones que necesito
      Quicken Classic es solo para EE. UU. y Canadá
      Me pregunto si alguien conoce una opción así, o varias opciones que se puedan usar juntas de forma razonable para lograr este objetivo
      Al ver que las empresas de acceso a datos de transacciones no cruzan el puente entre EE. UU. y la UE de una forma fácil de usar para particulares, parece que hay algún motivo, como la incompatibilidad entre las burocracias de ambos lados
      O quizá simplemente no hay suficiente gente que lleve una vida tan internacional

  • Administré un negocio con GnuCash, incluyendo nómina y gestión de cuentas 401k
    Era estable y, si se trataba de un negocio con gastos limitados o si tenías experiencia en contabilidad, el seguimiento de costos era suficiente
    Me encantó que pudiera generar el balance general y el estado de resultados para entregárselos al contador