Thursday, August 30, 2007

Refund

Out of the box refund logic is absurd! It imposes arbitrary constrain on early refund of payment. It is very inflexible in terms of what is refundable what is not. The way we normally change this kind of behavior is modifying the hooks (policy op-code in Infranet jargon). Unfortunately refund flow has no predefined hooks, so I end up dumping it a write a custom one.

Wednesday, May 23, 2007

Application Architecture

I always like software applications with well-defined application programming interfaces (API) and modular architecture. This is one of the stronger points of Portal Infranet. It gives you fairly well-defined demarcation lines between the core application logic and external interfaces as well as between different core modules. The application core is a set of shared libraries and predefined data access modules and a series of preprocessing and post-processing hooks. Need to modify the business rules? Change the hooks. New functionality? Just add a new core module. Have a new data source? Whip up a new connector... It goes like that.

I have seen many popular enterprise applications that have no comparable architecture. Data just go straight from web user interface to database tables. But that does not seem to relate to how well they sell :) Technology is details. Marketing is king.

Wednesday, May 9, 2007

Deferred Revenue Recognition -- Part II

It turns out the rate flag is not reliably set for all cases, but it is set for certain cases. I just have to make certain assumption when I can't figure out its value. It happens for the very first cycle charge, which helps since I know the context of the first cycle. Anyway it looks like I can get this feature to work on 7.2, admittedly it is not easy. But hey no pain no gain :)

Wednesday, April 25, 2007

Deferred Revenue Recognition

One of the most frequent custom features that I have been asked to do is implementation of deferred revenue recognition. This is useful primarily for subscription based services, where a service plan can be sponsored or prepaid, but the revenue can't be consumed until the service is activated.

In previous releases (circa 6.x), this can be achieved by modifying multi-month cycle start/end dates before the cycle event is rated. The system would use the custom dates to set revenue start/end dates for the event. Sometimes the future dates confuse the system (remember it's supposed to be 'real-time no limit', so back-dated & future-dated are with limit), in that case I use post rating hook to rectify the situation.

In the more recent releases (circa 7.x), the rate flag used to determine rating scenarios is no longer set. It looks like rating process flow has changed quite a bit. I need to figure out soon what to do here to upgrade this feature. Just wish it is part of supported out-of-box features. As one of my colleagues always says 'Don't %@#$ with dates', so do it at your own risk. :)