Various Features

[freerobby]

Hi Michael,

Thank you very much for creating Plutus. This is the first Ruby accounting library I've seen that gets all the fundamentals of double entry bookkeeping correct. Much appreciated!

I would like to use Plutus for a real estate accounting project I am working on, but to do so I will need to make some additive changes to the library in order to accommodate my needs. I'd like to know whether these features sound like things you'd like to pull into the Plutus library proper, or whether I should fork it and maintain a separate library to suit my purposes. If you are interested in pulling my work into Plutus, I am happy to break all of this out into separate issues and pull requests; but I figured I'd start with it all in one place so as not to spam you with a bunch of issues that you may have no interest in.

Features I need (completed features as of 10/3/2015 are crossed out)

1. Generation of Income Statement (preferably HTML though I could be convinced to do PDF) for arbitrary period of time.
2. Generation of Balance Sheet (ditto HTML/PDF sentiment) at arbitrary point in time.
3. effective_timestamp attribute on Plutus::Entry so that entries can be designated as taking place at an exact time, separately distinguishable from when those entries are created and updated in the database.
4. Account#balance method to take an optional timestamp to provide the balance of that account at that exact moment in time.
5. Designation of assets and liabilities as either "current" or "noncurrent" for proper reporting purposes.
6. A simplified web form for admins to log expenses and reimbursements, without their needing to understand proper bookkeeping (i.e. maybe they describe expenses and select accounts, and we take care of credits/debits behind the scenes). This needs more fleshing out, and normally I would argue this is an application issue, but since Plutus is a Rails engine with some frontend pieces, I figured I'd ask if this is within the scope of frontend features you'd like to see.

I was wondering if you could briefly comment on which, if any of these features you'd be willing to pull into the Plutus library if I did the work for them and you found my code suitible? Again I am happy to break them out into separate issues if you prefer.

Thanks,
Robby

[mbulat]

@freerobby That all sounds awesome. Most of what you suggested has been on my wish list for Plutus for some time.

I'd suggest maybe breaking out the features into small bites, and submitting pull requests for each as you go. Let me know if I can be of any help.

Thanks!

[mbulat]

@freerobby I also just remembered that there was some talk in issue #10 about potentially adding an alphanumeric code to the account model as would be used in a chart of accounts. I'd be interested on your take on that, and if it fits in with what you are doing.

[freerobby]

Thanks, Michael. Let me check up on #10 and add my thoughts to that thread
later today.

On Tue, Jun 9, 2015 at 1:40 PM, Michael Bulat [email protected]
wrote:

@freerobby https://github.com/freerobby I also just remembered that
there was some talk in issue #10
#10 about potentially adding an
alphanumeric code to the account model as would be used in a chart of
accounts. I'd be interested on your take on that, and if it fits in with
what you are doing.

—
Reply to this email directly or view it on GitHub
#45 (comment).

Robby Grossman
@freerobby https://twitter.com/freerobby
http://rob.by

[lightningdev45]

I agree with adding an alphanumeric field by default. I am a CPA in addition to a developer, and not once have I come across accounting software that didn't give the option of assigning an account number/code. The issue of of scoping the code so that all codes for assets must fall into a certain range, etc, is a little bit tricky however.

With respect to my issue that you just closed, you mentioned you would call the new field date. I was wondering if the type was going to be a simple date or a datetime?

[mbulat]

@kempchee Nice to have a CPA giving feedback!

I was going to leave the field as a date only. I would assume that would make reporting easier, since there would be less timezone and cutoff issues? I'm also open to suggestions on the field name. All the accounting examples and other software I've seen just label it as just date, and I was leaning toward something that would be obvious for most users.

[lightningdev45]

I support that decision. I'm interested in your long term plans for this project as I have always thought the open source community needed a truly free, web based accounting software project. I'm not aware of anything like that out there. I have used GNU cash but it has an ancient UI and they made some very poor decisions imo.

[mbulat]

My long term hope was that plutus would bridge the gap between startup ecommerce apps and accounting software. At previous companies it was always someones job to translate all the web app order and sales data into the accounting systems, or there was a project to integrate data into something like NetSuite. (nightmare)

My thinking is that plutus might simplify things greatly. I could imagine a full blown accounting application that would use plutus as it's back end engine, and so integrate seamlessly with the web application. The web app would be making the correct entries at time of sale or what have you, and the CPA could have a real time view of that data within their accounting app at the same time.

