|
'The Electronic
Newsletter For Users
Volume X #13 |
IN THIS ISSUE: |
|
|
You are receiving this e-mail
because you asked for it, either because you have requested information
about our products and services and given us your e-mail address (Thanks!)
or because you are a current customer of ours (Double Thanks!)
TO UNSUBSCRIBE, MAKE
SUGGESTIONS or to CHANGE ADDRESS: Send a message to:
webmaster@suntowersystems.com |
||
SAFE/X Tip:
Let's Split The Check!
Number 379 in
our list of small but useful enhancements to SAFE/X, you can now split Vendor
Bills into separate A/P Checks. You may have ten vendor bills to pay, but one of
them is special and you'd prefer to put that bill on it's own check. Until now,
you'd have to do two separate print runs. But now, when you tag the bill for
payment, simply check the 'Separate Check' box to the right of the Amount To Pay
field. This places that one bill on it's very own check, regardless of how many
other bills are tagged for that vendor. You can easily distinguish these 'Tagged
Separate' bills by their new icon (a check mark split in the middle by a red
slash.)
A way to automatically split checks without manually checking this box is by remittance address. This comes in handy if you have multiple checks to 'CASH' account Vendors or have a single vendor with multiple payment addresses. To enable this, you'll want to enable the Global Option:
MODULE: PRINTAP:CHECKS
PARAM: PrintOrder
VALUE: Address
This forces the checks to print in Vendor ID order, but 'breaks' them apart within each Vendor ID by their Remittance Address. All regular vendors print as per usual because they have a single address.
The Dreaded Form
Re-Design!
So the question inevitably comes up... does this require a form re-design
charge? The answer is an emphatic, Maybe!
In the case of Separate Checks, so long as you are using a standard cut sheet
form with one check per page, you do not need to change anything. If, however
you are using continuous checks or are using our popular three on a page format,
you will need a form re-design.
Also, if you want to split checks by vendor remit address and are not using the standard one page A/P Check (Quicken Format), you will need to have your check format re-designed.
Til Next Time!
Ollie Tip:
Passwords
We often get
asked our opinions about passwords and what are the available options for Ollie.
Opinions, we have in droves. And options too.
As you know, a SAFE Contact is an On-line User in Ollie. They are one and the same entity. So every 'User ID' in SAFE must be unique. That right there might be a consideration. After some customers you set up on Ollie will want to create User IDs that are meaningful to them. They may wonder how there could possibly be another User in their company with the User ID 'MOONDOG'. Of course, there isn't. There's someone equally clever at another of your customers.
Passwords in Ollie are a bit different from passwords in SAFE.
1. They are longer (15 chars in Ollie vs. 8 in SAFE)
2. They can be subject to various validation rules which SAFE passwords cannot. All these validation rules are Customer Specific. That is, the rules can be set independently for each Customer's Users (though not for each User.) Some of these validation rules include:
a. Allowing (or not) Users to change their own passwords.
b. Demanding that users change their passwords after a period of days. For example, forcing all users at a particular Customer to change their passwords every 90 days.
c. The ability to enforce various password strengths. For example, you can demand certain lengths (6,8,10,15 chars). You can also insist that passwords contain both letters and numbers.
d. The ability to lock out Users after a certain number of incorrect password attempts (a common settings is '3'.) After the set number of failures it will require you to reset the User's password. A further option is available if you allow users to set their own passwords. In that case, when you reset their password, you specify a temporary password which is only good for one session. During that session they must reset their password to a new permanent value.
e. Though not really a 'password' feature per sé, each Customer may be set with a password page timeout, ie. the number of seconds the user is allowed to complete the page. As with option (d.) if they do not enter a valid User ID and Password in the allotted time, their password is disabled until you reset it.
By default, each of these validation rules are turned off. You enable them in the On-Line Options Browse by right clicking from the Customer Browse.
3. One final aspect of passwords which is Site Specific, ie. global to all customers and users on a given Ollie Site is Secure https Login. This means that the login page is encrypted so that user passwords cannot be hacked. A short word of explanation. 'https' refers to a web protocol which encrypts all information transmitted from the server to the client's browser. This encryption, though safer than 'regular' http web traffic is much slower. It is therefore usually restricted to pages with highly sensitive information; such as credit card processing or passwords.
SELLING SECURITY!
It's always very important to research potential customers and no
area rewards effort as much as knowing their feelings about security. If you
demo Ollie to a potential customer it is imperative that you know their
expectations regarding passwords and set up your demo to match their feelings.
We say 'feelings' because this is, as you may know, often a visceral
issue--especially for IT people. It is usually best to err on the side of 'too
much' rather than too little; at least in the proof of concept phase of the
sales process.
That said, what we have found is that most Customers over time tend to relax these requirements in the face of day to day practicalities. Although strong passwords seem like a great idea, users often rebel against too many constraints. It's important to recognise this reality and not overdo it. One has to weigh the potential risks of break-ins vs. the 'hassle factor' which should not be under-estimated. After all, if a site is hard to use for any reason, users will either not use it, or use it less than they would otherwise. It is therefore, critical to monitor not only management desires but also user feelings about this issue.
Til Next Time!
Ciaran's
Corner: We're All In This Together (The Annual Backward Compatibility Rant)
One of the, if
not the toughest issue we deal with year after year is backward compatibility.
It's often an issue with new customers. I've come to see this almost as a
political struggle. Sharp-eyed new customers can easily find lots of features
that seem duplicated or not 100% consistent. 'My world and welcome to it.'
Years ago, when Hugh and JC built the original core of Simple Accounting it was decided to make almost every feature 'customer-extensible.' (Ed Note. Take note of clever use of name dropping to avoid responsibility.) That is, they figured out a way to make it manageable to add features for each customer without impacting others. The real trick? Having a system that allowed these changes be maintained through subsequent releases.
Think about that: let's say I'm a real estate developer. I sell the same house floor plan to customers all over the country. As the years go by, I offer to come in and add upgrades to every house using standardised parts. But along the way, I also offer to make changes to your floor plan as your specific needs change. And I further promise that any change I make just for you, will:
a. Not be impacted by the generic upgrades
b. Not prevent you from receiving the generic upgrades.
c. Not charge for this backward compatibility. In effect, I guarantee that I can keep adding generic features, while maintaining your features at no additional charge.
Believe me... this is no small trick. It ain't sexy, but then neither are a lot of very good things in life... like roads, bridges, power grids, etc.
What we didn't count on was the political end I alluded to before. There will always be a conflict between past and present because we definitely could take SAFE forward much faster and farther if we did not function in this manner. However, what I've come to realise in this most political year in recent memory is that there's also an element of self-interest vs. 'the public good' that we did not foresee way back in 1988. How you feel about the above strategy comes down to 'what's in it for me'.
If you think about the above a,b and c, it sounds great until you realise that it is of far greater benefit to established customers (conservatives) than to newer customers (liberals). New customers don't already have a long-term investment in SAFE, so the most change---new features; the greatest possible consistency. Older customers (you're not old, I just meant...) have a stake in things staying the same. They want new features, sure, but not at the risk or expense of disrupting (and by that I don't mean 'bugs', I also mean changing) existing processes.
Of course, these are over-generalisations. We have older customers who benefit greatly from the customisations, but still wish we could add benefits faster. After a while, we tend to take for granted what we have no matter how great it is and wish for more. ('What have you done for me lately?') It's hard to keep getting jazzed about something that works the same every day. When was the last time you woke up and decided to ring the phone company to tell them what a bang up job they're doing. You're more likely to ring them to complain as to why they haven't yet added DSL to your neighbourhood. And of course, their answer is the same as ours, 'we're working on it, Madam.' They have their existing infrastructure and we have ours. They have to find a way to add services without disrupting the existing order. The big difference between the phone company and us in this analogy? They ask for more money when they add new features. We don't.
We hope (and count on) your feeling, at least a bit, that we're all in this together; that you're OK with a slower rate of 'feature creep' in return for backward compatibility and the opportunity for great extensibility at a reasonable cost. And we hope you can maintain that 'big picture' view even when there are aspects of the program that aren't changing as fast as you would like.
We certainly want to move SAFE forward as quickly as possible. We've always been technologically ----way---- ahead of our competitors in this market, but that's only because most customers in this market (that would be you) tend to be slow adopters of technology. We're definitely not as far along as other name-brand Windows programs which do not have the obligation towards pre-existing customers and their custom code. Not a day goes by that our engineers don't drool over some new technique that will simply have to wait because we have to first figure out a way to do it while maintaining protecting existing investments.
What always tips the balance towards moving forward is your feedback. As we always say, 'the squeaky wheel gets the grease.' Those who make the time to present their needs/wants/desires in a cogent manner have always gotten the most consideration. Newer customers may not yet trust in this, but older customers can all confirm it. And I say this in good conscience, even though, when you send us that proposal, we likely say something like...
We're working on it, Madam. <rimshot>
Til Next Time!
Ciaràn Marron
Technical Support Manager
cm@suntowersystems.com
End of E-News From The Suntower, Volume X #13
