Hello all and especially Alfred.

I think I see the problem. When the GETTEXT is not installed on the server, FrontAccounting will create a PHP file from the PO file. But there is no PO file there, therefore it will fail. You then tried to upload a PO file instead of a MO file, but FrontAccounting renamed it to a MO file.
The solution here is to have two upload fields. One for the PO file and one for the MO file. This way we would be sure that either way the new language files will work.
I will change the Install routine, so this would eliminate the problems.
Of course you could have uploaded the PO file by FTP, but you wouldn't know what the problem was, right?

Thanks Alfred, for pointing this out for us.



(27 replies, posted in Dimensions)


There was an explanation in the Setup Forum but it should have been here, so I will repeat it.

Simply speaking it is just a way of keeping track of various departments, cost centres, projects inside the company.
You can have 2 levels, e.g. level 1, department, level-2, cost-centre.
When you create the dimension you decide if it should be of level 1 or level 2.
You can by this keep track of cost centres inside a department inside a company.

Default the system havs 1 level of dimensions. That is, you can keep a simple track of departments or cost centres or whatever, but just in one level. That is, you can keep track of departments only or cost centres only inside a company.

If you don't need dimensions you can set it to 0 in the company setup.
Here you can choose between level 0, 1 or 2.

I hope this gives meaning to you.



(2 replies, posted in Report Bugs here)

Alfred, these bugs have been fixed a while ago, se answers to your last post in the Setup Forum.



(9 replies, posted in Setup)

Hello again Alfred,
Please take a look at the file /frontaccount/CHANGELOG.txt at SourceForge in the CVS repository.
After the release of 1.12 there have been several updates, among others those that you report here. We also changed something in the file gettext.php as you will see here.
Try to update all the files since release 1.12.

There hasn't been time to make a translation documentation yet, though there are some explanation on the download pages.

You might search the Internet for gettext and poEdit for more documentation about the MO and PO files.



(9 replies, posted in Setup)

Hello again,
I don't have much experience with the IIS for Windows. But I know that there are others out there that have succeeded to install language on it. I think it was an email correspondance and I don't have that email on hand.

Let us hope, Alfred, that there are somebody out there that can help us again. And it that case we would put a more detailed instruction here.

So please guys, tell us if there are special things to do for Alfred smile



(9 replies, posted in Setup)

Try to get the latest gettext.php from the CVS repository at SourceForge. It is in the folder /frontaccount/includes/lang/gettext.php. I hope this helps.


Hello popsicles12,

You can ask the Administration through 'Contact Us' on this site. I know that they are working on it, but I'm not sure how far they are.



(4 replies, posted in Wish List)

Hello patsko,
This sounds like a real hoot. We will think of a way to implement it. I think it can be done without database inteference. If we create a special folder for these external scanned documents, it should be easy to view them online.

Well we have to think of a way to split it up and to get it optimal.

Certainly a good idea. Thanks.



(4 replies, posted in Reporting)

Hello El_Guar
The documents are all hard coded at the moment.
Most of the field positions are inside /reporting/includes/pdf_report.inc in the member function header2.
If you intend to change it, please make a backup of the file, should we make further changes to it.

Best regards


(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.



(9 replies, posted in Setup)

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.


This will be fixed in the next release.


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.



(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.


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.


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.



(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.



(2 replies, posted in Setup)

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.