Search options (Page 179 of 247)

Wikied "Watermarking and background / logo merging in reports". It now stands documented!

@joe: Thanks for the OpenWriter file. Will be useful in documenting this feature.

English translation of Swedish "laboration": Laboratory / Experimental Work.

Anyone used the Header.php / Header2.php in the reporting/forms folder in the company/#/ folder?

@joe: Thanks for the doPDF tip. PDFCreator too generates small PDF files and is free but may try to install some nagware (optional) in the later versions.

@joe: Thanks. Very nice alternative real solution. Attached Screenshot.

You might also want to refer the php.ini max_input_vars setting to increasing it from the default of 1000 to 3000 or beyond as instructed in this thread.

Comment out lines 145 and 146 of reporting/includes/header2.inc (or place a copy of the file in the appropriate path in the company reporting folder):

        if ($this->pageNumber > 1)
            $this->Text($this->endLine - 35, _("Page") . ' ' . $this->pageNumber);

@joe: either a report form variable to suppress page numbers or a config variable/sys_prefs variable to be a flag for it would be nice - atleast going forward in FA v2.4.

"scale of vendor FA?"
Do you mean - how many Vendors can FA handle?

"Market share of online accounting that FA has?"
Your guess is as good as mine. Maybe 0.0001% to 1% of all online accounting usage!
The ocean covers 2/3rds of the earth - where would you like to swim?

@joe: I stand corrected that the Tmpl inclusion is needed for other reasons. The $rep->SetHeaderType('Header2') "includes" the header2.inc and doctext.inc files. These included files refer to data obtained in SetCommonData() which is useful for including non field db data as illustrated in the wiki for Bin Location type of functionality.

In this instance in rep107.php (Invoicing), $contacts is populated with data from the get_branch_contacts() function and is passed on as an argument into the $rep->SetCommonData() method which in turn populates the $this->formData and $this->contactData properties which in turn is used to get the contacts to email the reports to. In fact the SetCommonData() method makes even a single email id into an array, ie., $this->contactData.

Will investigate further....

@bobloblian: Let's see what line 978 onwards in reporting/includes/pdf_report.inc has:

                $contactData = array();
                if ($this->contactData)
                    foreach($this->contactData as $contact)
                        if (!empty($contact['email']))
                            $contactData[] = $contact;

                if(!count($contactData)) {
                    $this->SetLang(user_language());
                    display_warning(sprintf(_("You have no email contact defined for this type of document for '%s'."), $this->formData['recipient_name']));
                } else {
                    $sent = $try = 0;

Only if there was no email available would you get the error stated

Therefore in the incoming $this->contactData itself, there would be no such record with email contact details and that narrows it down to the output of the get_branch_contacts() function. A check on with and without the last parameter being false will reveal that when it is true, the defaults have kicked in and not the appropriate contact for the specified action type. Try adding more than one contact to the branch where you choose it to be of invoice type (rep107.php) and then see what happens on making the last parameter false.

Please note that you will need tobackportsome report fixes from FA 2.4 since the SetCommonData() method needs to precede the Header2() call in reports that call it. This is necessary because the property $this->contactData is assigned from the $contact in line 409 and the latter comes from the said method SetCommonData() which in turn gets it from the get_branch_contacts() function call in rep107.php a couple of lines earlier.

@joe: the backports of the repXXX.php files done on 2015-01-21 is hence necessary.

Whilst getting all contacts and using it for emailing (To, Cc, Bcc, etc) is fine, getting only one contact is important for report printing and for use in the FA user interface screens.

Currently, the function get_branch_contacts is used in:

sales/includes/ui/sales_order_ui.inc
repXXX.php
where XXX in 103 (commented out), 107 (Invoice), 108 (commented out), 109  through to 113.

In the extensions, rep_email_customers calls it in modules/reporting/rep_email_customers/includes/customer_emailer.inc with the last parameter as false (no defaults). Also, when the second parameter ($action) is set to null as in this file, all contacts accrue.

In sales/includes/ui/sales_order_ui.inc the following construct in lines 112-114:

    $contact = get_branch_contacts($branch_id, 'order', $customer_id);
    $order->set_branch($branch_id, $myrow["tax_group_id"],
    $myrow["tax_group_name"], @$contact["phone"], @$contact["email"]);

expect to have defaults (missing last parameter assumed $default as true) and restricted to the 'orders' type alone and is used as a single contact for populating the branch details alone.

The standard repXXX.php listed above use the following constructs:

rep107.php:
$contacts = get_branch_contacts($branch['branch_code'], 'invoice', $branch['debtor_no'], true);

rep109.php:
$contacts = get_branch_contacts($branch['branch_code'], 'order', $branch['debtor_no'], true);

rep110.php:
$contacts = get_branch_contacts($branch['branch_code'], 'delivery', $branch['debtor_no'], true);

rep111.php:
$contacts = get_branch_contacts($branch['branch_code'], 'order', $branch['debtor_no'], true);

rep112.php:
$contacts = get_branch_contacts($myrow['branch_code'], 'invoice', $myrow['debtor_no']);

rep113.php:
$contacts = get_branch_contacts($branch['branch_code'], 'invoice', $branch['debtor_no'], true);

which makes last parameter $default to be true but allows for (but currently does not obtain) multiple contacts in subsequent emailing usage alone.

Either we determine it to be a single contact (count elements in array), or choose only the first one for the sales/includes/ui/sales_order_ui.inc and all other places we need single contacts or make a new function called get_branch_contact (singular) with the current code in it and make new content for the existing function get_branch_contacts (plural) for usage where multiple contacts are needed.

As far as emailing is concerned, we can make the first contact as the "To" recipient and all others as the "Cc" recipients if they exist!

Way forward is to be decided - all your thoughts on this is welcome before a patch is forwarded to @joe.

Hence currently, no code change is required except for setting the last parameter as false in reports that need to be emailed to multiple entities!