- My Forums
- Tiger Rant
- LSU Recruiting
- SEC Rant
- Saints Talk
- Pelicans Talk
- More Sports Board
- Fantasy Sports
- Golf Board
- Soccer Board
- O-T Lounge
- Tech Board
- Home/Garden Board
- Outdoor Board
- Health/Fitness Board
- Movie/TV Board
- Book Board
- Music Board
- Political Talk
- Money Talk
- Fark Board
- Gaming Board
- Travel Board
- Food/Drink Board
- Ticket Exchange
- TD Help Board
Customize My Forums- View All Forums
- Show Left Links
- Topic Sort Options
- Trending Topics
- Recent Topics
- Active Topics
Started By
Message
re: Accounting for arbitrary/abstract "commodities" (tickets, memberships, etc)
Posted on 9/3/20 at 11:35 am to Korkstand
Posted on 9/3/20 at 11:35 am to Korkstand
quote:
My idea is to, instead of using tools that perfectly fit a given set of problems, use a more generic tool and modify the problems slightly to fit the tool. In other words, the "right tool for the job" seems to be to modify the jobs.
If a member asks me "how much do I owe, am I registered for X event, and how far am I from earning X award?", currently I have to pull up the accounting package, then pull up the ticketing tool, then pull up the spreadsheet, and then hope it's all been updated properly to be in sync. I'd like to instead reduce every event down to a simple balanced transaction and store it all in the same format to be processed by the same tool. That way I can run a status report for a given member and instantly have the answer to any question they could have.
What you need, honestly, is a membership management program. Something that can track member info, purchases, events, balances owed, etc. That type of program should be able to handle all the things you want. Many of them can also tie in with QuickBooks, so for example, when a member buys a ticket, it will not only be recorded in that program, but it will also automatically update QuickBooks for the financial information.
I also found this article, which may help you.
LINK
1
Posted on 9/3/20 at 3:20 pm to LSUFanHouston
I appreciate the suggestion and thought, and trust me when I say that I understand the effort put into all of these programs and the value that they provide. And I know that for the majority of people, this type of purpose-built tool with automation and integrations with other programs is absolutely ideal.
But for me, I am considering more than strictly financial or time costs (though these things are important given the shoestring budget). My decision includes philosophical and other, uh, unconventional factors. For instance, something that is important to me is ownership of my data. And while your QuickBooks file is "yours" and your membership data in a cloud service is "yours", if you have to rely on software or a service controlled by a 3rd party in order to use that data, it's not really yours. So maybe this is philosophy, or maybe it just stems from me being IT-minded, or both, I'm not sure.
But for me, I am considering more than strictly financial or time costs (though these things are important given the shoestring budget). My decision includes philosophical and other, uh, unconventional factors. For instance, something that is important to me is ownership of my data. And while your QuickBooks file is "yours" and your membership data in a cloud service is "yours", if you have to rely on software or a service controlled by a 3rd party in order to use that data, it's not really yours. So maybe this is philosophy, or maybe it just stems from me being IT-minded, or both, I'm not sure.
Posted on 9/18/20 at 1:34 am to Korkstand
Update for anyone who cares:
I ended up just doing the simplest thing I could think of. Instead of thinking of tickets as physical things to pass around, I'm moving the service/liability that they represent between accounts. So I just made a couple of generic accounts for "virtual" commodities, called literally Expenses:Virtual and Assets:Virtual.
So when a member registers for an event, Expenses:Virtual gets 1 EventX and Members:John gets -1 EventX (a liability, he is owed a service). Maybe a couple dozen members register and pay, then on the day of the event I make a transaction that "pays" off all the EventX's owed to members from Assets:Virtual.
Maybe it doesn't make perfect sense, or maybe it's totally arse-backwards from how this should be handled. But I understand it and it serves the purpose, I know at all times total tickets sold by event and to which members. If a member has a non-zero balance, I know he is owed services. And the concept extends to things like memberships, where a member may be owed 1 year of membership and I can automate monthly transactions of fractional memberships.
And of course it handles all the cash too.
As I mentioned, it is all plain text files, so I have it checked into a git repository. This is typically used for software development version control, but it's a great solution for any text files. I can see exactly which lines of which files changed and when, what it looked like before and after the changes, every step of the way back to their creation. It gives me unlimited undo/revert to any point in any file's history.
I'm sure you guys couldn't care less about all this, but to me this is very exciting. There is already a robust set of tools to handle all of the typical accounting reports, queries, and exports, but more importantly this system makes my accounting data programmable. There is no limit to the ways I can enter, manipulate, or view the data. Accounting is fun for me now.
I ended up just doing the simplest thing I could think of. Instead of thinking of tickets as physical things to pass around, I'm moving the service/liability that they represent between accounts. So I just made a couple of generic accounts for "virtual" commodities, called literally Expenses:Virtual and Assets:Virtual.
So when a member registers for an event, Expenses:Virtual gets 1 EventX and Members:John gets -1 EventX (a liability, he is owed a service). Maybe a couple dozen members register and pay, then on the day of the event I make a transaction that "pays" off all the EventX's owed to members from Assets:Virtual.
Maybe it doesn't make perfect sense, or maybe it's totally arse-backwards from how this should be handled. But I understand it and it serves the purpose, I know at all times total tickets sold by event and to which members. If a member has a non-zero balance, I know he is owed services. And the concept extends to things like memberships, where a member may be owed 1 year of membership and I can automate monthly transactions of fractional memberships.
And of course it handles all the cash too.
As I mentioned, it is all plain text files, so I have it checked into a git repository. This is typically used for software development version control, but it's a great solution for any text files. I can see exactly which lines of which files changed and when, what it looked like before and after the changes, every step of the way back to their creation. It gives me unlimited undo/revert to any point in any file's history.
I'm sure you guys couldn't care less about all this, but to me this is very exciting. There is already a robust set of tools to handle all of the typical accounting reports, queries, and exports, but more importantly this system makes my accounting data programmable. There is no limit to the ways I can enter, manipulate, or view the data. Accounting is fun for me now.
Page 2 of 2
Popular
Back to top
Follow TigerDroppings for LSU Football News