Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modeling negated transactions #101

Open
gordonje opened this issue Nov 15, 2017 · 1 comment
Open

Modeling negated transactions #101

gordonje opened this issue Nov 15, 2017 · 1 comment

Comments

@gordonje
Copy link
Contributor

California campaign finance committees are required to itemize returned contributions on the same schedule that includes received contributions. The real world situation would be something like:

  • In May, John Doe gives gubernatorial candidate Gavin Newsom $1,000
  • In October, after learning that John Doe is a total scumbag, Gavin is embarrassed into returning the $1,000

In our source data, we have a line item for the original contribution and another with a negative amount for the returned contribution:

filer contributor amount date type
GAVIN 4 GOV JOHN DOE 1000.00 5/1/2017 Contribution
GAVIN 4 GOV JOHN DOE -1000.00 10/1/2017 Returned

In mapping these records to the Transaction model, my initial thought was to flip the sender and receiver and take the absolute value of the amount. So the above source records would become:

sender recipient amount date classification
JOHN DOE GAVIN 4 GOV 1000.00 5/1/2017 Contribution
GAVIN 4 GOV JOHN DOE 1000.00 10/1/2017 Returned

However, @palewire and I discussed further and decided against this approach. We're worried about the potential for inaccuracies when summing the amount field. Instead, we're planning to leave the source values more or less unchanged in loading the Transaction model:

sender recipient amount date classification
GAVIN 4 GOV JOHN DOE 1000.00 5/1/2017 Contribution
GAVIN 4 GOV JOHN DOE -1000.00 10/1/2017 Returned

Have others seen similar use cases in other jurisdictions and, if so, does our approach for fitting it into our shared models make sense?

If we agree this is proper use, then we might expand the description on Transaction.amount to say that negative numbers are allowed and why.

aepton pushed a commit to aepton/docs.opencivicdata.org that referenced this issue Dec 16, 2017
@aepton
Copy link
Contributor

aepton commented Dec 16, 2017

Added this to #104 - added an optional is_rejected boolean to the amount field, and explained in the description not to use that field if you're setting transaction values to negative for returned contribs, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants