Reminder emails were needed to be sent out to remind sales staff to follow up on projects.

Solution

I developed a simple command line executable that takes 1 parameter which is an XML file.  The contents of the XML file would look something like:

<?xml version="1.0" encoding="utf-8" ?>
<Settings>
	<ErrorEmail>
		<Email>email@gmail.com</Email>
	</ErrorEmail>
	<SummaryEmail>
		<Email>email@gmail.com</Email>
	</SummaryEmail>
	<Query>
		SELECT * FROM Projects
		WHERE Cancelled = 0 And Completed = 0 AND BookDate IS NULL
		AND FollowUpBy <= getdate()
	</Query>
	<SQLConnectionString>Server=SQLServer;Database=MainDatabase;Persist Security Info=True;Integrated Security=true</SQLConnectionString>
	<TemplateEmailFileName>EmailTemplate.txt</TemplateEmailFileName>
	<EmailSubject>Alert Email For Project#<:ProjectID:></EmailSubject>
	<EmailDomain>mycompany.com</EmailDomain>
	<ToAddressDatabaseField>Salesperson</ToAddressDatabaseField>
	<ToAddressFieldIsEmail>0</ToAddressFieldIsEmail>
	<SMTPSettings>
		<SMTPServer>smtp.gmail.com</SMTPServer>
		<EnableSSL>1</EnableSSL>
		<RequiresAuthentication>1</RequiresAuthentication>
		<Username>email@gmail.com</Username>
		<Password>*******</Password>
		<Port>587</Port>
		<FromAddress>email@gmail.com</FromAddress>
	</SMTPSettings>
	<LogFileDirectory>Daily</LogFileDirectory>
</Settings>

The command line executable would then run the query (<Query>) against the supplied database in the XML file.  For each row returned, the program will send out an email to the user.  Which user?  What email?  The recipients email address would need to be one of the fields returned from the query and noted in the XML file in the element <ToAddressDatabaseField>.  The template for the email body is supplied by the <TemplateEmailFileName> element.   To make the email custom, it is possible to insert fields returned from the database into the email template.  For example, lets say the query returned a field called “FirstName”.  In the email template text file, you could have:

Hello <:FirstName:>,

When the program ran, it would swap “<:FirstName:>” with the contents from the database.  This is similar to a mail merge for emails.  Since all of the values are configurable in the XML file, the usage possibilities are unlimited!  Let say you needed to run this once a week, no problem.  Set up a Windows Scheduled Task to run the executable at the specified interval.

E-manage is a business management application.  It is capable of managing customer databases (CRM) as well as projects, invoices, purchase orders, and inventory to name a few.  The e-manage client application runs on a users desktop and uses Microsoft .NET as foundation along with a Microsoft SQL Server as the back-end.

Problem:

Getting information was easy when you were in the office at a computer.  However, you were out of luck when you were out of the office.  Something was needed to allow users access to crucial business data while mobile.

Solution:

I was asked to created a mobile web portal that could be used with any smart phone that had a basic Internet connection.  This would allow users to access company data while out of the office.

Result:

Mobile portal landing screen with alerts and recent items.	Mobile portal company view
View/Edit/Create Service Tickets	View/Edit Projects

e-manage Mobile Portal – Create Service Ticket (Video)

e-manage Mobile Portal – Add New Company (Video)

I created a web application written in VB.NET that would connect directly with the MS SQL Server to supply the user with the data they needed.  I created it to be light as possible without giving up functionality and usability.  I also integrated with Yahoo Business Search API to lookup business addresses automatically to increase accuracy.  From the mobile portal, you can:

• View/Edit/Create a Company or Location
• Create a Company with the aid of a Yahoo search
• View/Edit/Create a Contact
• Assign existing Company Contacts to a Project
• View/Edit/Create a Project
• View/Edit/Create a Service Agreement
• View Service Ticket part totals when viewing a Service Agreement
• Easily see a service agreement’s validity based on the agreement’s start date and agreement contact length
• View/Edit/Create a Service Ticket
• Assign/Re-Assign Service Tickets to Service Agreements
• Add Parts to a Service Ticket by Searching the e-manage part database
• View Part totals for a Service Ticket
• View/Download a document/attachment that belongs to a Company, Contact, Project, Service Agreement, or Service Ticket
• View/Create a Note that belongs to a Company, Contact, Project, Service Agreement, or Service Ticket
• View/Reply/Acknowledge a Note that belongs to any object
• Submit Project Action Items
• View your Actions To Perform
• View your Open Action Items
• View Recent Items (syncs with the Recent Items in e-manage and updates any items that you open via the mobile portal)
• Open multiple items at the same time in a tabbed environment

