Hello, everyone. I have a client that is considering rewriting a large desktop software from legacy development platform to Xojo, which we would.
Since this program is so large, we will not be rewriting another (howbeit integrated) program that is also currently in this legacy development platform. It is a full accounting package.
Does anyone already have an of the shelf accounting software that is available for purchase written in Xojo?
Do a search for Category = Business and type Accounting in the search box, you will find some.
Accounting software is a kind of application that is complicated because it involves a lot of work and on top of that fiscals law are specific to each country. The most complicated part is employees pay creation. If you can find an accounting package that does the job, itâs the way to go as long as you may integrate functionnalities specific to your client.
This client uses payroll service and has for many years. So, that will not be a need. He does not need inventory control either. So, the standard accounting modules is all that is needed. And, yes, we will need to integrate some with the main program.
I spent years working on a âQuickBooks for General Contractorsâ application years ago that was written in VB6. Iâm not sure that Xojo is a great fit since accounting apps tend to have very have large and complex grid controls and Xojo currently does not have a grid control. While the built-in listbox is relatively powerful I wouldnât try a modern accounting application with it.
I wrote a good part of one in a legacy development system a long time ago also. It is a big undertaking.
I donât suppose it has to be written in Xojo. I just will need to be able share data with it from the other system we will be writing. We are even looking into Quickbooks.
My client thinks, however, that the way they are pushing their online app, they will probably discontinue the desktop version. I donât suppose it wouldnât be that big of a deal to stay in sync using their apis and a local app running as a service, but in my opinion local is still better.
Thanks for thinking about it for us, Steve. But what we will need is not âfund centricâ, but something simple with standard business accounting.
Rocky
Iâve written a SQL based accounting package for our own family small companies during the last 3 years. Apart from the usual, classic accounting functions it has a complex tax module, as well as assisted bank conciliation and assets and amortization control modules, having also some funny utilities like user calendar with reminder alerts and the option to individually mark entries and/or accounts for later review.
Iâm very happy with the result, both functionally and aesthetically, as Iâve achieved to keep the data entry and review process quite easy for the operator while having immediate access to accounting information like Balance and Profit and Loss. For the data grids -plenty of them- I use Jim McKayâs Dataview, that IMO is the best available ListBox replacement.
But as mentioned before, the main issue to eventually sell commercially this solution is tax compliance requirements, that are really crazy here (Spain) as youâve to introduce lots of additional data that even at some point must be sent daily to national Tax Authorities.
This means that accounting entries must be entirely designed with tax compliance on mind, and as the tax regulation changes every few months, youâve to constantly adapt the software.
Iâm the chief of development of a german accounting system (rhvFibu) and have evaluated Xojo for rewriting the system to a multi-platform engine. After a long time of testing we decide NOT to use Xojo.
The main reason was the changes in Xojo itself. Our Accounting System has approx. 300.000 lines of code (without space lines) and for example a change to the new API would not be affordable. Nobody pays for this internal work and that means binding expensive resources for nothing.
I like Xojo very much for some other stuff, but we donât trust in the future changes that Xojo might do.
Writing accounting software is not that hard, even with Xojo. But indeed, the biggest problem is keeping up with all the tax regulations. That alone is hard to get right and you for sure need a lot of experience in this field. If you mess up that part, you can even get in real trouble (claims?) because your client, that will use your software, expect the accounting software is accurate, all the time in any situation.
I would like to add, that there are accounting applications made in Xojo. As well as various tax and insurance calculation applications.
If you want to do it in Xojo, you certainly can. Of course if you use Listbox, you have to stay within what it can do. e.g. if you have some custom widget drawn in CellPaint event, you may need to change its state in mouse events and have it redraw.
But the challenge is more other questions like how you store numbers, do the math, the double-entry accounting and all the other little things coming with the regulation around this.
I donât think itâs a good idea to buy an âaccountant softwareâ
there are too many variations of them out there.
you may need more time to understand the sources of the app you may buy
and how to implement it and link to your app
than make it all yourself in your actual appâŠ
I did a lot of accounting apps, almost everytime it was something different
what you need is a robust database framework in xojo, to connect to your database
and a listbox subclass to handle the many cases you need
(or buy some good one like dataview)
This is a very valid concern that is shared by many others. IMHO, I believe that this will continue to be a concern for years to come until it is addressed by Xojo in a way that can alleviate the necessity to re-write vast sums of code, to continue standing still.
I agree. Almost 20 years ago I wrote or rewrote and accounting package along with an CPA and programmer. We set it up so that the Federal, state, county, and city specific tax code were able to be imported.
And you are correct, this CPA had to collect all of the information from each of these government entities and convert them to the format that the accounting package could import. It was sold very various states, so it so definitely a big job.
That was my timeframe as well and we found a library that handled all of the Federal, state, count, and city taxes. It was pricey but well worth it because I didnât want to be the one maintaining it. But then we got into sales tax issues like (I think it was New Jersey) where multi-dwelling (i.e. apartment buildings) didnât have to pay it between October and March. It was the stupid edge cases that drove us crazy.
You can correct. It is quite involved. With the other things that we are looking to rewrite for this client, I was never intending to do this myself (again).
Thatâs why I was asking about whether or not anyone else had an off the shelf solution already done. My client will probably just go with one of the major products out there. Accounting for him is the minor part and can be just a standard software. The big project ahead of us is the âcustomâ part of his business (everything else besides accounting).
I know that some of the big accounting apps have an API that 3rd party apps can use. Desktop Quickbooks on Windows has (had??) it and Iâd imagine their web version does as well. In the accounting app I worked on we used their API to convert customers from QuickBooks to our app. Probably violated any number of points in their terms of service but whatever. Iâd say donât reinvent the accounting wheel unless you absolutely need to.