Designing and optimising new invoice PDFs
The Open Event project has proven to be an excellent event management application with a growing user base. With recent workflow refactors in the order process in open-event-frontend and introduction of event invoices (to be rolled out this month as a work product), the open-event-server’s invoices required a makeover. A ticket buyer is now required to give their billing information if the order is comprised of paid tickets and to accommodate this, and long information addresses, optimisation was required.
Restructuring order invoices
The new order invoices use nested tables concept instead of previously used two-cell tables. The pros of this new design is the accomodation of long-addresses and corresponding changes in billing information display.
{% if order.is_billing_enabled %} td style="text-align:center;"> table > tr > td > strong >Company :</ strong > td > td > strong >{{ order.company }}</ strong > td > tr > tr > td valign="top"> strong >Tax Info :</ strong > td > td > strong >{{ order.tax_business_info }}</ strong > td > tr > tr > td valign="top"> strong >Address :</ strong > td > td > strong >{{ order.address }}</ strong > td > tr > tr > td > strong >City :</ strong > td > td > strong >{{ order.city }}</ strong > td > tr > tr > td > strong >State :</ strong > td > td > strong >{{ order.state }}</ strong > td > tr > tr > td > strong >Zipcode :</ strong > td > td > strong >{{ order.zipcode }}</ strong > td > tr > tr > td > strong >Country :</ strong > td > td > strong >{{ order.country }}</ strong > td > tr > table > td > |
This made sure that the new orders have enough space to prevent information overflow and still maintain the original structure to give a sense of uniformity in old and new PDFs.
Generating new event invoices
The new event invoices needed an overall change in structure. They will be rolling out on 1st of every month, according to current implementation. This required an overall implementation of new invoices.
First, the published events are taken in consideration for generation of invoices for a particular user. It has been implemented as a scheduled job accordingly.
events = Event.query.filter_by(deleted_at=None, state='published').all() |
This function also required one minor modification. The function for calculating monthly revenue had to be updated as to dodge certain unseen bugs related to non completed order amount calculations hence restructuring the function as follows.
def calc_monthly_revenue(self):
|
This enabled the system to finally serve event invoice PDFs. One of whose examples are given above, With this, the open-event-server is finally able to serve event invoices accordingly which can be paid via PayPal to the Eventyay account.
Resources
Related Work and Code Repository
You must be logged in to post a comment.