That is the reason why I have created my unofficial repo. Download and use offline - will be slightly outdated though.
https://github.com/apmuthu/frontaccounting/blob/master/farepo.zip

5,402

(2 replies, posted in Reporting)

Check this post.

Share the code?

Make the extra fields in a new table with a 1:1 relationship with the parent table and have the inserts and updates done using a trigger. This way all will be fine when the db schema changes and it can be made into an extension.

Install the old version so that the files and folder permissions and apache configs will be okay. Now update to the latest code from Sourceforge.
Empty the database using phpmyadmin or some other mysql client. That way the db user for the FA db will exist. Now install from the web GUI.

5,406

(2 replies, posted in Setup)

Make sure you empty the database first before the restore.

5,407

(6 replies, posted in Translations)

Use the file from:
install/lang/new_language_template/LC_MESSAGES/empty.po as a template and make your translations in a new file (pt_PT.mo) and then compile it into pt_PT.mo file (or Joe will do it for you) if you submit it to the project.

5,408

(2 replies, posted in Modules Add-on's)

Joe, wouldn't you want to include it in the core?

5,409

(24 replies, posted in FA Modifications)

Wouldn't you want to share how you did it?

5,410

(4 replies, posted in Modules Add-on's)

Activate the extension and theme in the specific company and use it.

5,411

(40 replies, posted in Modules Add-on's)

Re-Updated the RegGen v2.3.9-3 extension to v2.3.13-1 at my personal GitHub Repo.
View Git ChangeLog.

The real change is in the sql file and hence the table xx_reports must be updated.

The changed files are attached in this post..

Change the installed_extensions.php files at the webroot and the company specific folder as well to reflect the change in version of the extension.

5,412

(18 replies, posted in Reporting)

Look at this post and change the default language for printing to suit your needs.

Install the old version from the repo, replace the /var/www/frontaccounting folder contents with the latest one and purge the database and install from the web browser.

5,414

(24 replies, posted in FA Modifications)

FA v2.3.x does not use the Foriegn Keys as yet (aka CASCADE ON DELETE, ON UPDATE, etc). It will be implemented only in FA v2.4. In PHP, the SQL statement will manually connect the tables using the JOIN syntax only. The keys will be there and the indexes will be available to speed up the execution.

The ERD is to show what links to what but is used to understand and frame the SQLs only.

5,415

(4 replies, posted in Announcements)

Official Git and Primary SF Mercurial Repos are now in synch after some SF hiccups some time ago.

5,416

(12 replies, posted in Announcements)

Diff Files from FA v2.3.16 to FA v2.3.17 is attached herein.

5,417

(3 replies, posted in Announcements)

FA v2.3.16 is synched with the unstable v2.4.

The diff file set from v2.3.15 to v2.3.16 is attached herein. Minor SQL changes pertaining to extra fiscal years and default company fiscal year are needed (see the sql file diffs).

5,418

(4 replies, posted in Announcements)

The changed list of files that can safely overwrite existing ones for migration from FA v2.3.17 to FA v2.3.18 is attached herein.

No database changes needed.

No attached files. Zip up the font files together and upload the zip file.

Where are the three font files?

More on Tuffy Font:
http://www.fontsquirrel.com/fonts/tuffy
http://www.dafont.com/tuffy.font
http://packages.debian.org/squeeze/ttf-tuffy

In Linux:

apt-get install ttf-tuffy
ln -s /usr/share/fonts/truetype/ttf-tuffy/* reporting/fonts

5,421

(2 replies, posted in Accounts Receivable)

Quick Entries is the way to go.

5,422

(24 replies, posted in FA Modifications)

FA has an includes folder in each major functionality's folder (sales, reporting, etc) besides a common one in the webroot. Each db folder in the major functionality's folders are basically models in the MVC architecture where themes serve the views, the actions coming from the URL GET parameters and the ACLs from the session variables.

Using a trigger to make the extra fields get inserted when the primary table's insert succeeds is one way to avoid writing php code.

As for docs, what little I have culled out is placed in the Wiki which would benefit from better organization as I have been left on a limb quite often when searching for my own nuggets hidden there in not very intuitive key word search terms.

Where possible, I have cross referenced in the wiki pages, the forum posts that pertain to it but not vice-versa very much.

Foreign Keys and references are due in FA v2.4 only.

5,423

(24 replies, posted in FA Modifications)

The function add_item is in inventory/includes/db/items_db.inc and the sql statement for the insert referred above is at line 49 onwards:

    $sql = "INSERT INTO ".TB_PREF."stock_master (stock_id, description, long_description, category_id,
        tax_type_id, units, mb_flag, sales_account, inventory_account, cogs_account,
        adjustment_account, assembly_account, dimension_id, dimension2_id, no_sale, editable)
..
..

From a design sustenance point of view, it might be better to have a separate table and link the primary keys on a 1-to-1 basis and use another insert statement in a new function that gets executed after this function's success. Then such scripts can be bundled into a separate Extension and installed into any FA instance. It will then possibly be compatible with future FA versions or be considered redundant if the functionality gets incorporated into the FA core.

5,424

(8 replies, posted in Modules Add-on's)

Thanks Elax. That settles it for the record then.

1. Manually enter one item directly from the FA GUI
2. From the Import Items Extension, choose to export the Items
3. Prepare the rest of your Items as per the exported file
4. Now import this prepared file into FA from within the Import Items Extension