Our CRM software contains a huge list of contacts that are only available from within the software application.

Problem:

It becomes a challenge when a sales team member is out of the office (on the road) and needs a customer’s phone number or email address.  It is typically not feasible to boot up their laptop, connect to the Internet and lookup the contact.

Solution:

The solution was to create a simple Blackberry application that will allow the team member the ability to lookup a contact against our CRM software’s database.  From their Blackberry, they would then be able to call any of the listed phone numbers for the contact or send them an email.

Result:

I created a small Blackberry application designed using the Blackberry Plug-in for Microsoft Visual Studio.  The applications allows the user to search by name or company (or both).  The application then submits the search request to the Blackberry Enterprise Server, which then uses a web service that I created to search against our CRM database which is a SQL Server 2005 database.
Once the results are returned, you then have the ability to call any of the listed numbers, email, or add them to your Blackberry address book (which will in turn add them to your Outlook address book).
Overall basic program, but can be a lifesaver when out of the office.

As for any company, physical inventory time is never fun.  Our inventory software did not have a good interface for doing this.

Problem:

The process of taking physical inventory was long and tedious.  The process typically involved printing our a huge list of parts, write in the quantity next to the part, then someone would enter that info in an Excel spreadsheet so that it could be imported back into our inventory software to reconcile.  Another issue was finding the inventory items themselves, most items were organized well, but some could only be found by the "one guy" that knows where everything is located.  Identification of parts and part numbers was needed.

Solution:

The solution was to create a desktop application that could be used to take physical inventory.  The application would search against our existing parts database and store inventory quantities in a separate table that could later be reconciled.  The application would also print out a part identification label on a thermal printer that was to be placed on the shelf of each item.  This would make subsequent physical inventories much easier.

Result:

Fig. 1

Fig. 2

Fig. 3  

I created a desktop application the keep track of inventory.  The application also has the ability to print out part identification stickers on a thermal printer that included part information along with a barcode.  Fig. 2 shows the part detail screen.  You can find out various information from the Detail screen as well as adjust inventory levels.  You can pull up a part by either searching by part number or scan the corresponding barcode the program had previously printed out.
The application was such a success, I created a web interface to allow certain other employees access to inventory levels.  Also various reports were created that were needed Accounting purposes.

A company I worked for had a new Internet (external) web site built.

Problem:

We already had a working Intranet (internal) site, but my company wanted to make the Intranet (internal) site to have a similar look and feel of the Internet (external) site.  They also wanted it to be more database driven so regular users could update the site without using Microsoft FrontPage (the way it was updated at the time).

Solution:

I was to create a new Intranet (internal) web site to have a similar look and feel of the external site.  I also needed to bring over a few existing tools from the existing Intranet site and make it easier to update.

Result:

Fig. 1

Fig. 2

Fig. 3  

I created a new Intranet site that looked very similar to the new Internet (external) site.  The site was created using Visual Studio 2005 and is almost completely database driven.  This way routine updates can be made either from within the site itself or by modifying data in the database.  Fig. 2 shows the "People Finder" employee lookup.  You can search by name, department, or office location.  Fig. 3 shows the training area.  This is a place where videos, documents, etc can be placed.  Originally I created the "tree" to pull from a database.  Shortly after publishing the site, I was hammered with stuff to add to the training section, so I changed it to pull from a folder on the web server.  So if you needed to add a item you could use Windows Explorer, browse out to that folder, and paste the file.  Every time the page loads, it looks to that folder and re-creates the tree.  This works great for the capacity that we are using it.  Article items (shown in the tan and blue boxes in Fig. 1) can be added/modified from within the web application.

This project had a similar background to the Install Schedule application.  We started using a software package called eManage (I worked for this company later and built a mobile web application to interface with their database) to manage several areas of our business.  The software has a built in calendar that can be used for scheduling installations.  The look and feel of the calendar is very similar to the Microsoft Outlook calendar.

