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.