Change Details

{T235751} introduced the requirement of having a "valuation date" for a donation that's different from the "creation date" of a donation, for bookkeeping reasons. The current database structure does not allow for an easy introduction of another field in the `Donation` entity, so we took on some technical debt and "hacked" in the requirement at the export side only, using the available payment processor metadata to represent the valuation date. This ticket is about introducing the concept to the domain. Acceptance critera: * `Donation` class has a nullable `valuation date` field that's stored/retrieved in the methods of all `DonationRepository` implementations. * When a donation is booked via `bookDonation`, it sets the valuationDate from its `paymentMethod` object (see https://github.com/wmde/fundraising-payments/pull/12) * The donation export uses the valuation date (if not null, otherwise the creation date) instead of picking it out of the payment data.

{T235751} introduced the requirement of having a "valuation date" for a donation that's different from the "creation date" of a donation, for bookkeeping reasons. The current database structure does not allow for an easy introduction of another field in the `Donation` entity, so we took on some technical debt and "hacked" in the requirement at the export side only, using the available payment processor metadata to represent the valuation date. This ticket is about introducing the concept to the domain. Acceptance critera: * `Donation` class has a nullable `valuation date` field that's stored/retrieved in the methods of all `DonationRepository` implementations. * The `spenden` database table gets a new field `valuation_date` * When a donation is booked via `bookDonation`, it sets the valuationDate from its `paymentMethod` object (see https://github.com/wmde/fundraising-payments/pull/12) * The donation export uses the valuation date (if not null, otherwise the creation date) instead of picking it out of the payment data.

{T235751} introduced the requirement of having a "valuation date" for a donation that's different from the "creation date" of a donation, for bookkeeping reasons. The current database structure does not allow for an easy introduction of another field in the `Donation` entity, so we took on some technical debt and "hacked" in the requirement at the export side only, using the available payment processor metadata to represent the valuation date. This ticket is about introducing the concept to the domain. Acceptance critera: * `Donation` class has a nullable `valuation date` field that's stored/retrieved in the methods of all `DonationRepository` implementations. * The `spenden` database table gets a new field `valuation_date` * When a donation is booked via `bookDonation`, it sets the valuationDate from its `paymentMethod` object (see https://github.com/wmde/fundraising-payments/pull/12) * The donation export uses the valuation date (if not null, otherwise the creation date) instead of picking it out of the payment data.