plan of action with v bundles

[Luis Cordova]

i need advise on how to use the v bundles

i am basically having a collection of licenses created with certain type

those would be i guess my product items

so i need to run a calculator

add their prices

and add tax and substract unit discount

and add any monthly other charge

so to get a total monthly

how can i achieve this with v bundles?

just need to make up a plan

anyone could point me in the right direction please? thanks

[Richard Shank]

I would say that each license could be a product. you could use the cart to do the calculations. some of the work that has been done recently on the pricing context could help with the various rules concerning taxes and discounts. With the pricing context you can deal with bulk discounts. The monthly total would be in the cart and the cart would become an order. In this case a recurring order, so there would need to be some billing information and rules that worked with that.

[Daniel Kucharski]

As Richard points out, a license would be a specialised product type.  

However you need to be aware that there is a difference between a cart product and the installed (base) product of a customer.  When a customer is ordering an license the actual license key doesn't need to exist.  It's only upon fulfilment of a cart that you'll most probably generate a license key for the customer.  This means you'll need to keep track of an Installed Base of your customer: the collection of licenses he has.  

We don't have a interface for a install base product yet but I imagine we could have such an interface an base class in the core; It would need to relate a customer (PartnerInterface) to a virtual product and meanwhile keep meta data about this particular customer product.  Example is a license key and expiry date of the license.    In a web hosting context the installed base could be a VPS server of a given type.  The meta data could then include information such as the IP address.   Moreover the Installed base could be used to track consumption of the given product (eg.  monthly traffic of a server) and be used for billing.

This brings me to an important question:  does one needs to bill by a (sales) order or by active licenses a customer has?   Both options have an impact on your design.  

If you would require billing by active licenses, check out my thoughts on billing here: https://github.com/inspiran/VespolinaBillingBundle 

If your requirements hold billing by sales order, you'll need to implement a concept of a recurring sales order which seems obvious but isn't the case.

In both cases you'll need to create a sales order to register customers demand.  With the former you start processing payments async from the sales order (it will be managed by billing requests for which you track if they are paid) whereas with the latter you'll have complex logic to manage the current state of the sales order (eg. when is a sales order considered overdue? ).   What if you have a new license?  you'll need to create a new sales order. If a customer has three licenses coming out of two sales orders and you need to request payments, you'll need a way to group them together to offer it to the payment gateway (less transactions = cheaper).

[Luis Cordova]

`This brings me to an important question:  does one needs to bill by a (sales) order or by active licenses a customer has?   Both options have an impact on your design.  `

I think it is blur to me the difference, i think it is both because 

there can be upgrade payments, as we upgrade accounts with different levels

so customer has types and it encloses the business rules that get affected when you do an upgrade from user basic to pro for instance

So all in all for this part we have both, we need to bill by sales and by active licenses a customer has.

============================

So the `Installed Base of your customer: the collection of licenses he has.  `

Is a class InstalledBaseProduct or just InstalledBase that keeps tracks of what it is configured by the customer on checkout or keep tracks of what he already has? I did not have that clear.

Also you mentioned `to a virtual product `:

interface InstalledBaseInterface

{

    function getLicenseCollectionConfiguredWithoutKeys();

    function getLicenseCollectionUserCurrentlyHas(); ?

    function ....? metadata?

// I guess the implementation has the info upon fulfillment/installation?

    function getCustomer();

    function getVirtualProduct(); ?

}

============

`In both cases you'll need to create a sales order to register customers demand. `

I take this above to mean that the creation or processing of sales order is to tie a cart/order to a given user?

================

So how to implement with which services or managers (business rules, i am using Ruler from bobthecow) ?

class SalesOrder

{

    const STATE_OVERDUE = 'sale overdue';

    const STATE_PREPARING = 'sale preparing';

    const STATE_OTHER = 'another state';

    

    function getStateOfOrder();

}

==============

your last comment was on a say a grouping of transactions, this i guess will be in the case when we don't charge the customer upon getting the license but after the batch process for the monthly cycle runs, is this what you mean to save in transactions?

I wonder how much do we save on transactions if we have a considerable amount of users or such other factors.

Encouragements

cordoval /o/

let's go vespolina community!

[Luis Cordova]

One other question we are looking into not storing CCs and having a system do it for us like authorize.net or other bank system

do you recommend certain path for approaching this?