Lançamento do GnuCash 5.9

 (gnucash.org)
2 pontos por GN⁺ 2024-10-02 | 1 comentários | Compartilhar no WhatsApp
  • O GnuCash 5.9 é o décimo lançamento da série estável 5.x, reunindo correções de bugs encontrados desde o 5.8 e melhorias no parsing de datas em CSV e nas cotações online
  • Esta versão corrige 12 bugs, incluindo problemas na janela de reconciliação, mensagens de erro do backend MySQL, copiar/colar transações, crash ao excluir contas e erro de locale no separador decimal do teclado numérico no Windows
  • Nas cotações online, foram adicionados a configuração de chave de API do YH Finance(FINANCEAPI) e a fonte financeapi, e a importação de CSV agora lida melhor com datas baseadas em locale e nomes de mês em inglês
  • Há pacotes para Windows 10 ou superior, macOS 10.13 High Sierra ou superior e flatpak no Flathub; para compilar manualmente, são necessárias dependências mínimas especificadas como Gtk+, Guile e Boost
  • Usuários alemães do AQBanking passarão a usar o AQBanking 6.5.4 incluído no bundle, e a beta da nova implementação de PIN/TAN está disponível apenas nas nightly builds do GnuCash

Natureza do lançamento do GnuCash 5.9

  • GnuCash 5.9 é o décimo lançamento da série estável 5.x
  • O GnuCash é um programa de contabilidade gratuito e de código aberto distribuído sob a GNU General Public License (GPL), com suporte a GNU/Linux, *BSD, Solaris, macOS e Microsoft Windows
  • O desenvolvimento começou em 1997 e o primeiro lançamento estável saiu em 1998

Principais problemas corrigidos desde o 5.8

  • Foi resolvido o problema em que novas transações adicionadas durante a reconciliação não apareciam na janela de reconciliação
  • O backend MySQL agora informa o erro "access denied" em vez de "bad or corrupt data" para credenciais incorretas
  • O comportamento de copiar/colar e recortar/colar transações foi corrigido
    • Isso inclui o problema em que recortar/colar uma transação não a movia para a conta de destino
  • Foi corrigido o problema em que o script Python de exemplo emitia erro ao criar um novo arquivo no backend sqlite
  • Na visualização Transaction Journal, foi corrigido o problema de posição do cursor desalinhada após confirmar alterações em uma transação
  • Foram resolvidos falhas no parsing da data de reconciliação, crash ao excluir contas e erro no cálculo de trimestre em deslocamentos de data relativa
  • Foi corrigido no Windows o problema em que a entrada do separador decimal no teclado numérico não correspondia ao locale
  • Foram corrigidos o problema da caixa de listagem suspensa de contas pequena demais na tela de publicação de faturas e um problema intermitente de preço de cotação

Melhorias em cotações online e importação de CSV

  • A infraestrutura de cotações online recebeu a configuração de chave de API do YH Finance(FINANCEAPI)
    • A configuração correspondente pode ser gerenciada na página Online Quotes
    • financeapi foi adicionada às fontes de cotação conhecidas
  • O parser de datas em CSV foi aprimorado para usar ICU e Boost
    • Faz o parsing da data do locale atual com base no formato de data Locale do ICU
    • Pode processar entradas como "3 May 2023" ou "2024年9月13日" em LC_TIME=zh_TW.utf8
    • Os formatos d-m-y, m-d-y, y-m-d foram reforçados com os parsers UK/US/ISO do Boost
    • Datas com nomes de mês em inglês, como "30 Sep 2023", "May 4, 1978" e "2023-Dec-25", também podem ser processadas na importação de CSV
    • O parser do Boost não reconhece anos com dois dígitos, então "30 Sep 24" não é válido
  • A página de introdução do Assistente de Importação de CSV foi melhorada

Limpeza interna e mudanças voltadas a desenvolvedores

  • A estrutura de tratamento de itens copiados foi reorganizada
    • copied_class e copied_leader_guid foram movidos de variáveis estáticas para fazer parte da estrutura copied_item
    • Ficou mais claro que a chamada de clear_copied_item é necessária antes de usar copied_item
  • Ao abrir arquivos no histórico de arquivos, edições não confirmadas agora são tratadas corretamente
  • gnc_difftime foi marcado como deprecated porque converte time64 para double
  • Foram removidos gnc_pricedb_substitute_commodity e gnc_pricedb_lookup_at_time64, que não eram usados

