A comment about the single user and huge data. I've a test database with 100 000 account, 1 000 000 events, etc. That is about 2 gb in size. Not huge, but not tiny either.
There's no multiuser support yet, but I plan to add it.
Storing accounting information is not that hard. Generating reports on them is. I know about ledger and beancount and will definitely look into them.
Unfortunately local laws demand each verification to be enumerated and not editable. That's something ledger and beancount doesn't provide to my knowledge. (and this again proves your point, writing accounting systems are hard, perhaps it's better to stick with the CRM bit).
Just out of curiosity: what prompted you to make it ncurses based?
I can see lots of reasons why this could be practical but most of them (like bad network connection or slow hardware) belong to the past.
Is it just a personal preference or aesthetics?
I do most my work in the terminal, using vim and mutt. I wanted something fast, I can't stand waiting for a webpage to load. That's not a good user experience for mem.
So I tried to mimic vim (fast load times and no use for a mouse). Then ncurses was a natural choice because I wanted to be able to reach the app from everywhere (at least until I've made it network aware).
What's old is new again!
Beautiful and reminiscent of old school mainframe systems in CICS.
When system users were mainly roomfuls of data entry staff (universally female) these systems were absolutely optimised for power users banging through as many transactions as possible. No mice in sight, all keyboard operation.
Not yet, it's something really early and I haven't had time for a project page yet.
Still figuring out if I should make this open or closed source. Hard choice!
I definitely reach out here again once I've project page up and running.
A web based interface IMHO would be more usable. However nice project. I am an emacs person so using the system via a vi-like editing style seems hard to me.
Maybe you could automatically generate invoices with LaTeX and save a pdf, that would be cool.
Also, you could add an account overview, where you could see the balances of all your accounts, compare it with previous periods. Paint them red if you're expenses are soaring etc. Maybe some graphs...
You could also prepare a screen for financial indexes such as cash flow, debt-capital ratio etc.
Hi,
I'm the developer. Thank you for your suggestions. I must make you dissappointed that there's no plan for emacs style keybindings at this point.
The system has a very clear API between GUI and backend, so future plans is to add more interfaces, a web based one is on the list (although IMHO web based interfaces are worse to use).
The LaTeX idea is great, so great that it's already done. I tried to keep the video short and don't show all features. I also have integration with mutt. Sending a new invoice is just a keystroke away and then mutt is opened with an attached pdf and a template mail body.
The account overview is the biggest weakness right now and something I look forwared to improve. I definitely take your suggestions with me towards that work.
> A web based interface IMHO would be more usable.
I'm sure you're not the only one but I can see how this could be much nicer than a Web UI for someone (like me) who prefers Vim and Mutt over Atom and Gmail.
I have a supicision that OP is also a Vimmer who (like me) gets upset when a user interface doesn't accept hjkl and all the other idiomatic Unix/Vi keyboard commands.
A comment about the single user and huge data. I've a test database with 100 000 account, 1 000 000 events, etc. That is about 2 gb in size. Not huge, but not tiny either.
There's no multiuser support yet, but I plan to add it.