A bug, unnecessary parameter $db in check_for_recursive_bom, has been fixed in /manufacturing/manage/bom_edit.php.
Check out the new file in the CVS repository at SourceForge.
Joe
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by joe
A bug, unnecessary parameter $db in check_for_recursive_bom, has been fixed in /manufacturing/manage/bom_edit.php.
Check out the new file in the CVS repository at SourceForge.
Joe
Hello,
I presume you have installed the language correctly.
The xx_XX.mo file is in place /lang/xx_XX/LC_MESSAGES
You cannot use the 'Display Setup' for permanently changing the language. You must use the 'User Setup' and select the user and there change the language.
After that you must logout and login again.
Now the language should work.
Joe
Thanks,
This will be fixed in the next release.
Joe
The program takes care of the rounding problems.
Should you experience problems with the rounding, please let us no.
We have not experienced any problems so far.
Joe
You are right. We should probably change that to a 'cleaned' chart.
A chart without demo data (clean) is available in the frontaccounting package under /sql/en_US-new.sql.
Joe
Hello swiro,
An easy and very simple solution to the quote problem is to just create a new report and copy the the Sales Order script to a Quote, and rename the report to a Quote, with no further changes.
But it should be done during a version update, as a couple of files need to be changed. Remember it is quite easy to delete Sales Orders. So should there be no order you just delete the Quote (Sales Order not sent yet).
For better result the Sales Order should be marked as a Quote as long no Sales Order has been sent. But this requires a database table change.
The item regarding creation of documents in a more interactive way has been considered, but due to lack of resources it was postponed.
Joe
Just a comment to the last item.
Under the tab, Items and Inventory, section Pricing and Costs, Purchasing Pricing, you can enter Provider specific details about an item.
Joe
Hello Tim,
I guess they are about moving the site and this item didn't come through.
Anyway, your message was about having alphanumeric accounts instead of numeric accounts in the General Ledger.
To everyone out there. This is really not a problem to change. The internal database field is alphanumeric, for sorting purposes, and therefore no changes have to be done to the database.
As I can see, there is only one place to change in /gl/manage/gl_accounts.php,
Line 50-55. Uncomment the lines with // in fromt of the lines like this:
//elseif (!is_numeric($_POST['account_code']))
//{
// $input_error = 1;
// display_error( _("The account code must be numeric."));
//}
A generally better solution is to have a global switch for allowing alphanumeric characters in the accounts, e.g. in config.php, that has a default value of 0.
E.g. the variable $accounts_alpha = 0.
Then the lines would look like this:
elseif (!$accounts_alpha && !is_numeric($_POST['account_code']))
{
$input_error = 1;
display_error( _("The account code must be numeric."));
}
As you see, if this switch is set to 1, the script will never perform this sentence.
This could be a wish for the next version.
Joe
Hello,
The language setting in the display setup is not being saved. It only uses the language during the session. To save the language setting go into your user account and change the language here, save, and the next time you log on it should have changed.
Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.