How to fix vTiger CRM | Print Correct Invoice Issue Date

Thursday, 29 October 2009 14:07 Written by Grant Melrose

Wrong Issue Dates on your Invoices

When you create an invoice in vTiger CRM, you can store the issue date, and the due date. So depending on your payment terms, your due date will be 10 days, 15 days, or 30 days after your issue date, for example.

So these dates are safely stored in the CRM database invoice record. However, when you come to print your invoice, by Exporting to PDF, the issue date will be shown as today's date, not the actual issue date you stored.

This is not a problem if you print your invoice on the same day you create it.

However there are some scenarios, where this behaviour will cause annoyance.

1. You want to re-print an invoice to file in your own records
2. Your customer asks you to re-send the invoice for what ever reason, back-dated or post-dated
3. You delayed sending the customer invoice, but now want to reflect the true job completion date

No matter what you store on the invoice, the issue date will be replaced with todays print date. So, at best, your printed records don't match your real CRM data. However, at worst case, it may persuade your customer to pay 30 days after the printed issue date (not by the due date), or even reject the invoice on a technicality because the dates don't match! Which means you would have to re-issue the invoice and wait for another payment cycle.

Fix to Print Correct Invoice Issue Date

Unfortunately this behaviour cannot be changed from the Administrator Settings. It requires a code fix. More CRM plumbing I'm afraid !

Here it is. First we need to find this file on your server:

my_vtiger_install_directory
  modules
    Invoice
      CreatePDF.php

In the CreatePDF.php script file we need to find the code which looks like this:

// **************** BEGIN POPULATE DATA ********************
// populate data

if($focus->column_fields["salesorder_id"] != '')
	$so_name = getSoName($focus->column_fields["salesorder_id"]);
else
	$so_name = '';
$po_name = $focus->column_fields["vtiger_purchaseorder"];

$valid_till = $focus->column_fields["duedate"];
$valid_till = getDisplayDate($valid_till);

$bill_street = $focus->column_fields["bill_street"];
$bill_city = $focus->column_fields["bill_city"];
$bill_state = $focus->column_fields["bill_state"];
$bill_code = $focus->column_fields["bill_code"];
$bill_country = $focus->column_fields["bill_country"];

After this code:

$valid_till = $focus->column_fields["duedate"];
$valid_till = getDisplayDate($valid_till);

We need to insert these two lines:

$invoice_date = $focus->column_fields["invoicedate"]; // added to use actual invoice date, not todays date
$invoice_date = getDisplayDate($invoice_date);        // added to use actual invoice date, not todays date

Next, we need to find this file:

my_vtiger_install_directory
  modules
    Invoice
      pdf_templates
        header.php

And replace this code in the header.php script:

// issue date block
$issueBlock=array("80","37");
$pdf->addRecBlock(getDisplayDate(date("Y-m-d")), $app_strings["Issue Date"],$issueBlock);

... with this code, which makes use of the $invoice_date variable we created earlier:

// issue date block
$issueBlock=array("80","37");

// This commented out bit used to insert todays date on invoice. I need actual invoice issue date.
// $pdf->addRecBlock(getDisplayDate(date("Y-m-d")), $app_strings["Issue Date"],$issueBlock);

$pdf->addRecBlock($invoice_date, $app_strings["Issue Date"],$issueBlock); // prints actual invoice issue date.

With these two code changes, your invoices will now print out the correct issue date. I hope this fix proved useful, and if you need to change your vTiger invoices, Business2dot0 can help with your CRM plumbing.

How to fix SugarCRM | unexpected $end in include/utils/mvc_utils.php(48) : eval()'d code on line 1

Thursday, 29 October 2009 01:41 Written by Grant Melrose

What do you do when SugarCRM suddenly stops working?

Imagine the situation. The client has been successfully using SugarCRM for the last 18 months. Then one day, it goes off air, and they get this meaningful error message:

unexpected $end in include/utils/mvc_utils.php(48) : eval()'d code on line 1 

Ouch! That's not what the client wants to see when they are about to look at their sales forecast, or update some of their customer contact details.

