
Ask HN: Good stack for a billing and invoicing application? - tmbsundar
I&#x27;ve a Visual Basic application at hand which served its time and still going strong in a productions setting. But changes to the logic are  expectedly difficult with UI and business logic completely intertwined. And also, if I want to put it on cloud, this architecture is going to fall off. For the above two reasons, I wanted to upgrade this into a modern stack - and an obvious choice was to - Javascript based UI, with any DB to support (postgres) and a queue or app server to service this.<p>My question is: None of the web style solutions seem to be suitable for a keyboard based (tabbing style) grid to represent an itemized billing. I was able to see some Kendo or dojo etc.., but most of them have a mouse based &quot;Add next Item&quot; button , which is not suitable for a fast paced billing application. Any suggestions within or apart from web based frameworks should I look at? Or should I fall back to some systems programming language (C type) with Qt kind of solutions?<p>Thanks for your suggestions in advance.
======
uiri
I would say, eschew any fancy front end framework. Build an HTML form. They're
tab-able by default. You can even tab to a button and hit enter to press it
from the keyboard.

Separate out the UI and business logic, and you can probably port most of it
to a backend MVC (where view means a template, meaning HTML) framework in
VisualBasic. Once it is cleaned up, you can do a feature-by-feature rewrite in
your backend language of choice (I'd likely recommend Django if you can go
Python, but SparkJava might be more prudent for the kind of big freaking
Enterprise that chooses to do stuff in VB).

Edit: after seeing
[https://news.ycombinator.com/item?id=14787139](https://news.ycombinator.com/item?id=14787139)
I agree that you'll probably need handsontable or something like it.
Simplicity is your friend; overengineering is unfortunately a common tendency
among developers of all stripes, although the web kind especially.

------
wheelerwj
Have to ask, why are you building this in house? Most accounting packages
(quicken/quickbooks/sage) have this built in already and your
accounting/bookkeeping people would already be familiar with it.

Or, if you're a smaller shop, maybe something like stripe? Or even a Google
Doc/Excel. They have a bunch of easy to use templates these days.

If you really have/want to build it, this architecture is simple enough that i
don't think its really stack dependent. MEAN would handle front end and a
diverse invoice structure; Django/Postgress have some great admin-form
features and handle multi-table queries gracefully; and .NET with windows
forms would make short work of a desktop UI. Just go with what you know and
focus on speed.

~~~
tmbsundar
> why are you building this in house?

This is an existing desktop application built years ago (10+) and went through
many updates over the years.

Lot of business specific customisations are also in. Hence, can't ditch it and
go for a generic solution at this stage.

------
meredydd
So, the first question to ask is: "Do I need the full-fat web development
stack?"

If this is a hobby project, and the goal is to learn all five languages and
3-4 frameworks needed to create a traditional JS+API+DB web app, then go to
town! Everything you want to do (eg keyboard-driven layout) is possible on the
modern Web; you'll just need to read a lot of documentation. (And you will
have quite a valuable skill-set at the end of it).

