Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options
Yes, db_fetch() function used in list helper functions returns data array indexed both associative and numerically. So it can lead to some problems depending on code processing the result. As far as I know this is not the case with FA base code.
Regarding blank string (" ") used as fourth argument in customer_list_row(), it is intentional in some places, just to have unnamed special option, which could be read just as 'not applicable'. E.g. in recurrent invoices it is special case of recurrent invoice defined for whole sales group, not individual customer.
J.
Please ignore this topic, we now need some forum tests.
Sorry for inconvenience.
Well, there are some places where confirmation is good idea, but it make no sense to include it everywhere. I believe application
should make user's life easier, so asking for confirmation where there is small risk for any damage is just waste of user's time. We have added confirmation dialog iin places where using delete action can complicate user's life, and when the action can be harmful additional constraints does not allow for this. But if you want to add confirmation dialog in any customized page, you can do it easily using submit_js_confirm() helper.
Have you found any place in standard FA where additional confirmation should be added?
Janusz
Quickbooks is not known in my region at all, but seems it is quite popular in Anglosphere.
Does quickbooks have any generic export feature included (like CVS) ?
Janusz
Hi bhoo,
Could you send me example selenium based tests as you use it for your modules?
Janusz
Well, I'm not sure where the problem appears, but in general case rounding errors should never appear in accounting application. This simply can break balances in some places. Please report where you have found the problem, maybe better approach is just to avoid the problem at the source?
Janusz
AFAIK ISO-8859-15 is just Latin1 extended by Euro sign. This does not solve the problem for other latin encodings, but for Western Europe languages is probably the best solution. Using Utf-8 has other drawbacks like enormous PDF reports size, so we have decided to use mixed approach in next FA 2.5 i.e. utf8 encoded database together with arbitrary encoding in user interface. upgrade scripts will recode old databases to utf8.
Janusz
Really excentric approach
.
Keep in mind FA make lots of checks before the data for any entered document are stored in database. The more FA code you ommit the more chances to break your ledger.
Janusz
You can eventually block the message by commenting out display_warning() call in sales/includes/ui/sales_order_ui.inc ca line 60.
Well, off BS accounts are used also in Poland, however they are optional, and so far are not implemented in FA.
Janusz
Nothing changed so far I'm affraid. The payroll system highly depends on local requirements, so we have not decided to start this development in main FA core.
Janusz
I'm not sure what you mean. If the problem is long delay on this page, probably you have no internet contact to our package repository, which is checked when you entry Install/Activate Extension menu option.
Janusz
If your account has Default24 POS tied, constraints related to this POS are used during invoice issue.
Otherwise e.g. the salesman not allowed to make cash payments could issue cash invoices and receive money.
Janusz
This is really strange. I guess this can be related to php version you use. I have encountered similar problem on some php 5.2.x i nstallation some time ago. Unfortunately I have no access to Win based FA installation, but you can try adding following line at the top of install/index.php:
just below line containing '$path_to_root="..";
Janusz
Seems this can be related to bug 0001173 just resolved. Please login to our Mantis system, download fixed session.inc file, use it and report the results here.
Janusz
Posts found: 15