Welcome to Rails!
Your first question seems first like a modeling question. It seems to me you want two tables. Debts and Payments. In your debt model, you would declare has_many :payments, and in the payment model you declare belongs_to :debt. This implies that the payments table has debt_id field that associates each payment to a single debt. Of course if payments can be applied to multiple debts then this breaks down and you would need to use a third table.
The key bit here is to learn how ActiveRecord Associations work and what they provide for you. For instance, with that structure you could do Debt.find(:all, :include => :payments) and it would automatically LEFT JOIN the payments and return the debts and all their payment objects in one query. However if you only need the total, it would be more efficient to set up a specific query using SUM() and GROUP BY clauses to return just the data you need. ActiveRecord supports this by allowing you to pass in the contents of each clause in the find options (select, joins, conditions, order, group, limit and offset).
As to your second question, what you are referring to as a global variable sounds more like a session variable (both in PHP and Rails). Your controller should initialize the session variable to its default. The menu would be set up as a select menu in the view. However, if you are re-using this menu in multiple views than I suggest making it into a helper. If you are using declarative scaffolding (ie. scaffold :model_name in your controller) then you aren't going to be able to edit anything. Instead use the script/ generate scaffold ... command from a terminal to generate the code so you can modify it. One thing to keep in mind is that controllers and views are tightly coupled--it's more of a judgement call where to put things. Models, on the other hand, should be completely decoupled. That is, you should be able to use all your model code directly from the console (script/console) without any need for the rest of the Rails environment.
I realize there are a lot of pieces to figure out here, but stick with it. The key to the Rails way is knowing the purpose of each component and where code best fits. Past experience developing web applications will help because you understand what needs to be done behind the scenes.