Alterações em traduções e documentação

  • As traduções adicionadas ou atualizadas são Assamese, Chinese(Simplified), Chinese(Traditional), Croatian, Dutch, English(United Kingdom), Hebrew, Hungarian, Macedonian, Norwegian Bokmål, Portuguese(Brazil), Russian, Spanish, Swedish e Turkish
  • A mudança na documentação foi a atualização das versões das GitHub CI actions
  • Nas traduções da documentação, German foi adicionado ou atualizado
  • A participação em traduções é orientada pelo projeto GnuCash no Weblate

Aviso relacionado ao AQBanking

  • Há um aviso separado para usuários alemães do AQBanking
  • O autor do AQBanking continua trabalhando para finalizar o código atualizado de PIN/TAN
  • Os bundles Flatpak, macOS e Windows desta versão incluem a última versão estável, o AQBanking 6.5.4
  • Se o AQBanking estável não funcionar, pode-se considerar as nightly builds do GnuCash, que incluem a beta da nova implementação
  • A lista completa de bugs em aberto pode ser consultada na lista de bugs do GnuCash

Pacotes de distribuição e requisitos de build

  • O GnuCash 5.9 é disponibilizado em pacotes all-in-one pré-compilados para Microsoft Windows 10 ou superior e macOS 10.13 High Sierra ou superior
    • No Windows, ele vem em formato de instalador
    • O pacote do macOS é uma imagem de disco com um bundle de aplicativo em arrastar e soltar
  • Também está disponível como flatpak no Flathub.org
  • Os arquivos para download incluem tarball, instalador do Windows, dmg para Apple Silicon, dmg para Intel Mac e tarball da documentação
  • O código-fonte pode ser obtido no SourceForge e no GitHub em formato bzip2 ou gzip, e também pode ser feito checkout diretamente do repositório Git
  • Para compilar manualmente, são necessárias as seguintes dependências mínimas
  • Para a lista exata de dependências e versões, é preciso consultar o arquivo README.dependencies no código-fonte

