Re: Super flexible class subscription implementation

["Alexey Parshin" <alexeyp@gmail.com>]

We skip the payment phase means:

1) there is no payment processing in UI
2) since 1) there is no call to payment_register() in database

2007/6/23, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com>:

Alexey Parshin wrote:
> The payment phase is only necessary, if the required funds is more
> than the balance on student's account (that is always >= 0). If the
> course price is zero, then we just skip payment phase and call
> confirm_order() and class_subscription_confirm().
"We" - UI, or "We" - database?
>
> 2007/6/23, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     So, until class_subscription_confirm is called, it will not become
>     valid.
>     Now, class_subscription_confirm will be called only after payment.
>     What do you expect to happen in UI for non-payment classes?
>
>     Alexey Parshin wrote:
>     > I've just finished basic testing of the new class subscription
>     > implementation.
>     >
>     > Now, the subscription of a person for a class has two parameters:
>     > start_date and end_date, as discussed earlier.
>     >
>     > The subscription rule implementation is totally changed. The process
>     > is now more complicated, but much more flexible.
>     >
>     > The subscription rule is a record that defines title,
>     description, and
>     > subscription method (a stored proc implementing subscription
>     > algorithm). The subscription rule record may optionally have
>     > subscription_parameter_template child records. Every parameter
>     > template record defines parameter name, parameter type (a
>     reference to
>     > parameter_type table) and "required" field indicating if that
>     > parameter must be defined. Parameter type defines a type name and
>     > "input_type" that should contain interface-specific HTML/JS code
>     > needed to present and validate that type.
>     >
>     > The subscription process goes through three stages:
>     >
>     > 1) The subscription is requested from the interface. The selected
>     > class is used to get subscription_rule method (subscription
>     algorithm,
>     > stored proc name) and class subscription parameters (if any) form
>     > class_subscription_parameter. A subscription_order record is created
>     > with person id, and class id. The subscription parameters define
>     > amount, start_date and end_date. Order has 'opened' state.
>     >
>     > 2) The payment amount (or more), defined in subscription_order,
>     should
>     > be paid through external system (outside of the database), and
>     > registered on user account with register_payment() stored procedure.
>     > This creates credit on user account in the database. The
>     > order_confirm() proc is called to celebrate this step switching
>     order
>     > to confirmed state.
>     >
>     > 3) The class_subscription_confirm() is called to find the confirmed
>     > order, register payment from user account to class, and include user
>     > into the students group of class he is subscribing to. That
>     > automatically closes the order.
>     >
>     > The described scenario is used in subscription_rule_functions_test()
>     > (in file procs/subscription_rule.sql) to illustrate the whole
>     process.
>     >
>     > Here are some examples of the subscription rules (already
>     implemented).
>     >
>     > 1) The basic subscription rule 'Free subscription' contains no
>     > parameters and needs no record in
>     subscription_parameter_template. The
>     > subscription algorithm is implemented as class_subscribe_free()
>     > function in file procs/06_subscription_rules.sql.
>     > 2) The basic subscription rule 'Single payment subscription'
>     contains
>     > one parameter (Subscription Price) and needs one corresponding
>     record
>     > in subscription_parameter_template. The subscription algorithm is
>     > implemented as class_subscribe_single_payment() function in file
>     > procs/06_subscription_rules.sql.
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

-- 
Alexey Parshin,
http://www.sptk.net