Google Invoicing

Vector Drawing in a browser

2009-09-05T22:52:00.000-07:00

Inevitably, the apps project is going to have BOMS, or builds, or a product hierarchy.

A hierarchy already exists inasfar as products belong to product groups, which in turn belong to ranges. A build is slightly different because a product does not need to belong only to one group.

The definition of a products 'belonging' then does not come from the product itself, but from its parent. i.e. you create a parent product, and then decide what products belong to it. Some of those products may themselves be builds and so on.

If you haven't come across the concept before, then it is difficult to get your head around without a picture, which is where the subject of this blog comes in.

Browsers are notoriously difficult to get dynamic, vector pictures into. The problem has been addressed with flash, java applets and front end applications. However there is another answer : clever javascript libraries.

Include a small 7k library from http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm, then call the drawing elements of the library from java like this:

function myDrawFunction() {
for (i = 10; i < 259 ; i = i + 100) {
   jg_doc.setColor("#"+genHex());
   jg_doc.drawRect(300-i,300-i,i*2,i*2)
   jg_doc.drawString("Some Text",300-i,300-i);
}
jg_doc.paint(); // draws, in this case, directly into the document
}

var jg_doc = new jsGraphics(); // draw directly into document

It works ! It is cross browser and fast !

PHP and variable scope

2009-05-18T02:03:00.001-07:00

For some historical reason, ostensibly to do with the design philosophy, PHP
can store data in the user session, but can't store data with application
scope.

ASPs can do it, JSPs can do it, but PHP doesn't, and has no plans to any
time in the future.

For this application, it means that every single user is going to have to
grab hold of a copy of the database schema every time they start their
session. When we reach the point of tens of thousands of hits per second, we
are going to need far more power in the database than would otherwise be the
case. As it happens, this particular application is designed such that users
of a particular size are going to be happy to pay for their own, uncontended
database instance, and no single company is ever going to grow to a size
where they would need anything more.

It is the principle which counts, though.

You could simply write stuff to disk, and put up with the performance
overhead, but then you might as well use a federated or replicated MySQL
instance. A better solution is to use Memcached. It is a highly scaleable
cacheing tool with a handy PHP interface called Memcache. Install the
package, start the daemon, and throw objects at it. For private objects, use
a name prepended to the session id. For public objects like the schema, just
use a common name. Although it isn't a straightforward install, we
essentially have application scope objects.

To use the memcache interface, I would need to rewrite some code. The code
is going to first check for object existence in memcache, then read from DB
and put into memcache if it isn't already there. I probably wouldn't
normally use the options, but it is possible to put objects into memcache
with a limited time, and to restrict the memory usage of the daemon.

Not something I need to worry about yet (the apps are lightning-fast), but
good to know there's a solution when I need one.

PHP - Mysql vs Mysqli vs open database conns

2009-05-17T01:12:00.001-07:00

There is an ongoing question over what database the application should use,
and indeed whether it should be database independent.

My view on this is that there is pretty much only MySQL. It is free, fast,
scalable, widely used and easy to find support for. Beyond MySQL, there is
Oracle which isn't free, but is more scalable for certain types of
application. Importantly, if it is being used in a site with expertise in
some other database, MySQL really can be left alone, and it will work away
happily without needing maintenance.

Of course MySQL won't be free forever now that Sun own it, and upgrades are
likely to be sporadic with the best features being a cost option.

MySQL also has two distinct php interfaces. MySQLI, and the older MySQL. The
uptake of MySQLI has been relatively poor even though it has been out for a
few years, possibly because there isn't currently an implementation for a
persistent connection.

As a consequence of all this, there are a few design philosophies:

- All database connections are controlled through a single include.php, the
class needs to be extended in order to be used.
- All SQL outside the class needs to be ANSI-99.
- Accomodating a new database should only need a quick whip through the
parent class. An hour or so's work.
- I am using MySQLI as an interface, although it should be a simple matter
to revert to MySQL, or indeed implement memcache within the parent if
necessary.

...job done, and I am not giong to even bother with the complexities of user
configured database connections. In practise, the configuration of DB
connections gives rise to at least 50% of all installation problems anyway.

Quotation Creation

2009-05-08T23:42:00.001-07:00

I've spent some time going through all of the bugs in the quotation creation program this week and have arrived at the point where I can't find any more to fix!

The program emails PDFs, or prints from emails, allows for the entry of notes against both the line or header, maintains details of GST numbers etc.

