You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
aepton
pushed a commit
to aepton/docs.opencivicdata.org
that referenced
this issue
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.
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 our source data, we have a line item for the original contribution and another with a negative amount for the returned contribution:
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: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: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.The text was updated successfully, but these errors were encountered: