Line item options

ajj3085 posted on Monday, October 08, 2007

Hi,

I have my quoting application live finally, and the user's are happy with it.  There is one change though, and I'd like some feedback on best to implement this.

I have a few classes, which all inherit a common LineItem base class.  In this specific request, a change to the behavior of the PackingFeeLineItem is needed to accomodate one customer.  Now, I don't intend on having the class look at a particular customer and figure it out itself; instead, I want to give the users a way to switch a flag that affects its behavior.  If the flag is not set, the PackingFeeLineItem will calcualte the fee as a percentage of the quote total, or $10, whichever is more.  If the flag is set, the minium fee won't apply at all. 

I'd like to handle this in such a way that I can add other similar options to arbitrary line items.  My current thinking is that I will have a flag on LineItem which indicates if the item supports options at all, a method to enumerate the supported options (this will give the UI details such as what kind of values to allow, a description to display, a "key" which identifies the option, etc), and two more methods to get or set the value of the current option.

My thought is that this will allow me to enable other very specific options for line items in the future while keeping the UI dumb about what is actually going on.  To this end, the UI only knows about an interface, ILineItem... the specific classes are internal to my busines layer only. 

I believe this scheme will work... but I'd like some feedback on this.  In the future, I may add support for changing the percentage discount on my DiscountLineItem via this API.. currently you need to delete the discount and add a new one... but thats not important right now.

Thanks
Andy

ajj3085 replied on Tuesday, October 09, 2007

I guess I'm right on track.

david.wendelken replied on Tuesday, October 23, 2007

In general, the approach makes sense to me.  Having been down this route before (just not with OO languages to support me), there are some business issues to consider.

ajj3085:

Hi,

Now, I don't intend on having the class look at a particular customer and figure it out itself; instead, I want to give the users a way to switch a flag that affects its behavior. 

Here's an example:

I negotiate a special deal with management, that my minimum shipping fee is $5 instead of the normal $10.  We put it into our contract.

You implement this as an option that the user chooses from when filling out the line item.

All the sales staff are told about the exception via an email memo or staff meeting.

A new guy joins the sales team and, of course, no one sends him last months email or remembers to tell them about the special rule for this customer.

He invoices them $10 instead of $5 for shipping on several orders.

Another clerk is "less than average in reliability".  This might be because he's depressed, or hung-over, or just doesn't give a rat's behind about the quality of his work.  So, in a boredom-induced stupor, he enters "the usual" $10 shipping fee for several more orders.

The customer notices that they are being charged $10 instead of $5 despite a contract to the contrary.

The important question is:

How mad will the customer get and how much money might it cost the company in lost sales?

So, you might want to consider adding the ability to set a non-default choice at the customer level for these types of customizations.   

 

jeff replied on Wednesday, October 24, 2007

You could also implement a strategy pattern. ie. Define an interface such as IPackingFeeCalculator or maybe ILineItemTotalCalculator which would have a Calculate method of some kind. Then you create various implementations of the calculator such as PercentageOfQuoteTotalCalculator or MinimumFeeCalculator. Use some sort of "dependancy injection" to give the LineItem class the appropriate implementation either through the constructor or by setting a property. Or you could create as needed in the LineItem class (less testable).

One side effect of this is improved testability since you would be able to mock the ILineItemTotalCalculator and thus test isolated behavior of the LineItem class without worrying about possible bugs with the calculator classes.