Showing posts with label paperless. Show all posts
Showing posts with label paperless. Show all posts

Sunday, 16 January 2011

Running a paperless office (update)

A friend raised question a question with regard to keeping digital taxation records. Are you sure you can do that? Well, a quick search on our Government's ATO website revealed a positive answer:
Electronic records
Documents that you are required to keep can be in written or electronic form. If you make paper or electronic copies they must be a true and clear reproduction of the original.
We recommend that if you store your records electronically you make a back-up copy to ensure the evidence is easily accessible if the original becomes inaccessible or unreadable (for example, where a hard drive is corrupted).
Source: Australian Government, Australian Taxation Office, Keeping your tax records, Electronic records

Tuesday, 4 January 2011

Edit a PDF using flpsed

I've been looking for a simple tool to annotate PDF files.   Since going paperless, I've often wanted to annotate scanned images with additional information.  Well, I finally found a tool that is light weight and simple to use.  It is flpsed.  Some advice on its use:
  1. When using "Save As", ensure this is saved with file extension ".ps" so not to get confused.  
  2. "Export" the finished annotated document as a PDF.
To Do: How to use an external tags file?  I assume this is a PostScript file containing key/value pairs.

Saturday, 9 October 2010

[Update] A Simple Reminder System

This is an update to my last post A Simple Reminder System
Scanning the technical news I recently came across: gcalcli. Can this be used with my reminder system? Well, yes it can! Very simply in fact. It took a short Bourne shell script which reads calendar entries forward from today, then post them to Google Calendars. This is the script:
#!/bin/sh
# Update Google calendar with local calendar.
#
# $Id: syncgcal.sh 706 2010-10-09 05:28:44Z frank $
echo -n 'Reading calendar events ...'
forwardDate=`/bin/date --date="+7 days" "+%Y%m%d"`
/usr/bin/calendar -t $forwardDate | while read entry
do
   /usr/bin/gcalcli quick "$entry"
done
echo ' done!'
exit 0
The trick used here is to check upcoming events for a fixed number of days forward.  If you use calendar -A then you'll get events repeated. This is a compromise: checking only a fixed number of days forward and posting items for that date only. What would be better, would be to identify changed entries and just posting them. To do this you need to have a additional data store of posted events and lots more code. Maybe next time. I will trial the current set-up and see how it goes.

The gcalcli command uses a Python style configuration file of ~/.gcalcli. This is where you can record user, password and calendar defaults for your Google calendar. Not surprising as gcacli is written in Python.
Finally, add a cron table entry:
@daily ~/bin/syncgcal | /usr/bin/mail -e -s "Google calendar updates" your_user@localhost
This will daily invoke calendar updates. The results are locally emailed back to you, which is useful for testing.

Saturday, 2 October 2010

A Simple Reminder System

This is a continuation of my post on running a paperless office.
Ever faced with the problem of constantly forgetting important events, missing bill payments or forgetting anniversaries? Don't want to publish billing information onto an online calendar? This  simple email reminder system seemed the most versatile. This is how it works:
The solution centres upon the calendar(1) command from the bsdmainutils package. It takes a simple formatted text file as input, and displays events within a user specified number of days forward from today. The format is really easy maintain a list of birthdays, or of bills requiring payment. Create a file called ~/.calendar/calendar. The file will contain entries like:
#ifndef _calendar_frank_
#define _calendar_frank_
LANG=en_AU
#include <calendar.australia><calendar.australia>
#include <calendar.birthday><calendar.birthday>
#include <calendar.reminder><calendar.reminder>
#endif
And this is what a the calendar.australia file looks like:
/* Australian holidays $FreeBSD$ */
#ifndef _calendar_australia_
#define _calendar_australia_
LANG=UTF-8
/* Australia */
Jan 26 Australia Day Holiday (Australia, except NSW, Vic)
Mar/SunLast Daylight Savings Time ends in ACT, NSW, SA, TAS and VIC.
Apr 25 Anzac Day (Australian and New Zealand Army Corps) Day (Australia)
Jun/MonSecond Queen's Birthday Holiday (Australia, except WA)
Oct/SunLast Daylight Savings Time starts in ACT, NSW, SA and VIC.
/* Victoria */
3/MonSecond Labour Day (Vic)
Nov/TueFirst Melbourne Cup (Vic)
#endif
In the same fashion, the calendar.reminder is formatted with a month, day and finally a description. The descriptions follow a standard pattern so that you can quickly identify billing information. It also means that the reported entries are standardised.  My suggested formatting is:
Mon dd Bill Title: bill code, Reference: 9999, Amount: $000.00, Receipt:
When the bill is paid, append the receipt id, then comment out the line.  Commenting it out prevents you being reminded for a bill you've already paid:
/* Feb 23 Telephone: TLS123, Reference: 456, Amount: $11.30, Receipt: 7890123 */
So a single reminder file contains current and historic information. Which is useful if you wish to see how bills change over time. 
Finally, to activate an automatic reminder via email, add the following entries to crontab(5). The following will give me warning of events 7 days in advance:
@reboot /usr/bin/calendar -A 7 | mail -e -s "Reminders from Calendar" name@localhost
@daily /usr/bin/calendar -A 7 | mail -e -s "Reminders from Calendar" name@localhost
That is all there is too it!  Enjoy!  Please let me know if you have any suggestions or corrections.

