How would you handle accounts for lots of clients?

[hadees]

So I'm new to Double-entry bookkeeping and I'm also new to this Gem.  In the app I'm writing we are middle men so we take in money from a bunch of ad companies, take our cut, and pay out our money to a bunch of publisher companies.

Should we have a separate Liability for all publisher clients?  It seems that way to me so we know how much to pay each of them.  Do all the ad companies get their own asset?  Or is the idea to have more generalized books and just use the description to query?  If I do have to create one for each publisher and advertisers how do I associate their models to their account?

Additionally what happens if I need to create more accounting books I know you say do it in seed but can I do it after too?

Thanks!

[mbulat]

So first a disclaimer... I am not an accountant (IANAA)  =D

But yes, I would think you would want separate accounts for each of your publishers. In our system we have separate revenue accounts for each of our products that we sell. Each of those products is associate with the account via the following on the Product model:

belongs_to :account, :class_name => "Plutus::Account"

The tutorial is pretty vague with how to set up the accounts, and eventually I'd like to have more specific examples and better accounting tutorials in the wiki or a site. 

In general I think you want to be pretty specific with your accounts. For example you'd want a separate Asset per bank, or credit card merchant (ie, "Cash at Bank of America", separate "Revenue" accounts per product (ie "Widget Sales"), etc. Obviously it's much easier to roll up specific accounts than to try and separate transactions later.

You can create the Accounts at any time in code or migration. I'd probably create an associated account in whatever script or page creates the publisher in your system.

-- Mike

[ezmend]

Hi Mike:

I have a similar objective to parent, with the difference being that I need to have multiple accounts per customer- not just a one to one mapping. So on my customer model I'd have has_many :accounts... In my scenario, the customer is a club member who has monthly dues as well as other one off payment obligations to the club throughout the year.  Having separate (multiple) accounts allows for better reporting (done monthly), where members can see a breakdown of where they are owing instead of one summarized liability figure (hope I'm being clear).

The first challenge I'm seeing is the establishment of a one to many relationship between customer and accounts.  I guess I can modify the accounts table with  member_id(customer_id) foreign key.

Secondly, there would be two approaches to implementing such a scheme: a) "Sub-ledger" accounts -  like what you have described here or b) separate "mini" chart of accounts for each customer/member

With b, it seems transactions that affect both club and member would need to be done in two legs.  Eg. in the case of a invoicing for monthly dues...for club dr AR, cr Revenue and for member dr Expense cr AP.  Can these transactions be achieved while adhering to ACID- specifically, the Atomicity part?  Don't think I would have this problem with approach a, though, since it could be acheived in one leg: dr member's AR sub-ledger a/c and  cr member's sub-ledger Revenue a/c .

This all might be confusing as am not an accountant myself but any guidance will be appreciated.

[Michael Bulat]

Hi,

What your trying to do sounds better accomplished with a billing/invoicing system in addition to plutus.

Businesses typically keep track of all of a customers purchases through the use of invoices and receipts and other "commercial documents". Back in the day, the accountants would translate all these items into transactions in the accounting books. In other words, invoices/bills are customer facing, whereas Accounts are private to the business.

For you, I would suggest keeping track of the various payments in something like an Invoice class. You can have LineItems for these, as well… so many-to-one LineItems to Invoice for example. Then Customer would have one-to-many Invoices.

Each LineItem could have an account associated with it, or a Product that has the account associated with it.

For example, you might have a "Monthly Billing" product, which would have a one-to-one association with some Revenue account, and additionally a "One off payment" product which would be associated with a different Revenue account.

So your relationships might look like

Customer (has_many ->) Invoices (has_many ->) Line Items (belongs_to->) Product (belongs_to ->) Plutus::Account

So when you generate your Invoice, you look up the Plutus::Account for each Product, and then create the Plutus::Transaction and associate it with the Invoice as the `commercial_document`.

In any case, I wouldn't suggest using plutus to keep track of customers' billing and payments. Plutus really should be seen as a traditional accounting system that tracks the business's internal financial situation.

--
Michael Bulat
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

> --
> You received this message because you are subscribed to the Google Groups "plutus-gem" group.
> To post to this group, send email to plutu...@googlegroups.com (mailto:plutu...@googlegroups.com).
> To unsubscribe from this group, send email to plutus-gem+...@googlegroups.com (mailto:plutus-gem+...@googlegroups.com).
> To view this discussion on the web visit https://groups.google.com/d/msg/plutus-gem/-/gnggSlw5DDMJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Patrick Ribeiro Negri]

Hey Mike, i didnt understud the "belongs_to" line. What that means? (Not the AR thing).

I dont understand why i would put a belongs_to :account in a Product model. Can you elaborate?

Thank you! We are doing lots of tests with this gem.

[mbulat]

Sure... it's just a way of associating a type of product that you might sell with an account of some type. So perhaps you have a "Widget" product, and you associate it with a "Widget Sales" Revenue account. And then you have a "Gadget" Product associated with a "Gadget Sales" Revenue account. That way when you sell the item you know which account to credit.

You can also associate any model with multiple accounts that way you could keep track of both expenses and revenue for instance with something like:

class Product < ActiveRecord::Base
  belongs_to :revenue_account, :class_name => "Plutus::Account"
  belongs_to :expense_account, :class_name => "Plutus::Account"
  ...
end

Obviously, it's all highly dependent on your business, and Plutus attempts to be as flexible as possible for different business models. 

-- Mike

[Emiliano Castaño]

Mike, thanks for this amazing gem.

I'm writing here because I'm not sure why in the case of transactions you allow to have a polymorphic association for comercial documents, but in the case of accounts, the other models should belong to the account. Why you opted not create also a polymorphic association for accounts? (Please bear in mind, that I'm asking to really understand your thoughts and I'm not in any way complaining).

Kind regards,

Emiliano

[mbulat]

Hi Emiliano, 

The primary reason is that Transaction has a "belongs_to" relationship with CommercialDocuments, whereas Account has a "has_many" relationship with other models. Rails only supports polymorphic associations on "belongs_to" relationships. This is due to issues with mapping an inheritance model to a relational database.

To be a little more explicit:

Transactions are one-to-many with CommercialDocuments. Since a Transaction can only belong to a single other Commercial Document, a polymorphic association is needed to permit different models. In addition, since the foreign key to the CommercialDocument is kept in the Transaction table, it's possible to keep that id, along with a "type" column to tell Rails which table to lookup for the commercial document.

With Accounts there is a many-to-one relationship with various other possible models. The foreign key of the Account is then kept among the other possible tables. So a single relationship definition would be unable to supply Rails with enough information on what other tables to query. To handle this, you can subclass the other models to have a "belong_to" relationship with an Account, ie:

class Product < ActiveRecord::Base

  belongs_to :account, :class_name => "Plutus::Account"

  ...
end

class Widgets < Product
end

class Things < Product
end

Since Plutus can't know what those tables will be, and there's no "polymorphic has_many", you'd need to add these into Plutus on your end. A solution to this would probably be to create your own model that inherits from Account, and add your "has_many" relationships there. 

Here's a diagram of the relationships described above for reference:

Hope that clears things up. :)

-- Mike

[Emiliano Castaño]

Thank you very much for your explanation, it was really clear!