Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options
I have a few small bugs and a bunch of questions. I'm doing a virgin install of 2.4 based on apmuthu's git repo, which I've forked on GitHub.
The demo data doesn't install thanks to a SQL error.
core\sql\en_US-demo.sql line 2022 has a "default ''" on a text field, which is illegal. The same is true for
core\sql\en_US-new.sql line 1776.
I'm likely to find a few more things like this along the way. At some point I'm likely to start hacking on some of the code in a bigger way, mostly refactoring stuff. That said I don't want to have an unmaintainable orphan on my hands, so I'm not sure where the best place to send push requests is, apmuthu's repo or the git repo on Sourceforge.
Also:
- Is there a policy on PHP support? Can we code to 5.4?
- My IDE is complaining about ANSI encoding in various files. Is there a problem with converting them to UTF?
Alas, this is nowhere close to retail POS. It's an application domain specific solution. There are about three providers in the space, none of them with more than a vague and ill-informed clue on the matter of ERP, and none of them FOSS. The one I'm using is the best of the bunch, has a dominant market position, and my guess is there's 5 to 10 developer years required to replace the application specific functionality, although I know from talking to others in this business there's some demand for an open solution. That's a ball I'm not going to be picking up...
Indeed, it's a POS system with a few accounting-like bits done by someone who had never kept a set of books in their life. One day I hope a FOSS solution will emerge to replace it. It would be great to have FA handle invoices from the time of generation and strip out the rest, while still giving users access to payments though the existing UI. That would be a huge project and I'm not holding my breath.
If all you got for setting up your repo is a few ruffled feathers, then you've done very well. In my experience keeping secret sauce in private repos just leads to slower innovation, increased maintenance, and needless forks. Google will tell you I'm a pretty fanatical supporter of the GPL, but I think it makes for good business sense to work as collaboratively as possible.
My top priority will still be getting our records up to date and getting data into FA. Once that's under control and I've made the accountant happy I'll take a look at 2.4.
I'm hesitant to tie things together via the database. Our current billing solution does a great job of invoicing, tracking payments, and integrating with back end systems but from an accounting perspective it's near brain dead: it has no idea about distinguishing between product and service revenue; it's impossible to set terms by client, so a random visitor gets the same credit treatment as a Fortune 100 enterprise. The phrase "purchase order" has never crossed the developer's minds, and so on. Yet the other things it does it does very well and it's an essential part of our business. Fortunately it's extensible, with hooks for just about every possible event, so it shouldn't be too hard to have invoices and payment posted to FA and broken down by the right product/service at the same time.
We're also in the process of adding another brand with an unrelated product line, so the hope is to use FA for that exclusively. I want FA to track A/R so that means two invoice numbering systems, or at least a field to link "external" invoices in FA.
I should also mention that two of the things I've done a fair bit of are unit testing and web page parsing. My UT experience is with PHPUnit, which may not be helpful here. As for parsing, if I get particularly lazy I'll write a Yodlee equivalent page scraper for TD Bank so I can get bank data straight from the source. 
@ahrtgnbn if you hadn't asked the question I probably would have sailed off into a broken implementation so I'll give you credit for that at the least! No question that @apmuthu has done great work and provided a wealth of information along the way. As a PHP developer I have mixed feelings: on one hand I find the code a little dated but at the same time I'm glad I don't have to master yet another framework to dig into it. I've spent a good part of this year looking at a range of accounting solutions ranging from gnucash through to Xero and FA looks like the best choice from my perspective. That's a subjective evaluation, heavily biased by my deep expertise in PHP vs. just knowing enough to be dangerous in C or Python.
As far as bookkeeping is concerned I've got some catching up to do, and I need to build a major integration with the closed source billing solution that runs our business. The catching up means I've got a pile of OFX files I need to bring in to FA, so it looks like an import module is high on the list ( I know I could do an OFX to CSV conversion but there's some transactional integrity built into OFX that I'd prefer not to lose). Our billing system integration is going to require an extension of what I've found in terms of an API, and possibly a little schema modification to ensure that everything is tied together. On that note I'm not sure if the PayPal import module will hit the mark with dual currencies and linking back to invoice numbers in the billing system, so that might be job three.
Short story: unless there's some show stopper I'm missing, I expect to be around and involved with FA for quite a while.
I just wanted to thank both of you for this thread. As another Canadian just starting to evaluate FA, this thread has a lot of useful information that just saved me a lot of time.
Posts found: 6
