SAFE/X: Invoicing Come Undone!
It's only taken fifteen years! But we've finally made invoicing 'undoable'.

When you invoice customers, either one or in a 'batch' you are now given the option to undo the printing. As you expect, this simply returns the invoices to their previous state.

There is really only one purpose to this--to prevent an 'Oh %$#&#!' moment, when you realise you accidentally clicked 'Print Invoice' when you meant to click 'Print Packing Slips'. An invoice run may only be undone immediately after printing and you only get one shot at it. You cannot go back the next day and say, 'Oh silly me, I'll just undo those invoices!'.

Some Rules
When an invoice is undone it's posting is reversed in the G/L. This is one way to audit that this 'undoing' has occurred (and also who did it.)

When an invoice run is undone a single Translog entry is created documenting exactly which sales order/invoices were undone.

If someone else has generated other invoice(s) while you were generating your batch, you will be prevented from undoing your batch. As an example, let's say you accidentally generated Invoices #1001 to 1099. At the same time, Brenda also hit 'Print Invoice' and generated Invoice #1100. You will not be able to undo your batch because that would leave gaps in the numbering sequence. In other words, you cannot use earlier invoice numbers.

There is also a time-out function. The Confirm Run Window will time-out if you do not answer within a reasonable amount of time (the default is 6 minutes.) If that happens, it's as if you said 'OK!' In other words, doing nothing is the same thing as saying, 'The print run is confirmed.' That way, you can walk away after printing without having to go back and click.

Interestingly, you have a couple of options regarding this time-out
1. You can set the length of the time-out. For example, if you routinely generate many invoices, 1 minute may not be enough. So you can bump that up to six minutes.

Important Note: We're sure there will be a temptation to do the following: Jack this value up to something like an hour so that you can audit all invoices for any mistake and thus avoid the whole 'Clone/Void/Re-Bill' cycle. But unless you are the only person using SAFE in your office, we do not recommend this! The whole point of this feature is to avoid having to redo a ton of work if the printer jams. The price of this feature is that while that little Confirm Print Run Window is open, all other users are on hold. Under the hood, SAFE is guarding the entire Sales Order system to prevent anything interfering with the invoicing process. Until, you answer with either 'OK' or 'Undo', everyone is waiting on you. So the question becomes: How long do you want to keep all order processing waiting?

2. You can also change what happens if the window times out. As we said, the default is 'Confirmed', but you can also change this so that if the window times-out, that means the run is Undone. (We try to please everyone.)

In Summary
Invoice Undo Run is a valuable addition to SAFE, but it's not a panacea. It can save a lot of work in the case of a paper jam, but it is not meant to replace the traditional Clone/Void/Re-Print cycle which is still recommended for correcting invoices which had incorrect data upon generation. Used with caution, however, it will likely prevent a few major headaches for all our customers when the printer misbehaves.

Til Next Time!


Remember: The New Incentive Program
As part of our Annual Customer Appreciation Discount, I am willing to pay you to report bugs. That's right. I'm going to pay people cash, greenbacks, shekels, lettuce, Jacksons. And not 'companies', I mean people.

I'll pay anyone five bucks to report a site specific bug---something that isn't working properly at your site that should at least be caught by SAFE (no error message, for example). I'll double that and pay $10 to anyone who reports a verifiable program bug (something that would affect all SAFE users everywhere.) And for those? I don't even care if you're the first or the fiftieth person to report the same damned bug; if it's verifiable---you get paid, until we issue an update or patch. (If you report the bug after we issue a fix, you get bupkus.)

Why?
Three reasons:

1. Good PR. We want you to understand how much we want to get this stuff straightened out. Contrary to various conspiracy theories, we want to get every problem resolved. Fast. I know that many of you have never heard of a software company admitting that a product has bugs, but let's face it: they all do. No large program is perfect. From what I can see, we're better than anyone else in our industry and we see no harm in being straight up about flaws.

You see, we view SAFE more as an office building, and ourselves as real-estate developers. You guys are our tenants. Ever been in a building that was perfect or that didn't require periodic maintenance? Me either. They're just too complicated. So we try to be responsive landlords. And showing a willingness to fix a leaky faucet is just part of being good landlords.

2. More moolah. It doesn't make sense to leave problems uncorrected. It costs everyone money. The faster we get problems resolved, the more attention we can pay to creating products for which we can charge $$$.

3. There really is very little cost for us. There simply aren't that many legitimate bugs in SAFE; certainly not enough where these payouts would impact the bottom line. If we make even one customer feel like we care that didn't---hey it's the best ad money we could ever spend.

Procedure?
Just do what you've been doing (Next time I'll have another rant on how to most effectively communicate problems.) But for now, the main thing is to tell us who you are so you can get the dough and not Francine over in Accounts Payable or Ed the Owner/Sales Manager who already has enough money to go to Barbados every year. Forget Ed! Think of yourself!

In May, when we announce our Annual Discount for year twenty one, we'll send everyone who contributed a list of their reported bugs and, more importantly, a check.