But if you just want to get something done (and especially if you're used to
the ease of VB), be warned that the web is a exhausting many-tentacled pile of
technologies. You might want to look at a simpler approach. I'm biased - I'm
cofounder of a tool that aims to bring the VB experience to web apps (visual
UI design, everything in one language [Python] etc - check it out at
[https://anvil.works](https://anvil.works)). If you don't want to tangle with
the web, something like Anvil, or building a native desktop application, are
still possible routes.

~~~
tmbsundar
Thanks for your comments.

> If this is a hobby project

No. It's a production live project. But, there is no urgent timeline as of
now. I am not in a hurry to move.

> if you're used to the ease of VB

Yes. But, not looking a close experience in web tech. I am familiar with web
tech to some extent. But, the grid thing is a little bit tricky for me.

Thanks for sharing Anvil - Will look at your solution.

------
cyberferret
I wouldn't dismiss most js frameworks because the buttons seem to be mouse
driven. With simple jQuery, or even plain javascript, you can 'attach' hotkeys
to those buttons.

For example, our HR app (which is built on Bootstrap + jQuery) has a button
for 'Add Employee' on the main employee list, but we have also linked the '+'
hotkey to that button so the user does not have to revert to the mouse to add
the next employee when doing batch entry.

Within that, there are plenty of grid style entry plugins (mentioned elsewhere
in this thread) that you can add on to do things like the invoice screen etc.

But be aware - study the depth of some of these plugins. Invoice entry screens
are fraught with all sorts of things like real time validation (e.g. will you
allow a user to specify a quantity of an item greater than what is in stock?
Can you calculate tax amounts on the fly line by line? Can the user change the
pricing of the item on the fly and are there rules that have to be adhered to
in order to prevent fraud) etc.

Yes, I've developed invoicing type apps many times before. It certainly has
some 'gotchas' that can trip you up, and the UI is certainly a lot more
complex that it first appears as you have to adhere to strict accounting
principles in the back end.

~~~
tmbsundar
> But be aware - study the depth of some of these plugins. Invoice entry
> screens are fraught with all sorts of things like real time validation (e.g.
> will you allow a user to specify a quantity of an item greater than what is
> in stock? Can you calculate tax amounts on the fly line by line? Can the
> user change the pricing of the item on the fly and are there rules that have
> to be adhered to in order to prevent fraud) etc.

Yes. You hit the nail on it's head. All of these apply in this case.

------
notoverthere
If you're interested in building it as a web app but want a keyboard-
accessible grid / spreadsheet-like interface, then you have a few options.

The first resource I'd recommend is JSpreadsheets, which is a list of open-
source JavaScript spreadsheet & data grid libraries.
[https://jspreadsheets.com](https://jspreadsheets.com)

One of the most fully-featured JS libraries is Handsontable. It looks very
flexible. They have some demos on their website to play with:
[https://handsontable.com/examples.html?headers](https://handsontable.com/examples.html?headers)

(Bonus: If you're using react, there's already a react component for using
Handsontable: [https://github.com/handsontable/react-
handsontable](https://github.com/handsontable/react-handsontable) )

------
kowdermeister
> None of the web style solutions seem to be suitable for a keyboard based
> (tabbing style) grid to represent an itemized billing.

I suggest you to build your own keyboard listener extension, frontend
frameworks are don't really have built in support for this since it's too
specific. You can very easily listen to all keyboard events with vanilla JS
and trigger actions accordingly.

Take a look at Angular 4, it has all the event handlers you need in the
templates/view modules. [https://coursetro.com/posts/code/59/Angular-4-Event-
Binding](https://coursetro.com/posts/code/59/Angular-4-Event-Binding)

Angular is more like a full feature framework with some enterprise feel to it.

If you want a modular system with craftmanship level attention to detail (you
can build your stack how you like it), then try React or Vue.js.

------
johncomposed
Fwiw, I built a very-very similar application recently using Angular (1.5) and
it wasn't a great experience.

I originally used Angular because of all the enterprise components available
(like JSON-Schema form elements and custom tables) but pretty much all of them
ended up having some behavior that wasn't quite what we needed. Which resulted
in tons of wasted time writing code around them, then forking and modifying
them, then eventually just scrapping them and rewriting the parts of the app
that used them. So I'd personally recommend not going with existing large
table/form components. I also found myself working around some of the "Angular
way" of doing things as the number of inputs and calculated outputs got
larger, with most of the time savers up front (two way binding, etc) requiring
major refactoring to get decent performance.

If I was doing it again I'd probably use react/redux/redux-thunk, just for
more control over how the application's structured and how I'm connecting the
inputs to the business logic.

Like, I recently found [https://nadbm.github.io/react-
datasheet/](https://nadbm.github.io/react-datasheet/) and was pleasantly
surprised how small and reasonable the codebase looked. Though I'd still just
use it as a start/inspiration for your own custom table components instead of
actually pulling it in as a dependency. And they give an example where they're
constantly reloading the whole state of the table on change (I think
intentionally just to keep the demo simple), but there's definitely better
ways to deal with mass input. Just my 2 cents, good luck!

Edit: I originally recommended checking out redux-inputs for mass input, but
it has an open issue* that was exactly the kind of thing I ran into with the
form/table libraries that started the vicious cycle - I guess the moral is at
least when you write your own way of doing this kind of thing you get to
choose your battles.

* [https://github.com/zillow/redux-inputs/issues/14](https://github.com/zillow/redux-inputs/issues/14)

------
jasim
Check out ERPNext ([http://erpnext.com/](http://erpnext.com/)). It is a modern
open-source ERP solution built in Python, has commercial support and an active
community.

There is also Eto
([https://github.com/picoe/Eto](https://github.com/picoe/Eto)), a cross-
platform C# GUI toolkit on which the excellent Manager accounting software
([http://www.manager.io/](http://www.manager.io/)) is built.

------
martijn_himself
Would you consider migration to a (C#) .NET based solution with either a web-
based or WPF / UWP front-end? I can't imagine keyboard shortcuts being an
issue with either one of these choices.

~~~
tmbsundar
Thanks. Would explore this option.

It's not keyboard short-cuts, but the ease of showing a let's say 10 by 8 cell
grid and entering data by moving up, down, side - left and right. etc.,

~~~
tmbsundar
Can't edit this comment anymore. Hence, posting as a reply.

Looks like UWP is more specific to Windows. When moving away from VB, I was
thinking of more decoupling from any specific lock-down, in case this can be
productized later.

------
holydude
I would stay away from JS fancy stuff. Stick to the proven Java/C#/RoR stack.

------
pc86
If it's already in Visual Basic the default for "modern stack" would be a C#
API back end and whatever JS front end you want. This would also be crazy easy
to host online if that's what you wanted to do.

This has to benefit of being able to use the exact same database and update
the schema over time with your API, completely independent of the front end.

You don't specify whether your app is currently desktop or web based. Hitting
the enter key has been the standard way to submit HTML forms since the very
early days of the internet. Why would you need a special library to support
that?

Since you're asking about C/Qt I'm assuming the current app is desktop based?
Having just completed a client project migrating a large desktop-based
application to the web (C# API, Angular front-end), work flows are going to
have to change to at least some degree. It is very rare to be able to cleanly,
easily port 100% of the desktop experience to the web. If that's a deal
breaker, make sure it's not worth it to stick with the desktop. You can still
separate your concerns and provide a modern experience.

~~~
tmbsundar
> currently desktop or web based

currently desktop based. Want to move to web based.

~~~
pc86
Assuming you're using a local SQL Server instance, you can put that online and
build out an API and front end independently. Put some serious thought into a
C# API and JS front-end. When done right, you can rewrite either of them
without impacting the other.

------
lypusest
If you used strictly Visual Basic and still utilise .net, have you ever tried
to use PowerApps from Microsoft. It is like ready to use tool to create custom
applications without much of programming and maybe it is worth of trying for
you instead of any new frameworks?

------
tim333
Sounds like you can use all sorts of different tech but web2py might be easy -
the default forms are tabable, it's quite quick, easy, relatively secure and
doesn't need updating all the time. Against it's not so modern and makes it
hard to do stuff like chat messaging.

------
rwieruch
If you like to try React, checkout the open source book The Road to learn
React [0]. Not sure what kind of payment gateway you are using, but after your
first application is up and running, you could add Stripe to it [1][2].

\- [0] [https://www.robinwieruch.de/the-road-to-learn-
react/](https://www.robinwieruch.de/the-road-to-learn-react/)

\- [1] [https://www.robinwieruch.de/react-express-stripe-
payment/](https://www.robinwieruch.de/react-express-stripe-payment/)

\- [2] [https://stripe.com/](https://stripe.com/)

------
ojhughes
Personally, I would choose Spring Boot + Angular 4 for a project like this.
Lots of functionality automatically configured "out of the box" (DB access,
security, JSON object mapping) and a rich set of UI components available with
Angular such as Prime-NG
([https://www.primefaces.org/primeng/#/](https://www.primefaces.org/primeng/#/))

------
lostboys67
As I spent years working on billing for a world leading telcoms company I have
to ask

What do you mean by "billing application" your q implies you want to input
transactions into some accounting (presumably double entry) system?

Does not your Accounts receivable have a web frontend or an API? do you really
need to build your own accounts receivable / invoicing system

------
8ig8
Instead of writing your own invoicing application, what about writing a custom
front end to an existing web-based app (using existing API)?

That way you can focus on the specific UI you need and not mess with
recreating everything else. Your UI doesn't need to be browser-based.

------
Tade0
I don't have a specific solution for you, but you can narrow down your search
by taking into account whether something(be it a framework or component of a
framework) is focused on accessibility.

------
maxxxxx
Maybe libraries like Developer Express would work for you. They have pretty
sophisticated grids and other UI controls that are close to a desktop look and
feel.

------
paraplegic
Ncurses?

