Search options (Page 31 of 97)

No, this should not be changed even by phpmyadmin. When you change it uom on already issued invoices will change also. Create new item with another uom instead.
Janusz

Yes, this is great issue in current tax system. All tax rates should be defined with start-end dates. This is complex problem, as after the tax rates change we have still support both taxes in parallel for some time. This extension  still waits to be done.
Janusz

I'm not sure what you mean. If you want to change the additional information from order to order - there is no support for this. All what you can do is just include additional information together with the supplier code and this will be printed on every PO to this supplier. E.g. if have entered:
  'ABC123 - available in individual packaging or in 12 pc parcel.'
in 'Purchasing pricing' page as supplier's description of the item - this will be printed on every PO.

Janusz

I see nothing suspicious in your setup. What about php.ini file?

The tax system  basics was described many times here. Also there is a couple of example chart of accounts in FA repository with various tax systems set. You can install one of them on separate comapny and check how the tax system is set up. Tax system in FA is flexible, but may seems complex at start.
Janusz

Currently most of the auxiliary info on PO is not set at all. We shold provide some usable info here in next FA release. Regarding line description: you can entry per supplier item description in Items & Inventory/Purchasing pricing. Those per supplier descriptions are printed only on pdf reports, or purchase orders sent to supplier. For internal use (eg in PO inquiry) they are still presented using company's own naming.

Janusz

We have to see at least your php.ini file and System Diagnostics info to have a chance to help you, howevere this is not message displayed by FA  so most probably also the problem is somewhere outside the FA source code.
Janusz

Yes, Elax, you are right . This is really real example . Surely any reported issue of this kind will be fixed.
Janusz

There is no special requirement to php extension beside openssl to access extension repository, so I guess the problem is related to some other settings. Also the message mentioned in the first post does not appear to be generated by FA code. It rather suggest some external problems with conenction to repo.frontaccounting.com
Janusz

Yes, I know this legendary rounding problem, but I couldn't find single place in FA where addition is done so many times without rounding, that the error has a chance to rise above half a cent. Of course I can be wrong, so we can switch with all the database double columns to  numeric, as soon  as the problem  will be proven  on real example .
Janusz

We used to translate the messages using poedit or similar tools. According to my feelings the problem here is not lack of tolls, but rather lack of translators .
I'm not sure what we can do to help you with the problem?
Janusz

I'm not sure what you consider unusual here, this seems rather logical for me. There are many situations when company posess a couple of inventories, and no all the goods are available from the inventory located at the same place as salesman office. Therefore inventory is considered only as default. Sales terms are another subject: the company owner not always want to give full credit to every salesman, so sometimes only cash sales is accepted, sometimes only delayed peayments, sometimes both.

Janusz
NB Keep it easy, we really like to be helpfull for everybody at this forum, but sometimes the real life need us outside virtual reality .
J.