Saturday, 25 September 2010

Edit a PDF using the Gimp

This is a continuation of my post on running a paperless office.
Only some PDF documents lend themselves to being edited using OpenOffice. Those that can be will be discussed in a later blog. Here we are going to describe how to use the Gimp to edit a PDF document.
On occasion PDF forms received that need to filled out. The typical way to enter these forms is to print them, add the requested information, then finally, scan or facsimile the document back. What I will describe here is a way to update a form electronically so you can then email or fax directly the completed document.
The methods described below were developed over time as part of my initiative to run an paperless office.
Suppose you have a multi-page PDF document to be updated. Each page will be separately edited and the final result stitched together. There are two reasons for this: Firstly this reduces the risk of losing the entire document on a mistake. So, you'll be able to recover up to last completed page. And secondly, The Gimp is memory hungry, so opening a page at a time means a more response machine.
Use The Gimp to open the first page as a layer:
Open as Layers... (CTL+ALT+O)
Increase the Resolution from the default of 100 pixels/inch to at least 300. For best results choose a resolution 100 pixels per inch above your printers default.
Select the first page to edit.
Create a new transparent layer:
New Layer. (Shift+CTL+N)
Use Layer Fill Type with default Transparency. 
Identify the first entry to update, name the layer to reflect this entry. A transparent layer will be added for each new form field. This will allow you to individually place and edit form data.
Select the Text Tool (T). Using the Tool Options dialogue, set the desired font and colour. The font size will need to be adjusted to fit the form text size. Choose a colour so that your form entries standout. On a black form navy blue works well. It has a HTML colour code of 000080. Add the required text. Place the text correctly. Use the Move Tool (M) to reposition the text if needed. Finally Merge Down the text box into the associated named layer:
Layer ► Merge Down
Hint: Ensure the named layer is on the top of the layers stack.
Repeat this process for each form field.
Once the page is complete print the page as a PDF. Include a page number in the name to assist merging of multi-page documents.
Load the next page, and repeat.
At the end of all this you will have a multiple documents representing a single form. So the next step is to stitch them together. For this use Ghostscript. This gives you the power to combine files, convert files, and much more, all from the command line. To combine several input files into one combined PDF using Ghostscript:
gs -sDEVICE=pdfwrite -dSAFER -o combined.pdf first.pdf second.pdf third.pdf […]

Monday, 13 September 2010

Running a paperless office

Sometime ago I made up my mind to try running a paperless office. While there maybe many environmental justifications for doing so, my reasons were far more practical: laziness. A modern life collects an awful lot of related documentation. Documentation that needs to be saved for a few years, forgotten, then found again during those rare Spring cleans, and finally shredded. There certainly is a need to record information, I just couldn’t see the point of maintaining it in paper form. First, there is the storage required. Then what do you keep? And how long do you keep it for? Computer storage is cheap, very cheap. So that is when I decided to fire-up the scanner. Taking action straight away reveals problems early: OK, now I’ve scanned a document, what do I name it? Where should I file it? How long should I keep it for? Much the same issues that you have with paper. It is just easier. Over the past two years I worked out a system that works, for me ...
What is recorded?
For the most part it is amazing how little ends up needing to be scanned and recorded digitally once you make the decision to go paperless. Many business now offer that information be delivered by email or as a PDF or spreadsheet download. Many others provide information on their websites that can be forwarded in a variety of formats. What is left can be scanned. This has a number of benefits. For Australian taxation purposes, proof of purchase must be retained for a set number of years. But the paper receipts provided by many retailers fade after just a couple of weeks. Scanning ensures that information is legible for as long as your computer screen remains lit. In the early days I was concerned about such things as quality of image resolution, colour or black and white, as PDF, PostScript or as an image? This is now much simpler by focusing on the only important question: is the scanned image legible? Generally PDF’s are chosen so that multi-page documents can be recorded and stitched together by subject, such as proof of purchases for insurance purposes or annual tax receipts. It is amazing how much documentation has accumulated in relation to taxation! Going paperless has meant more can be recorded, not less. Look out for annual reports or summary statements, as more businesses now provide this information online. While they may be doing this to reduce their costs, it is to our advantage as it reduces the need to scan and improves there usefulness to searching of archives. 
How is it organised?
I maintain a bills directory with an archive sub-directory. Any current bills and associated receipts are recorded in the bills directory. When a new bill arrives, both old documents get archived and the new bill is recorded in a calendar reminder system. This works well in conjunction with daily and monthly backups. The archive directory is useful for looking at last months data, and backups retain the rest.
How long should I keep it?
Current and previous months are retained locally in the directories bills and bills/archive. This covers most queries. The accounting system is really the first point of reference. Archives are really there if proof of payment is required. The monthly backups are on a 12 month cycled, and Taxation records are record to archive CD as an accumlative data archive. So little data storage is consumed by this that for the last four years I’ve been practising this fits snuggly onto a CD without compression. So, the move to a DVD archive will be a while away. I prefer not compressing the files, just as it makes retrieval and receovery from data corruption easier.