5 ms·

If there are BigCapital devs here, could you please maintain compatibility with https://github.com/ledger/ledger https://github.com/ledger/ledger also i dont s

If there are BigCapital devs here, could you please maintain compatibility with https://github.com/ledger/ledger https://github.com/ledger/ledger also i dont see mention of an API. Being able to provide an API to one's own accounting system is a super-power (and probably very incremental to the work you're doing anyway)

RamblingCTO 3y ago
I don't see how this is actually a use-case. How many people that need accounting software do it from the terminal? And on what earth is that a worthwhile business decision to spend time and money on this?
- sandGorgon 3y ago
  being able to maintain local backup/copies of your entire general ledger, even if u are using a cloud tool is generally the #1 blocker for any accounting team. Instead of building a whole new format (with implications on testing, etc) - it would be incremental effort to build support for ledger-cli format . And completely mitigate 90% of the objections by accounting teams. not asking for them to build cli functionality. this is the file format - https://ledger-cli.org/doc/ledger3.html#Example-Journal-File https://ledger-cli.org/doc/ledger3.html#Example-Journal-File
  - RamblingCTO 3y ago
    I understand. But this is not a proper journal file imho. We're actually building something in this space as well and there are way better but probably local standards like the Datev format (essentially CSV). Accountants need double book formatted journal entries. This is just a collection of amounts it seems. But I really appreciate all the different solutions in this space! I build our own when we started.
    - sandGorgon 3y ago
      as far as the ledger-cli google groups [1] go, they seem to think it is a proper journal file. It has been fairly tested with OFX imports (https://github.com/ledger/ledger/wiki/OFX-Import https://github.com/ledger/ledger/wiki/OFX-Import) as well bank autosync (https://github.com/egh/ledger-autosync https://github.com/egh/ledger-autosync). In fact, someone also wrote a book on this - https://leanpub.com/personal-accounting-in-ledger/ https://leanpub.com/personal-accounting-in-ledger/ I will defer if you are indeed building your own competing tool in this space which is better, but holding to the original point of my request - maybe it will be incremental to support your format if ledger-cli format is supported today. versus not supporting any disk format (or inventing a new one). [1] https://groups.google.com/g/ledger-cli/search?q=double%20entry%20 https://groups.google.com/g/ledger-cli/search?q=double%20ent...
      - RamblingCTO 3y ago
        I'll just link to my comment here: https://news.ycombinator.com/item?id=36129740 https://news.ycombinator.com/item?id=36129740 tldr: we have quite different requirements and we operate in a very different space. I still think ledger looks cool!
    - gen220 3y ago
      If "better" incorporates "battle-testedness" and portability, I'd advocate for considering Ledger's format. (Or beancount's. It's almost identical and has more accessible FOSS parsers + generators) It's about as minimalistic as you can get while still incorporating legibility and flexibility to support arbitrary transactions (including in commodities, etc.). I say this as somebody who voluntarily wrote a parser and generator for their format, as a happy user, and without being affiliated with the project -- it's quite good!
      - RamblingCTO 3y ago
        No, better actually means more than hobbyist accounting with publication obligations. While I think it's a cool tool, for proper (German/European) accounting you'd need tax quotas, reverse charge taxation, compatibility with SKR04 most likely (your tax consultant uses that in > 90% of the cases). You'd also need different dates for each journal entry: invoice date, date of service and booking date, booking notes, links to the invoice/contract causing the accounting event (that's mandatory) and a whole lot more. So I think our requirements are a tad more complex than ledger can support. We are compatible with the German DATEV format. DATEV is the accounting software and we don't wanna replace it. I could write a whole lot about that but I'll spare you that. Let me just say that we have good reasons to have our own format of accounting internally and there's no benefit in supporting ledger. I don't think there's even one person in the world that is a) our target persona and b) uses ledger.
        gen220 3y ago
        Well, I'm not going to tell you what's good and bad for your business, but for what it's worth Ledger supports all of those things. Whether it's right for your business or not is up to you and your customers, but you're selling Ledger short by describing it as "hobbyist accounting". Tax quotas, reverse charge taxation, the various date types, notes, links are all totally supported with Ledger's primitives as they are. SKR04 just looks like a list of account classifications, which is totally fine. You can either make that 1:1 with the account list you use, or you can tag entries in a transaction with metadata indicating that it's associated with that SKR04 classification. Again, not attacking your decision to use your own format, it's the right choice in many situations. But ledger is literally the primitives of accounting – it's up to you to superimpose your system of rules and regulations on it, but since it's just double-entry accounting with metadata and tags, it almost certainly can. Here's an example transaction, where somebody pays $20.00 for 20 tons of scrap metal, with links to the invoice, an invoice and transaction date, a mark to indicate that it's settled, and a $8 VAT liability that accrues at the end of the month. 2021-01-01=2021-01-03 * ACME Supplier ; invoice_num: 123 ; invoice_link: https://invoices.widgetsandthings.de?id=123 ; service_date: 2021-01-02 ; notes: John said he'll charge us more next year. Liabilities:CreditCards:Chase:XXXX $-20.00 Liabilities:Taxes:VAT $-8.00 ;[=2021/01/31] ; reverse charge tax, accrues at end of month [Quotas:Tax:VAT] $8.00 ;[=2021/01/31] ; you'd use a "virtual" account to express "quotas" or "budgets". Expenses:ScrapMetal $28.00 ; I'm bundling the VAT and metal expense into a single entry. ; But if you wanted to record them separately, with their own effective dates, you can. Assets:ScrapMetal 10 tons ; skr_code: SM2201 (I'm making this up) Receivables:ScrapMetal -10 tons

