Check the error logs and revert.
Since it works in 2.3.24, check out some intermediate versions of 2.3.24+ and see when it breaks.

Alternatively, a credit of maximum usage can be agreed upon and provided as a loan to the customer and advance received back into the customer's account.

A credit limit too can be used.

3,553

(1 replies, posted in Wish List)

A cursory look at the code shows that the schema is in install.php. It uses the mysql constructs and can be updated to use the mysqli functions.

3,554

(10 replies, posted in Report Bugs here)

Check the history of file changes for the said file in github.com and see if an upgrade to the latest FA v2.3.25+ is of any use.

3,555

(10 replies, posted in Report Bugs here)

Take a backup and zip it up and upload somewhere (possibly password protected) and pm me the link. Also state what your version of FA is.

3,556

(10 replies, posted in Report Bugs here)

Choose default theme - no dashboards. Dashboard themes do too much querying for each front page display.

3,557

(10 replies, posted in Report Bugs here)

Rebuild the index / table.

3,558

(1 replies, posted in Items and Inventory)

Try treating Commission as a pseudo tax using a separate Commission Account that receives it (or pays it out if negative).

Otherwise, make an extension for it.

FA does not have taxes based on Invoice Value. You will need to write your own extension for it. Cumulative taxes (Tax on Tax) is however available in FA.

3,560

(5 replies, posted in Setup)

Difference compared to FA 2.3 would be useful if illustrated.
Attached is your page in PDF.

3,561

(1 replies, posted in Accounts Payable)

Post the invoices as on today and make a note in the memo that it pertains to goods received in 2015.

Check the MySQL and platform versions. Also do a query to take the difference of the field value from a zero constant. It is possible to assign 0 instead of 0.00 in the insert statement in the backup sql and re-import it.

3,563

(3 replies, posted in Setup)

Move to a country that does not charge (so much) VAT wink

The CoAs will not be updated in the v2.3 repo anymore judging by what I have seen hitherto in the last couple of years. The various CoAs have not been formatted in a standard way and hence is not amenable to easy comparison - that probably was not the intention but less diligence amongst the many contributors and little or no vetting while incorporating into the repo and/or not updated when the primary sqls changed would be the real reasons.

Whether you setup separate tax accounts or just use the filtered reporting in FA is a matter of choice.

The wiki and the forum posts abound with several examples. The search feature in the wiki is broken and unlikely to be fixed in the near future on priority.

Removing the VAT lines from the reports (repXXX.php) and placing them in the company's reporting folder will override the standard ones for that company.

3,564

(10 replies, posted in Reporting)

Just re-compile the standard en_US.mo file. Only changed strings need be in the new .po file and compiled into the .mo file.

In the case of Australian or Indian English too the same applies with changed strings.

Extract the .po file from your current .mo file - only those stings that changed need/will be there. Then refer to the empty.po file and add in "the strings you wish to change" into the extracted .po file and recompile and use it.

In future, do not upgrade the language file at all from the GUI and instead only incorporate the changes in them into your version of the extracted .po file, compile and use the resultant .mo file.

In most instances language files have little or no changes and version bumps occur regularly - good business for "consultants".

3,565

(10 replies, posted in Reporting)

Hardcoding is the "Quick 'n Dirty" means.

You can make the string translatable using _("...") since the input argument will be used if not found in the .mo file (as absent in the original empty.po file). Changing it in the .po file and then using the newly compiled .mo file will make for less hassles when comparing code with the master repo and seamless in upgradation.

3,566

(10 replies, posted in Reporting)

Do not edit the _('DELIVERY NOTE') as it is a translatable string that needs to be altered in the appropriate .po file which then needs to be compiled into a .mo file before being used.

If you are using only 1 language and/or prefer this string to be in English alone, hard code it using the following instead:

                {
                    $rep->title = 'CUSTOMER INVOICE';
                    $rep->filename = "Delivery" . $myrow['reference'] . ".pdf";
                }

Post the code changes you have done.

As the db_pager_view.inc is a core file, modifying it may not be good. Checking the file that @joe suggested may be useful.

There are many places where the session.inc file is included but the add_access_extension() is not called.

Please use the "set_ext_domain()" function - see some extensions for examples like this. Even the logout.php file does not call the add_access_extension() function.

If you decide to retain the transactions for Jan-Mar in the old accounting system, then enter the march end closing balances as the April 1st opening balances by making a journal entry for the mid year Balance Sheet and P&L entries (entire Trial Balance) as of 31st March.

In the case of migrating to FA during start of a fiscal year, only the Balance Sheet closing balances of the previous fiscal need be carried forward.

Avoid sessions and keep the js local at the client side. Just toggle the state of the "select all" checkbox and on it's change based on it's current value, either populate or clear all target checkboxes and make sure the value of the "select all" checkbox is a blank string when submitting the form and it is to be ignored in the form processor.

3,572

(21 replies, posted in Items and Inventory)

Grown is Manufactured over multiple years just like if the manufacture started in one fiscal year and ended in the next one. In the interim period whilst it is being grown (manufactured) it will be considered "in process". Stock valuation can be based on "accrued value" much like if the exchange rate changed or in semi finished state.

Alternatively, the inputs for "growing" can be considered as stock consumed / applied / expenses or paid in advance to  a dummy supplier. Just before sale of grown items, they can be purchased from the dummy supplier at 0 value or at pro-rata of advanced to dummy supplier and then sold at profit to end customer as usual.

Comment out the following lines 18, 19, 80 & 81 in frontaccounting.php:

..
..
//    include_once($path_to_root . '/applications/manufacturing.php');
//    include_once($path_to_root . '/applications/dimensions.php');
..
..
//            $this->add_application(new manufacturing_app());
//            $this->add_application(new dimensions_app());
..
..

I think you need to change the size of the form field's maxlength value:

<input _last="" name="_code_id_edit" id="_code_id_edit" size="12" maxlength="10" value="" class="combo3" rel="code_id" autocomplete="off" title="" type="text">

$opts['max'] should be 20 instead of default 10 in your case in Lines 282 to 287 of includes/ui/ui_lists.inc:

        $edit_entry = "<input $disabled type='text' name='$search_box' id='$search_box' size='".
            $opts['size']."' maxlength='".$opts['max'].
            "' value='$txt' class='$class' rel='$name' autocomplete='off' title='"
            .$opts['box_hint']."'"
            .(!fallback_mode() && !$by_id ? " style=display:none;":'')
            .">\n";

When done, please submit patches here for peer review and possible inclusion in FA 2.4.