Tuesday, August 28, 2007

VIC CRM: Importing a Notes Addressbook (and upcoming changes)

One of the most frequently asked questions I get about VIC CRM is how to synch the Index with a Notes addressbook.

The short answer is, you can't. But -- and it's an important "but" -- "synching" is a two-way street. You can import an addressbook from either Lotus Notes or Microsoft Outlook. And, you can use the Index itself as an addressbook, so synching usually isn't necessary.

The reason synchronization isn't included is a little complicated, but it's mostly just a decision on my part. VIC is an application, and in writing it, I really have no idea how you're going to use it. I only know how I use it, so unless you contact me, I'm writing for me. Also, VIC is a fairly vanilla platform that can be customized for your use. In fact, I expect that you'll customize it. As such, there are some self-imposed design guidelines I follow.

First and foremost, I never depend on customizations external to the application. Some packages (such as OverQuota, the precursor to Relavis eSales) synch with your mail database by providing a customized mail template. I really hate that, so VIC is designed to handle all interaction with the mail template without touching the design of the mail template itself. This means that with with VIC CRM you're not locked out of upgrades to Lotus Notes as you often are with other packages. The current version of VIC requires a minimum notes version of 6.5, but there is no upper limit to the version until IBM breaks backward compatibility. This means you can upgrade to version 7 or 8 of Notes without having to stick with the old mail templates. It also means that you can (as I do) use the OpenNTF Mail Experience template, which is much better than the one provided by IBM.

Secondly, VIC is intended for a broad range of users. I don't know what your needs are, and I try not to bloat the system with a bunch of functionality that's not broadly usable. It means that synchronization to external addressbooks, directories, financial data, etc. is best done as customizations. Of course you could hire me to do them, but the important thing is that you don't have to... you can hire anyone to do them because the code is open.

Another reason addressbook synchronization isn't included is because the VIC Index is an addressbook. Just add it to your Local Addressbooks list in your Notes User Preferences. Here's how it looks for me:



Piece of cake. Now I can use the VIC index to address any Notes mail to a VIC contact. Notice the red circle-and-slash icons next to some of the contacts in the illustration: these are customers that don't have email addresses. Why even include them? Well, I tried leaving them out, but that just confused people who thought they were "missing". This way, you know they're there, and you know why you can't email them:



For the most part, my Notes addressbooks are well-organized and empty of extraneous information. They're listed in my User Preferences in the following order:
  • The company addressbook contains my internal company members, and it's exclusively used to address internal mail and handle ACLs (access control lists).
  • The VIC Index contains customers, clients, and professional contacts that need to be shared among team members.
  • My personal addressbook contains only private contacts that I don't want to share in the company. I don't ever put customers in either stock Notes address book. That's generally not the right place for them.
Going from a Notes Addressbook into VIC is pretty easy, but it's designed to be an all-or-nothing thing. From your workspace, if you highlight the VIC Index, you can select Actions, then Import, then 1a. Notes Addressbook. This will import all of the addressbook entries that don't currently exist. Then select 2. Create Organization docs to create an organization doc for each person (if necessary) and properly relate them. This is limited to a degree... it tries to key off of the company name, so variations in spelling are significant. And data may change over time, and this routine simply assumes you're keeping up with your company info in VIC Index. In other words, after-the-fact changes made in the Notes addressbook may be lost. For these reasons I suggest that this be limited to a one-time import.



You might notice that there's an import option for a Microsoft Outlook addressbook. This works after a fashion, but Outlook's export function is semi-broken, so explaining it is a whole other topic. Nevertheless, it works and I've used it. We're going to skip over that for now.

Now, even though VIC acts as an addressbook on its own, there's a reason you might want to move contact information from VIC into another addressbook, and that's if you've got a PIM that can't see VIC as an addressbook for whatever reason (it may be making unwarranted assumptions about the local addressbooks). Again, this is specific to you and the equipment you chose; and frankly, though I've been asked about it in general terms, nobody's actually asked me to fix it for them. Nevertheless, I'm asked about it often enough that for the next VIC release (targeted for this Autumn), I'll be adding a method of picking and choosing the Notes addressbook entries to bring into VIC, and I'll be adding an Export feature to send selected VIC contacts to the Addressbook.

Upcoming Changes

Regular users of VIC will notice that even in this small screenshot some other things have changed. VIC Launch is a new feature that gives you a distinct starting point for the application. It doesn't really do anything else on its own, but it is the launching point for the My Activities page, and it makes management of the My Activities page much more stable than it has been. It's mostly there to make sure the GoVIC launcher has nothing to do.

In related news, Projects is a little further along. Sales probably should update the Financials pages, though in practice I've found the views in the Sales db itself are adequate to my needs, so I've been leaving it open for customizations.

I probably should explain that one a little bit, though I really don't want anyone to get overly excited about it. The Sales db was originally created to keep a record of what you've sold to a customer so that you can keep track of what you need to support. So you could create a Sales record and pull in some product information from the Library. Simple, right?

Well, I'm still unsatisfied with 100% of the Open Source accounting packages out there, though, and I do a more consulting time than product sales; so as a stopgap I'd just put in a "product" called Consulting Time. Then it occurred to me that I'm already tracking my time in the Journal, so in addition to pulling time from a Product Brochure, I can simply select Journal Entries for a customer as if they were products, and they become Sales line items, complete with the actual amount of time recorded in the Journal. Simply applying an Invoice form to the Sales document makes it a printable Invoice.

So basically, I go to bill a customer by creating a Sales doc. I click on Add Product, click From Journal, and I'm presented with a list of all the billable visits I've made to that customer (the Journal knows whether it's billable because every Journal Entry has a billable flag). I select whatever it is I want to bill, and the sales doc is automatically populated with the description of the visit, the duration, and the value is automatically calculated. Basically, I'm just pointing to the visits and VIC takes care of the Sales doc. VIC also establishes links between the sales doc and the Journal Entries, so when I'm looking at a Journal Entry I can tell immediately whether it's been billed (and can pull up the Invoice right there). Conversely, if I'm looking at an invoice and I have questions about a line item, I can instantly drill down to the Journal Entry associated with it. I send an invoice by clicking on Invoice (it's conceptually equivalent to turning a sales order into an invoice), selecting a banner (if I'm not using pre-printed letterhead), and pressing Print. With a PDF printer, it's great for sending bills in email, too.

I manage the Sales db using views for Open Sales Orders, Open Invoices, Paid Invoices, and Invoice Not Sent, among others. You can view documents by Date, Period, Professional, or Customer. You can apply a payment to an Invoice and it's dutifully calculated in the views.

That said, Sales is in no way a replacement for an accounting package. Even though it's the easiest way of billing time I've ever used, there are lots of holes, like no real audit trail and no way to track partial payments or do balance forward billing. It gets bills out and money in, but it doesn't "account" for anything. To be perfectly honest, I still recommend you use anything BUT the Sales db for accounting, though it is pretty much at the point where I've been using it to create my own invoices, and scratches about 70% of my itch.

More info as it develops.

0 Comments:

Post a Comment

<< Home