FS 315770 K-13 PART POD Format Rework
From Calidus HUB
PartnerLink
POD Format (Rework)
CALIDUS ePOD
7th March 2014 - 0.3
Reference: FS 315770/K-13
Contents
Functional Overview
Client Requirement
Fix the POD format created for Partnerlink, referenced in Appendix A.
Solution Overview
A POD report format will be produced.
This format will be configurable against the Partners.
Scope
- These changes will be made in the latest version of the CALIDUS ePOD system.
- Best efforts will be made to match the produced format to the sample provided, but differences in production and presentation (i.e. Browser, Email, etc) may result in some small differences.
Set-up
Pre-requisites
Menu Structure
None
Data
Ensure Job Groups must be configured to use the Partnerlink format, where required.
Ensure an EPOD_CUSTOMER record is created for the EP_SITE_ID, populated as follows:
- EPL_CUSTOMER_NAME, EPL_ADDRESS_1/2/3/4, EPL_POST_CODE, EPL_TELEPHONE - As required
- EPL_ADDRESS_LINE_5 - URL e.g. http://www.knightsofold.ltd.uk for site L03 (KOO).
Ensure Logos are uploaded for the Sites (on EPOD_SITE).
Functional Description
Database/DAL Changes
Table EPOD_JOB_ADDRESS requires the following modification:
- EPL_NAME - nvarchar(40)
Existing packages will be modified to allow the creating, editing and selecting of the new field, including but not limited to:
- EPOD_JOB_ADDRESS_INSERT
- EPOD_JOB_ADDRESS_DELETE
- EPOD_JOB_ADDRESS_SELECT
- EPOD_JOB_ADDRESS_UPDATE
The existing EPOD_JOB_ADDRESS DAL object will be changed to:
- Export the new field in XML requests
- Read the new field
Note: It is not necessary to add this field as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.
Table EPOD_JOB requires the following modification:
- EPL_ACCOUNT - nvarchar(40)
Existing packages will be modified to allow the creating, editing and selecting of the new field, including but not limited to:
- EPOD_JOB_INSERT
- EPOD_JOB_DELETE
- EPOD_JOB_SELECT
- EPOD_JOB_UPDATE
The existing EPOD_JOB DAL object will be changed to:
- Export the new field in XML requests
- Read the new field
Note: It is not necessary to add this field as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.
Import/Export Changes
The Partnerlink Import process will be modified to populate the following fields from the incoming file:
- EPL_ACCOUNT of EPOD_JOB - populated from column 58 (Account Code).
- EPL_NAME of EPOD_JOB_ADDRESS - populated from column 7 (Col Name) for Collection Addresses, from column 18 (Del Name) for Delivery Addresses. Both job addresses should be written at all times, as both are present on the incoming file.
POD Report Format
The final format will look like this prototype:
Mapped fields on the POD report have not changed from the original specification. However, these are re-stated here for clarity.
- Partner Logo - taken from EPL_LOGO of EPOD_SITE for this EPL_SITE_ID
- Partner URL - taken from EPL_ADDRESS_5 of the EPOD_CUSTOMER record for this EPL_SITE_ID
- Partnerlink Logo - removed if this is a Palletforce job (i.e. EPL_JOB_GROUP = "PALLET")
- Partnerlink URL - fixed text as "http://www.partnerlink.ltd.uk" - removed if this is a Palletforce job (i.e. EPL_JOB_GROUP = "PALLET")
- Customer - EPL_ACCOUNT
- Consignment Details - EPL_JOB_CODE
- Consignor - the address of the consignor (collection address). This will come from EPOD_JOB_ADDRESS for this EPL_JOB_ID, where EPL_JOB_TYPE = "C". If this does not exist and this is a collection job, this should be populated from the the EPOD_CUSTOMER record for this EPL_CUSTOMER_CODE. If this is a delivery job, this should be populated from the Partner address, by retrieving the EPOD_CUSTOMER record for this EPL_SITE_ID. If this does not exist, use the Site information (EPOD_SITE.EPL_SITE_NAME) with no address (blank).
- Company - EPL_NAME (if EPOD_JOB_ADDRESS), EPL_CUSTOMER_NAME (if EPOD_CUSTOMER), EPL_SITE_NAME (if EPOD_SITE)
- Address - EPL_ADDRESS_1/2/3/4/5 of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Postcode - EPL_POST_CODE of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Phone - EPL_PHONE_NO of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Deliver To - the delivery address. This will come from EPOD_JOB_ADDRESS for this EPL_JOB_ID, where EPL_JOB_TYPE = "D". If this does not exist and this is a delivery job, this should be populated from the the EPOD_CUSTOMER record for this EPL_CUSTOMER_CODE. If this does not exist, this should be blank.
- Company - EPL_NAME (if EPOD_JOB_ADDRESS), EPL_CUSTOMER_NAME (if EPOD_CUSTOMER)
- Address - EPL_ADDRESS_1/2/3/4/5 of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Postcode - EPL_POST_CODE of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Phone - EPL_PHONE_NO of EPL_CUSTOMER or EPOD_JOB_ADDRESS
- Driver - EPL_USER_ID of EPOD_DRIVER
- Vehicle - EPL_VEHICLE_REG of EPOD_VEHICLE
- Track Num - EPL_EXT_REF
- Trailer Number - EPL_TRAILER_ID
- Col Date - EPL_COL_DATE
- Manifest Number - EPL_LOAD_ID
- Del Date - EPL_START_PLANNED_DATE
- Service - EPL_SERVICE_LEVEL
- Del Time - EPL_START_PLANNED_TIME. Note: The display of this time should be suppressed (i.e. not displayed on the report) if the value of this field is "2359".
- Conditions - Hard-coded as "CONDITIONS: ALL GOODS HANDLED IN ACCORDANCE WITH THE COMPANY'S OWN CONDITIONS, COPIES OF WHICH ARE AVAILABLE ON APPLICATION."
- Customer Ref - EPL_CUST_REF
- Customer Ref2 - EPL_SO_NUMBER
- Consignment Instructions - EPL_JOB_INSTRUCTION
- Total Packs - Calculated from number of the job's container records (not including loose products)
- Total Weight - sub-totalled from EPL_GROSS_WEIGHT of the job's container records (not including loose products)
- Consignee Signature - EPL_JOB_SIGNATURE
- Printed Name - EPL_CUST_SIGNATORY
- Date - EPL_END_ACTUAL_DATE
- Arrival Time - EPL_ARRIVAL_TIME
- Departure Time - EPL_END_ACTUAL_TIME
Note: All fields are from EPOD_JOB unless otherwise specified.
The details section is mapped as follows:
- Consignment Packs - EPL_CONTAINER_ID
- Status - the translated status, as follows:
- "Delivered" - EPL_STATUS = "C"
- "Cancelled" - EPL_STATUS = "X"
- "Claused" - EPL_STATUS = "C" and EPL_REASON_CODE not blank, or EPL_CUST_COMMENTS not blank
- Notes - EPL_REASON_CODE and EPL_DESCRIPTION of EPOD_REASON_CODE of type "DET" (if present and EPL_STATUS = "X"), else EPL_REASON_CODE and EPL_DESCRIPTION of EPOD_REASON_CODE of type "CLA" (if present and EPL_STATUS = "C"), else EPL_CUST_COMMENTS.
Note: All fields are from EPOD_CONTAINER unless otherwise specified.
Differences from original designed report:
- "DRIVER COPY" is now "PROOF OF [EPL_JOB_TYPE.translated]" e.g for a Delivery job, this would be "PROOF OF DELIVERY".
- Customer is now set from the account code on the incoming file.
- The "Del Time" value is suppressed if this is "2359"
- The "Item" title on the details section is now "Consignment Packs"
- The following labels and data are all vertically aligned: Track Num, Manifest Number, Service, Driver, Vehicle, Trailer, Col Date, Del Date, Del Time.
- Labels are now bold
Additional differences from coded report:
- Correct Partnerlink Logo
- URLs for the respective businesses in the header
- General formatting of the POD (border lines, heading positions, spacing, size of text, etc)
- Correct formatting and positioning of Signature box
- Correction of Arrival title (colons)
- General correction of spacing between labels and data
- Correct number of lines in details section (30 lines)
- Data mapped correctly for the following fields (see above for details):
- Consignment Details
- Track Num
- Customer Ref2
- Departure Time
As there is a possibility that the number of containers will exceed that allowable on a page, the format should be written as a paginated document. The style of this should be copied from previous examples (e.g. ALS.aspx/ALS.aspx.cs).
The specific requirements of this format are:
- 30 lines should be allowed per page.
- The Container list should be recognised as the Detail portion of the document, the rest seen as the header.
- The header should be shown on each page, ensuring that the signature is shown at all times.
- There is no footer section
Notes on how to develop POD formats for CALIDUS ePOD
- All new reports should be created by using existing pagination code - this should be centralised and reusable where possible.
- To simplify development, existing reports that already use the pagination code should be copied.
- Pagination allows for a string definition of just the following 3 sections: Header, Details and Footer. Note: This may be extended in time to Initial and Final headers, plus Page Header and Footers.
- The call of the Pagination object (ReportPager) allows for the configuration of each section (for example, whether a particular section should be displayed, whether to reserve space for it, etc) - see this code and extensive examples for details of how this works and how to extend this for your report, if necessary.
- A prototype is always created in plain text - use this to copy in the header, detail and footer sections, escaping special characters as required. Also use this to source the correct CSS.
- Each section is defined in the C#.NET file (i.e. the "aspx.cs" file) rather than defined as objects in the asp.NET file (i.e. the ".aspx" file), modifying the copied populateReport method and any called methods, such as generateContent, generateHeader, generateFooter. These will be built by copying the provided prototype HTML code replacing data from the records found, escaping special characters as required. Note that data may be retrieved from globally- or locally-declared DAL objects within the report, if this is required.
- All other methods in the C#.NET file should be common to all POD reports, as follows:
- private int ValidateUser()
- public void Page_Error(object sender, EventArgs e)
- protected void Page_Load(object sender, EventArgs e)
- protected override void Render(HtmlTextWriter writer)
- protected override void OnUnload(EventArgs e)
- protected void emailBT_clicked(object sender, EventArgs e)
- private string convertJobType(String EPL_JOB_TYPE)
- public static int roundup(int i)
- The asp.NET file contains only:
- The required CSS code for this format, sourced mainly from the prototype rather than the copied source code.
- The "Email" div
- A general "POD" div.
- When complete:
- Check against the prototype - pay particular attention to line breaks (both forced by the HTML BR tag and those automatically placed into data and labels by size restrictions.
- Check the final PDF result by converting the produced page to PDF using the conversion tool.
- It should not then be necessary to check on multiple browsers, as the prototype has already been tested against all major browsers and likely versions, such as:
- Firefox (latest)
- Chrome (latest)
- Internet Explorer 11
- Internet Explorer 6-10 (through emulation)
- Safari (through PDF conversion)
When creating a report following these instructions, the produced report should match the prototype completely, and therefore there is less chance of a customer being unhappy upon delivery, having received a report that does not match the specification and prototype that they agreed before development commenced.
Appendix A: Quote & Document References
| Cost Details | ||||
| Activity | Estimate No. of Days |
No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
| Requirements | 0.00 | 0.00 | 0 | £0.00 |
| Change Request Evaluation | 0.00 | 0.00 | 0 | £0.00 |
| Functional Specification | 0.50 | 0.50 | 0 | £0.00 |
| Technical Specification | 0.00 | 0.00 | 0 | £0.00 |
| Development | 3.00 | 3.00 | 0 | £0.00 |
| Testing and Release | 0.25 | 0.25 | 0 | £0.00 |
| Implementation | 0.00 | 0.00 | 0 | £0.00 |
| Project Management | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | 0 | £First argument to "number_format" must be a number. |
| TOTAL | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | £First argument to "number_format" must be a number. | |
| Estimate excludes training, release to live and go live support. |
A.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | FS 304709 Partnerlink POD Format | 0.2 | 27/08/2013 |
A.2 Glossary
| Term | Definition |
|---|---|
| EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
| CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
| PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
| DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
| GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
| GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
A.3 Authorised By
Phil Harding | OBS Project Manager | _____________________________ |
Andrew Allison | Client Representative | _____________________________ |
