[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Counting money
Ok, from what is said, I can make the following conclusion:
Any money transaction in UU may belong to one of the accounts :
a) person
b) class
c) course
Therefore, the most suitable structure for the account record is:
CREATE TABLE account_list (
al_id serial primary key ,
al_person int ,
al_class int ,
al_course int
);
I don't show foreign key here, but they should be defined for all the references {person,class,course}. Only one of the fields al_person, al_class, al_course can be NOT NULL in any given record.
If we agree on this structure, I'd add an automatic creation of account upon creation of any of: { person_list, course_class, study_course } records.
We may need some extra fields for the account records - I'm opened for suggestions. The next step is payment_history table. The draft for the structure is:
CREATE TABLE payment_history (
ph_id serial primary key ,
ph_debit_acount int ,
ph_credit_account int ,
pp_date timestamp not null ,
pp_amount decimal(16,2)
);
Foreign keys are not shown but obvious.
2007/6/8, Alexey Parshin <alexeyp@gmail.com>:
2007/6/8, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Alexey Parshin wrote:
> We currently have 1-1 relations between course and class.
WHAT???
Sorry, my bad, 1-N. There is still only one course for any class..
> So, the money can be distributed directly from class. I'm asking,
> because if we have more than two source/destination types (more than
> person and class), then it requires different structure for the
> tables. (I'm still thinking on the best implementation).
>
> 2007/6/8, Ilya A. Volynets-Evenbakh <
ilya@total-knowledge.com
> <mailto:
ilya@total-knowledge.com>>:
>
> Course accounts are needed, since course authors will be drawing money
> from them.
> There is also class->course transaction possibility.
>
> Alexey Parshin wrote:
> > First of all, I needed to confirm the 'account' entity.
> >
> > Now, as far as I see, these transactions always include to
> parties: a
> > person account and a class account.
> > A person may be one of: author, teacher, student, admin, translator,
> > or anonymous (for donations).
> > I'm not sure about course, however. I need to understand, if we need
> > other source/destination accounts (besides person and class) and
> what for.
> >
> > As soon as we have account system, the stored procs handling the
> money
> > to/from these accounts can use transaction rules.
> >
> > 2007/6/7, Ilya A. Volynets-Evenbakh <
ilya@total-knowledge.com
> <mailto:
ilya@total-knowledge.com>
> > <mailto:
ilya@total-knowledge.com
> <mailto:
ilya@total-knowledge.com>>>:
> >
> > As far as sources/destinations go, I could also think
> > of translators as destination (not sure we need it within
> > the system, but probably not much extra cost) and also
> > there is one other source - generic donation (could be even
> > from outside person that doesn't sign up to anything at all).
> >
> > Oh, and people might want to donate to Total Knowledge,
> > for writing such a wonderful system ;-) Also not sure if we
> > need to integrate that into UU itself, or just link to some
> > separate page for that.
> >
> > Now, on top of that all, we need to find a way to define
> > distribution rules/procedures for shared accounts (class,
> > course)
> >
> > Alexey Parshin wrote:
> > > Gentlemen,
> > >
> > > Since we gonna have a money traffic (well, at least for
> closed
> > > server), we need to define - what are the possible sources and
> > > destinations of these money.
> > >
> > > I can think of few sources:
> > >
> > > 1) Students are paying for class:
> > > source: a student, destination: a class account
> > >
> > > 2) Teachers are paid for teaching:
> > > source: a class account, destination: a teacher
> > >
> > > 3) Authors are paid for the authorship:
> > > source: a class account, destination: an author
> > >
> > > How does that sounds for you? This creates an entity
> 'account'..
> > >
> > > --
> > > 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
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com
--
--
Alexey Parshin,
http://www.sptk.net