help me introduce the concept of payment to my app

I'd like some advice if poss.

I've got my app up and running and I'm very pleased. I've learned an
awful lot and learn more each day, ror is amazing.

I've got just two models in my DB at the moment - owners and properties,
an owner has many properties and a property belongs to an owner. I store
lots of things in the owner table including login information, notes as
well as the obvious stuff like name and address. A property is inactive
when first added by an owner (as it is not paid for) and later the admin
activates the property (just a boolean field that the admin can set but
not the owner). Everything works just fine and I'm very comfortable with
the existing setup (two tables built with migrations is a good way for
me to cut my teeth). As stated below I'd like to stay with two tables
for the time being (although I could be persuaded to introduce a new
model).

I've got a challenge now though that I'm not 100% sure how to handle. I
need to start recording when an owner pays. They pay per property for
one year up front. After payment the admin makes the property active.

My initial reaction is this, two new fields in the Property table -
datepaid(date) amountpaid(integer), I can then calculate a renewal date
by datepaid + oneyear. I don't mind if later on I'll be introducing a
payments history table but for now I just want a simple solution to get
me going?

I'd really appreciate any feedback.

bb

since it's a per year payment you'll definiteliy need an extra table to
handle multiple payments per property. no sense in making a 'simple'
solution if it can't even last one year.
and it's easy enough, just a table payments which :belongs_to property
(needs a field property_id) and finished with it for the next years. and
amountpaid should be float if you're not 100% sure never to get values
like 50.55

OK thanks - this is really helpful so I start to do things right. Float
is definately better (I set this up somewhere else also so I'll change
it to float there also).
I drafted the following migration, does this look about right? I always
wonder if I should be doing something in here with defaults and
allow/disallow nulls?

Would you start with what's below?, clearly I will set my belongs_to and
has_many in my models.

bingo bob wrote:

OK thanks - this is really helpful so I start to do things right. Float
is definately better (I set this up somewhere else also so I'll change
it to float there also).
I drafted the following migration, does this look about right? I always
wonder if I should be doing something in here with defaults and
allow/disallow nulls?

Would you start with what's below?, clearly I will set my belongs_to and
has_many in my models.

---

  def self.up
    create_table :payments do |table|
      table.column :created_at, :date
      table.column :updated_at, :date
      table.column :date, :date
      table.column :amount, :float
      table.column :note, :text
      table.column :property_id, :integer
    end
  end

  def self.down
    drop_table :payments
  end

---

going on from this idea is the implementation. Payments is an admin
function and is closely linked to when a property becomes active (ie
normally a payment will be received and the property will become
active). Although a property could be paid for but then deactivated for
some reason (unlikely).

Renewal dates are another concept that needs to be considered.

Am thinking of a concept where there is perhaps a boolean field in the
property table (paid_up) that is automatically set as on if there is a
payment and the payment is not more than a year old.

or it could just be a manual thing, the admin sets the active field
manually (having knowledge of payments received).....any tips (hopefully
you can follow my train of thought)?

OK thanks, I think I've got you, I think it's like this...

migration...

  def self.up
    create_table :payments do |table|
      table.column :created_at, :date
      table.column :updated_at, :date
      table.column :payment_date, :date
      table.column :paid_until_date, :date
      table.column :amount, :float
      table.column :note, :text
      table.column :property_id, :integer
    end
  end

  def self.down
    drop_table :payments
  end

model..

and then make some changes in in my model (amazingly I've not been using
this after_create method thus far, haven't seemed to need it) when a new
record is created the after_create method sets paid_until_date to be one
year from now OR if paid_until_date is not null it should set it to
paid_until_date + 1 year. phew, did i get it right?

bb

i thought this paid_until_date to be in the property table not in
payments
so you can have several payments per property and the last one updates
the property/paid_until_date

Thorsten Mueller wrote:

i thought this paid_until_date to be in the property table not in
payments
so you can have several payments per property and the last one updates
the property/paid_until_date

Yes - sorry my mistake...

I'll add paid_until_date to the property table...not payments...

Thanks for this i'm on the right track,

One last thing, can you help with the syntax for my after_create method
- it goes in my payments model i assume, and does after_create
(property/paid_until_date by one year)?

I'll implement this tonight after work :->

One last thing, can you help with the syntax for my after_create method
- it goes in my payments model i assume, and does after_create
(property/paid_until_date by one year)?

I'll implement this tonight after work :->

this would be like that (yes, in payment model)

after_create :update_paid_until

def update_paid_until
  # check if paid_until_date is nil, then today + one year
  # otherwise paid_until_date + one year
end

bingo bob wrote:

an owner has many properties and a property belongs to an owner. I store
lots of things in the owner table including login information, notes as

Will owners ALWAYS be the only users logging in? It won't be worth
adding the complexity of having a User model (and code) if so, but if
other user types need to login in the future, the Owner model will have
to be refactored to move the User behavior into a separate model.

Thanks for this yesterday.

I'm there I think on the model setup and such like, the belongs to and
has many relationships are in place and the property_id column. The
action after the create is there in my payments model with dummy code
for the time being.

Trouble is, I can't see how to implement this in my controllers...

I generated a scaffold for payments, ./script/generate scaffold payment,
which clearly gives me a payments controller with CRUD actions and the
views for these.

Trouble is, I can't quite see where I make the link between the property
and payment (I mean I've done it in the models but I need to tell the
payment which property the payment is for when I create or update)?

If anyone can provide a simple example of some controller code to add a
payment to a property I would be very grateful.