RamblingCTO 3y ago

I don't see how this is actually a use-case. How many people that need accounting software do it from the terminal? And on what earth is that a worthwhile business decision to spend time and money on this?

sandGorgon 3y ago
being able to maintain local backup/copies of your entire general ledger, even if u are using a cloud tool is generally the #1 blocker for any accounting team. Instead of building a whole new format (with implications on testing, etc) - it would be incremental effort to build support for ledger-cli format . And completely mitigate 90% of the objections by accounting teams. not asking for them to build cli functionality. this is the file format - https://ledger-cli.org/doc/ledger3.html#Example-Journal-File https://ledger-cli.org/doc/ledger3.html#Example-Journal-File
- RamblingCTO 3y ago
  I understand. But this is not a proper journal file imho. We're actually building something in this space as well and there are way better but probably local standards like the Datev format (essentially CSV). Accountants need double book formatted journal entries. This is just a collection of amounts it seems. But I really appreciate all the different solutions in this space! I build our own when we started.
  - sandGorgon 3y ago
    as far as the ledger-cli google groups [1] go, they seem to think it is a proper journal file. It has been fairly tested with OFX imports (https://github.com/ledger/ledger/wiki/OFX-Import https://github.com/ledger/ledger/wiki/OFX-Import) as well bank autosync (https://github.com/egh/ledger-autosync https://github.com/egh/ledger-autosync). In fact, someone also wrote a book on this - https://leanpub.com/personal-accounting-in-ledger/ https://leanpub.com/personal-accounting-in-ledger/ I will defer if you are indeed building your own competing tool in this space which is better, but holding to the original point of my request - maybe it will be incremental to support your format if ledger-cli format is supported today. versus not supporting any disk format (or inventing a new one). [1] https://groups.google.com/g/ledger-cli/search?q=double%20entry%20 https://groups.google.com/g/ledger-cli/search?q=double%20ent...
    - RamblingCTO 3y ago
      I'll just link to my comment here: https://news.ycombinator.com/item?id=36129740 https://news.ycombinator.com/item?id=36129740 tldr: we have quite different requirements and we operate in a very different space. I still think ledger looks cool!
  - gen220 3y ago
    If "better" incorporates "battle-testedness" and portability, I'd advocate for considering Ledger's format. (Or beancount's. It's almost identical and has more accessible FOSS parsers + generators) It's about as minimalistic as you can get while still incorporating legibility and flexibility to support arbitrary transactions (including in commodities, etc.). I say this as somebody who voluntarily wrote a parser and generator for their format, as a happy user, and without being affiliated with the project -- it's quite good!
    - RamblingCTO 3y ago
      No, better actually means more than hobbyist accounting with publication obligations. While I think it's a cool tool, for proper (German/European) accounting you'd need tax quotas, reverse charge taxation, compatibility with SKR04 most likely (your tax consultant uses that in > 90% of the cases). You'd also need different dates for each journal entry: invoice date, date of service and booking date, booking notes, links to the invoice/contract causing the accounting event (that's mandatory) and a whole lot more. So I think our requirements are a tad more complex than ledger can support. We are compatible with the German DATEV format. DATEV is the accounting software and we don't wanna replace it. I could write a whole lot about that but I'll spare you that. Let me just say that we have good reasons to have our own format of accounting internally and there's no benefit in supporting ledger. I don't think there's even one person in the world that is a) our target persona and b) uses ledger.
      - gen220 3y ago
        Well, I'm not going to tell you what's good and bad for your business, but for what it's worth Ledger supports all of those things. Whether it's right for your business or not is up to you and your customers, but you're selling Ledger short by describing it as "hobbyist accounting". Tax quotas, reverse charge taxation, the various date types, notes, links are all totally supported with Ledger's primitives as they are. SKR04 just looks like a list of account classifications, which is totally fine. You can either make that 1:1 with the account list you use, or you can tag entries in a transaction with metadata indicating that it's associated with that SKR04 classification. Again, not attacking your decision to use your own format, it's the right choice in many situations. But ledger is literally the primitives of accounting – it's up to you to superimpose your system of rules and regulations on it, but since it's just double-entry accounting with metadata and tags, it almost certainly can. Here's an example transaction, where somebody pays $20.00 for 20 tons of scrap metal, with links to the invoice, an invoice and transaction date, a mark to indicate that it's settled, and a $8 VAT liability that accrues at the end of the month. 2021-01-01=2021-01-03 * ACME Supplier ; invoice_num: 123 ; invoice_link: https://invoices.widgetsandthings.de?id=123 ; service_date: 2021-01-02 ; notes: John said he'll charge us more next year. Liabilities:CreditCards:Chase:XXXX $-20.00 Liabilities:Taxes:VAT $-8.00 ;[=2021/01/31] ; reverse charge tax, accrues at end of month [Quotas:Tax:VAT] $8.00 ;[=2021/01/31] ; you'd use a "virtual" account to express "quotas" or "budgets". Expenses:ScrapMetal $28.00 ; I'm bundling the VAT and metal expense into a single entry. ; But if you wanted to record them separately, with their own effective dates, you can. Assets:ScrapMetal 10 tons ; skr_code: SM2201 (I'm making this up) Receivables:ScrapMetal -10 tons