Sector(s)
Wards Transportation is a shipment & transportation management company and this project was to create the full blown back office management system for their business. This includes creation of shipment (called as jobs), manifests, connotes, scanning of barcodes feature, integration with quickbooks API and a host of other features. A systematic transition from one phase to another needed to be achieved which helps out in smooth transit between different branches, along with the detailed record keeping and job sheet creations through barcode scanning feature which we implemented.
About the project
Goals
The main goal of the project was to build a complete back office management system for the client's growing transportation and shipment business. This would need to accomodate literally everything they do in their day to day business, which till that time would happen in pen and paper mode, and they wanted to convert this to web based handling which they could then use in their various branches and check points. The feature set needed were job creation, price calculation based on set pricing and weight rules, branch to branch transition, connote and manifest creation, PDF generation, barcode scanning and quickbooks integration. The project was huge, and there were complications at various levels, which out team discussed through during the discovery phase. We spoke to client, got clarity, made suggestions and finally came up with a working plan.
Requirements
Job Creation
The basic unit was called Job. This would contain Customer reference, Sender and Origin Branch Reference, around 42 fields conditionally displaying which collected various information about the job and later helps in tracking and finally a field collection with the actual job items. The most complicated part was the validation and calculation. Each job item, based on the selected pricing plan, and weight mode, needed to be validated against a set criteria and price needed to be calculated through AJAX. Forms API, Field API, AJAX API and Validation handlers we heavily utilised and every single logical channel was handled with care keeping the performance parameter in mind. The Client wanted each calculation and validation to not take more than a few sec, and we needed to implement heavy performance tuning in order to achieve this.
Customer Creation
Customers were referenced at various points in job creation - Customer, Sender & Receiver. The Customer content type had about 54 fields, taking inputs on various information about the customer. It was neatly organised into various tabs through field collection tabs and field collection ajax modules. To a customer, there would be a few pricing plans attached, which would decide how the pricing rules will be applied to the jobs.
Pricing Plan Creation
The pricing plan content type was designed to add prices. In addition to some fields collection general information about the plan it was of 2 main types. Pricing by Weight and Pricing by PL SPC. So it will have rows, for each row, you mention sender and origin branch and then you set price by PL SPC and/or weight. When you set prices, you would need to set it in chunks, say 0 - 10, 10 - 20, 20 - 40 etc. When a pricing would be calculated, in the Jobs content type, the weight, origin and destination branch would be passed and the right price will be returned. This was very very complicated mechanism, and needed huge amount of calculation and validation checks.
Getting Jobs, Customers & Pricing to Play Well Together
These 3 entities needed a lot of co working. Jobs is where these 3 things integrated. In Jobs you would select customer, from customer, pricing plan would be deduced and combining it with sender and receiver branch and weight ranges, price would be calculated. There were several other conditions, like once automatic calculation kicks in, use can override the value through manual entry, but then a marker need to be set, which would show up during the job view. Safe to say, these three things were extremely complicated part of the project, but other features were not too far behind!
Manifests & Connotes
When a Job passes from branch to branch, various manifests and connotes were created. Each manifest and connote can hold multiple jobs as a part of the shipment. We employed and created a full blow custom field type and custom selection widget for this as client had in mind a very specific way of doing this, and we were to do it exactly like that.
Job, Manifests, Connote PDF Generation
At each stage, Jobs, Manifests and Connotes needed to be exported as PDFs. These PDFs needed to look exactly like what they used to use, which was detailed tabular structure and a custom bar code printed against each. We made use of MPDF library with some patches and custom enhancements in order to set certain style elements into the PDF. The process if setting this was very time consuming and complicated, but we managed it very well in the end.
Bar Code Scanning
Client wanted a mechanism through which, the PDFs generated would need to be scanned, and there would a interface, which would allow bulk updating of certain properties. For example, client would open the interface, scan a few manifests and connotes and then mention what change was needed, for example updating the branch and check in status. Once done and saves, all those properties for the manifests and connotes for which barcodes were scanned would update all together. This was again a very complicated process.
Quickbooks Integration
Finally, the entire system was to be integrated with the Quickbooks software which the client used to keep his finance and accounts. This means export of customers, pricing plans, jobs pricing and status, connotes and manifests data. This was again a huge and very lengthy task, which we need to custom code the API and finally check and fix the calculation errors through a det of dummy data. The nature of the data was very varies and there were an extremely large number of parameters that needed to be taken into consideration.
Admin Management Screens for Customers, Jobs, Pricing Plans, Manifests and Connotes
Client needed a detailed management area where they could view these data based on certain filters and complex combination of display parameters. For example, jobs which passed a certain date would be colour coded for better display and filtering.
Outcome
This is a very complex project, and as they say, more the complexity, the sweeter the success tastes. We were finally relieved to see that the client was extremely satisfied and pleasantly surprised as some of the features that we implemented, the client was not even sure that it could be implemented in a usable fashion. End result, happy customer and happy us!
Why Drupal was chosen
Well, to be honest, the features as mentioned were extremely complicated. It needed a very powerful field API as there were extremely large number of fields and to be rendered in a very complicated fashion. Also, it needed an extremely vast array of validation criteria and calculation processes for various fees calculation and weight management matrices. Hence, Drupal with it's great field API and contributed field modules plus the power of ajax and forms API were primary reasons we suggested Drupal to the client. The frontend site of this project was already in Wordpress, and we decided to keep it as it is. But for this back office (which would be another site/installation), client approved Drupal as the framework.
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
This project was mainly a lot of custom code, most of the logics, functionalities have been custom coded. So not many modules were used. Only thing majorly used was Field Collection and it's associated set of modules. The Field Collection module provided an excellent base for the data entry process, even though it needed to be customised heavily for calculation and validation needs. Quickbooks integration was also custom implemented. Things that really helped us was the extensive Forms and Ajax API of Drupal core.
