4,976

(3 replies, posted in Manufactoring)

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

4,977

(9 replies, posted in Setup)

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

4,980

(1 replies, posted in Setup)

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

4,983

(2 replies, posted in Banking and General Ledger)

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

4,984

(2 replies, posted in Setup)

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