But Wait There's More?
The person with the highest overall score will receive a fabulous Grand Prize which is so fabulous I haven't figured out what it is yet. But I've got five months to think it over and let me assure you right now that it will definitely be better than a set of steak knives! (OK, I'm not the most creative guy in the world, fine.) If you have suggestions on the Grand Prize, please do send them along.

Til Next Time!
 

Ollie Tip: Keeping On Line Transactions Fresh!
A common group of questions we get asked is how to manage on line orders. There is always the concern that orders are being noticed (and acted upon) when they are placed. And there is also the need to monitor orders which are in danger of 'going stale', ie. placed but not approved. Sure it's easy to say, 'Hey, the customer didn't approve it so it's not my problem.' But as we all know, regardless of who's responsibility it should be, the fact remains that your customer does consider it your responsibility to make sure all orders are processed promptly.

OK, so what do you need to look for in SAFE and Ollie to root out orders in danger of going stale?

First there is the Entry Date and Time. These are time-stamped when the user first creates the order. You can see the Entry Date on screen in the Sales Order Browse. Note that we said creates and not submits. This is a very important distinction. Read on.

Secondly, there is a Last Revised Date and Time. This is updated every time the order is edited in any way, by either an Ollie user or a SAFE operator (Ed. Note: As per usual, to avoid confusion, we refer to on-line users as 'users' and 'operators' as SAFE... er... 'users'.) The first time this field is updated is when the user submits the order.

Thirdly, there is an Order Status column, also visible in the SAFE Sales Order Browse.

With these two dates and the status column, we already have pretty much everything we need to manage."
1. If there is an Entry Date but no Last Revised Date, then the order hasn't been submitted. If the Entry Date is older than, say 24 hours, it means that the user left Ollie in the midst of their session. These orders need prompt attention because, as we discussed in our last issue Ollie automatically purges unsubmitted orders after a certain period of time (and the default is 3 days!)

2. If the order was submitted, but not approved and you can see that the Last Revised Date is the same as the Entry Date, then perhaps a call or e-mail to the user or approver is in order? (eg. the order was entered and submitted two days ago but has not been touched since.)

Oh, If Only There Was A Way to Automate All This!
First off, in SAFE, you can use the Business Reminders Browse to automatically check for on-line orders. And you can use the new Queries to create the kind of filters we just discussed. You can also print several standard reports using the above Query fields:

RSOSOS - Sales Order Summary
RSOSOD - Sales Order Line Item Detail
RSOPRH - Sales Order Detail With Ship To Information

So for example, you might create a Query on these reports with the following options:

• Orders which have been entered but not submitted and which are older than 24 hours...
  Entry Date < Today AND OrderStatus = 'U'
   
• Orders which have been submitted, but not approved and which are older than 24 hours...
  Entry Date < Today AND OrderStatus = 'W'

In Ollie, your Admin won't want to fool with Queries. So there is a built-in Open Order Report to show all unapproved orders; submitted or not. They can then use a filter to show orders entered before today. With those on screen, they can send a *Blast Mail to all users and their approvers reminding them to get on the stick!

*We'll be talking more about Blast Mails in a future issue. If you haven't used these before, for now just think of them as bulk e-mails... but not spam!

Til Next Time!
 

Ciaran's Corner: A Greener You (Part I)
King County here developed a little web site where you can calculate your 'carbon footprint'. A couple of the guys here decided to try it out. Everything is going fine and then you enter your 'flights'. Wham. You're screwed. Take more than 3 flights a year and you've pretty much doubled your carbon use! Holy 747 Batman!

'Green' has always been a bit of a touchy subject in the printing business. Frankly, many in 'the biz' have seen the 'paperless office' as a threat. And many have seen it as a joke---after all, computers have only increased the amount of paper we all use, right? But you're not in the paper business, right? You're really in the value added business. Anyone can sell paper. You sell a value added to the paper or the web site or the mailing system or whatever. Also, you want to keep your own costs down and help the planet too, right? So for the next couple of issues I'm going to quickly mention some things we've found which can help save money, save the world and so on and so forth...

First off, a quickie... Time to check out one of those ideas that makes so much sense, you wonder why no one thought of it before.

http://printgreener.com/download.html

Actually, lots of people have thought about this for years. We were using a program that 'condensed' reports (two or four pages at a time) back in the DOS days.

But GreenPrint, like so many things, is an idea who's time has come. It takes the output of your reports and combines pages as efficiently as possible. Think how many reports and web pages you print out where the majority of the pages are white space? GreenPrint ends that waste. The amount of physical pages of printing it saves can be remarkable. It works from any Windows application and there is even a 'home' version which is free, Free, FREE! Highly recommended.

Next time, we'll move up the food chain and discuss communications.

Til Next Time!

Ciarān Marron
Technical Support Manager
cm@suntowersystems.com

THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. The information contained in this document represents the current view of Suntower Systems on the issues discussed as of the date of publication. Because Suntower Systems must respond to change in market conditions, it should not be interpreted to be a commitment on the part of Suntower Systems and Suntower Systems cannot guarantee the accuracy of any information presented after the date of publication. INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND FREEDOM FROM INFRINGEMENT. The user assumes the entire risk as to the accuracy and the use of this document. This document may be copied and distributed subject to the following conditions:
1. All text must be copied without modification and all pages must be included.
2. All copies must contain Suntower Systems' copyright notice and any other notices
    provided therein
3. This document may not be distributed for profit.

End of E-News From The Suntower, Volume X #9