Try removing your .htaccess file and install what you want and then revert it back.

Describe your MIS reporting needs or try dashboard (and extension) / exclusive / exclusive_db themes

4,578

(3 replies, posted in Installation)

Trace the login method that check for IP spoofing and tailor it to suit your needs.

4,579

(15 replies, posted in Setup)

The Full Tax is okay within FA.

The "Simplify" Tax is not available in FA currently and I do not think any other country follows such rules and hence may not get into FA.

You can however tweak the ajax updation code for the "Simplify" invoice so that it automatically puts the rest in an expense account.

4,580

(6 replies, posted in Installation)

Your Shared host running FA v2.3.22 - is it a live production server having data? If so, PM me.

4,581

(4 replies, posted in Reporting)

It will be easy if you forked a Git (either the official one for the core alone or mine for both the core and the extensions and my mods) and then began developing so that others can study the code and assist you and possibly include it in the core if found useful to many.

The gl/bank_transfer.php file has a function gl_payment_controls() that populates the form you refer to (Banking and GL => Bank Account Transfers). Refer how the dimensions are populated in some other forms you wish to emulate.

The official snapshot from GitHub.

What country and what language are you after?

When you create a new FA install, you will have Company 0 which is the default. Create a new company within it and then you will have Company 1 which should be your actual company.

Log in to Company 0 and then in Setup page add what ever language/exten/theme/CoA you need and the activate it for the appropriate companies (Company 1 here).

Now login to Company 1 and you can choose what language you need from those activated for it.

4,583

(48 replies, posted in Setup)

Administrator Access permissions in the default CoAs for FA v2.4 for "Closing GL transactions" stands disabled as of now.

The others like the following remain disabled by default and are same as in FA v2.3:
1. Allow entry on non closed Fiscal years
2. Revenue / Cost Accruals

FrontAccounting is not blocking your access to PO / MO files. All such files have been openly available in my GitHub Repo as well as within the FA User Interface for the default company.

Please clarify as to what your actual live setup is and whether you are accessing it from the default company. Also what is your Linux blockages. Use PoEdit for making po/mo.

You cannot access the install/create sub menus in setup if you are not logged into the default company.

What virtual environment are you referring to?

4,585

(48 replies, posted in Setup)

Work on FA v2.4 is progressing steadily.

Some minor fixes have been backported into my GitHub Reop's FAMods folder.

Kindly note that any changes to the FA v2.3 sql (CoA) using my mods will break auto migration to FA v2.4 - the tables will then have to be manually updated for the differences using tools like db schema synch as in SQLyog.

Here is a lowdown on the developmental changes in FA v2.4 today:

A stub for db_profiling has been created.

Line 12 has been inserted in includes/db/connect_db_mysqli.inc (This will need to be taken care of when directly importing date fields values into tables)::

define('SQL_MODE', 'STRICT_ALL_TABLES,NO_ZERO_IN_DATE');

includes/ui/ui_input.inc [function edit_trans_link()]

is changed to

includes/ui/ui_view.inc [function trans_editor_link()]

This simplifies links like in manufacturing/search_work_orders.php necessitating an extra field sorder.trans_type in the sql in the function get_sql_for_sales_orders_view()

A minor fix to JsHttpRequest now includes a check for existence of array key in $_SERVER['QUERY_STRING'] before using it.

Transfers between bank accounts is now editable qualified by check and update bank transfer functions.

includes/date_functions.inc now has sql_date_comp() and date_comp() helper compare functions.

The typos in the language reference strings are now collimated in the wiki.

If anyone finds that such strings exist in the code, please update the said wiki page.

4,587

(1 replies, posted in Reporting)

Currently, in reports where the From and To form fields are used, abbreviations (DN, etc) denoting the document are inserted between the document number and reference name (Customer, Supplier, etc) or prefixed to the document number (SI, etc). The Glossary page in the wiki clarifies them.

In some reports forms, the document name is prefixed to the labels From and To instead and this should be the way forward (and backported for uniform user experience on migration).

