{% extends "attendeereg/base.html" %} {% block styles %} {% endblock %} {% block content %} {% load adminmedia %}{% load attendeereg %}

{{ title|escape }}


Contents

Double Billing ({{ double.count }}) contents

These are Invoices with multiple PayPal Silent POST ACK's. These are most likely double billings due to the user reloading the browser at the wrong time or checking out twice. You should check the ACK in the admin to make see if the result codes are all '0' and if they are, contact the Treasurer and person immediatly to set up a refund of one of the ACK's. {% for invoice in double %} {% endfor %}
Invoice Cost Name Created Updated Notes Acks
{{ invoice }} ${{ invoice.total_cost }} {{ invoice.user|escape }} {{ invoice.created|date }} {{ invoice.updated|date }} {{ invoice.org_notes|escape }} {% for ack in invoice.paypalack_set.all %} {{ ack.PNREF }}({{ ack.RESULT }})
{% endfor %}


Multiple Non-Invalid Invoices ({{ multi_inv.count }}) contents

Users with Multiple Invoices. A user might have multiple invoices due to registering multiple people in separate transactions, due to a failed attempt, or have some partial invoices for a partial refund or partial payment. The users with multiple Paid Invoices are the ones to be concerned about, as these could be double billings. Only those users with multiple non-invalid invoices are shown. {% for usr in multi_inv %} {% for invoice in usr.invoice_set.all %} {% if not forloop.first %}{% endif %} {% endfor %} {% endfor %}
UserInvoiceStatus CreatedUpdatedNotesRequests
{{ usr }}
{{ invoice }} {{ invoice.get_status_display|escape }} {{ invoice.created|date }} {{ invoice.updated|date }} {{ invoice.org_notes|escape }} {% for req in invoice.changerequest_set.all %} {% if not forloop.first %}
{% endif %} {{ req.text|escape}} - {{ req.created|date }}{% endfor %}


Multiple Registrations ({{ multi_reg.count }}) contents

Users with Multiple Active Registrations. This can happen due to a person registering, and then thier company registering them. They could also have also checked out twice. This table should always be 0. If there is an entry, there is work to be done. {% for usr in multi_reg %} {% for reg in usr.registration_set.all %} {% if not forloop.first %}{% endif %} {% endfor %} {% endfor %}
UserRegistrationStatus InvoiceInvoice Status Additional InfoNotes
{{ usr }}
R{{ reg.id }} {% if reg.paid or reg.active %}{% if reg.paid %}Paid{% endif %} {% if reg.active %}Active{% endif %}{% else %}Not an active registration{% endif %} {% if reg.invoice %}{{ invoice }}{% else %}(None){% endif %} {% if reg.invoice %}{{ invoice.get_status_display|escape }}{% endif %} {{ reg.extra_info|escape }} {{ reg.org_notes|escape }}


Change Requests ({{ change_requests_unhandled_count }}/{{ change_requests_count }}) contents

Change Requests by Invoice.
{% regroup change_requests by invoice as groups %} {% for group in groups %} {% for request in group.list %} {% if not forloop.first %}{% endif %} {% endfor %} {% if forloop.last %} {% endif %} {% endfor %}
InvoiceNameStatus[X]RegRequestorCreatedRequest
{{ group.grouper }} {{ group.grouper.user|escape }} {{ group.grouper.get_status_display }}
[X]{% else %}>{% endif %} {% if request.reg %}R{{ request.reg.id }}{% endif %} {{ request.user|escape }} {{ request.created|date }} {{ request.text|escape }}


Lost Invoices ({{ lost_invoices.count }}) contents

PayPal Silent POST Ack's with an INVOICE field, but not tied to an Invoice object. This is more of a data corruption problem. This can happen if we delete an Invoice in the DB for some reason (after the testing period, this should never, ever be done). If for some reason it does happen, we should track down the information, create a new invoice, and connect it to the ACK. The 'INVOICE' field should remain with the old id, while the 'invoice' field should point to the new invoice. {% for ack in lost_invoices %} {% endfor %}
PNREFINVOICECreatedIPNotes
{{ ack.PNREF }} {{ ack.INVOICE|escape }} {{ ack.created|date }} {{ ack.ip }} {{ ack.org_notes|escape }}


Pending Refund ({{ pend_refund.count }}) contents

Invoices marked Pending Refund. We may mark an invoice as pending refund as part of a partial refund (which should refer to the invoice and registration being refunded). When Kurt processes the refund, then it is marked refunded. It could also be for an invoice which we got a request for a full refund on, but Kurt is otherwise unavailable (or maybe its a check refund). This way the Invoice owner knows we got the request and are working on it. If this table is not empty, then there is work to be done by someone. {% include_invoice_table pend_refund %}

Pending Manual Payment/Change ({{ pend_manual.count }}) contents

These are Invoices people are paying by check or have requests for special payment handling. People who are requesting a free registraiton should have that information as a change request or as additional info on the registration. We would like this table to be empty, but check processing makes that difficult. At least it should be empty of all Invoices/Registrations requesting comp's (unless they are determined not to deserve a comp). Remember to reset to Allow Checkout after updating the Invoice. {% include_invoice_table pend_manual %}

Pending PayPal Silent Post ACK ({{ pend_ack.count }}) contents

This table should be empty (yea right...) These are the problem Invoices. These Invoices are stuck in limbo. Check the psf-donations mailing list to see if they actually paid (there will be an e-mail from Kurt with the Invoice ID and PNREF/OrderID in the subject). PayPal might take up to 30min to process a transaction after sending the payment e-mail, but after that, they need to be manually processed. If they have not been paid and there is no change request after a few hours, then we need to contact the invoice owner and find out what happened. The Invoice owner can not pay for this Invoice in this state. It needs to be Invalidated, or set back to Allow Checkout. If you do not hear back from the invoice owner in a week, then invalidate the Invoice. Otherwise we could run into problems with over booking tutorials. We will need to be more strict the closer we get to the conference. {% include_invoice_table pend_ack %}

Refunded Invoices ({{ refunded.count }}) contents

These could be full or partial refunds. These invoices represent money we returned to people. {% include_invoice_table refunded %}

{% comment %}

Invalidated Invoices ({{ invalid.count }}) contents

These are invoices which have been canceled and were never paid for. {% include_invoice_table invalid %}

{% endcomment %}

Invoices reset to Check Out ({{ checkout.count }}) contents

These are invoices which the person can now re-checkout. these are in limbo as far as tutorial registrations are concerned. {% include_invoice_table checkout %}

Unconnected Registrations ({{ unconnected.count }}) contents

These are Registrations which are not for the Invoice user, and are not connected to a django login yet. That is, these registrants have never logged in, and we do not know for sure the e-mail address is correct. They could also be speakers which we think are not yet registered. {% for reg in unconnected %} {% endfor %}
RegNameStatusInvoiceInvoice StatusCreated
R{{ reg.id }} {{ reg.name|escape }} {% if reg.paid or reg.active %}{% if reg.paid %}Paid{% endif %} {% if reg.active %}Active{% endif %}{% else %}Not an active registration{% endif %} {% if reg.invoice %}{{ reg.invoice }}{% else %}(None){% endif %} {% if reg.invoice %}{{ reg.invoice.get_status_display|escape }}{% endif %} {{ reg.created|date }}
{% endblock %}