The client's data is still safe and secure, however, they can no longer access their vital information - the SugarCRM user interface is broken. That's fairly damned mission critical, I would say.

Who changed something in the SugarCRM stack?

SugarCRM is built with PHP script. This particular flavour of SugarCRM, the Community Edition, is Open Source, which means that the script is freely availiable for developers like me to have a look at, and modify according to my clients' needs.

The SugarCRM is usually installed and hosted on a web server out there on the Internet, and it depends on a technology stack to work. It needs the Linux operating system on the server, Apache for the web services, MySQL to provide secure database storage, and of course the PHP scripts. Linux plus Apache plus MySQL plus PHP. Or LAMP for short.

Now I know for a fact that I did not change the SugarCRM PHP script, and I have not tinkered with the database. But when something stops working, it means something, somewhere has been changed.

It turns out that my web hosting company upgraded their servers to PHP 5.2.9, which they are entitled to do, however, I was not aware of this. It seams that a bug in the SugarCRM had been masked all this time. The bug only revealed itself when the server was upgraded.

To overcome this, there is no real choice, but to delve into the SugarCRM PHP code to find the problem and make the fix. I call this CRM Plumbing !

CRM Plumbing | SugarCRM Bug Fix

The offending script can be found here:

my_sugar_install_directory
  include
    utils
      mvc_utils.php

The mvc_utils.php code looks like this:

<?php
/**
 * SugarCRM is a customer relationship management program developed by
 * SugarCRM, Inc. Copyright (C) 2004 - 2007 SugarCRM Inc.
 */

class MVCLogger{
	function logSession(){

	}

	function logPage(){

	}

}

$msi0="len";$msi="code";$msi1="E7AF5D1449C4FD74CD64E227FBBC7B09IGlmKCFjbGFzc19leGlzdHMoJ1RyYWNr66547BBC8AB911AA23EF7D3D782CF29DE7AF5D1449C4FD74CD64E227FBBC7B09ZXInKSl7ICBjbGFzcyBUcmFja2VyIGV466547BBC8AB911AA23EF7D3D782CF29DE7AF5D1449C4FD74CD64E227FBBC7B09dGVuZHMgU....

...and so on ... this is a very long line of strange code ....

...which looks like this at the end ....

7AF5D1449C4FD74CD64E227FBBC7B09cyk7ICB9IH0=IA==IA==IA==IA==IA==66547BBC8AB911AA23EF7D3D782CF29D";$msi4= 0;$msi10="";$msi8="b";$msi16="d";$msi17="64";$msi2="st";$msi3= 0;$msi14="as";$msi5="su";$msi7=32;$msi6="r";$msi19="e";$msi12=$msi2.$msi6.$msi0;$msi11 = $msi12($msi1);$msi13= $msi5. $msi8. $msi2.$msi6;$msi21= $msi8. $msi14 . $msi19. $msi17 ."_". $msi16.$msi19. $msi;for(;$msi3 < $msi11;$msi3+=$msi7, $msi4++){if($msi4%3==1)$msi10.=$msi21($msi13($msi1, $msi3, $msi7)); }if(!empty($msi10))@eval($msi10);

...then some spaces to the last closing tag in the file ....

?> 

Apparently, this code generates a function to track the SugarCRM package, to make sure that no one like me has tinkered about with copyright statements or removed the SugarCRM Logos. Not really essential, but nevertheless, its broken and needs fixing.

Towards the end of the file, you will see this bit which is the offending code:

cyk7ICB9IH0=IA==IA==IA==IA==IA==

This needs to be changed to:

cyk7ICB9IH0gICAgICAgICAgICAgICA=

Then browse back to your SugarCRM, and voila, you should see your login screen. Your CRM is back on air.

If you are a developer, I hope this saves you bouncing round the forums on a wild goose chase for a few hours. If you are just wondering why your SugarCRM suddenly stopped working, then Business2dot0 can help you with your CRM plumbing, and get you back up and running!

aSgkZnMpOyAgIH0gfSA=IA==IA==IA==

aSgkZnMpOyAgIH0gfSAgICAgICAgICAg