I'm now at the stage where I can go in one of two directions. Either :

- I expand functionality to allow for multi-currency, variable GST rates, complex formatting against notes and optional quote layouts etc.
- I expand breadth to encompass invoicing, ordering, stock control, credit control etc.

Every step in additional functionality is also a direction toward complexity, so I'm going to head down the latter of the two options above.
With an architecture painfully assembled around the quotes, adding new form types should be straightforward. We'll see, as I start on sales orders.

Example of PDF attached.

Updated quote interface

2009-04-30T01:24:00.001-07:00

I've spent some time on the quote interface trying to weigh off a very simple interface (such that first time users aren't turned off) against the flexibility of a system which caters for different types of business.

Oracle, for example, has an interface which is far too complex with too many options. Most online invoicing systems aren't going to be viable most of the time because they are just too simple.

The way I have tried to get around this is with context-sensitive tabs. You see the basics by default, but you can click a tab to see more. When you are editing a quote header, there is one set of tabs, and when you are editing the lines, the tabs change.

All best explained in the video below.

Making PDFs using PHP

2009-04-23T20:43:00.001-07:00

Having spent several days using a HTML->PDF conversion program (DOMPDF), I've become disappointed with the original conversion software. Part of the reason was the the code was abstracted beyond belief. Every line of code seemed to make a reference to a class whose name was calculated then dynamically loaded; every function referred to another function in the same class which contained only one line setting a protected object in the class.

The code was also unneccessarily padded out with comments like the one below making a thousand lines into five thousand:

/**
* a record of the current font
*/
public $currentFont = '';

and here's the bit which really upset me:

function DOMPDF_autoload($class) {
$filename = mb_strtolower($class) . ".cls.php";
require_once(DOMPDF_INC_DIR . "/$filename");
}

if ( !function_exists("__autoload") ) {
/**
   * Default __autoload() function
   *
   * @param string $class
   */
function __autoload($class) {
    DOMPDF_autoload($class);
}
}

What the above code does is to hunt through an (abstracted) directory for a file of a particular description whenever a class or function is called which isn't in the already loaded code. Not only that, but the whole thing has been abstracted to a further external function. Try debugging that !

So in summary, I couldn't really tell what was going on. More importantly, the code has some serious security vulnerabilities, didn't convert images accurately, and was unnecessarily slow. In fact, the DOMPDF code represents everything I hate about obsessively written abstracted software.

Predictably, the set of classes didn't actually create PDFS. It was itself an abstraction of a beautiful set of code written right here in New Zealand, which also has a concisely written manual. http://www.ros.co.nz/pdf/readme.pdf. Like all good code, it isn't loosely coupled, everything works the way you expect first time, and you can quickly find out what is going on.

To run it, you load a single file containing a single class, instantiate the class and call the methods laid out in the manual. Like this:

require_once("class.ezpdf.php");
$pdf =& new Cezpdf();

Add an image like this:

$pdf->addJpegFromFile('COLDHOT2.JPG',150,650,100);

Add a table like this:

$dblink = getconn();
$results = "";
$stmt = "select itemid,name from gst";
$result = mysqli_query($dblink,$stmt);
if ($result) {
while($row = mysqli_fetch_array($result,MYSQLI_ASSOC)){
$results[]=$row;
}
}
$data = $results;
mysqli_close($dblink);
$pdf->ezTable($data,'',$title,$opts);

Add a block of text on the page like this:

$opts = array('shaded'=>0);$opts['showHeadings'] = 0;
$opts['yPos'] = 400; $opts['xPos'] = 200;
$opts['fontSize'] = 11; $opts['showLines'] = 0;
$data = array(array('aaa'=>"Is this a\nmulti line problem"));
$pdf->ezTable($data,'',$title,$opts);

File it to disk like this:

$pdfcode = $pdf->ezOutput();
$fp=fopen('findthis.pdf','wb');
fwrite($fp,$pdfcode);
fclose($fp);

Or push it to the browser like this:

$pdf->ezStream();

The big problem is that I now have two output types. Firstly, an html representation of a document, and secondly a PDF representation. It is certainly possible that the two will diverge over time so that what is printed on the user's printer is different from what is PDF'ed up and sent to a trading partner. In my opinion, this is a small price to pay for a much faster, more reliable, safer and better looking result. DOMPDF is now officially scrapped!

Printing

2009-04-22T21:17:00.001-07:00

