The New York City SharePoint Developers User Group Monthly Meetup

Wednesday, April 20, 2011

5:30 PM

Microsoft Office NYC - 6th Floor

1290 Avenue of the Americas New York, NY

Required apps for Cloud computing

You've done your research and know the differences in business model between the 3 areas of cloud computing:

• SaaS (software-as-a-service). WAN-enabled application services
• PaaS (platform-as-a-service). Foundational elements to develop new applications
• IaaS (infrastructure-as-a-service). Providing computational and storage infrastructure in a centralized, location-transparent service

So you decided to jumped on the bandwagon. Now you're planning the operations of the company and looking at the operational processes from the point of contact to revenue recognition. You start creating the flow and do an inventory of the applications required for each process. At a high-level this is what you had at the end:

CRM - This system will initialize the process. A simple CRM sales cycle include prospecting, proposal then Win. You can go for On-demand or On-premise solutions.

Contract Management -  The contract creation should be simple yet flexible. These days CMS softwares are flexible enough to create contracts in different languages which caters to different regions - EMEA, AsiaPac, etc. Flexibility is very important because contracts can have different data elements and the application should have this feature.
Billing - This is the heart of the whole system. When looking for this system, you should understand that this goes to details of your process so involve hands-on users as they know what's important to this process. Accurate billing is your main objective here. Invoice formats is likewise an important piece.
Collections - With companies going global, expect that customers will require you to cater to their needs. One common pitfall of this system is the ability to receive payments other than the customer's region currency. Your system should be flexible enough to accept payments in different currencies. You don't want to return a payment because it's on the wrong currency...Money is king!
Usage Metrics -  Every customer using your service expect to know their monthly usage. This system should be able to track where the customer is in terms of usage. If you're sending a monthly invoice to your customers then this is based on monthly usage. Some companies support real-time usage on their websites for customers to see.
Revenue Recognition - The accounting for Cloud computing is still on its infancy. New accounting rules will be define in the coming years and this will change how applications determine Revenue recognition. The juice of the discussion will focus on how to leverage this new way of doing business. Revenue calculations will neatly integrate with customers subscription contracts but there are other ways of doing business in the cloud which can define how the new rules will be laid out.
General Ledger -The last piece of the puzzle but not the least important as this can determine if your process is working or not. Other applications will feed this system, application or module. You have to know your integration points and GAAP rules that govern those systems. Don't take your reconciliation process for granted.
Others - Tax, reporting - financial and operational, templates,etc.

Integrating with Dynamics GP - Part II

One of the more complex integration in this project were the customer payments integration and Revenue. The entry point of the integrated data in GP will be in two (2) windows: General Ledger and Bank Deposits.

The General Ledger integration were the entries originally created from the Revenue & Expense Deferral (RED) module. Now that the subledger is non-resident to GP, we have to create the middleware to do this. It was a mix of SSIS & Dexterity and since the host system was on Oracle we had to create Linked Servers.

The Bank Deposits is pretty straight forward as customer payments were received from the billing system, the entries are booked to GP as cash and a separate GL entries are created.

Another complexity in this project is the data migration of the subscription contracts in GP. We were using a 3rd-party product and we made customizations which slices the contracts on an annualized basis. All active contracts were migrated so billing can continue on the new system.

Lastly, reporting and Smartlist. Given that subledger reports will be coming out of the new system, the reconciliation process between GL & Subledger will change. Smartlist reports for subledgers goes away as well.