Problem:

Our employees were accustom to the layout of the Install Schedule application.  They liked each installer to have its own line, doing it that way also makes it easier to manage employee’s time too!  It was not possible to change eManage to show the calendar this way.

Solution:

Build a separate web site application that will have the look and feel of the Install Schedule, but pull its information from the eManage application.  Job assignments and modifications will be made from within the eManage application and those changes will be reflect instantly on the web site.

Result:

Fig. 1

Fig. 2

Fig. 3  

The web site pulls data straight from the eManage database so the info is always live.  It also provides the installers and coordinators a familiar look to the schedule.  Each user has their own user settings which allows you to view the installers that you want to view and customize the size of the calendar to fit your particular screen resolution.  Fig. 2 shows that you are able to click on a job to expand the bar to see all of the information.  The color schema for the jobs are the same as they appear in eManage.  Fig. 3 shows the "Jump to Date" which utilizes a modal popup screen.

I created a single page web page that was set as the background using the Active Desktop function of Windows XP.  This web page allowed you to search the employee database for phone numbers or extensions.  It also had a section to calculate shipping for certain items my company sells.

Problem:

Active Desktop started messing up when laptop users would boot without a internet connection present.  Also, since the web page was hosted on the company Intranet, a login dialog box would pop-up if IE was not configured properly which was confusing to some users.

Solution:

Rebuild the web page to not use Active Desktop, but still have the tools easily accessible.  Having a bookmark to the web page was not considered "easily accessible".

Result:

Fig. 1

Fig. 2

  Fig. 3

I decided to created a small application that runs in the system tray.  Right-clicking the icon in the tray would expand a menu of available tools.  Fig. 1 shows the menu and the employee search box that appears after clicking "People Finder".  Certain menu items are shown/hidden depending on the user’s login.  For example, my login shows 6 items, but "Support Ticket" and "Cams" are not show for others.  Rights are stored in the SQL database and not in the application so allowing access is simple and does not require an application update.  Since we are on the subject of databases…how should the application connect to it?  I decided to not connect directly to the database since the user would have to be on the network or have their VPN connected, but instead indirectly by using web services.  Using web services allowed the application to work as long as any Internet connection was present.  If a connection was not present, the application hides menu items that require a connection or certain rights.  I created a separate web site that hosted the web service application that basically would act as a proxy for my application.
Since I knew I would be updating the application as time went by, I wanted the application to be able to update itself.  I accomplished this by using some of the "Click Once" features of Visual Studio.  Instead of using the default settings, I handled the Click Once part programmatically so that I could force the update.
I added a "Sales Links" item that expands into a limitless list of links and sub-links.  The links can be  URLs, local folders, or anything that you can type into the Start>Run box!  Users with permission can easily modify and add links.  The application refreshes the links from the database every 30 minutes.
Lets talk security…
Since only a standard Internet connection is needed for the application to work, there were a couple of security concerns.  The web service application was open to the public!  That’s okay, lots of web service applications are open to the public…that’s kind of the point of them.  I decided to use "keys" that had to be passed each time the application consumed a web service.  In other words, a password (or key) is passed to the web service and every method (function) the web service has requires a password.  What about updates?  The application needs to look in a public place for updates.  If its public then everyone could download the program.  That’s okay too!  I just had to put some security measures in place with the application is launched.  Let’s just say that when the program starts it knows if it is suppose to be on that computer, if the check fails the application quits.

One of the many things my company does is file room conversions.  To make this short and sweet, a file folder may need to be moved to a new location.  In the process the folder may need a new label applied to the folder.  This is simplistic example of a conversion.  A client requested this type of service from us.

Problem:

This was a large conversion and the client required several specific "checks" to be in place.   The original folder needed to be scanned by a barcode reader to rule out data entry errors.  The barcode data would then need to be sent to the client so that other various information could be added.  The data would then need to come back to us so that we could print new labels.  Since this was a daily process for approximately 3 months, some tracking was needed so that at any given time a folder could be found.

Solution:

I was to create several applications to aid in the conversion process.  Starting with one to handle the barcode scanning in the first stage.  Next a secure web site needed to be created to allow files to be received from scanning, downloaded by the client, and re-uploaded.

Result:

Fig. 1

Fig. 2

Fig. 3 