The previous post brings me on to the general area of printing.

To print a document which has just been created

For example a delivery note. Typically, this can be done via a browser as suggested in the previous post. It isn't possible to override the local user's browser setting, however they can change their own settings so that page headers are not printing, shading and images are printed, and even that they are not prompted for permission to print.

To print a batch, or print on someone else's printer

For example a batch of customer statements, or a batch of customer invoices, 100 sites worth of P&Ls etc. The print run might take a long time to prepare, which would result in a browser timeout. In this context, we are not going to be printing via the user's browser.

Have network access from a central print server to the client's printer. The job can then be run invisibly in the background, and the print can spool when the print is ready. A fairly simple print spooler can be run on a standalone linux/windows machine.
Emailing the user with the results of the print. The user can then open the document, print at their convenience, or depending on the format, cut/paste and analyse the results.
Emailing the user with a link to the results of the print. As above, other than that some central storage would be required, along with some sort of job schedule listing.
Introducing a job scheduler or concurrent process manager, and running the job in the background.

Pretty much all of the above need the ability for jobs to run in the background. This potentially opens up the complex area of job scheduling, including precedents, parallelisation, the ability to classify jobs by user, view and cancel jobs, and user time scheduling limitations, recurring jobs etc.

For the practical purpose of this application, I'm going to avoid batch processing entirely. Everything is going to go via the user's browser or otherwise complete while the user has their browser open, and applications will be written with this in mind. When timeouts eventually occur, clients will be given the option of running the application on a dedicated server, or will be of the size where they can afford some programming expertise to meet their requirements.

Using CSS to differentiate between printable and unprintable elements

2009-04-22T20:59:00.001-07:00

As long as the browser is CSS2.1 compliant (IE7 and Chrome are fine), it is possible to have a web page looking quite differently when printed from the way it appears on screen.

Doing this is fairly simple - each CSS element can be enclosed in a media envelope to determine how the html is interpreted when printed, or on screen.

So for example we have:

@media screen {

.bt {
    background: transparent url('button.gif') scroll top right;
    font: normal 12px arial, sans-serif;
    height: 24px;
    margin-right: 6px;
    text-decoration: none;
    top-border:none;
    bottom-border:none;
}
}

@media print {
.bt {display: none;}
}

In the above, buttons aren't printed, but are shown on screen. The principle is ideal for web pages with drop down menus which are usually meaningless when printed. To convert any existing CSS, simply enclose it in @media screen brackets, then create a new @media print section for each css indicator.

For print-only html pages, the reverse can be done. i.e. the page is not visible to the user unless they print it.

PDF Invoice / Quote

2009-04-21T00:36:00.001-07:00

It took some time to find CSS which rendered properly in cross-browser and pdf scenearios, and I've arrived at the source below.