To this end amongst others, another wiki page titled FrontAccounting Form Fields User Interface code is now available.

4,588

(4 replies, posted in Manufactoring)

The "period(.)" is truly confusing (thousands separator in EU land and a decimal point in others) - we follow the en_US-general/demo sqls for COAs when reporting generic issues. Putting in a country in your profile might save some confusion in such cases.

4,589

(1 replies, posted in Reporting)

Abbreviations, Terms, Meanings and Explanations for FA are now in their own page in the wiki. This is expected to help non native English speakers (and that includes US and all English dialects spoken outside of the strict Commonwealth) find equivalents in their "vernacular" and leverage FrontAccounting fully.

The supplier.notes field can contain Non Field DB Data in key#value pairs and can now be displayed in the header of the PO Entry Form. The pseudo field#values can be like MO#100 PPFrt#2000.  This will enable us to realise that we must order more than Min Order Value (MO) and will get free freight paid if the order value exceeds the PrePaidFrt Value (PPFrt). This requires the backported reporting/includes/reporting.inc file.

The commit is available in my GitHub FAMods folder.

4,591

(15 replies, posted in Setup)

What do you want instead of 30 (days?) ?

4,592

(65 replies, posted in Setup)

1. You might want to take the whole CoA (accounts master table) into an excel sheet, replace all "&" with "and" and avoid any special characters (thanks to some encoding issues) in them.
2. Then re-number the account codes to keep a 5 or 10 spacing as the case may be whilst retaining the first digit to cover similar account classes.
3. Suitably alter the records in sys_prefs table and other places where account code defaults get in.
4. Make sure you have the right foreign key values in the various accounts dependencies - the wiki page on ERD will be useful in this regard, especially the A/c Masters and POS Relationships ERD.
5. Import them in when done making changes as needed to other tables for these Account Code changes.

4,593

(4 replies, posted in Reporting)

This is a prelude to fleshing out a Wiki page on DIY FA Reports - Innards and Construction and to address a request from @mkisekka:

....
I am a php newbie but generally understand programming concepts and work with oracle databases.
I have a task to customize some FA reports, such as the cash flow statement, profit and loss statement - adding some rows, changing layout and the like.

I was wondering what general advice you would give to someone starting out - in terms of understanding report structure and/or using Repgenerator.
I've installed FA and tinkered abit with some code but so far its only hacking and I might need a more structured approach. E.g. say I took rep707.php and wanted to understand how the report is structured, should I study line by line or?
....

The following notes are to act as a general guide for code and layout information:

1. The reporting/includes/header2.inc file contains elements of the top portion of any standard report.
2. The reporting/includes/doctext.inc obtains all the variables needed for the reports
3. The actual reporting/repXXX.php file contains the body of the report where line items are listed.
4. The reporting/includes/pdf_report.inc has the FA reporting classes and common includes
5. The reporting/reports_main.php file has the form elements that tailor the report (filter choices)
6. The reporting/includes/reporting.inc file has the code for Non Field DB Data where many key#value pairs delimited by # and space separated are placed in some large text field and parsed out on demand. This needs to be backported for v2.3 or taken from my GitHub's FAMods folder.

The first 3 above can also act as company overrides by placing them in the appropriate company/#/ folder.

Examples are in my GitHub FAMods folder.

The RegGen extension was hacked in to work in a rudimentary manner and was made for a much earlier version of FA. It is not very secure and can at best be used for development purposes in a trusted secure environment.

Hitherto, FA users who have successfully built reports have not significantly shared their work and hence it is in a state of relative freeze at present. With the knowledge of DIY reports becoming common, this situation will hopefully reverse itself into competing betterment and result in wider FA adoption.

4,594

(1 replies, posted in Reporting)

When we take a rep101 using the years in which there were some transactions, there are some rounding errors.

4,595

(65 replies, posted in Setup)

Committed the mod for printing the name of the person who generated the sales quotation. Needs to be activated in line 19 of doctext.inc - depending on whether the one in the overriding company/#/reporting/includes folder is used or the native one in reporting/includes folder is used.

