Search options (Page 24 of 247)

Update the extension from the FA24extensions repo.

It is possible that the Arabic abbreviation works in the FA UI but will need to be in English (IMHO) as it is a parameter to the appropriate function through the SlimAPI (probably the way it is implemented as there is no language/theme info in the API) and not a direct variable from a translatable form.

In your instance, the amounts were different across vouchers and appear multiple times, but such occurrence is due to the voucher number being same. There should be no linkage with amount as we can have the same amount legitimately in the same day for the same account too. Check on duplication in the reference: BKPMT-00010. Maybe if the taxes are different you might want to have different account numbers for each.

State which version / date of FA you are using. Please note that the file referred to was last changed on 2015-12-12 and no one has complained about it in the last few years.

Possibly the report re-calculates it instead of taking the adjusted value. Make the adjustment with some dummy "receipt of inventory" and see what happens.

Backdate entry sys_prefs variable can work in unexpected ways like when time zone is taken into account. Editing any field in an invoice is fraught with foreign key issues. Best is not to allow any edition at all and allow deletion and make fresh entry or make credit/debit note entries and supplementary invoices for any differences envisaged. Accounting is serious business - no marks for a good try.

@joe: any sys_prefs flag to prevent selling below cost?

Again, this is a "feature" to provide for freebies and encash obsolete stocks as well. Buy a cat for a million and get the house free!

The way FA is currently setup is that the salesman is part of the cust_branch table and that dictates the inquiry and reports as well.

As FA v2.4.x has frozen the DB schema, we can make this new feature in FA 2.5 only or in the meanwhile, make an extension for it.

Alternatively, we can possibly keep the salesman in the cust_branch table as the default and keep a flag in the sys_prefs table for overriding it using the logged in user but what if the logged in user does not happen to be a salesman at all? Hence this filter too has to be applied before using the override - that the logged in user is a salesman indeed.

@joe: looks like in this way we can address this issue and modify the views/inquiries and reports to accommodate it as well.

Fine indeed. This is so for those small businesses where the only owner wears all hats.
Change line 556 in sales/sales_order_entry.php:

        display_warning(sprintf(_("Price %s is below Standard Cost %s"), $price, $std_cost));

to

        display_warning(sprintf(_("Price %s is below Standard Cost"), $price));

The Quantity and amount sizes of 15 are hardcoded in qty_cells() and amount_cells() functions in includes/ui/ui_input.inc and are visible in the rendered page source code attached.

The outer table is 80% of the browser width and the inner table 90% width of that table. The field's column cell widths dynamically expand but the actual input fields remain the same size.

Also refer:
https://www.tutorialrepublic.com/faq/how-to-expand-select-box-to-its-default-width-on-focus-using-css.php

Yes, that is the way to go for now since currency is on a per customer basis as of FA 2.4.8. Maybe, FA 2.5 can have currency per branch. There exists a default branch bank account but may mix up currencies and exchange rate computations if used for a single customer!