<html>
<head>
<style>
td.c1 {font-family:Helvetica;font-size:50px;font-weight:bolder;color:#c0c0c0;}
td.c2 {font-family:Helvetica;font-size:13px;}
td.c3 {font-family:Helvetica;font-size:12px;}
td.c4 {font-family:Helvetica;font-size:12px;border-bottom:solid 1px gray; border-left:solid 1px gray; }
td.c5 {font-family:Helvetica;font-size:12px;border-bottom:solid 1px gray; border-right:solid 1px gray; border-left:solid 1px gray}
th.h1 {font-family:Helvetica;font-size:12px;border-bottom:solid 1px gray; border-left:solid 1px gray; border-top:solid 1px gray}
th.h2 {font-family:Helvetica;font-size:12px;border-bottom:solid 1px gray; border-left:solid 1px gray; border-right:solid 1px gray; border-top:solid 1px gray}
table {margin-left:50px;margin-top:10px;margin-right:10px;}
</style>
</head>
<body>
<table width=90%>
<tr><td width=15%>
<img src="coldhot2.jpg" width=100px>
</td>
<td class=c2 valign=top><b>PickMaster</b><br>
37 Isobel Road<br>
Greenhithe<br>
Auckland<br>
0632
</td>
<td valign=top align=right class=c1>
Invoice
</td>
</tr>
</table>

<table width=90%>
<tr>
<td width=50%></td>
<td valign=top align=right class=c3>Invoice Number</td>
<td valign=top class=c3>10302</td>
</tr>
<tr>
<td width=50%></td>
<td valign=top align=right class=c3>Tax Date</td>
<td valign=top class=c3>12 Dec 2009</td>
</tr>
<tr>
<td width=50%></td>
<td valign=top align=right class=c3>Order Number</td>
<td valign=top class=c3>Customer Order Number Goes Here</td>
</tr>
</table>
<br>
<br>
<table width=60%>
<tr>
<td class=c3 width=30%>Customer Addy<br>
Address Line 1<br>
Address Line 2<br>
Address Line 3<br>
Post Code
</td>
<td class=c3 width=30%>Customer Addy<br>
Address Line 1<br>
Address Line 2<br>
Address Line 3<br>
Post Code
</td>
</tr>
</table>
<br>
<br>

<table width=90% style=" border: 0pt none black;" cellspacing=0; >
<tr>
<th valign=top class=h1 align=left width=15%>Code</th>
<th valign=top class=h1 align=left width=60%>Description</th>
<th valign=top class=h1 align=right width=15%>Qty</th>
<th valign=top class=h2 align=right width=10%>Price</th>
</tr>
<tr>
<td valign=top class=c4>ActualCode</td>
<td valign=top class=c4>Full Textual Description Description</td>
<td valign=top class=c4 align=right>14</td>
<td valign=top class=c5 align=right>23.00</td>
</tr>
<tr>
<td valign=top class=c4>ActualCode</td>
<td valign=top class=c4>Full Textual Description Description</td>
<td valign=top class=c4 align=right>14</td>
<td valign=top class=c5 align=right>23.00</td>
</tr>
<tr>
<td></td>
<td></td>
<td align=right valign=top class=c4>Total</td>
<td valign=top class=c5 align=right>23.00</td>
</tr>
<tr>
<td></td>
<td></td>
<td align=right valign=top class=c4>GST</td>
<td valign=top class=c5 align=right>2.30</td>
</tr>
<tr>
<td></td>
<td></td>
<td align=right valign=top class=c4>Total</td>
<td valign=top class=c5 align=right>25.00</td>
</tr>
</table>
</body> </html>

Search Algorithms

2009-04-14T23:40:00.001-07:00

I also went through all of the searching algorithms.

Limits results within master class
Lightning fast on almost any size table
Allows for selection of 'none of the above'
Fixed bug on where multi-page select lists used in conjunction with a change of search criteria
Cached results for further speed enhancements

Rendering in pdf

2009-04-14T23:29:00.001-07:00

First off, I should point out that I *hate* PDFs.

When the format was first launched, I remember a review of it, and the article posed the question "What is the point?" It was inconclusive, and I have still not worked out what the point of a PDF is. Does it stop the receiver from editing the document? - No. Is it easier to transmit ? - No. Is it easier to write software for ? - Definitely No. Is it in some way more secure? - No. Is it easier to read ? - No, more difficult. Is it more portable than HTML? - No.

Notwithstanding, people expect to be able to transmit documents as PDFs. Adobe have done a wonderful marketing job, and it isn't my place to unilaterally open everyones' eyes to the pointlessness of their proprietary document format.

The solution? The applications produce html (probably from within the database), then have the facility to convert it to pdf at application level. The user can then transmit the PDF as an email attachment or file it somewhere as they see fit. Production of XML, direct import into google apps and other machine-readable formats will follow later.

To perform the translation, I am using dompdf v 0.5.1. This is a free, downloadable set of classes specifically for converting html to pdf, it is all done natively in php and requires no further downloads. It has limited font support (suggest stick with Helvetica), but understands CSS, tables and graphics, and even some support for inline scripting.

Here's an example bit of conversion code:

<?php
require_once("dompdf_config.inc.php");
$dompdf = new DOMPDF();
$dompdf->load_html_file("test.htm");
$dompdf->render();
$dompdf->stream("sample".time().".pdf");
?>

And it seems pretty happy to convert something like this:

<html>
<head>
<style>
td {font-family:Helvetica;font-size:10px;background-color:#ffffff;border-style:solid;border:thin solid #c0c0c0}
th {font-family:Helvetica;font-size:30px;background-color:#e0e0e0;border:thin solid #c0c0c0}
table {border:none;border-spacing:0;border-collapse:collapse;}
h1 {font-family:Helvetica;font-size:20px}
</style>
</head>
<h1>A Heading</h1>
<table width="100%">
<tr>
    <tH>a</tH>
    <tH>b</tH>
    <tH>c</tH>
</tr>
<tr>
    <td>d</td>
    <td>e</td>
    <td>f</td>
</tr>
</table>
<img src=".\coldhot.jpg">
</html>

Here's some more documentation.

http://digg.com/d11Kqn

Sales Order Interface

2009-04-13T00:36:00.001-07:00

The sales order input program is probably the most important one for a number of reasons:

Strategically, it is close to the customer. In a telereactive sales environment, it gives the customer an impression of the business.
It should be the thing you do most often in your business - invoicing, quoting and raising orders.

The quote program is mostly written in principle. Further enhancements:

Ability to enter 'Manual' lines, i.e. not affecting stock, and not in the product file.
Ability to enter 'Special' lines, i.e. a physical product, so purchase order needed.
A 'type' grid for quotes, invoices, credits, collections, orders, directs, credits (no stock), cash type sales. Conditional conversion between types.
Calculation of customer selling prices, incorporating discount grid.
Packs and kits.
Credit control / order hold.
Printing / transmission.

Consequently, and with the above goals, it is the quotes (and order processing) routines I am concentrating on this week.

Disabling form resubmission

2009-04-09T17:13:00.001-07:00

When the user of a web site clicks on the submit button, the page is wrapped up and sent to the web server for processing. Depending on the speed of the connection and the web server, the user may click submit twice.

When this happens, the web server will receive exactly the same page twice, and will need to decide what to do. Depending on the complexity of the server-side application, you may need to cater for many different situations in a complex application.

It is much simpler to reduce the number of duplicated submissions (many users still think double-clicking is the right thing to do!), and to generate a general error. So how do you prevent form resubmission?

Answer : like this:

<%@ page contentType="text/html;charset=windows-1252"%>

Disabling form resubmission

<HTML>

<HEAD>

<SCRIPT language="JavaScript">

function submitform()

{

document.myform.getme.disabled = true ;

}

</SCRIPT>

</head>

<form name="myform" onsubmit = "return false">

Search: <input type='text' name='query'>

<input name=getme type=submit value=test onclick="submitform()">

</form>

</html>

Google Apps

2009-04-09T16:18:00.000-07:00

Every small business has the same problem.

If you are a builder, a taxi driver, an electrician, an IT contractor, a masseur, cleaner or whatever, people want quotes and they want invoices. You need to keep records for tax and GST, and you need to keep details of who owes you money.

So what do you do?

Go out and buy MYOB or Sage / some other small accounting package, or you try to keep paper records using MS Word/Excel.

Both options are full of problems:

If you set up a small accounting package, you need to spend some cash.
You spend ages setting the software up and it's complex. You then need to keep installing updates.
When your hard disk fails, you lose your records. Either that, or you need to be good at backup and restore.
You need to be at your computer to create the quotes, or you write them out by hand while on site, and then need to rekey them as invoices later on, hoping you don't make any mistakes.
If you use Word, you keep saving your invoices and deleting the old copies. You also can't keep track of who owes you money.
Importantly, the setup won't grow with your business. As soon as you have more employees, need to open another site, employ an accountant or expand, you need to change software. Then before you know it you need to employ someone to look after the application.

So what's the solution ?

Googapps online invoicing. You don't need to worry about backup, keeping up to date with the latest GST legislation, updating software or expansion. Furthermore, because the software is online, you can create quotes and invoices from any computer with a browser and internet connectivity - even your phone.

On site with your customer and want to see how much they owe? Use your phone to access their account, then email them the details. Better still, if they are a googapps user too, they can import the invoices directly into their own googapps account.

Computer hard drive crashes? Get a new computer, borrow someone else's or use your phone. It won't affect your business.

Google Invoicing

Vector Drawing in a browser

PHP and variable scope

PHP - Mysql vs Mysqli vs open database conns

Quotation Creation

Updated quote interface

Making PDFs using PHP

Printing

Using CSS to differentiate between printable and unprintable elements

PDF Invoice / Quote

Search Algorithms

Rendering in pdf

Sales Order Interface

Disabling form resubmission

<%@ page contentType="text/html;charset=windows-1252"%>

Disabling form resubmission

<HTML>

<HEAD>

<SCRIPT language="JavaScript">

function submitform()

{

document.myform.getme.disabled = true ;

}

</SCRIPT>

</head>

<form name="myform" onsubmit = "return false">

Search: <input type='text' name='query'>

<input name=getme type=submit value=test onclick="submitform()">

</form&gt;

Google Apps

</form>