search

magfest / ubersystem

MAGFest's Ubersystem - handles ticketing, staffing, analytics, volunteers, and tons more
http://magfest.org
GNU Affero General Public License v3.0
48 stars 55 forks source link

Automate tax deductible emails #2426

Open BlueHat-GURU opened 7 years ago

BlueHat-GURU commented 7 years ago

Include an automated email with the amount of extra donation that people kicked in for the calendar year.

Probably depends on persistent uber.

Might also need some calculations regarding swag vs fair market value for supporters.

@nickthenewbie1 can provide more details

binary1230 commented 7 years ago

This task has a lot of subtle backend stuff needed, very precise tax info is required to be known. It is something we need later this year, along with some reporting along the same lines. Probably doesn't depend on persistence

bds002 commented 7 years ago

Yeah as long as all applicable values are defined, the email can be sent out from individual instances.

binary1230 commented 7 years ago

(in front of computer now) more details:

This issue describes one of two related tax-related things that we need, by (I -think-) the end of each calendar year (ending Dec 31).

  1. The feature this github issue is talking about is: an automated email sent to each attendee who donated money above a certain threshold (I think $250, need to check). this serves as a non-profit donation receipt which has to have a very specific format, very specific wording from the IRS, and the money laid out in a very specific way. some tax info about this: https://www.councilofnonprofits.org/tools-resources/saying-thank-you-to-donors
  2. Related feature that we also need: https://github.com/magfest/ubersystem/issues/1919 This is a report, used by the accountants on our real taxes, which breaks down purchases made through ubersystem by some of the following ways: base price of badge, fair market value of swag, amount extra they paid over the fair market value. maybe other stuff.

BOTH of those tasks, from a technical standpoint, are pretty easy. What is challenging is that they require probably a rewrite of the underlying data structures we use to input badge prices in ubersystem.

For example, the existing way we describe a supporter badge in the INI is:

And the new way might have to be something like: supporter pack:

(I have some whiteboard chickenscratch and notes about how we might structure this data, when we're ready to work on this, hit me up and I will post it here [need to do some digging to find it])

What is also challenging is that, normally, when we open preregistration, we don't exactly know WHAT is in the supporter pack, only that there will be some random swag. i.e. at reg launch, we don't know that $40 is the fair market value. We won't know until we actually buy the stuff and negotiate with suppliers.

So changing up how this works might require us to do stuff like:

potentially related to:

One other note: I would categorize this task as critical/important (as Nick can attest having done it manually), but also, it's not as high a priority til later in the year. Still, we do tend to get busy later in the year, so it would be good to find out when deadlines are needed for 1) sending emails to attendees for this and 2) when accounting (Steph and co) need the report.

binary1230 commented 7 years ago

btw also, completing this task -might- (I'm not sure, @kitsuta is the resident expert and can say better than me) require us to do some refactoring of all the different price-related DB fields on the Attendee and Group model, like .amount_extra and other related fields.

binary1230 commented 7 years ago

continuing braindump:

my chickenscratch that no one should even attempt to read, putting here so i can braindump more info from it later: 20160829_175400 img_20160829_175655 2

binary1230 commented 7 years ago

I believe Tony have more info on the exact format of fair market vs cost of goods vs other stuff.