This now commited to my FAMods in my GitHub Repo

4,597

(65 replies, posted in Setup)

In fact I have just completed a few backports and non field db data into reports (Min Order, Prepaid Freight, etc) in my FAMods besides the en_GB-general.sql complete fix in the extensions.

The devs have categorically said they will only provide critical updates to the v2.3.x branch henceforth and I expect a final v2.3 release is hence due.

On the 7th the extensions were queried and an update was expected but all were frozen as of 28th last. I have also done a thorough clean up of all 38 official languages including the yet unaccepted Tamil (ta_IN) even though it has more phrases translated than some of those already there.

The easiest way to do a fresh CoA is to
1. Import the en_US-new.sql into a fresh database
2. Export it from your mysql client schema + data - to say one.sql
3. Make changes as you see fit in the tables that contain data - Currencies, date/time formats, company defaults, sys_prefs, chart_masters, fiscal years, etc.
4. Export it to say two.sql.
5. Use Winmerge to sift the differences and see how they compare with the existing Canadian one.
6. Make changes to two.sql but retain a blank audit_trail table and the standard users table from the US CoA except for some specifics for Canada. That way you'll preserve the default admin access / password and not bother with session based timestamp changes.
7. Remove the CREATE DB and USE DB commands in two.sql.
8. Now you have your CoA - two.sql - rename it to en_CA-general.sql and upload it in the place of your officially installed one so that the config entries remain.

The ones I maintain have the schema without the collations bunched together and the insert statements entered later all in one bunch with those that vary between CoA's alone towards the end. That way when making a new CoA, we just need to copy this and make changes to the data towards the end alone!

In fact my suggestion was to keep the schema and standard data in one sql file and the rest that changes between CoAs alone be used from separate sql files. It remains unaccepted due possibly to accommodate some queer collations and out of turn insertion of data where strict InnoDB and other RDMS constructs will make import fail on cascade dependencies.

If a supplier provides free Pre Paid Freight if the order exceeds a certain value (eg., PPFrt#2000) and accepts orders above a certain Minimum Order value (eg., MO#100) and we need these values on the Purchase Order, the commit in my GitHub repo does it.

The said formatted values should already exist in the #_suppliers.notes field.

During the preparation of this mod, starting with a fresh FA install with customer, supplier and items imported, the sql statements necessary to reset the FA database after testing POs were:

TRUNCATE TABLE `1_audit_trail`;
TRUNCATE TABLE `1_comments`;
TRUNCATE TABLE `1_gl_trans`;
TRUNCATE TABLE `1_grn_batch`;
TRUNCATE TABLE `1_grn_items`;
TRUNCATE TABLE `1_purch_data`;
TRUNCATE TABLE `1_purch_order_details`;
TRUNCATE TABLE `1_purch_orders`;
TRUNCATE TABLE `1_refs`;

-- SELECT * FROM `1_stock_master` WHERE material_cost <> 0'
-- UPDATE `1_stock_master` SET `material_cost`='0' WHERE `material_cost`<>'0'
UPDATE `1_stock_master` SET `material_cost`='0' WHERE `stock_id`='ITEM001';

TRUNCATE TABLE `1_stock_moves`;
TRUNCATE TABLE `1_supp_invoice_items`;
TRUNCATE TABLE `1_supp_trans`;

-- SELECT * FROM `1_sys_types` WHERE next_reference <> 1;
UPDATE 1_sys_types SET next_reference=1 WHERE next_reference <> 1;

Checkout SlimAPI FA (manual extension).

Info in the Wiki.

The en_GB-general.sql Chart of Accounts have been thoroughly cleaned up for FA v2.3.22+ and made in synch with the en_US-new.sql CoA and attached herewith. compare with a diff tool like WinMerge to see the details.

View the commit in my GitHub repo.

It now sports the new GRN Clearing Account (1003) and set in the sys_prefs table as well and all field sequences match the standard US CoA.

@joe: Can include in official repo.