Search options (Page 180 of 246)

Currently email is sent using the reporting/includes/class.mail.inc file's email class and that too only using reporting/includes/pdf_report.inc's End() method of the FrontReport class and the function send_reorder_email() in inventory/includes/inventory_db.inc (yes, there is no inventory/includes/db folder in FA 2.3). These wrapper function and method are the only ones that get mail sent in FA.

The email class' methods to(), cc() and bcc() are the ones that add email addresses to the respectively named class properties that get into the mail header before being sent.

Therefore the calling wrapper functions/methods must properly populate the email addresses into the appropriate array argument's to be passed on to the actuator functions in the email class.

Also see a related post.

See if the function that gets the email addresses returns a scalar / one address only.

Also see if your sys_prefs table has this entry.

Also check if this post is relevant to this issue.

You may have to manually hard code in 2 or more email addresses into the routine that emails out and see if the emails sent actually get through php in the first place.

Some issues discussed in this post may be relevant as well.

Yes. The Non Field DB Data concept has now become available - see detailed instructions in the wiki.

When you bill the customer, just bill it as 2 items, one for the gas and the other for the empty cylinder and track the latter.

Thanks for the feedback. Sharing is what makes the community dependable and trusted.

There are many report generators available based on PHP/MySQL/TCPDF and you can easily extend the FA reports by writing your own. Proprietary ones are pre-canned and limited to field level logic but you can customise FA reports to suit your needs. The project relies on "experienced FA advanced users" like yourself to extend it's functionality - welcome to the party.

Why not make a mockup graphic design of the reports you like so that some community member may want to and be able program it? If they are just some modifications to existing ones, then mark the add/delete/modify portions in them and link it here. For example, see this thread.

You may refer to this thread for a tutorial on report making in FA.

Thanks for the feedback. This will be the case when large reports are to be generated like when we have too many items.

Generally available since PHP v5.3.9 but Debian implemented it in PHP 5.3.3-7+squeeze7 but may be ignored (YMMV) but works in PHP 5.1.6.

Adding the directive into php.ini or placing following lines into .htaccess will work:

php_value max_input_vars 3000
php_value suhosin.get.max_vars 3000
php_value suhosin.post.max_vars 3000
php_value suhosin.request.max_vars 3000

Please note, you cannot set this directive in run-time with function ini_set(name, newValue).

The best way is to compact all form data using javascript.

On the receiving side you cannot use the PHP parse_str() function because the max_input_vars directive affects this function too, so you need something else like my_parse_str().

Otherwise, the serialize and JSON.stringify may work together.

Use a skeletal FA install.
Take a backup - 1.
Make a Sales Order 1.
Take a backup 2.
Make a Work Order 1 using the Sales Order 1 created above.
Take a backup 3.
Make a Sales Order 2.
Take a backup 4.
Make a Work Order 2 using the Sales Order 2 created now.
Take a backup 5.

You will now ave 4 incremental backup diffs from the above, based on which you should be able to figure out the sqls needed to bulk transform Sales Orders to Work Orders. The problem is to now segregate which Sales Order items are gotten from which Work Orders and their items.

That is why for simplified data entry and understanding, only one Sales Order is mapped into one Work Order for a 1:1 tracking. All other complex means that satisfy individual users are to be made as extensions which may be submitted tot he project so that it will be carried forward into future releases and benefit from user testing and improvement.

The standard Charts of Accounts have redundant indices. A cleaned up set is attached for incorporation into the current Hg repo.

Today's snapshot of FA 2.4 installs correctly but reports will not display correctly unless line 759 of includes/current_user.inc - function company_path() is changed from:

return ($comp_path[0]=='.' ? $path_to_root.'/'.basename($comp_path) : $comp_path);

to

return $path_to_root.'/'.(in_array($comp_path[0], Array('.', '/')) ? $comp_path : basename($comp_path));

(devs have been notified)

In FA 2.3, in config.php:
$comp_path = $path_to_root.'/company';

In FA 2.4, in config.php:
$comp_path = dirname(__FILE__).'/company';
Now relative paths too can be used. If they are outside the webroot, either an apache conf alias or a symlink may be used.
The equivalent of the default for reporting purposes is:
$comp_path = '../company';
and  if it is to be reporting/company:
$comp_path = './company';
and if at the webroot:
$comp_path = '/company';

The use of relative addressing was generally fraught with various path value consequences but now that a wrapper function is used, all should be well.

All upgrades will now have a log file at tmp/upgrade.#.log where # is the company number. (Attached screenshot).
Logs can now be viewed from within FA - themes may need to accommodate it if hardcoded.

A new patch class has been made and the upgrade php files now use it.

Default utf-8 collation of the database changed from general to unicode.

That is why I stated in my previous post that you only make Sales Orders and not Invoices during the month and make the invoice only after all changes have been made to the Sales Orders and that too only at the end of the month!