Search options (Page 41 of 246)

Version 2 should be a new module (with it's own distinct name) in your case as you want to have both versions concurrently with only a subset using the new version. A separate script in your new version module must independently migrate the security settings as needed or have it set anew in it.

Investigate at point of display if the user decimals kicks in.

PHP Version?
Some have rounding errors.
Increase precision to 17 from default 14 in php.ini.

Please note that this was done when escaping was really long winded in the old days 10 years or more ago with having to carryover large number of users from PHP 4 and MySQL 3.x.

Also a multitude of languages cause quite some heartache across linux/windows platforms that all this was cobbled together with least pain. The forum is replete with such legacy issues.

Possibly in FA v2.5, better HTML escaping and accommodation of HTML encoding / decoding will be implemented.

Nice to have such experienced users like yourself pitch in. Please study the code as it evolves and make suggestions that hopefully will not break existing users installs.

We do not want code to be executable like "Bennet Cole &$var Co" where $var can be a malicious bit of code change.

@joe: If such allocations are not accounted for, we need to update the wiki accordingly - or is a fix slated for it in 2.5?

Check the code flow on value of $all in the get_invoices() function in the report.

As SA_MULTIFISCALYEARS has been enabled (logged out and logged in again after clearing browser cache), verify the setting is saved in Setup => Access Setup => Role: System Administrator (Role of logged in user).

The function that allows Suppliers, Customers and Items to be entered in older fiscal years is defined in admin/db/fiscalyears_db.inc is is_date_in_fiscalyears() and is used in the function is_date_in_fiscalyear() defined in  includes/date_functions.inc where the first said file is "include"d.

Inspect the variables at that point in Line 204 of the last file stated above. The function user_check_access() is defined in includes/current_user.inc file.

Scope, availability and visibility of the variables and their values will be of use in investigating it. If all is well, then scour the scripts that use these values before "post"ing the updated values to the db.

@itronics: must this now be added into the core?

Switch active fiscal to previous fiscal in Setup => Company Setup temporarily for the change to be done.

@poncho1234: This may not be tenable this way as the checkbox for Editable Description can be changed independant of the specific transaction at any time. However, if it is implemented by checking f a change in standard description from the one used in the PO, then any inadvertent change there may get reflected in the Supplier Invoice without notice - hence a prudent way was sought in the current implementation where a human re-check is envisaged before finalisation.

@joe: If this was the original intended functionality, then it must be changed.

When a PO is raised and the Description is edited, then it must persist through to the Supplier Invoice.