Documentação do GnuCash 5.9

  • A documentação do GnuCash 5.9 pode ser consultada na página Documentation do site do GnuCash
  • Em GnuCash v5 (current stable release), há leitura online e download em vários idiomas
  • Os formatos de download incluem pdf, epub, mobi
  • A documentação também está incluída nos bundles de aplicativo para macOS e Windows
  • O código-fonte da documentação do GnuCash 5.9 pode ser obtido no SourceForge ou no GitHub, e também pode ser feito checkout diretamente do repositório Git

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-02
Opiniões no Hacker News

  • Uso o GnuCash para a contabilidade da empresa e ele atende bem às funcionalidades de que preciso.
    Não uso o QuickBooks que os VCs recomendam em blogs; ele tem recursos convenientes, mas não a ponto de justificar o preço, e também não preciso de dinheiro de VC nem de CPA.
    Nunca usei o GnuCash com SQLite, mas gostaria de testar quando tiver tempo, e tenho curiosidade sobre sua confiabilidade.
    No passado trabalhei como engenheiro técnico/funcional no Oracle EBS, lidando com esquemas complexos em que até subledgers ficavam interligados, e sempre pensei em adicionar ao GnuCash uma funcionalidade de reconhecimento de receita.
    Olhando o esquema SQLite, talvez dê para tentar.

    • Se alguém que está migrando do QuickBooks quiser ajudar outras pessoas, o conversor qb-escape QuickBooks→GnuCash precisa de ajuda: https://github.com/erikmack/qb-escape/
    • No GnuCash, o SQLite é estável.
      Migrei de XML para SQLite alguns anos atrás e não tive problemas.
    • Para uso pessoal ou negócios muito pequenos, é excelente, mas, se você tentar tocar uma startup de verdade com GnuCash, pode se dar muito mal.
      Pela minha própria experiência, a devoção ao GnuCash é prejudicial; o mundo dos negócios odeia o GnuCash e só liga para o QuickBooks.
      Venho travando essa batalha em organizações sem fins lucrativos e startups desde o início dos anos 2000, e antigamente eu também era a pessoa que dizia “temos que usar GnuCash”.
      Em um mundo ideal, o GnuCash, ou qualquer ferramenta que não fosse o QuickBooks, seria uma opção para a contabilidade de pequenas empresas, mas, na realidade, a Intuit tornou difícil escolher qualquer coisa além do QuickBooks por meio de APIs e formatos de arquivo.
      Se você não usa QuickBooks, bancos, investidores, sistemas de folha de pagamento, sistemas fiscais e contadores sofrem; em alguns casos, até subsídios ou auditorias podem ficar bloqueados.
      Vejo com frequência defensores de open source bem-intencionados exigindo o uso do GnuCash, e você não deve ser essa pessoa.
      O mundo escolheu o QuickBooks, e essa escolha foi feita sob pressão e intermediação corrupta de poder, mas já está decidida.
      Pode haver opções SaaS decentes, mas elas só existem enquanto a Intuit permitir; competir com o QuickBooks provavelmente significa ser adquirida pela Intuit e desaparecer.
      Em várias organizações sem fins lucrativos e empresas, vi o GnuCash ser escolhido e depois, por causa de fechamento de captação, exigências bancárias, pedidos de empréstimo e solicitações de subsídio, terem que trocar de plataforma às pressas; no fim, a pessoa responsável pela contabilidade acabou refazendo tudo em semanas de mais de 60 horas de trabalho.
      O GnuCash é um projeto incrível, e eu gostaria que todos pudessem usá-lo, mas, em negócios reais, ele não pode ser usado por motivos arbitrários e artificiais.
      Você não aceitaria se a pessoa da contabilidade chegasse e obrigasse você a usar NetBeans, então mostre a ela a mesma cortesia na escolha das ferramentas.
    • Parece mais um caso de sucesso do software livre graças ao fato de ser gratuito como cerveja grátis

  • Já usei muitos softwares de finanças pessoais, mas, tirando o antigo Pocket Money para PalmOS, todos eram muito incômodos para inserir despesas
    Se você registra a visita inteira à loja como uma única transação, tipo “mantimentos no Lidl”, dá para tolerar, mas, se tenta colocar cada linha do recibo como um item separado de uma transação dividida, precisa digitar tudo de novo a cada vez, sem boas sugestões baseadas no histórico
    Por exemplo, poderia ser sofisticado a ponto de, se a contraparte da transação fosse o Lidl, ao digitar apenas “br” ele sugerir food:bread e o preço, e, se a contraparte fosse a Victoria Secret, sugerir clothing:bra e outro preço, mas nenhum dos que usei oferecia isso
    O antiquíssimo PalmOS 3.0 Pocket Money era muito prático, e todo o resto, seja desktop ou mobile, é muito pior nesse aspecto
    Se você registra transações em grande detalhe, acho que categorias aninhadas são melhores do que “contas” aninhadas
    É quase uma diferença cosmética, mas é estranho que “dinheiro” e “food:meat:pork” sejam objetos do mesmo tipo
    Você não transfere dinheiro para “food:meat:pork”; você gasta com isso, e o dinheiro vai para a loja, não para o produto
    Até onde sei, sistemas contábeis profissionais também não criam uma conta de ativo da empresa separada para cada monitor, notebook, computador e mouse
    Fico pensando se talvez eu ainda não tenha encontrado, ou se há algo recomendável

    • Questiono se rastrear cada item do recibo é realmente tão útil assim
      Pode servir para alguns tipos de compra, mas é bem possível que seja um trabalho detalhista desnecessário que não gera valor proporcional ao esforço envolvido
    • No passado, experimentei várias ferramentas e, por volta de 2009, irritado com softwares proprietários para OS X, especialmente o iBank, além de não gostar do GNUCash nem do KDEMoney, acabei criando meu próprio app open source simples
      É um app nativo em Cocoa e, mais recentemente, também tem um port em Qt para Linux; desde então uso todos os dias
      Antes eu dividia as categorias em muito detalhe, mas hoje não vejo muito sentido nisso; o app dá suporte a transações divididas, mas normalmente uso só categorias como “mantimentos”, “bebidas” e “itens essenciais”
      Ainda assim, coisas como “café” eu deixo como “Drinks:Coffee”, para conseguir ver quanto gasto em um item específico
      No fim, parece uma questão de equilíbrio entre o esforço de registrar com esse nível de precisão e o valor prático disso, e o mesmo vale para coisas como “Car:Fuel” e “Car:Service”
    • Quando comecei a acompanhar minhas finanças, planilhas sozinhas rapidamente chegaram ao limite, e as opções existentes também não atendiam às minhas necessidades
      Para a maioria das pessoas, esse nível de rastreamento detalhado pode ser exagero, mas, para mim, não toma muito tempo
      Acabei criando meu próprio app: https://github.com/VMelnalksnis/Gnomeshade
      Eu sentia algo parecido em relação às contas, então dividi as transações em duas partes, transferências e compras, o que permite lidar com várias moedas e tratar categorias separadamente das contas
      Não cheguei a investigar as sugestões automáticas mencionadas; fui pelo caminho de fazer parsing de recibos de itens que compro com frequência
    • Talvez você esteja granularizando demais
      Eu separo só em algo como “mantimentos”, “consumíveis” e “roupas”
      Não entendi completamente do que você precisa exatamente, mas eu mudei do GnuCash para o KMyMoney há mais de 10 anos
      Se você já inseriu itens individualmente no Walmart antes, na próxima vez que for ao Walmart e importar a fatura do cartão de crédito, ele usa como ponto de partida uma transação anterior do Walmart com valor total parecido, o que ajuda um pouco
      E o KMyMoney usa categorias em vez de contas, embora o modelo de contas esteja mais alinhado aos princípios contábeis
    • Seria bom se os recibos tivessem um formato de QR code para esse tipo de uso
      Poderia incluir, em linhas gerais, nome/localização da loja, valor total, campos separados de impostos, uma categoria geral no caso de compras simples, como “combustível” ou “comida” em um recibo do McDonald’s, e agrupamentos de itens para lugares como Costco, onde você pode comprar mantimentos e roupas juntos
      As categorias principais poderiam se basear nas usadas por vários países para classificar o índice de preços ao 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...

  • Não gosto muito do modelo do GNUCash
    É meio trabalhoso de usar e também bastante difícil extrair as estatísticas que eu quero, então, no passado, experimentei vários outros pacotes até me fixar em um
    Ainda assim, quando consegui meu primeiro emprego, décadas atrás, o GNUCash já existia, e continua existindo hoje
    Parece que quase nenhum outro pacote demonstrou esse nível de continuidade

    • O fato de ter um design de utilitário de meados dos anos 90 é parte do charme
      Ao mesmo tempo, justamente essa interface ao estilo dos anos 90 é extremamente frustrante
      Nunca vi um utilitário cuja interface tenha evoluído tão pouco quanto a do GNUCash
      Dá a impressão de que fizeram um protótipo, disseram “perfeito!” e então ignoraram o feedback dos usuários e passaram a trabalhar no backend
    • Essa continuidade tem um valor enorme
      Uso o gnucash desde o fim dos anos 90 e tenho todos os arquivos de dados voltando até 2000

  • Testei há alguns anos, mas acabei ficando com o HLedger
    Assim como no GnuCash, consigo possuir e controlar meus dados, mas no HLedger posso editar diretamente no Sublime Text para corrigir ou alterar coisas em massa
    Claro, meu caso de uso é bem básico e não é um sistema crítico de negócios, então pode variar de pessoa para pessoa

    • É um motivo válido para não usar o GnuCash
      Concordo que o formato XML não é excelente, mas eu uso o formato SQLite, então consigo escrever scripts em cima dele
    • Estou usando Firefly III: https://firefly-iii.org
      Como é um app web auto-hospedado, é bom para mim, que o uso principalmente pelo celular
      Ele tem uma API bastante ampla e, embora a edição em massa não seja tão fácil quanto em arquivos de texto, deve ser relativamente simples
      Também há um sistema de regras que pode ser usado para edição em massa
    • Uso GnuCash, e a falta de alterações em massa ou scripting fácil é bem irritante
      Especialmente, por exemplo, quando se comete um pequeno erro na importação de CSV
    • Usei hledger e ledger por vários anos, especialmente o recurso de lots
      Uma das coisas boas do hledger é seu sistema de regras de CSV muito flexível
      Acoplei a isso um script simples em Python para inserir as informações adicionais necessárias ao registro de ganhos de capital
      No fim, os dados brutos de entrada são arquivos CSV com os registros, e a saída são relatórios financeiros em vários níveis de detalhe
    • Na prática, executo um pequeno script que converte XML do gnucash para ledger e acompanho tanto o resultado da conversão quanto o XML original com git
      Se você o executa com bastante frequência enquanto faz lançamentos na UI do gnucash, consegue ver as alterações em logs e diffs do git fáceis de ler
      Mas a capacidade de “alterações em massa” fica de fora
      Como o gnucash é apenas XML, também daria para editar diretamente, mas ainda não tive coragem de tentar
      Baseado em [0]: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • Uso GnuCash para a contabilidade de um hackerspace
    A escolha era usar isso ou um site chamado “wave”, recomendado pelo responsável pela contabilidade de um makerspace próximo
    Criei uma conta no wave e mexi um pouco, mas não fiquei convencido; algumas semanas depois, quando decidi usar o wave, minha conta estava bloqueada sem motivo algum
    Então fui de GnuCash
    É um bom software e, no fim, escrevi um código que faz link dinâmico com a biblioteca libgnucash para gerar automaticamente as cobranças mensais das mensalidades dos membros

    • Fico me perguntando se não há uma forma melhor de automatizar o GnuCash, por exemplo com scripts Bash ou Python
    • Interessante; fico curioso para saber se você poderia compartilhar o código

  • Analisei o GnuCash em detalhes antes de escolher Beancount ou contabilidade em texto puro em geral como software de finanças pessoais
    O ponto decisivo que pegou para mim foi o formato interno XML ou SQLite do GnuCash
    Ele não se encaixa muito bem em scripts de coleta de dados brutos ou geração de relatórios, enquanto ferramentas em texto puro como Beancount ou HLedger têm exatamente esse objetivo
    Em comparação com ferramentas em texto puro, o GnuCash parece um jardim murado demais
    O formato em texto puro exige mais trabalho no início, mas, se você se acostumar e tiver experiência com scripting, é excelente

    • Cada um tem seu gosto, mas minha experiência é exatamente o oposto
      Texto puro parece simples para olhos humanos, mas é um pesadelo para fazer parsing de forma estruturada, e automatizar edição de texto puro com scripts também é bagunçado
      Já bancos de dados foram feitos para esse tipo de uso
      Depois de gastar muito tempo com reclamações e tentativas de melhorar a contabilidade em texto puro, agora uso SQLite, e foi uma melhoria enorme
    • Se o esquema XML/DB estiver documentado, na prática ele é melhor e mais robusto do que o formato de texto puro do Beancount/Ledger
      Uso o backend XML do KMyMoney e também tenho um script que converte os dados para o formato Ledger
      Justamente por não ser texto de formato livre, foi mais fácil usar esse script
    • A combinação Beancount + Fava parece bem boa; fico curioso para ouvir experiências de quem já usou
    • Se SQLite não for suficiente, o GnuCash também oferece suporte a backends SQL
      Estou operando assim há quase 10 anos

  • O GnuCash tem um lugar especial no meu coração
    Nos primeiros anos depois da faculdade, eu administrava um orçamento muito apertado com uma renda curta; sempre que fazia compras, levava o recibo para casa e o lançava diligentemente no livro-caixa
    Sempre batia tudo, mas dava um trabalhão

  • Como consultor freelancer na Suécia, olhei o GnuCash várias vezes ao longo de mais de 10 anos, mas sempre houve o mesmo problema
    Ele não é adaptado à nossa economia nem ao sistema da Receita
    Na Suécia, se o faturamento for inferior a 3 milhões de SEK por ano, é possível usar o “förenklat årsbokslut”, algo como “fechamento contábil simplificado”
    Na prática, basta criar por conta própria um programa bem básico para gerenciar despesas e receitas, gerar os números necessários e inseri-los manualmente todo ano no app online da Receita

    • Também sou freelancer solo e uso a contabilidade simplificada
      A contabilidade por partidas dobradas, depois de superar a curva inicial de aprendizado, não exigiu mais esforço do que a contabilidade por partidas simples
      Isso porque ela ajuda a evitar automaticamente erros comuns
      Uso o GnuCash há 20 anos com bons resultados e não tenho intenção de voltar para uma planilha frágil ou um banco de dados Access malfeito

  • Usei o GnuCash por um tempo, mas acabei gastando tempo demais ajustando a configuração de sincronização online
    Nas contas em que eu precisava baixar e importar manualmente, o atrito fazia com que eu adiasse a importação
    Hoje pago pelo Quicken Classic, e é uma das despesas anuais com que fico mais satisfeito
    A conexão com contas online funciona de forma consistente como esperado e, no geral, resolve tudo com muito menos dor de cabeça

    • Preciso cuidar de contas nos EUA, no Canadá, em dois países da UE e no México
      Seria ótimo ter uma opção paga em que as conexões bancárias funcionassem de forma confiável, como no Quicken Classic, mas parece que nem existe um único produto que cubra ao mesmo tempo os EUA e sequer uma grande economia da UE; cobrir todas as regiões de que preciso é ainda mais difícil
      O Quicken Classic é exclusivo para EUA e Canadá
      Fico curioso para saber se alguém conhece uma opção assim, ou várias opções que possam ser usadas em conjunto de forma razoável para atingir esse objetivo
      Pelo fato de as empresas de acesso a dados de transações não fazerem uma ponte EUA-UE de um jeito fácil para pessoas físicas usarem diretamente, parece haver algum motivo, como incompatibilidades entre as burocracias dos dois lados
      Ou talvez simplesmente não haja gente suficiente vivendo de forma tão internacional assim

  • Usei o GnuCash para administrar um negócio, incluindo folha de pagamento e gestão de contas 401k
    Era estável e, para um negócio com despesas limitadas ou para quem tem experiência com escrituração, o acompanhamento de custos era suficiente
    Foi realmente ótimo poder gerar o balanço patrimonial e a demonstração de resultados para entregar ao contador