Importing customer csv data in FA v2.3.6 (Page 3 of 3)

When done, don't forget to submit it here and to the project to assist others.

@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.

@instance & @ahrtgnbn: Thankyou for your kind words. With 2 dedicated Canadians on the team, FA is now set to scale great heights!

OFX (Open Financial eXchange) can be used directly in FA as it is XML. An extension can be hammered out for data interchange between FA and OFX. That way there need be no CSV conversions / import / export rigmarole.

Where 1-way data transfer is envisaged, the target database can have the affected tables replaced as views of queries based on the source database tables. That way there will be no need for any data exchange at all.

When implementing Inventory, the foreign item codes may cause the item_code tables to have different item_codes for the same stock_id which is intentional to enable different vendors to map their same products onto common stock_id of FA and such item_codes will be used for ordering from the respective suppliers.

FA does not have history of item prices in it's price lists but all goods sold / purchased will have such history in their transaction records.

The wiki will need good cross referencing within it's pages and between the wiki and the forum threads besides summarizing the distilled info from the forums into properly linked wiki pages in context to enable easy and intuitive search / navigation.

When time permits, do test out the FA v2.4 as it is now undergoing some final testing before release. There is a separate thread on it's developmental progress.

1. FA 2.4 is still a work in progress with basic FA v2.3 functionality merged into it and some new features being implemented. The db schema is subject to change and quite a few unused fields in FA v2.3 will be removed and some new ones are now being introduced. For all but very basic small installs, FA 2.4 will be trouble at the moment. Progress on FA 2.4 has been slow (yes, years in the making...) and in bursts and spurts when the key dev @itronics gets the time. Meanwhile changes in FA 2.3 need to be incorporated in FA 2.4 from time to time as well. If you know what you are doing and can manage a separate fork of 2.4 for your trajectory, then it will be suitable. If only basic usage is envisaged and no upgrades are needed, FA 2.4 might just fit the bill.

2. You need items in inventory before they can be chosen to be ordered! If all items in your supplier invoices need not be tracked, then they can be listed as a Service Item with editable description. If you do not wish to track inventory at all (Service Item) and avoid purchase order generation itself, then just maintain journal vouchers - manually compute taxes if any....

and we're going to play it safe with 2.3; will advise ...

A

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.

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...