FrontAccounting is designed after usual model implemented by all fiscal systems known to FA developers. This model does not allow to use on invoice tax rates according to taxpayer wishes, but the tax calculated is dependent either on item tax category, customer tax group or both. So, I guess you will not find proper solution to your problem inside FA.
Janusz

452

(20 replies, posted in Translations)

riyaz has finally solved the problem himself, and the ur_PK (partial) translation is in repo. Thanks!
Anybody interested in finishing the translation is welcome to do it.

Janusz

453

(6 replies, posted in Accounts Payable)

Skynight, please look closer at the GL postings generated in FA, then you will find they are made properly: inventory GL account postings are triggered on delivery/GRN, not on invoicing. (Providing you have correctly set up FA).
Janusz

454

(1 replies, posted in Accounts Receivable)

All the settings description is about Points of Sale menu option under Setup tab. As POS every user has assigned POS definition, you can control which type of sale user can make (credit and/or cash sales).

Janusz

455

(6 replies, posted in Accounts Receivable)

Mercurial does not need git installed of course. And you probably also do not, unless you use git for other projects smile.

The instructions above contain all what is needed to have version control of your local code changes, and easily merge all new code from FA upstream when the changes appear in central repo.

When you clone FA repo, the result is new working directory, with local hg repository in .hg hidden subdir. When you have cloned  repo, all subsequent Hg commands should be run inside the working directory tree (but outside .hg subdir). Therefore the start of the procedure in your case should probably looks like this:

cd /var/www
hg clone https://frontaccounting.hg.sourceforge.net/hgroot/fontaccounting/frontaccounting repository4FA
cd repository4FA
hg branch local_branch
.... etc...

(providing you really want to access your FA with url like http://localhost/repository4FA/index.php )
Janusz

All the strings in database are user defined, so we cannot add them to *.po/*.mo file, just because we don't know what is content of your database. You can do it  yourself if you have enough time for it:
1. add the strings from your database tables you want to be translated to all *.po language files you like;
2. translate them and generate *.mo files;
3. find all places in sources where the strings are displayed not translated, and add _() calls over respective variable/expression.

As you see recipe is simple, but you need to spent a couple of days to be satisfied.

Janusz

All the user interface is subject to translation, so FA user sending out an invoice in Germany can have messages in German.  The document printout language is defined on target basis (e.g. for invoices you can set document language per customer branch). But unfortunatelly FA does not support multi-language texts stored in database, so e.g. item names will not not be translated.
Janusz

No, as for now it is not considered in near future, but both tasks  (make sales order on base of PO and adding additional informative  field in  items table)  is rather simple task. Anyway unless you are somewhat comfortable with php syntax you probably will need  somebody hired to make it for you.

Janusz

Regarding popup editors available under function keys, they are set using set_editor() function. In specific case of customer_list_*() UI helper functions you can toggle this feature with $edit_key argument (see ui_lists.inc).

Janusz

I'm happy you have read my post, but have you created any purchasable items in inventory, or not?
Janusz

461

(10 replies, posted in Installation)

I guess you have extracted FA traball in some subfolder under your www document_root (e.g. /var/www/frontaccounting) ?
Then just run installer in your browser (just http://localhost/frontaccounting/index.php) and follow instructions.
Janusz

I have added possibility to close sales order even if it is partialy delivered. You can now use 'Cancel Order'  button in sales order edition form to remove undelivered quantities from sales order. Will be available in next minor FA release.
Janusz

Have you read my post?

464

(38 replies, posted in Accounts Receivable)

Yes, this is the right way.
Janusz

465

(38 replies, posted in Accounts Receivable)

Yes, if you only use the possibility to keep your own report version in company folder, you even do not need mercurial. But AFAIR you have talked about some other customizations (added links on final transaction page) in another thread. The described worflow should make your life  easier in this case.
Regarding the company folder you can easily remove the company folder from Mercurial version control in your local_branch to be on safe side.
Janusz

466

(10 replies, posted in Installation)

Unfortunately Debian/Ubuntu package is very old, and the problem arises due to changes in MySQL syntax (since some version TYPE is not allowed in CREATE, ENGINE should be used instead). Please follow Joe's advice.

Janusz

Check your hosting account, probably your server is compromised.
Janusz

468

(8 replies, posted in Translations)

Your language files should be named ur_PK, not ur_PAK.*
Janusz

469

(20 replies, posted in Translations)

Please send the translation files to us, then we can check what is wrong with them (if any). YOu can use contributions mailbox.
Janusz

470

(9 replies, posted in Reporting)

You have to activate the installed extension for every company you like to use it in.  Go to 'Install/Activate Extension' select your company in top selector and activate the report extension.

Janusz

471

(38 replies, posted in Accounts Receivable)

If you are looking for easy way for maintaining local patches on top of latest FA, you should simply use mercurial. Just clone sourceforge repository on your development box and  maintain your local changes in separate branch e.g.:

hg clone https://frontaccounting.hg.sourceforge.net/hgroot/fontaccounting/frontaccounting
hg branch local_branch

Then apply all your local patches, and save the changes:

hg commit -m "my local patches"

When new changes appears in repo and you want to update your local_branch:

hg pull
hg checkout local_branch
hg merge default

When no conflicts happen between your changes and chnages in repo you are done. Otherwise you have to resolve conflicts and commit the effect of merge to the local_branch (more details about how to resolve the conflicts you will find in google).
Janusz

472

(4 replies, posted in Installation)

Was this some .htaccess file related problem?
Janusz

473

(7 replies, posted in Translations)

Fine! This way you will have language pack updates instantly available from repo, and the report files will be _much_ smaller than in those generated on utf-8 systems.
Janusz

I don't know Windows environment, but FrontAccounting can print to any network printer supporting lpr protocol. This can be e.g. any computer using CUPS system with activated legacy BSD lpr support.
Janusz

475

(7 replies, posted in Translations)

You can recode the language file (e.g. with 'recode' tool), compile it again with msgfmt, and change declared encoding in installed_languages.php. But if you have enough permissions on your linux server you can just add de_DE.iso-8859-1 locales along with de_DE.utf-8. I see no reason why you consider this simple solution as 'not smart'.

Janusz