At the very least, I wanted a way to allow any ecommerce app at startup to ensure it was recording transactions correctly, instead of as an afterthought. I've been at startups where the audit trail was a mess, and then doing something like receiving investment was delayed (costing time and money) because it was unclear where the money was at.

[freerobby]

This is exactly why I started using Plutus. I was using AccountEdge to
manage my vacation rental properties, and I hated porting the financials
between the app/payment processor and the accounting software. Too much
time spent doing menial bookkeeping. I've since built my own accounting
system within my web site on top of Plutus. It is rudimentary but works
very well for my tasks, generates balance sheets, p&l on demand as needed.
I assumed that Plutus being a Rails engine, rather than just a gem, was
because there are plans to move common bookkeeping/accounting tasks into a
web-based admin area. I hope to work on some of those features myself when
I have more time.

On Wed, Jul 22, 2015 at 1:40 PM, Michael Bulat [email protected]
wrote:

My long term hope was that plutus would bridge the gap between startup
ecommerce apps and accounting software. At previous companies it was always
someones job to translate all the web app order and sales data into the
accounting systems, or there was a project to integrate data into something
like NetSuite. (nightmare)

My thinking is that plutus might simplify things greatly. I could imagine
a full blown accounting application that would use plutus as it's back end
engine, and so integrate seamlessly with the web application. The web app
would be making the correct entries at time of sale or what have you, and
the CPA could have a real time view of that data within their accounting
app at the same time.

At the very least, I wanted a way to allow any ecommerce app at startup to
ensure it was recording transactions correctly, instead of as an
afterthought. I've been at startups where the audit trail was a mess, and
then doing something like receiving investment was delayed (costing time
and money) because it was unclear where the money was at.

—
Reply to this email directly or view it on GitHub
#45 (comment).

Robby Grossman
@freerobby https://twitter.com/freerobby
http://rob.by

[mbulat]

Yes, the current plan is to add a lot of the basic admin functionality, and reporting into Plutus directly. I'm not sure how it will evolve, and I could imagine splitting out a bookkeeping app into a separate project, but I'm not sure. It might do fine as a full featured accounting app as an engine.

@freerobby Do you have a fork with any of the features you've mentioned in the start of the thread? I've got some time and might start to work on them now. Any priorities?

[freerobby]

Hi Michael,

I don't yet. I began by implementing things in my application, and figured
I'd port stuff over as it crystalized in a more widely-usable way. The code
isn't robust enough as is that it makes sense to move into Plutus proper.

As far as my personal priorities, generation of P&L and Balance Sheet for
arbitrary periods/points in time would be high on my list. A safe way for
non-financial-savvy humans to enter expenses would be a close second, i.e.
name an expense and categorize it by account, but don't make them think
about credits/debits. I haven't fleshed out entirely what this second piece
would look like.

On Wed, Jul 22, 2015 at 2:27 PM, Michael Bulat [email protected]
wrote:

Yes, the current plan is to add a lot of the basic admin functionality,
and reporting into Plutus directly. I'm not sure how it will evolve, and I
could imagine splitting out a bookkeeping app into a separate project, but
I'm not sure. It might do fine as a full featured accounting app as an
engine.

@freerobby https://github.com/freerobby Do you have a fork with any of
the features you've mentioned in the start of the thread? I've got some
time and might start to work on them now. Any priorities?

—
Reply to this email directly or view it on GitHub
#45 (comment).

Robby Grossman
@freerobby https://twitter.com/freerobby
http://rob.by

[mbulat]

I've added a date field in 68aca8a. If not specified, it will default to the current date.

See https://github.com/mbulat/plutus/wiki/Updrade-Notes for notes on upgrading and copying over old timestamps to the date field

[mbulat]

Commit bcabf46 now allows balances to be calculated within specific date ranges. See README for examples. The calculations for persisted records now use the DB sum(:amount) for performance.

[mbulat]

Basic Balance Sheet and Income Statement views have been added via a45a479.

These are still super basic. @freerobby, @kempchee any feedback is appreciated.

I will probably close this issue out shortly, and open separate issues for the remaining features. I believe the remaining features are primarily around categorizing accounts and applying account codes, unless there's something else I missed.

Edit: A safe way for end users to enter expenses is still also on my list

[freerobby]

Thanks for putting this together @mbulat! I'm planning to send a couple PRs your way shortly for small odds and ends related to this stuff.