How to design such system to enforce regulations of a deal?

[Adrian Burlington]

I’m trying to create a ‘Check Comm Box’ where I check and fix the commission taken by a dealer. Check dealer's commission vs the amount of money offered by Honda.
I’d like to know how I should confront this challenge and would appreciate your input.

This is how it goes: Honda gives its dealers special DEALS where they can sell their cars and get a very nice commission.
The commission the DEALER can take is subject to the REGULATIONS or CRITERIA of a DEAL.

Example:

Deal 10001:
Dealer can take 10% commission if:
Criteria:
1. Sale date between 1-jan-09 and 10-jan-09
2. Car is either TYPE_1 or TYPE_2 or TYPE_3
3. Car’s engine is E_1 or E_2
4. Payment is not with AMEX

Dealer can take 8% commission if:
1. (same as above but) Car’s Engine is E_3

Deal 10002
Dealer must return to HONDA $30,000 and take any $ above this amount (eg., if sold car for $34,000 he gets $4,000)
Criteria:
1. Sale date between 05-Jan-09 and 22-Jan-09
2. Engine E_3
3. Car is TYPE_2


Scenario 1: Dealer sold a car on 2-Jan-09; car type_1 and engine E_3, paid with VISA and took 10% commission.
Expected Result: The Check Comm box should LOWER the commission to 8% and ask the dealer to return 2%

Scenario 2: Dealer sold a car on 5-Mar-09 with E_1 and T_2, paid with VISA and took 10%
Expected Result:: no commission – because he doesn’t have a deal for this period

Scenario 3:: Dealer sold a car on 6-Jan-09 with E_1 and T_2, took 10% and paid with AMEX
Expected Result: no commission – Paid with AMEX

Scenario 4:: Dealer sold a car on 6- Jan with E_2 and T_1 for $36,000 paid with VISA and return to Honda 30,000; took 20%
Expected Result: Good transaction! Valid on deal 10002 (on deal 1001 he would have received 10% from the sell but since there are 2 overlapping deals and 10002 is better – he can take whatever he wants above $30,000)

As you can note, there are the following:
Deal with criteria(s),
Different dealer
Car’s properties (engine, type, payment_type, sell date...etc)
Commission-correction-box

* criteria will be changed in the future (more will be added) to the deal,
* different deals will be given on periodic basis (deal can overlap)
* There are hundreds of deals and thousands of dealers.

Thank you for any comment and input.

[David Newton]

Moving per OP's request.

[Jimmy Clark]

Looks like a homework assignment. Good luck!

[Paul Clapham]

To me it looks ugly in the right way to be real life. But I'm not sure what's being asked here. Are we being asked for architectural ideas, like whether these deals should be stored in a database versus something else? Or do we already have the deals stored in some place we haven't been told about, and the question is how to apply them to the dealers' orders?

If it were me, and I were being asked to design this system from scratch, what I would be doing now would be going through all the past and current deals to identify the salient features of the deals. I would also be interviewing the people who invent the deals to estimate the probability that deals with new features would be appearing in the near future. Probably I would have in the back of my mind the idea that the deals would be in a database eventually, but I wouldn't be married to that idea. I wouldn't be thinking about programming just yet.

[Adrian Burlington]

Thank you Paul for your input.

The numbers given in the example are off (far from the truth), but this is a real life application. Per my request, I'm looking for how to confront this challenge in terms of architectural design. Yes, there's a db but it should not be a concern as I'm looking more at the 'checking mechanism' of the system.

I'm not yet in the programing stage, but I'm past the interviewing part. Again, I wish to know how one will create such a 'check' and deliver a GOOD/NOT GOOD 'transaction'; plus how to have a 'deal' more flexible by adding /removing criteria.