In views.py, we have:

note_id = int(note_id)
note = commerce.CreditNote.objects.get(pk=note_id)
current_note = CreditNoteController(note)

and

invoice_id = int(invoice_id)
inv = get_object_or_404(commerce.Invoice, pk=invoice_id)
current_invoice = InvoiceController(inv)

What would be nicer would be to go:

current_invoice = InvoiceController.for_id(invoice_id)

Which would also take care of str->int conversion.

It looks like the discounts are recalculated once per form. This feels rather inefficient.

Notes

Limits cache:

• Each user has a cache
• Can be nested; breaking out of the outermost nesting clears the cache
• Supersets for keys causes re-evaluation
• Subsets for keys returns the pre-calculated limits
• Limits can be for products, categories, or both
• Should also cache discounts
• Should also cache flagcount

E.g. purchase accommodation -> ask questions about their lodging preferences etc.

Send an e-mail when a credit note:

• Is generated
• Is applied to another invoice, or is cashed out

These e-mails should contain:

• Details about the credit note
• How to claim it
• The total credit the user has

Staff-facing reports should have:

• Ability to view as a table
  • Pagination?
• Ability to download CSV versions of the reports

All reports should have:

• Headings
• Tabular data

If you have multiple equal discounts on a product, sometimes you want to make sure that one gets offered before the other.

For example, if you have an Early Bird discount with a 200-seat limit, and an Extended Early Bird discount available to specific users, you'd like to be able to exhaust the former before making the latter available.

Two ideas:

• Upfront purchase of vouchers
  • Probably difficult, leads to reconciliation issues
• Bulk payment of invoices
  • through creating multiple payments at once (can Stripe do this?)
  • or through creating one big payment and applying credit notes (easy to do internally, but makes refunding hard)

Currently carts have:

• active
• released

Currently it's only possible for a cart to be active=False if released=True.

We should translate this to the following statuses:

• STATUS_ACTIVE for a cart that is currently active (and can have things added to it)
• STATUS_PAID for a cart that has been paid for
• STATUS_RELEASED for a cart that has been refunded

See also issue #16

• select accomodation, go '1' for that
• then go 1 sat extra night.
• then go back to the dashboard and accomodation, and make that '0',
• now my rego says 1 ticket and 1 extra accom nights (and no main accom)
• so it sprouts a 500 internal server error if i click the pay for rego button there
• so deselecting accomodation is not invalidating the things that are dependent on it

Thanks @faulteh

• Total money in (by type)
• Total money cashed out in credit notes
• Total unclaimed credit notes

Currently, the invoice_access link only allows access to the most recent unpaid invoice.

It should:

• If there are unpaid invoices, show the most recent unpaid invoice
• If there are only paid invoices, show the most recent paid invoice
• If there are multiple invoices, provide links to all of the user's invoices, allowing review and payment

If you have a mandatory ceiling for a product, then you can't use vouchers or other non-mandatory conditions to selectively enable the product. The mandatory/non-mandatory approach might need some work.

Symposion has a Conference object type, which allows proposals etc to be assigned to specific conferences. Registrasion currently doesn't make use of that object, and doesn't have an obvious UI for assigning products to specific conferences.

@faulteh notes that once you pay for your first invoice, the quantity boxes go to zero, and there's no local indication that the products you have purchased remain purchased.

Category pages should show all of the items in paid carts that belong to that category.

Currently test_flags and available_discounts get all conditions that apply to the products and categories in play, and then tests them in turn.

An alternative would be:

Put a classmethod on ConditionController -- pre_filter(cls, queryset, user). This method will return only the items from queryset that could potentially have their condition met for the current user.

We can then ask for each subclass type to filter down to all of their pre-met conditions.

In most cases, this will bulk-filter all of the conditions that may be met. The only one that's not obvious is implementing user_quantity_remaining for time/stock limit conditions.

We can now make is_met() take an extra parameter -- filtered. If filtered is true, then we only need to perform the filtering that we couldn't apply in bulk.

Attendance reports should show:

• Details for each attendee from user profile
  • (select fields)

We should be able to filter by products purchased (e.g. dinner ticket attendees are people who've selected dinner tickets)

Probably best that that weren't the case

E.g. if a user has not purchased a dinner ticket, send them an e-mail reminding them to update their dinner ticket registration.

Once you refund an invoice, it will generate a credit note. The credit note should be able to generate an invoice towards a cancellation fee, pay that invoice with a credit note, and then return a new credit note that can be returned to the original form of payment.

Go through zookeepr's admin interface and add issues for report types that we haven't implemented

In the demo, the accommodation item is presented as a 6-night parent item, with the ability to add extra nights. This is not suitable for conferences where attendees show up and leave on different days.

It should be possible to specify a check-in and check-out date, and have the individual nights added to the invoice.

At the moment everything is re-tested on adding each product. This makes testing cart category limits rather difficult, and the enabling conditions on each product gets re-tested each time. Let's make that more efficient.

The system should send out a copy of the invoice as it is generated, and it should also send out an e-mail:

• If an invoice transitions from unpaid to paid or paid to refunded
• If the new invoice voids an old invoice (e.g. by amending a registration), there should be a notification of that

If an invoice discount line applies to an item, it should include that in the description.

and there should be tests

• for set_quantities
• for validate_cart
• for apply_voucher

Currently invoices of value $0 still need to be marked as paid.

Current options:

• mark the invoice as paid as it is generated
• add an extra 'confirm registration' step (as demo site is currently implemented, this would be double confirmation?)

Noted by @faulteh

Due to @mject:

09:07 < mjec> "quantize result has too many digits for current context" with 999999
dinner tickets, 20000 t shirts and 1000 accommodation

This is overflowing the (max_digits=8, decimal_places=2) on the total invoice value.

As User Alice

• Apply the voucher (say it has limit = 1, so the voucher is now exhausted)
• Check out the current cart – A
• Buy the item discounted by the voucher
• Check out the current cart – B
• Ask for a refund of cart A -- the voucher from A is released *

As User Bob

• Apply the voucher
• Buy the item discounted by the voucher

Possible fixes:

1. Voucher discounts can only be claimed on the user's current cart?
2. Releasing a cart does not release the voucher

If a attendee completes a registration, and eventually asks to amend their registration, it should be possible for staff to:

• cancel the attendee's registration's, issuing a credit note
• re-populate the user's current cart with item selections from previously cancelled carts.

One way to do this would be to provide a staff-facing summary page, showing the user's currently-purchased items, and having check-boxes to re-add cancelled items.

1. Add a ticket with order = 20
2. Attempt to change to ticket with order = 10
3. You can't!

Suggested fix -- zero out all of the products before adding?

e.g:

• add accommodation
• submit

The "extra accommodation nights" form ends up completely empty with failed validation.

Currently, if you have a category with 30 products in it, the form gets really really long. This is the case for e.g. t-shirts, where users will only be picking one or two items.

As an alternative, we should have a form where:

• You can choose a product from a <select> field and enter a quantity
• You can press an add button to add a second type of product

Sales reports should give a report suitable for reconciling accounts. This means we should show:

• Line items for products
• Line items for discounts against products

... and these should be collapsed into (description/value) pairs.

Sales reports should show valid and unpaid invoices.

We should be able to filter reports so that they're against

• Products
• Category
• Ceiling flag/discount groups?