I created 2 desktop applications and 1 web application that included a web service.  The first desktop application was installed on laptop with barcode scanners attached.  This application would be used to gather file label barcode.  Fig. 1 show the screen of the laptop with the application running.  The screen provided various information and also included visual and audible verification of scanned barcodes.  Because of the barcode situation on the folders, the application needed to check to make sure the barcode was in fact valid. 
I provided 2 different way to get the scanned data back to the main office.  One way was by using a web site upload utility.  The other way was to have the barcode scanning application automatically send the file via a web service that I created.  Either way, the file was placed in the same folder back at the main office.  This folder was being watched my another desktop application that I made that ran on a separate machine.  Once a file was uploaded, the desktop application would grab the file, import all of the data into a SQL Server, and post the file on the secure web site where the client could download the file.  The client would add various information to the data and re-upload it via the web site.  Date and time stamps were noted of all of the transactions.  The re-uploaded file was placed in a different folder that was also watched by the desktop application.  Once this file was uploaded, it was checked for certain required data, checked for the correct sort order, imported into the SQL Server, and marked as "OK" so the client would know that everything was good.
Up until now, everything was automated and only required routine checkups to make sure everything was okay.  The last step was to print out the labels (sample shown in Fig. 2).  The step to print the labels was simplified into dragging and dropping the file that was re-uploaded from the client into a separate watched folder.  Once the file was dropped there, it was sorted into a special sort order since their sheets were later to be cut into single labels.  Then a cover sheet was printed followed by the label print job.  After the labels are sent to the printer the printed date and time is noted in the database and viewable from the web site.
Fig. 3 show the landing page of the web site application which allows access to several tools and lookups.

My company uses Sprint as a cellular provider.  Paper bills are 300+ pages and arrive in a box.  Sprint offers a service to download cell data at the end of each month (for a cost).

Problem:

Flipping through the bill was very cumbersome and took sometimes several hours.  My company wanted an easy way to look at the employees usage.

Solution:

Utilize the Sprint service to download data each month.  Load the data into our own SQL Server.  Create a web site to summarize that data while providing a simple user interface.

Result:

Fig. 1

 Fig. 2

I created a basic web site to simplify the cell usage data.  You can search by bill cycle or a specific data range.  Users that use more than 1,000 average billable minutes per month are highlighted in red.  Clicking the specific user will show the call details.  Fig. 2 shows the Detailed Usage page which also allows you to highlight mobile to mobile, text messages, nights, or weekends.

This is what started it all (at least at my previous employer).  The company I worked for company sells stuff and that stuff has to be installed by a professional installer.  They have a large staff of professional installers.  They have a lot of stuff that needs to be installed.  See where I am getting?  Before I started, this information was stored in a Excel spreadsheet, which did the job until they started growing.  Then it was moved to an Access database, which was much better; however, not everyone knows how to use Access, so a basic web interface to the database was created in FrontPage to update the rows of data.  Each row in the table was a day and each row had a column for every installer.

Problem:

This was functional, however as installers were added and new column had to be added to the Access database.  Also the FrontPage site had to be updated to account for the added column.  The good thing about FrontPage was that it appears simple because it hides a bunch of code behind the scenes, the bad thing is that if something goes wrong (like your computer crashes while updating the site) it becomes a real nightmare to get everything back up and running.

Solution:

The plan was to create a fully database driven installation calendar.  One that could be updated from within the application itself.  Instead of having a list of days and putting a installation on each day, we would have a list of jobs and add installers.  This makes it easier to use since jobs often spanned across multiple days.

Result:

Fig. 1

Fig. 2

Fig. 3

I created a web site that used ASP (Classic ASP, not .NET) and a MSDE database.  The hard part for me on this project was drawing out a calendar dynamically and "putting stuff" on it.  How was that going to look?  How should it look?  Fig. 1 shows the result.  The calendar is shown on the left and jobs that are shown in the current view are shown on the right.  Fig. 2 shows the detail view of a job.  This is where installers could be added to a selected job along with a few other functions.  Fig. 3 shows the print view.  This was helpful when trying to coordinate the jobs.  This was another painful page to write because of the layout.  The only way I could get the data in the format I needed for the page was to do lots of sub-queries.  One for each day and installer, this made the process time for this particular page several seconds!