[HN Gopher] Show HN: I've Built an Accounting System
___________________________________________________________________
Show HN: I've Built an Accounting System
It can create invoices and receive payments. Not quite production
ready, yet. Only need PostgreSQL installed to try. I will add
support to choose SQLite when they add native support for geography
types.
Author : journal
Score : 162 points
Date : 2024-09-18 21:04 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bbor wrote:
| Thanks for posting, looks pretty polished to me! Lowkey love the
| design, super modern finance applications do make me irrationally
| afraid. Perhaps it's trauma from Navient-administered student
| loans...
|
| I will say this is by far the most passionate README.md I've ever
| seen, lol; Intuit didn't invent accounting;
| they've stolen it. Accounting existed before computers,
| databases, and software. Transactions were recorded in physical
| journals using pen and paper, which forced accountants to have a
| better understanding of company finances due to the process of
| manual entry, with little room for error. Now, the process has
| been automated through software, and the journal entries are
| hidden away, leaving only the final report to spot errors and
| fraud. None of you can call yourselves accountants; you're just
| QwackBooks users. The truck drivers of the office. Your boss
| thinks of you as a whiny, tail-dragging *****.
|
| Do you have any particular reason/motivating experience for this
| ethos? Why not just use a piece of a paper/the default Excel
| ledger template/the `ledger` CLI tool if it's so important to do
| things by hand?
|
| P.S. "Truck drivers of the office"...?
| journal wrote:
| There are multiple reasons.
|
| 1. Intuit discontinued QB desktop on may 31 this year. 2.
| Intuit recently raised prices. 3. QB online has terrible
| navigation. I can make invoice in my system in less clicks. 4.
| I needed a feature to optionally print supporting documents
| with the invoice while having the ability to arrange the order
| of those documents. I then can integrate with mailing service
| and have PDF ready to mail programmatically. Instead of having
| to join PDFs together. (this feature doesn't work cause I can't
| afford IronPDF, it's the only PDF package I would use). 5. I
| don't like any limits on users or numbers of invoices I can
| have in my system. 6. Excel is error prone for more than a few
| records. Drag and drop accidentally one cell to another? 7.
| Multi-tenancy. I wanted to manage multiple companies without
| logging out.
| xupybd wrote:
| Hahaha, this is the most aggressive readme ever.
|
| None of you can call yourselves accountants; you're just
| QwackBooks users. The truck drivers of the office. Your boss
| thinks of you as a whiny, tail-dragging . That's why he needs
| just one of you who knows the entire system. Maybe you'll get
| lucky with an assistant, but most likely they'll cause more
| problems, because it'll be the boss's daughter and she doesn't
| give a .
| journal wrote:
| Yes, this initiative has been fueled by hate directed towards
| Intuit and the overall accounting community for refusing to
| advance. It's like playing AoE with a noob who's refusing to
| advance to the next age because there will be more units,
| technologies, and strategies to manage. Most businesses have
| one accountant, which means this entire profession is one
| initiative away from not existing at all. There's no excuse for
| a modern accountant to not know at least SQL.
|
| The patterns and practices that I demonstrate in the solution
| are nothing genius, it just took a while to put it all
| together, and it's very basic. Just one table with credit/debit
| columns, rows of which have to be organized into a transaction
| and linked with user-actions, like creating invoice, receiving
| payment, adjusting inventory, really anything, including
| foreign transactions.
|
| When the calculator was invented, we didn't get stuck with a
| bunch of "calculator-operator" professions, so why does
| accounting get to stay stagnant?
| xupybd wrote:
| Keep up the passion!
|
| What are your thoughts on plain text accounting? I know it's
| not really for businesses applications and really not for
| accountants but that's how I learnt accounting basics. I find
| that approach much better as I have total control of the
| structure. I suspect your application provides a similar
| level of control as the end company has to implement the
| details.
| journal wrote:
| I've thought about separating the journal into a command-
| line application, where the end result might look exactly
| like plain text accounting, a sorta like ffmpeg for
| accounting. Plain text is part of my backup strategy.
|
| If plain text are roads, then my approach is rail roads. A
| strict set of application logic so the operator doesn't get
| overwhelmed and is capable of managing large number of
| transactions at higher speeds of entry.
|
| Then, it's just a matter of building more rail roads for
| any additional functionality. Once built, you'd probably
| never have to touch that code again.
| 7bit wrote:
| > It's like playing AoE with a noob who's refusing to advance
| to the next age
|
| I will steal that, and there's nothing you can do to stop me!
| tonyedgecombe wrote:
| In the UK with have a concept called a micro entity in the
| tax code. Micro entities have some fairly strict constraints
| on them (10 employees or less, turnover under PS350,000, no
| foreign currency transactions and so on). Within those
| constraints the rules are fairly simple and most importantly
| HMRC provides online forms for filing your books.
|
| I always wondered about starting from those constraints and
| working back to a basic accounting solution for your typical
| business person. It would probably cover 90% of the companies
| in the UK as most of them have really simple requirements.
|
| Luckily I retired before I got around to it.
| patrickmay wrote:
| > . . . the most aggressive readme ever.
|
| I love it. It reminds me, in tone, of the Acknowledgements
| section of the Scsh manual: https://scsh.net/docu/html/man.html
| codeonline wrote:
| Some big claims in that readme for a project with no tests :)
|
| Lots of C# repo's here demonstrating unit/integration/acceptance
| testing within dockerised containers if you need some examples
| https://github.com/PeterKneale?tab=repositories
| journal wrote:
| Big things have small beginnings.
|
| I think Donald Rumsfeld said something about unknown unknowns.
|
| But, tell me what you want tested and add that to my list.
| HumblyTossed wrote:
| Lots of very successful software never had those things.
| bbkane wrote:
| Your accounts ARE the tests!!
| wg0 wrote:
| Brutally minimized to first principles and to the very core. It's
| always about the journal and that's it. No fluff. Great project.
| gamblor956 wrote:
| If you think Intuit is accounting than you don't really know what
| accounting is.
|
| Off the top of my head... every major ERP has better
| functionality, customizability, and usability than this
| relatively simple take on a financial system. Even Workday... and
| that's an accounting system grafted on top of a HR platform.
|
| This is basically yet another product created by a programmer
| that doesn't actually know enough about the field they're
| disrupting that they don't even realize that their disruption was
| obsolete a decade ago.
|
| And no, as is this program couldn't be used to run a bodega, let
| alone an aircraft carrier.
| minimalist wrote:
| Please elaborate more, my friend! Let's say that I was^W am a
| programmer who is seduced by the plain-text accounting / one-
| database-is-all-you-need notion and I think my needs will be
| simple, as I can keep the business of my bodega all in the RAM
| of my brain... Or at least I think I can.
|
| How can this go wrong? What are some of the needs that compel
| the bodega owner to move on to more sophisticated tools? Is it
| because of calculating things like taxes and hourly rates and
| the like?
| FredPret wrote:
| Imagine it's the year 1890 at Standard Oil and they have a
| building full of filing clerks.
|
| It's run by the great John D Rockefeller, of which you can
| read more in the fantastic biography _Titan_. He's a stickler
| for accurate accounting at all times.
|
| Now they decide to buy a batch of barrels for all their oil.
|
| - one clerk runs down to the cabinet with a file for all the
| items SO buys.
|
| - another cross-references each item and fetches the files of
| the vendors for each of those items
|
| - another cross-references with past invoices to get the most
| recent price for each item
|
| - another gets a list of locations SO uses to store barrels
|
| Now the purchasing manager looks at all this and decides
| which barrels to buy, from which vendor, how many, and where
| its getting delivered. So he writes out a purchase order /
| PO.
|
| So back to the clerks:
|
| - one runs along to file the PO in the PO filing cabinet.
| Remember, uncle John is watching and he wants to go to any
| cabinet or any manager at any time and get up-to-date details
| of what's going on.
|
| - another one goes to the Items cabinet, finds the barrels we
| ordered, and notes on them that a PO was issued for this many
| barrels on such and such a date.
|
| - one actually sends a copy of the PO to the vendor.
|
| Skipping over some steps for simplicity, the barrels arrive
| one day with their invoice attached.
|
| An Invoice! Now the army of clerks swing back into action.
| They get their guy at the warehouse to send them the original
| invoice that came stapled to the barrels. Then:
|
| - one runs to the PO cabinet, finds the PO that was issued,
| marks it as done, and writes the invoice number on it.
|
| - another one runs to the accounting department. There they
| make the double-entry bookkeeping entries to account for the
| money that is now owed to the vendor, and for the inventory
| value that has gone up.
|
| - another one runs to the vendor cabinet and records the
| purchase on their file
|
| - another one goes to the inventory cabinet and files a
| record updating the inventory balance for the barrel item
|
| - someone files a copy of the invoice for future reference
|
| Eventually we pay the invoice:
|
| - a clerk keeps an eye on the payment terms for this and
| other vendors and calculates how much cash we have to send to
| each vendor each month
|
| - another runs around to each paid invoice marking them as
| paid
|
| - another one actually writes the cheques and mails them off
|
| - someone has to tell the accounting department how much
| money we just paid, to which vendors, out of which bank
| accounts
|
| Things get fun when these barrels eventually get sent to a
| production facility and filled with oil. Now the clerks have
| to do the correct filings to destroy the barrel items along
| with a quantity of oil, and create a new filled-barrel item.
| The cost of this depends on all of the cost of the barrel
| item, the oil, the labour, and some other things, all of
| which is determined using past entries.
|
| This is a toy example and the complexity spirals from here.
| For example another invoice can arrive from the people who
| transported the barrels. Depending on your CFO, or the
| current accounting laws, you might want to include that in
| the cost of the barrels, or record it as a business expense.
|
| You might have different departments who do their accounting
| separately, so now each transaction has to be split
| correctly. You might want to track the hourly rates of each
| employee and factor that into the cost of each finished-
| barrel item, and also tracking what everybody should get
| paid.
|
| Add to this any idiosyncratic business rules stemming from
| management decisions, laws, unique physical constraints, or
| whatever.
|
| An ERP system is all of these cabinets and their rules put
| into a relational database with a front-end.
| PaulDavisThe1st wrote:
| The question was about a bodega owner ...
| FredPret wrote:
| Bodega guy can probably get away with Excel (I shudder at
| the thought but it could work) or a very lightweight and
| cheap ERP (which doesn't exist)
| RagnarD wrote:
| An excellent post, thanks.
| minimalist wrote:
| Thank you for the excellent reply! I think I understand
| now... Once a business starts transacting in things other
| than a single type of money (say durable goods,
| consumables, services, or say other types of money) it
| becomes necessary to reconcile these non-money-denominated
| accounts. And for that, you need more than a single
| database, or single spreadsheet. You need a suite of
| persons or softwares that can __account__ for these stocks
| and flows, and the rules that come along with them.
|
| And that is called ERP, of which "simple" money accounting
| is but one component of.
|
| So root commenter's objection was more along the lines of:
| "those are some bold claims for mere money-accounting
| program. if you used a _real_ accounting program (as in an
| ERP) then you'd understand how complex peoples' needs can
| be". And the tone they phrased it elicited the downmods :)
|
| I guess I understand. I still admire the OP and the
| frustration that fueled their desire to create a tool that
| works for them. And the tone of the readme is very
| endearing, it reminds me of the things my IRC friends would
| say to kick-off a lively discussion...
|
| And so it has!
| FredPret wrote:
| Thank you!
|
| To add to your point, there's also other complexities
| like multiple currencies, keeping track of tax owed, and
| probably the biggest one: multiple people of all skill
| levels entering data into the system at the same time.
| InMice wrote:
| This comment doesnt deserve the downvotes its getting. If you
| ever work in an ERP system you will realize the complexity of
| tracking cost, inventory management (which is not just simple
| item, location quantity), purchasing, quotes, lead times,
| approval processes, BOM data structure, assembly, work orders,
| sales orders internal/external, etc etc. All these may boil
| down to basic cost account primitives but making a system that
| is a ledger then dismissing other solutions and saying you
| could manage the project of constructing an aircraft carrier
| make you wonder if the author has ever touched an ERP frontend
| or back. On top of that there are open source ERP and other
| smaller companies that make proprietary ERP that do not do some
| of the things intuit may do draw the ire of some.
| 7952 wrote:
| I agree. Although do you think ERP as a discipline is
| actually successful in solving these kind of problems? It
| seems to be a field dogged by underperforming or failed
| systems.
| sotix wrote:
| Cool project! I think it is worth pointing out contra accounts in
| the section where you discuss how accounts can increase and
| decrease. Debiting a contra-asset account would decrease its
| balance for example.
| j45 wrote:
| Wow, this is really neat. Congrats on the launch. Are you seeking
| or accepting contributors? I'll be installing it today.
|
| I've unintentionally worked with and helped implement
| systemization and automation over a dozen different accounting
| systems and ERPs. They blur together.
|
| Since I have a tech background, it's not uncommon for me to say
| an accounting system or ERP is just line item rows moving though
| tables leaving their history behind... and how do you need it...
| and now it exists, haha.
|
| A few questions:
|
| - Journals and accounts are traditionally taught as the manual
| way to track different financial activities and ensure accurate
| reporting. Journals capture transactions as they happen, while
| accounts categorized them for analysis. Now that we have
| databases and reporting tools, is there a sense of where
| reporting or crunching things like profitability, job costing,
| etc could be built up from this?
|
| Account code migration - when implementing a new accounting
| system, companies tend to dither over getting their GL right, or
| changing it up at implementation. Being able to maintain that
| history could help migration of data easier.
|
| As someone who has helped design and lead implementations
| overall, with accountants handling their part, accounting depts
| can get caught in trying to do a lot with accounts and journals
| in lieu of a report.. while databases have allowed ERPs to report
| in ways (dimensions, etc) that might not be about accounts or
| journals alone.
|
| Mostly I'm thinking about organizations that wanted to build up
| calculation of profitability by asset, or resource or service, or
| product, and how a project like this could help people easily do
| it from these first principles.
| journal wrote:
| I have a few ideas in the works for accepting contributions
| that I will iron out in the coming days. I have some breaking
| changes in the works to make the journal more reliable and
| testable. The current implementation requires deep
| understanding of my vision.
|
| AFAIK, North Korea, Russia, and United States, all have the
| same five accounts types and require double-entry.
|
| This truly is a mission to rebuild an institution. My goal is
| to educate a new generation of accountants. The kind who can
| produce any report from raw journal entries and who can add new
| features to the journal.
|
| Parent-child relationships help with reporting, but I notice
| the need to include parent-child relationships almost
| everywhere; locations, items (products/services), chart-of-
| accounts, users, tasks, etc.
|
| I've not touched reporting because I know it will be easy to
| do.
|
| If I get the journal, accounts, and transactions right, the
| rest is easy street.
|
| One thing to mention at this time is that I don't see a need to
| manually enter journal entries. I'm ready to catch flack for
| saying this, but maybe... idk. Still in R&D phase.
| karl11 wrote:
| Lack of manual journals would be a non-starter, I am actually
| not clear how a business could possibly run their books
| without manual journals.
|
| An example: you make something that uses 5 inputs. I have
| inventory and cost of goods sold accounts for each of those
| inputs, but my invoices out to customers only reference the
| final product. This is where ERPs add insanely complex
| inventory management solutions. However, the simple way to
| deal with it instead is to use a manual journal to reconcile
| your inventory and cost of goods sold accounts monthly or
| however often you like.
| journal wrote:
| I have all the in the works, including complex assemblies
| and reporting.
|
| I wish I had the $ to hire help.
| j45 wrote:
| Interesting example - Complex ERP inventory management and
| manufacturing experience here:
|
| It seems reasonable to need manual adjustments, but I'm not
| sure if entries would be needed. Deciding how to make
| corrections and adjustments seems to be key in any manual
| journal entries, or not.
|
| If journal entries derive from transactions elsewhere,
| chaining those together, or something to adjust them them
| is pretty reasonable.
|
| About split entries like the scenario you've outlined? Cost
| of Goods Sold, vs manufacturing are all often in different
| parts of the ERP that may not tie back to journals always.
| Perhaps there is a pattern to setup that is repeatable. I'm
| not sure if you have a software background, but source code
| control of managing the bits of what changed when is
| important.
|
| Another scenario where manual stuff might not work is if we
| have a just in time manufacturing process, and don't
| complete the finished goods until the items are on the
| truck and signed for by the driver (un damaged) so then you
| can finalize manufacturing, invoicing, shipping documents,
| etc. There's ways to reduce having to undo all of those if
| product is damaged between manufacturing and shipping. Of
| course this has it's own caveats. Implemented OK in SAP
| though.
|
| Overall, a real need and goal is: reducing the amount
| accountants or anyone who works with an accounting data has
| to dump out data from the accounting system to "manipulate
| the data" to get a view of what happened/happening/needs to
| happen.
|
| Unpopular take based on experience: It's been my experience
| that a good chunk of accounting groups that run around with
| their hair on fire that the system is somehow not
| working... calls in someone with database or analysis
| skills, to discover something wasn't done as needed, or not
| configured and implemented. In this way, the Technical ERP
| whisperers out there who are not accountants but handle the
| "in depth analysis"..
| hersko wrote:
| As someone who was unfortunate enough to use Quickbooks
| professionally for several years, I laughed out loud at that meme
| on the bottom of the readme. Wish you all the luck.
| stevoh wrote:
| It is a good start but the hubris here is quite high (and maybe
| not a bad thing). Funny readme but rather harsh. Seems I have
| been trolled enough to provide a response here...
|
| I am not a fan of _" Qwakbooks"_ and I can't believe I am about
| to defend it but... it does allow you to enter journal entries
| manually. In fact, you do not have to use any of the screens
| overlayed on top of the GL. The additional features are meant to
| help users do things faster and more efficiently. The details are
| not hidden at all but most users don't need to see them to be
| successful.
|
| QuickBooks has all of the same core functionality including a
| well structured database too. You can interact with the
| QuickBooks Online API with a few endpoints and achieve the same
| thing much faster with scalability depending on which features
| you would like to use. If you don't believe me, just read through
| the API documentation which is really easy to follow.
| https://developer.intuit.com/app/developer/qbo/docs/api/acco...
|
| So yes, this is a well structured database for an accounting
| system but beyond that there isn't much here.
|
| Some other points:
|
| _" Due to its wide scope, the system is designed to be
| incomplete, allowing organizations to finalize the
| implementation."_ The customization involved to make this useable
| would be quite substantial and unaffordable unless you did it
| yourself (which would be a distraction from core business)
|
| _" Companies that adopt my system are far less likely to get
| audited..."_ This is false. You might survive an audit with a
| clean general ledger but it doesn't reduce the likelihood. There
| is also way more to audits than whether the TB balances - the
| substance of the transactions is obviously more important. ie.
| the accountant needs to know accounting otherwise audits with any
| system go poorly.
|
| At quick glance... both this and QuickBooks do not have purchase
| order management, capex or prepaid amortization automation,
| approval workflows, muti-dimension transaction classification
| (for FP&A), or strong multi-company/currency support. These are
| all reasons why companies switch to a more robust (and usually
| more expensive) system. These features are needed for most but
| not all big companies with hundreds of employees moving around
| tens of millions of dollars.
| journal wrote:
| Intuit has how many? I am one. Give it time.
| stevoh wrote:
| That is fair, I can respect that! Keep going!
| emeril wrote:
| omg, I'm an actual old fart accountant... "quickbooks" is good
| enough for small businesses (though I 100% appreciate the
| problems it has) if you need something robust with more controls,
| you either just use netsuite/etc. or something more specialized
| for your industry
|
| and FFS, only go the route of custom code as a last resort, you
| are better off slightly changing your business process to match
| whatever workflow/etc. is in the OTS ERP instead of having some
| cheap crappy dev (only crappy since most who do ERP programming
| are often not well paid) shoehorn your (likely ill conceived)
| process or report into the existing ERP...
| zie wrote:
| Nice start!
|
| There are a few other OSS implementations, a list on Wikipedia:
| https://en.wikipedia.org/wiki/Comparison_of_accounting_softw...
|
| As someone who has helped write and manage one used internally at
| a thousands of active employee organization I have some thoughts:
|
| Most of these skip over authorization of transactions, which is
| very important in many organizations. I.e. Tootie wants to buy a
| new widget. Her supervisor probably has to approve it along with
| someone from budget/accounting to confirm we actually have the
| cash to pay for said widget, etc.
|
| These authorization/workflow systems can get stupidly complex.
| Ours is rule/action based via regex matches against columns in
| the DB, and we support a _rules view on said table, to help
| achieve our goals and allow customization for each "module" or
| type of transaction that needs authorization.
|
| The other thing often missing is auditing. We have auditors show
| up once or twice a year and pour over our transactions, audit and
| access logs. We record every I/U/D that happens against any table
| in the DB and have kept this information forever. We also have a
| support ticket system with integrated VCS that we use religiously
| to help handle the _why_ , that also never erases information.
|
| The next big thing often missing is reporting. We have thousands
| of reports. Every employee basically needs a few different ones.
| The key people(The accounting, payroll, AP and budget
| departments, tend to get dozens of reports per employee).
|
| We perhaps overly abuse use PostgreSQL's access controls. Every
| user gets a login, and we use row and column level access
| controls. This way all of the above features are tied into access
| control. So if we make a generic report(say a birthday list), we
| can make it available for everyone, but a supervisor can only see
| their own employees and say the main manager at a particular
| location can only see records pertaining to their location.
|
| Lastly, these systems do not live in isolation, we are often the
| first and last source for information. We import and export data
| automatically against a wide range of various systems, from SSO
| to random one-off messes some employee managed to get installed
| somewhere. Having a sane way to deal with IO is essential. Our
| current best method is for every system we have to two-way sync
| with(which almost always happens if the product lives past the
| first year), we keep a separate world-view of what we think their
| data is. This way when stuff inevitably breaks, we can easily
| track down if it's an us or them problem and get it routed
| appropriately. Since we keep both our world-view _AND_ their
| world-view in our PostgreSQL database, we can replicate any
| previous state(due to keeping both world-views and precise
| auditing).
| robertlagrant wrote:
| All of that makes sense. Using your database's user model is
| something I've thought about for different types of system, but
| never done.
|
| I have a random, different question: what was the process by
| which this effort was approved? I can imagine a lot of
| companies (and their C[TI]Os) would say "Well, we should buy
| Oracle Financials and customise it".
|
| How do you get a large enough org to afford this development
| effort, without getting an org that picks a prebuilt solution
| that can be customised?
| zie wrote:
| It's because we are very old and we had custom software
| originally, way back in the 70 and 80's when we were first
| getting computers. When OpenVMS(the system our custom
| software was running on) was EOL'd, the existing team was
| given a lot of leeway to find a replacement. We were not very
| excited about the options and we had programmer staff already
| dedicated to the old custom software. Also users wanted "GUI"
| and "Web". So we implemented a new system in Python and
| PostgreSQL. PG functions are written in Python too.
|
| I wasn't part of the original team, but I was there for the
| re-write. I brought in Python and PostgreSQL and I created
| two-way sync between the old OpenVMS system and PostgreSQL,
| so we could take our time and didn't need to have a big
| cutover date. That was a _HUGE_ selling point that got
| everyone on board.
| MichaelRo wrote:
| Congrats on completing a rather involving project. Accounting
| isn't easy, I know coze I got a degree in it, although haven't
| pursued a CPA: I make a lot more as software dev and competition
| is way lower. Like, for every software company a few accountants
| would do, while it takes hundreds of developers, QA, HR, IT and
| other stuff to run it.
|
| But I digress. There's no shortage of accounting software, I know
| coze my wife works for a company selling one :) But to survive
| and succeed the key is not in the software per se as in support.
| Continuous support for all the dumbass questions the clients may
| ask and continuously updating the software to keep up with the
| incessant small changes in the legislation. Updates without which
| one cannot even submit a balance sheet to the IRS and are only
| available upon subscription.
|
| Without those the software is dead in the water.
| danielmarkbruce wrote:
| If a user understands accounting + software + databases, the
| problem and solution is quite simple. Unfortunately that subset
| is small. Given how much the world runs on software, one can
| imagine a company where a prerequisite to working there is
| understanding software and databases.
| Havoc wrote:
| >GAAP and IFRS compliant implementation of a forward-only double-
| entry accounting method
|
| You may want to replace well most of your lead image. It sounds
| like gibberish to accountants. It's the accounting equivalent of
| saying this is an IPv6 compliant x64 CPU. The words are all from
| the right field but they're put together in a way that makes no
| sense to someone familiar with it.
|
| That said accounting software is a fuckin trainwreck on both UI
| and features so I understand the hn urge to jump on this. Xero
| basically cornered the young company market by being a web based
| and being not entirely fuckin terrible.
| meiraleal wrote:
| Not knowing what they are doing is the basic premise of
| disrupting a market. It fails most of the times, but when it
| succeeds, big chances it was made by someone that didn't really
| understood the problem
| latentsea wrote:
| But does it support multi-currency?
___________________________________________________________________
(page generated 2024-09-19 23:01 UTC)