Module comparison
I'm not familiar with any other such pricing related modules. It seems to me that you will have to decide between these options:
- A stable module (aka the price "table" module).
- A module that's on the horizon (aka the price "list" module).
Whenever I have to decide between multiple modules, I often use the (23) criteria that I ever documented in "maintenance scorecards" (within the Community documentation). Those scorecards are actually "applied" to charting modules, but the same criteria can be used, I think, to mostly any type of module comparisons.
I'd be happy to provide some more details (via a next iteration of my answer), but if I was to decide I would definitely go for the stable, commonly used price "table" module. The major "red flag" (= no go) for the newer "list" module is criterium nr 26 (downloads vs reported installs ratio). Correct me if I'm wrong, but only like 10 % of downloads seem to have resulted in sites that continue using it.
Rules is your friend
I would definitely also consider the Rules module, using some custom Rules, something like so:
- Events = Calculate Sell Price of Product.
- Actions = calculate the price, and set the price to the calculated value.
Not sure (yet) if you'd need some extra 'Conditions' added to this.
Refer to Drupal commerce and rules: changing the product price dynamically for an example of dynamically changing product prices.
Create your own custom Rule
If for some reason you can't get it to work with the Rules module, then I'd consider writing my own custom Rule(s), similar to what is described in Drupal custom Rules how to write your own events conditions, actions and custom object.
The main steps that are detailed in this tutorial are further described below (with the code included below quoted from that link).
Part 1: Defining the Event, Condition and Action
Define the Rules Event
/**
* Implementation of hook_rules_event_info().
* @ingroup rules
*/
function your_module_rules_event_info() {
return array(
'your_module_package_bought' => array(
'label' => t('A package was bought'),
'module' => 'your_module',
'arguments' => array(
'acting_user' => array('type' => 'user', 'label' => t('The user who bought the package.')),
'package' => array('type' => 'package', 'label' => t('The purchased package.')),
),
),
);
}
Define the Rules Condition
/**
* implementation of hook_rules_condition_info()
*/
function your_module_rules_condition_info() {
return array(
'your_module_condition_package_type' => array(
'label' => t('Type of the package'),
'arguments' => array(
'package_id' => array('type' => 'value', 'label' => t('The type of the purchased package.')),
'package_type' => array('type' => 'string', 'label' => t('The type of the purchased package is')),
),
'module' => 'your_module',
),
);
}
Define the Rules Action
/**
* Implementation of hook_rules_action_info().
*/
function packages_rules_action_info() {
return array(
'your_module_action_change_order_status' => array(
'label' => t('Change the order status'),
'arguments' => array(
'order' => array('type' => 'value', 'label' => t('The order object.')),
),
'module' => 'your_module',
),
);
}
Part 2: Coding the custom Event, Condition and Action
Event:
Somewhere in your custom module, you need to include logic to trigger the event, with something similar to this example (note the your_module_package_bought in it):
//here the code for buying a package will be located
//when that code returns that a package was bought trigger the rule
$order = order_load($oid);//$oid will be the id of the order made
$package = package_load($pid);//pid will be the id of the bought package
global $user;
rules_invoke_event('your_module_package_bought', $user, $package, $order);
Condition:
To evaluate the Rules condition (to check if it is TRUE or FALSE), the function your_module_condition_package_type is executed using the arguments provided. Here is an example of how such function could look like:
function your_module_condition_package_type($pid, $type) {
$package = package_load($pid);
return ($package->type == $type) ? true : false;
}
Action:
Somewhere in your custom module, you need to include logic to perform the actual action, in this example it should be done within the function named your_module_action_change_order_status.
