Dates for transactions

[rverstappen]

Hi all,

Perhaps I have missed something. Is there any particular reason why there is no "effective date" field for transactions? It seems like it should be a standard field. The created_at and modified_at fields seem like they shouldn't be overloaded for this because creation/modification times are not necessarily the same thing as the transaction date (e.g., entering historical data).

Cheers,

Ron

[mbulat]

My primary reason for leaving it out at the moment was simplicity and to reduce data duplication. Additionally I wasn't sure what a transaction with a created_at date and a separate transaction or effective date would indicate. I've assumed that Plutus would be used in conjunction with some e-commerce application rather than as a standalone accounting system (like quickbooks or something), so manually entering dates didn't make sense to me. Also, my understanding is that backdating is generally frowned upon in accounting (adjusting entries should be dated/entered on the last day of the accounting period).

All that said, I'm am curious about your use case. Can you explain a little more about how you'd be using Plutus?

-- Mike

[rverstappen]

I have a loan management system which (among other things) tracks payments (principal and interest, late fees, returned checks, etc.). Since we don't go to the post office to collect checks every day, we use the day after the last mail pickup as the effective date for payments. So, a transaction may not always be "today". We may also not know about returned checks until days after the event. To the extent that these events may happen across month boundaries, not having an explicit effective date would make reports useless -- as would exporting those transactions to QuickBooks (or AccountEdge, which is similar). I also would like to use the double-entry data for customer statements, etc.

I already have Rails models for everything I need but guaranteeing data integrity with Plutus would seem to be a bonus. However, if I can't export the Plutus transactions because of date issues, then I still can't be sure that what I'm exporting has full integrity.

Off-topic: I support the idea of an account code string field, as per the topic of another thread.

Cheers,

Ron

[Michael Bulat]

Hi Ron,

So to preface this, I'll first say that I'm not an accountant, and most of my accounting knowledge comes from a semester accounting class and text book. Feedback like yours is critical to help create a system that works in the real world of accounting, but also makes it easy for developers to implement generally accepted accounting principles. So thank you! 

I have been thinking that Plutus needs some type of mechanism for making adjusting entries, and your returned check scenario is the perfect example. I'm sure you may not know about the returned checks until the next accounting period, so you'd need to go in and add an adjusting entry for the previous month, and manually overriding the created_at field does feel like a hack.

That said, I'm still unclear what you mean by an effective date. If I'm understanding your description right, you might need to implement a cash receipt system alongside Plutus. The `commercial_document` field in the transaction would be the association you could use for the receipt, which would have any data regarding the receipt of checks or cash. Transactions in Plutus are really meant to be journal entries that are usually based on source documents such as invoices, purchase order, receipts, check book stubs, etc. 

So if I were registering payments via checks that are picked up, I'd first issue a receipt for the check, noting the amount. The receipt would probably also show for what the check was a payment for. So if it's for service for last month, it would show dates for last month somewhere on the receipt (I believe this is what you might mean by an effective date?). In the accounting system, however, the transaction (i.e. the journal entry) would be entered on the day the receipt was created.

Part of my resistance to adding a date field has been that manual entry of dates for most transactions is probably not needed and might increase the likelihood of booking mistakes. Clearly for things like returned checks though, we need to be able to make adjusting entries. 

So my current thinking is that a date field is added to the transactions table. However, in the vein of Rails "sensible defaults" the transaction creation API would automatically set the date to the current day. A new "adjustment" API would be added that would allow the date to be entered manually, and mark the transaction as an adjustment. The additional date field would also provide a check that books aren't being messed with by being able to ensure that the transaction_date and create_at fields match unless it's marked as an adjustment.

Am I missing anything? Thoughts?

-- Mike

--
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.
To unsubscribe from this group, send email to plutus-gem+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/plutus-gem/-/IPmlU3nsOHUJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[rverstappen]

A returned check can be modelled outside of Plutus like anything else -- and, indeed, that's what I do. It has a date and reference to the original payment. So, it is really no different than a payment or a late fee in that regard.

By "effective date", I just mean a date that is not the "created_at" or "modified_at" date, because those are system timestamps. It may as well just be called "transaction date". It is basically the not-necessarily-today date field that we're discussing here. However, I don't see this as an adjustment in the way you describe. I see it as an integral part of the transaction and a field that I could passdirectly to the transaction build method.

I think we agree that having a date field in an export to something like QuickBooks is a desirable thing -- if not a requirement for such an export (I'm not sure QuickBooks would allow imports without a date field). If Plutus transactions don't have date fields -- or if the created_at/modified_at fields are not useful -- then every associated model must provide the same "date" method. It seems like we might be pushing a Plutus requirement into the associated models, which you would probably agree isn't ideal. Not to mention the impact of the database query on all the associated models!

On a related but different note (should it be a different topic?), have you considered adding a "reconciled" flag? I think it's related because this would allow details of transactions (e.g. dates) to be fluid until reconciled -- more like QuickBooks itself. I suspect you may have a coronary attack at that suggestion(!), but it does seem to map into real world usage.

Cheers,

Ron

 

[de...@derekunderwood.com]

I think a transaction date does need to be implemented and then exposed in a case by case basis.

By default, the system could make the transaction date the "created" or "modified" date, which seems like duplication. Or by default the system could make the field bank I suppose.

If checks are written one day (by hand) but then not entered into Plutus until a different date, which is common, then the transaction should be carrying the date the transaction took place, and not just the date it was entered into the computer. That is one example. Otherwise, reporting is not accurate if you need reporting by month or year, for example, of expenses.

I understand why this is not a field. I understand that Plutus is perhaps a part of a larger application. So, I guess a workaround is to allow a new transaction to override the "created" and/or "modified" date with a transaction date. That may be a way to handle this? Just thinking out loud...

Thanks for Plutus by the way!

[Emiliano Castaño]

I second this too.

You don't always add the transaction in your app exactly in the date the transaction occurred, ie: somebody enters all the invoices one a week in the system. Having a separate date field, could help Plutus to represent the real date of the transaction.

Kind regards,

Emiliano