Search options (Page 18 of 97)

The types are defined in includes/sysnames.inc, but those are system types, so adding new account types without respective changes  across application code does not make big sense.

Janusz

I have found the problem with the dashboard module, just small typo in installation setup already fixed. New module version is available from repo.
Janusz

@apmuthu
Thanks for support, all you have written is true. On the other hand usrr's response is main factor which drive the code changes to right direction. This application is made free available to help people do their everyday business, so it any feedback is highly appreciated. Lets don't discourage FA users .

@demille
I understand your objections regarding supplier invoice posting, but you are at least partially wrong, and probably it is effect of misunderstanding of FA Direct Invoice functionality.

So, Direct Invoice is just Supplier Invoice, GRN and PO made in one step. The additional cost GL lines available in Supplier Invoice form (and absent in Direct Invoice), are for special use and in most cases just sparse. Therefore _all_ journal entry postings generated by Supplier Invoice (without GL lines used) are the same as those generated when invoice is entered via direct Invoice page.

I agree it is sometimes useful to have editable tax entries on Supplier Invoice. When FA is properly configured taxes should be properly calculated, and there should be no  difference between real invoice and calculated VAT. The only reason I can see for this is small rounding errors which can be different in your supplier's invoicing soft.

Currently those differences are not supported directly in supplier invoice form in FA, but you can fix this by separated journal entry.

Again, I agree whether this is legally acceptable depends on local law. I can only say we are working on improvements in code which will make both EU intracommunity trade and above situation better supported in FA. Unfortunatelly this will not be available before next major release,a s additional databse changes are needed for this.

Janusz

I'm not sure what you are talking about. Nothing has changed in Charge to field recently. Which version you have used before, and which one you have installed now?
Janusz

There is no hot keys support in forms, only in menu and submenus (hot keys work on links).
Adding hot key functionality to form field would be big improvement, but this is quite complex javascript/php task.
The hotkeys could be stored analogicaly as underscored letters inn form field legend text. Anybody interested in contributing the code ?

Janusz

There is extension module 'requisition'  available in FA REPO, just for PO approvals processing. It was contributed by Dennis Gichangi  long time ago, and may be not fully functional. The extension need additional MySQL priviledges, which is not always possible on shared hosting accounts.
Janusz

Currently hot keys functionality works fine e.g. on FireFox, does not work propely under Chrome. Hot keys are defined in text messages (or translation files) by preceding respective menu option text letter by ampersand.

There is no need for any list of hot keys, as they are directly visible (as underscored letter) on menu options.
Janusz

The realse day is not decided yet, but maybe even this week.
Janusz

Sure, this is right workaround until this is properly implemented in application repo.
Janusz

Yes, I would like to find time to fix this. Email content hardcoded in repo class is definitely design issue, or rather long lasting stopgap .

Janusz

Erwin,

I have included the COA as I received it. I have no possibility to verify contributed COAs in all details, but I have just looked in the file, and seems that account group '30' (described  'OMZET') is here. Anyway if there are any problems found in the current version, please send me updated file to be included in repo.

Janusz

But this means that either the consumption/production is posted somewhere, or your ledger does not mirror your assets properly till the year end.