Calidus HUB - User contributions [en-gb]

SCR 361141 Enter charges for new job

2019-09-04T15:10:54Z

BAP:

{{Template:SmallCR
|Client=RHO
|LogNumber=361141
|Date=03/09/2019
|Requester=Kevin Galyer
|YourName=Barry Preece
|System=EPOD
|Request=Rhodes Freight require the ability to enter job charges when they add a job, without exiting and returning to the job screen.
|Reason=Product enhancement: improve usability for clients such as Rhodes Freight who do not have an ERP interface into ePOD and so use the ePOD maintenance screens directly to create and maintain jobs in the sysytem.
|Alternatives=Add the "Time, Expenses & Charges" tab to the New Job screen. Too complex so this option not chosen.
|Changes=Change the New Job window so that, after saving the new job, the window stays on-screen and the user can make edits to the new job. Note that this must now make the "Time Expenses & Charges" tab visible so that the user can add charges.

The screens must make it clear that the job has now been saved or created.
{{Note}} For consistency, the New Load, New Container & New Product windows should be changed to work the same way.
|Risks=Change of screen operation for existing users who add jobs manually. Not considered a problem; users can exit with a single click and will have the benefit of being able to edit the job before exiting.
|EST=0.25
|DEV=2.0
|TEST=0.25
|Implications=All customers using the Load, Jobs and Products/Containers screen need to be aware of the change.
|Status=
|Justification=
}}

SCR 361141 Enter charges for new job

2019-09-03T17:14:08Z

BAP: SCR 361141 Enter charges for new job

{{Template:SmallCR
|Client=RHO
|LogNumber=361141
|Date=03/09/2019
|Requester=Kevin Galyer
|YourName=Barry Preece
|System=EPOD
|Request=Rhodes Freight require the ability to enter job charges when they add a job, without exiting and returning to the job screen.
|Reason=It will take excessive time to enter new jobs, having to re-select and edit each job to enter the charges.
|Alternatives=Add the "Time, Expenses & Charges" tab to the New Job screen. Too complex so this option not chosen.
|Changes=Change the New Job window so that, after saving the new job, the window stays on-screen and the user can make edits to the new job. Note that this must now make the "Time Expenses & Charges" tab visible so that the user can add charges. For consistency, the New Load, New Container & New Product windows should be changed to work the same way.
|Risks=Change of screen operation for existing users who add jobs manually. Not considered a problem; users can exit with a single click and will have the benefit of being able to edit the job before exiting.
|EST=
|DEV=
|TEST=
|Implications=
|Status|=
|Justification=
|Client|TEMPLATE=}}

356578 REQ SOS POD and POC Layout and Mapping

2019-08-07T14:47:33Z

BAP: V 0.1 - Initial draft

<div class="noprint">
{{#vardefine:Client|SOS}}
{{#vardefine:ClientName|Storage On Site}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|POD Layout and Mapping}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|7th August 2019}}
{{#vardefine:Reference|356578}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Overview =

This document describes the proposed layout and field mapping for the POD (Proof of Delivery) documents to be developed for {{#var:ClientName}}.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.
There are 4 delivery documents within the scope, three of these share the same layout:
*Delivery / Collection Note
**Covers the Sales Delivery Note, Hire Delivery note and Collection Note
*Transfer Note
The Sales and Hire Delivery Notes and the Collection Note have identical layouts and content except for changes to some text headings so a single delivery note will be developed for these three documents.
The Transfer Note has some differences to this layout so will be developed as a separate layout.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


== POD /POC Layouts ==
This section shows the proposed layout of the delivery documents.

== POD and POC Mapping ==
This section describes the source of information that appears on the POD, which can come from various sources:

* Imported
** Imported into the ePOD Admin system in the job and load details sent by Anchor Bay Construction.
* ePOD Admin
** User entered and maintained in the ePOD Admin server screens.
* ePOD Mobile
** Data captured during the ePOD mobile delivery / collection process and uploaded to the ePOD Admin server.
* Fixed Text
** Text that is embedded in the POD layout. To change these in future will require OBSL to update the report layout.

= POD and POC Layouts =
The annotated layout for the electronic POD documents are on the following pages.

== Delivery / Collection Note ==
[[File:REQ 356578 SOS POD Sale.jpg|border|600px]]

== Transfer Note ==
[[File:356578 SOS POD Transfer.jpg|border|600px]]

= POD and POC Mapping =
These notes refer to the layouts on the previous pages.
== Delivery / Collection Note Mapping ==

Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||ePOD Admin + Fixed Text: This is user-maintained as customer details with a customer code of "SOS" (i.e. matching the site code for the system). The email addresses for Sales & Hire and Accounts will come from the customer contact and email. There is no mapping for the web site so this will be fixed text.
|-
|Document title ||Fixed text: "DELIVERY NOTE", "HIRE DELIVERY NOTE" or "COLLECTION NOTE" depending on the job type (Delivery / Collection) and job group. Deliveries for Job Group "Hire" are counted as hire delivery notes.
|-
|Logo ||ePOD Admin: This is the site logo maintained by uploading the company logo image into the Site screen in ePOD.
|-
|Document No. ||ePOD Admin: This will be called the "Delivery Note No." or "Collection Note No." depending on the job type (Delivery / Collection). The number is taken from the JOB ID in ePOD (a unique number generated by ePOD for each job).
|-
|Account No ||ePOD Admin: The Customer ID
|-
|Order No ||ePOD Admin: The Customer Ref from the job, entered by the user
|-
|Contract No ||ePOD Admin: The Sales No. from the job, entered by the user
|-
|Date ||ePOD Mobile: The date when the delivery / collection was confirmed.
|-
|Customer ||The customer name & address for the customer ID on the job (i.e. invoice address)
|-
|Delivery / Collection Address ||Imported EPOD_JOB (multiple fields): The job address. This will be called "Delivered To:" or "Collected From:" depending on the job type (Delivery / Collection).
|}

Detail Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Description ||ePOD Admin: Product description (short description: max 40 characters)
|-
|Stock No. ||ePOD Admin: Product code
|-
|Qty Shipped ||ePOD Admin: The product's Planned quantity
|-
|Qty Delivered / Collected ||ePOD Mobile: the quantity confirmed as delivered / collected by the driver.
|}

Footing Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name is entered on the job in ePOD Admin and can be changed when the customer signs for the delivery / collection.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|}

== Transfer Note Mapping ==
In ePOD, a transfer involves a collection job and delivery job both linked by the same job code on a Load. The Transfer Note can include information from both jobs.
The mapping of the Transfer Note is the same as the Delivery / Collection Note except for these differences:
*In the heading section, the document title is "TRANSFER NOTE"
*Instead of the Customer (Invoice) Address, the collection address is printed for the collection job (so the collection and delivery addresses are both shown)
*In the detail section the quantity collected and delivered are shown as the actual quantity confirmed for the collection job and the delivery job
*In the footer section, the driver's signature from the collection job is also printed to the left of the customer's signature from the delivery job




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

File:356578 SOS POD Transfer.jpg

2019-08-07T14:35:13Z

BAP: Storage On Site - Transfer Note

Storage On Site - Transfer Note

File:REQ 356578 SOS POD Sale.jpg

2019-08-07T14:31:22Z

BAP: Storage On Site - Sales / Hire Delivery Note & Collection Note

Storage On Site - Sales / Hire Delivery Note & Collection Note

REQ 354402 ABC POD and POC Layout and Mapping

2019-03-25T15:43:44Z

BAP: v1.0 - Issue for development

<div class="noprint">
{{#vardefine:Client|ABC}}
{{#vardefine:ClientName|Anchor Bay Construction}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|POD and POC Layout and Mapping}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|22nd March 2019}}
{{#vardefine:Reference|354402}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Overview =

This document describes the proposed layout and field mapping for the POD / POC (Proof of Delivery / Collection) document to be developed for {{#var:ClientName}}.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


== POC and POD Layouts ==
This section shows the proposed layout of the POD (Proof of Delivery) and POC (Proof of Collection) document, with annotated notes for clarification.

== POD and POC Mapping ==
This section describes the source of information that appears on the POD, which can come from various sources:

* Imported
** Imported into the ePOD Admin system in the job and load details sent by Anchor Bay Construction.
* ePOD Admin
** User entered and maintained in the ePOD Admin server screens.
* ePOD Mobile
** Data captured during the ePOD mobile delivery / collection process and uploaded to the ePOD Admin server.
* Fixed Text
** Text that is embedded in the POD layout. To change these in future will require OBSL to update the report layout.

= POD and POC Layouts =
The annotated layout for the electronic POD document is on the following pages.

* POD Document is the delivery note
* POC Document is the collection note

== POD Document ==
[[File:REQ 354402 POD.jpg|border|600px]]

== POC Document ==
[[File:REQ 354402 ABC POC.jpg|border|600px]]

= POD and POC Mapping =
These notes refer to the annotated layouts on the previous pages.
== POD Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||ePOD Admin: This is user-maintained as customer details with a customer code of "ABC" (matching the site code for the system), including the VAT number, phone, fax and email of the main address.
|-
|Document title ||Fixed text: "Delivery Note"
|-
|Logo ||ePOD Admin: This is maintained by uploading the logo image into the Job Group in ePOD. (Note: a new sub-company Forsite will come on board in the near future; this will use these same POD and POC layouts but will run as a separate site, which will allow it to have a different company name & address and logo on the documents)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Delivery Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE
|-
|Invoice Address ||Imported: EPOD_JOB: EPOD_CUSTOMER (contains multiple fields)
|-
|Date ||ePOD Mobile: the date that the delivery job was completed (Actual Date)
|-
|Page ||Page number
|-
|Shipment No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction job number which must be unique for each job.
|-
|Customer No ||Imported: EPL_CUSTOMER_CODE. This is the Anchor Bay internal reference code for the customer.
|-
|PO Number ||Imported: EPL_CUST_REF. This is the customer’s order number.
|-
|Salesperson ||Imported: EPL_SALES_CONTACT. This is the Anchor Bay sales person name or ID.
|}

Delivery Detail Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Qty Shipped ||Imported: EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. The quantity despatched.
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Delivered ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|-
|Total Weight ||Imported: Calculated as EPOD_PRODUCT: EPL_PRODUCT_WEIGHT multiplied by Qty Delivered. Note that this reflects the actual quantity confirmed by the driver, not the quantity shipped.
|-
|Short Reason ||ePOD Mobile: The reason code the driver entered when shorting or cancelling an item on the delivery. Reason codes are user-maintained in ePOD Admin.
|-
|Qty to Follow ||Imported: Calculated as EPOD_PRODUCT: EPL_QTY_ORDERED minus EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. Note that this reflects the quantity backordered at time of shipping and not any shortages or cancellations on delivery.
|}

Footing Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company / badge number will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|-
|Tot Weight ||Calculated: Sum of Total Weight for all delivered items. Note that, if the delivery note runs to 2 or more pages, this will only be printed on the last page.
|}

== POC Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||(See POD Mapping above)
|-
|Document title ||Fixed text: "Collection Note"
|-
|Logo ||(See POD Mapping above)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Collection Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE, EPL_TELEPHONE
|-
|Notes ||Imported: EPOD_JOB: EPL_JOB_INSTRUCTIONS. (Note that the driver also sees these job instructions on the mobile device when starting the job).
|-
|Date ||ePOD Mobile: the date that the collection job was completed (Actual Date)
|-
|Page ||Page number
|-
|Cust Return No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction collection reference, which must be unique for each job.
|-
|Customer No ||(See POD Mapping above)
|-
|Relates to Shipment No ||Imported: EPL_CUST_REF. This is the customer’s order number.
|}

Delivery Detail
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Collected ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|}

Footing
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Driver Signature ||ePOD Mobile: Driver signature. The name will be pre-displayed as the driver’s name from ePOD Admin.
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|}




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 354402 ABC POD and POC Layout and Mapping

2019-03-22T16:00:28Z

BAP: V 0.3 - more minor edits

<div class="noprint">
{{#vardefine:Client|ABC}}
{{#vardefine:ClientName|Anchor Bay Construction}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|POD and POC Layout and Mapping}}
{{#vardefine:Version|0.3}}
{{#vardefine:Date|22nd March 2019}}
{{#vardefine:Reference|354402}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Overview =

This document describes the proposed layout and field mapping for the POD / POC (Proof of Delivery / Collection) document to be developed for {{#var:ClientName}}.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


== POC and POD Layouts ==
This section shows the proposed layout of the POD (Proof of Delivery) and POC (Proof of Collection) document, with annotated notes for clarification.

== POD and POC Mapping ==
This section describes the source of information that appears on the POD, which can come from various sources:

* Imported
** Imported into the ePOD Admin system in the job and load details sent by Anchor Bay Construction.
* ePOD Admin
** User entered and maintained in the ePOD Admin server screens.
* ePOD Mobile
** Data captured during the ePOD mobile delivery / collection process and uploaded to the ePOD Admin server.
* Fixed Text
** Text that is embedded in the POD layout. To change these in future will require OBSL to update the report layout.

= POD and POC Layouts =
The annotated layout for the electronic POD document is on the following pages.

* POD Document is the delivery note
* POC Document is the collection note

== POD Document ==
[[File:REQ 354402 POD.jpg|border|600px]]

== POC Document ==
[[File:REQ 354402 ABC POC.jpg|border|600px]]

= POD and POC Mapping =
These notes refer to the annotated layouts on the previous pages.
== POD Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||ePOD Admin: This is user-maintained as customer details with a customer code of "ABC" (matching the site code for the system), including the VAT number, phone, fax and email of the main address.
|-
|Document title ||Fixed text: "Delivery Note"
|-
|Logo ||ePOD Admin: This is maintained by uploading the logo image into the Job Group in ePOD. (Note: a new sub-company Forsite will come on board in the near future; this will use these same POD and POC layouts but will run as a separate site, which will allow it to have a different company name & address and logo on the documents)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Delivery Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE
|-
|Invoice Address ||Imported: EPOD_JOB: EPOD_CUSTOMER (contains multiple fields)
|-
|Date ||ePOD Mobile: the date that the delivery job was completed (Actual Date)
|-
|Page ||Page number
|-
|Shipment No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction job number which must be unique for each job.
|-
|Customer No ||Imported: EPL_CUSTOMER_CODE. This is the Anchor Bay internal reference code for the customer.
|-
|PO Number ||Imported: EPL_CUST_REF. This is the customer’s order number.
|-
|Salesperson ||Imported: EPL_SALES_CONTACT. This is the Anchor Bay sales person name or ID.
|}

Delivery Detail Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Qty Shipped ||Imported: EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. The quantity despatched.
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Delivered ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|-
|Total Weight ||Imported: Calculated as EPOD_PRODUCT: EPL_PRODUCT_WEIGHT multiplied by Qty Delivered. Note that this reflects the actual quantity confirmed by the driver, not the quantity shipped.
|-
|Short Reason ||ePOD Mobile: The reason code the driver entered when shorting or cancelling an item on the delivery. Reason codes are user-maintained in ePOD Admin.
|-
|Qty to Follow ||Imported: Calculated as EPOD_PRODUCT: EPL_QTY_ORDERED minus EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. Note that this reflects the quantity backordered at time of shipping and not any shortages or cancellations on delivery.
|}

Footing Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company / badge number will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|-
|Tot Weight ||Calculated: Sum of Total Weight for all delivered items. Note that, if the delivery note runs to 2 or more pages, this will only be printed on the last page.
|}

== POC Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||(See POD Mapping above)
|-
|Document title ||Fixed text: "Collection Note"
|-
|Logo ||(See POD Mapping above)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Collection Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE, EPL_TELEPHONE
|-
|Notes ||Imported: EPOD_JOB: EPL_JOB_INSTRUCTIONS. (Note that the driver also sees these job instructions on the mobile device when starting the job).
|-
|Date ||ePOD Mobile: the date that the collection job was completed (Actual Date)
|-
|Page ||Page number
|-
|Cust Return No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction collection reference, which must be unique for each job.
|-
|Customer No ||(See POD Mapping above)
|-
|Relates to Shipment No ||Imported: EPL_CUST_REF. This is the customer’s order number.
|}

Delivery Detail
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Collected ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|}

Footing
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Driver Signature ||ePOD Mobile: Driver signature. The name will be pre-displayed as the driver’s name from ePOD Admin.
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|}




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 354402 ABC POD and POC Layout and Mapping

2019-03-22T15:52:20Z

BAP: V 0.2 - Minor edits to layout

<div class="noprint">
{{#vardefine:Client|ABC}}
{{#vardefine:ClientName|Anchor Bay Construction}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|POD and POC Layout and Mapping}}
{{#vardefine:Version|0.2}}
{{#vardefine:Date|22nd March 2019}}
{{#vardefine:Reference|354402}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Overview =

This document describes the proposed layout and field mapping for the POD / POC (Proof of Delivery / Collection) document to be developed for {{#var:ClientName}}.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


== POC and POD Layouts ==
This section shows the proposed layout of the POD (Proof of Delivery) and POC (Proof of Collection) document, with annotated notes for clarification.

== POD and POC Mapping ==
This section describes the source of information that appears on the POD, which can come from various sources:

* Imported
** Imported into the ePOD Admin system in the job and load details sent by Anchor Bay Construction.
* ePOD Admin
** User entered and maintained in the ePOD Admin server screens.
* ePOD Mobile
** Data captured during the ePOD mobile delivery / collection process and uploaded to the ePOD Admin server.
* Fixed Text
** Text that is embedded in the POD layout. To change these in future will require OBSL to update the report layout.

= POD and POC Layouts =
The annotated layout for the electronic POD document is on the following pages.

* POD Document is the delivery note
* POC Document is the collection note

== POD Document ==
[[File:REQ 354402 POD.jpg|border|600px]]

== POC Document ==
[[File:REQ 354402 ABC POC.jpg|border|600px]]

= POD and POC Mapping =
These notes refer to the annotated layouts on the previous pages.
== POD Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||ePOD Admin: This is user-maintained as customer details with a customer code of "ABC" (matching the site code for the system), including the VAT number, phone, fax and email of the main address.
|-
|Document title ||Fixed text: "Delivery Note"
|-
|Logo ||ePOD Admin: This is maintained by uploading the logo image into the Job Group in ePOD. (Note: a new sub-company Forsite will come on board in the near future; this will use these same POD and POC layouts but will run as a separate site, which will allow it to have a different company name & address and logo on the documents)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Delivery Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE
|-
|Invoice Address ||Imported: EPOD_JOB: EPOD_CUSTOMER (contains multiple fields)
|-
|Date ||ePOD Mobile: the date that the delivery job was completed (Actual Date)
|-
|Page ||Page number
|-
|Shipment No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction job number which must be unique for each job.
|-
|Customer No ||Imported: EPL_CUSTOMER_CODE. This is the Anchor Bay internal reference code for the customer.
|-
|PO Number ||Imported: EPL_CUST_REF. This is the customer’s order number.
|-
|Salesperson ||Imported: EPL_SALES_CONTACT. This is the Anchor Bay sales person name or ID.
|}

Delivery Detail Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Qty Shipped ||Imported: EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. The quantity despatched.
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Delivered ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|-
|Total Weight ||Imported: Calculated as EPOD_PRODUCT: EPL_PRODUCT_WEIGHT multiplied by Qty Delivered. Note that this reflects the actual quantity confirmed by the driver, not the quantity shipped.
|-
|Short Reason ||ePOD Mobile: The reason code the driver entered when shorting or cancelling an item on the delivery. Reason codes are user-maintained in ePOD Admin.
|-
|Qty to Follow ||Imported: Calculated as EPOD_PRODUCT: EPL_QTY_ORDERED minus EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. Note that this reflects the quantity backordered at time of shipping and not any shortages or cancellations on delivery.
|}

Footing Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company / badge number will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|-
|Tot Weight ||Calculated: Sum of Total Weight for all delivered items. Note that, if the delivery note runs to 2 or more pages, this will only be printed on the last page.
|}

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||(See POD Mapping above)
|-
|Document title ||Fixed text: "Collection Note"
|-
|Logo ||(See POD Mapping above)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Collection Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE, EPL_TELEPHONE
|-
|Notes ||Imported: EPOD_JOB: EPL_JOB_INSTRUCTIONS. (Note that the driver also sees these job instructions on the mobile device when starting the job).
|-
|Date ||ePOD Mobile: the date that the collection job was completed (Actual Date)
|-
|Page ||Page number
|-
|Cust Return No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction collection reference, which must be unique for each job.
|-
|Customer No ||(See POD Mapping above)
|-
|Relates to Shipment No ||Imported: EPL_CUST_REF. This is the customer’s order number.
|}

Delivery Detail
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Collected ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|}

Footing
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Driver Signature ||ePOD Mobile: Driver signature. The name will be pre-displayed as the driver’s name from ePOD Admin.
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|}




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 354402 ABC POD and POC Layout and Mapping

2019-03-22T15:39:53Z

BAP: V 0.1 - Initial draft

<div class="noprint">
{{#vardefine:Client|ABC}}
{{#vardefine:ClientName|Anchor Bay Construction}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|POD and POC Layout and Mapping}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|22nd March 2019}}
{{#vardefine:Reference|354402}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Overview =

This document describes the proposed layout and field mapping for the POD / POC (Proof of Delivery / Collection) document to be developed for {{#var:ClientName}}.
This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


== POC and POD Layouts ==
This section shows the proposed layout of the POD (Proof of Delivery) and POC (Proof of Collection) document, with annotated notes for clarification.

== POD and POC Mapping ==
This section describes the source of information that appears on the POD, which can come from various sources:

* Imported
** Imported into the ePOD Admin system in the job and load details sent by Anchor Bay Construction.
* ePOD Admin
** User entered and maintained in the ePOD Admin server screens.
* ePOD Mobile
** Data captured during the ePOD mobile delivery / collection process and uploaded to the ePOD Admin server.
* Fixed Text
** Text that is embedded in the POD layout. To change these in future will require OBSL to update the report layout.

= POD and POC Layouts =
The annotated layout for the electronic POD document is on the following pages.

* POD Document is the delivery note
* POC Document is the collection note

== POD Document ==
[[File:REQ 354402 POD.jpg|border|600px]]

== POC Document ==
[[File:REQ 354402 ABC POC.jpg|border|600px]]

= POD and POC Mapping =
These notes refer to the annotated layouts on the previous pages.
== POD Mapping ==

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||ePOD Admin: This is user-maintained as customer details with a customer code of “ABC” (matching the site code for the system), including the VAT number, phone, fax and email of the main address.
|-
|Document title ||Fixed text: “Delivery Note”
|-
|Logo ||ePOD Admin: This is maintained by uploading the logo image into the Job Group in ePOD. (Note: a new sub-company Forsite will come on board in the near future; this will use these same POD and POC layouts but will run as a separate site, which will allow it to have a different company name & address and logo on the documents)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Delivery Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE
|-
|Invoice Address ||Imported: EPOD_JOB: EPOD_CUSTOMER (contains multiple fields)
|-
|Date ||ePOD Mobile: the date that the delivery job was completed (Actual Date)
|-
|Page ||Page number
|-
|Shipment No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction job number which must be unique for each job.
|-
|Customer No ||Imported: EPL_CUSTOMER_CODE. This is the Anchor Bay internal reference code for the customer.
|-
|PO Number ||Imported: EPL_CUST_REF. This is the customer’s order number.
|-
|Salesperson ||Imported: EPL_SALES_CONTACT. This is the Anchor Bay sales person name or ID.
|}

Delivery Detail Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Qty Shipped ||Imported: EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. The quantity despatched.
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Delivered ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|-
|Total Weight ||Imported: Calculated as EPOD_PRODUCT: EPL_PRODUCT_WEIGHT multiplied by Qty Delivered. Note that this reflects the actual quantity confirmed by the driver, not the quantity shipped.
|-
|Short Reason ||ePOD Mobile: The reason code the driver entered when shorting or cancelling an item on the delivery. Reason codes are user-maintained in ePOD Admin.
|-
|Qty to Follow ||Imported: Calculated as EPOD_PRODUCT: EPL_QTY_ORDERED minus EPOD_PRODUCT: EPL_PRODUCT_QTY_PLANNED. Note that this reflects the quantity backordered at time of shipping and not any shortages or cancellations on delivery.
|}

Footing Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company / badge number will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|-
|Tot Weight ||Calculated: Sum of Total Weight for all delivered items. Note that, if the delivery note runs to 2 or more pages, this will only be printed on the last page.
|}

Upper Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Company Name & Address ||(See POD Mapping above)
|-
|Document title ||Fixed text: “Collection Note”
|-
|Logo ||(See POD Mapping above)
|}

Lower Heading Section
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Collection Address ||Imported EPOD_JOB (multiple fields): EPL_CUSTOMER_CODE, EPL_CUSTOMER_NAME, EPL_ADDRESS_1, EPL_ADDRESS_2, EPL_ADDRESS_3, EPL_ADDRESS_4, EPL_ADDRESS_5, EPL_POSTCODE, EPL_TELEPHONE
|-
|Notes ||Imported: EPOD_JOB: EPL_JOB_INSTRUCTIONS. (Note that the driver also sees these job instructions on the mobile device when starting the job).
|-
|Date ||ePOD Mobile: the date that the collection job was completed (Actual Date)
|-
|Page ||Page number
|-
|Cust Return No ||Imported: EPOD_JOB: EPL_JOB_CODE. This is the Anchor Bay Construction collection reference, which must be unique for each job.
|-
|Customer No ||(See POD Mapping above)
|-
|Relates to Shipment No ||Imported: EPL_CUST_REF. This is the customer’s order number.
|}

Delivery Detail
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Item Number ||Imported: EPOD_PRODUCT: EPL_PRODUCT_CODE. The product identifier.
|-
|Description ||Imported: EPOD_PRODUCT: EPL_DESCRIPTION.
|-
|Unit of Measure ||Imported: EPOD_PRODUCT: EPL_UNIT_TYPE.
|-
|Qty Collected ||ePOD Mobile: the quantity confirmed as delivered by the driver.
|}

Footing
{| class="wikitable" border="1"
|- bgcolor="silver"
|Item ||Sourced from
|-
|Driver Signature ||ePOD Mobile: Driver signature. The name will be pre-displayed as the driver’s name from ePOD Admin.
|-
|Customer Signature ||ePOD Mobile: Customer signature. The name can be imported in EPOD_JOB: EPL_CONTACT and changed at sign-off. The Company will be captured as a user-defined field (UDF) on the customer signature screen.
|-
|Terms And Conditions ||ePOD Admin: Maintained on the Job Groups screen in the Terms & Conditions tab.
|}




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

File:REQ 354402 ABC POC.jpg

2019-03-22T15:16:22Z

BAP: ABC POC layout

ABC POC layout

File:ABC POC.jpg

2019-03-22T15:13:09Z

BAP: ABC POC Layout

ABC POC Layout

File:REQ 354402 POD.jpg

2019-03-22T15:12:43Z

BAP: ABC POD layout

ABC POD layout

File:REQ 354402 POD Example.jpg

2019-03-22T13:50:51Z

BAP: Example of new POD layout with test data

Example of new POD layout with test data

File:REQ 354402 POC Example.jpg

2019-03-22T13:49:53Z

BAP: Example of new POD layout with test data

Example of new POD layout with test data

REQ 356284 Changes to On-time Report

2019-03-11T10:54:05Z

BAP: v1.0 - Initial release to client

<div class="noprint">
{{#vardefine:Client|MASH}}
{{#vardefine:ClientName|MASH Purveyors}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Changes to On-time Report}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|11th March 2019}}
{{#vardefine:Reference|356284}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Introduction =

This document relates to {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}} regarding changes required to the On-time Report (previously known as the OTIF report).



This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.

*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


= Client Requirements =
There are two separate requirements covered in this document, as detailed below.
The intention is that both requirements will be developed and delivered together in a single release.

== Report by Planned Date ==
The requirement here is to allow the report to select by planned date instead of the current actual date, so that it will include any orders that have not yet been delivered.
The Proposed solution for this is an option on when requesting the report to select whether the entered date range applies to actual or planned date.

Note that incomplete orders without an actual date would be classed as 'not on time' even if the planned date is in the future.

== Report to XML ==
The requirement here is stated as follows

We are looking to take the output direct from the point of creation (whilst keeping the option to open the spreadsheet as currently happens) into a dedicated directory where it can be picked up from and taken into a site based reports generator where the data will be manipulated to provide graphics, on time reports etc.
So effectively:-
* We run the report as normal
* If we want open the spreadsheet the options remains
* At the time the report is run it is copied to a dedicated directory (folder), preferably in XML format
* The file is picked up each time it is run from the report option and dropped into the folder by a site based package which will create dedicated kpis / statistical information, updating each time we run the report

The proposed solution for this is to provide a web service which can be called by specifying the report parameters and will return the report as XML.

The call to the web service would supply an XML request payload with authorisation, the report to be run and the parameters.
For example, the payload would look similar to this:

<EPOD_REPORT_REQUEST EPL_SITE_ID="" EPL_USER_ID="" EPL_USER_PASSWORD="">
<REPORT>MashOTIFReport</REPORT>
<SITE></SITE>
<DATE_TYPE>PLANNED</DATE_TYPE>
<DATE_FROM></DATE_FROM>
<DATE_TO></DATE_TO>
<CUSTOMER_CODE></CUSTOMER_CODE>
<ROUTE_CODE></ROUTE_CODE>
<LOAD_ID></LOAD_ID>
<JOB_TYPE></JOB_TYPE>
</EPOD_REPORT_REQUEST>

ePOD would respond with the XML in a response message similar to this:

<EPOD_REPORT_RESPONSE RESULT="ACK">
<NewDataSet>
<MashOTIFReport>
<Customer_Code>M1</Customer_Code>
<Customer_Name>Manchester Blood Centre</Customer_Name>
<Load_ID>TRN-00001432</Load_ID>
<Job_Code>NHS1432-1</Job_Code>
<Status>C</Status>
<Reason />
<Sequence>1</Sequence>
<Service />
<Planned_Date>23/10/2014</Planned_Date>
<Planned_Time>14:44</Planned_Time>
<Arrival_Date />
<Arrival_Time />
<On_Time>N</On_Time>
</MashOTIFReport>
<MashOTIFReport>
...
</MashOTIFReport>
</NewDataSet>
</EPOD_REPORT_RESPONSE>

Failures when running the report or with parameters would be returned in the standard mechanism, e.g.:

<EPOD_REPORT_RESPONSE RESULT="NAK">
<ERRORS>
<ERROR error="USER DETAILS NOT VALID"/>
</ERRORS>
</EPOD_REPORT_RESPONSE>




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 356284 Changes to On-time Report

2019-03-11T09:45:35Z

BAP: V 0.1 - Initial draft

<div class="noprint">
{{#vardefine:Client|MASH}}
{{#vardefine:ClientName|MASH Purveyors}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Changes to On-time Report}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|11th March 2019}}
{{#vardefine:Reference|356284}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Introduction =

This document relates to {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}} regarding changes required to the On-time Report (previously known as the OTIF report).



This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on information provided by {{#var:ClientName}} in emails and points clarified and confirmed in subsequent emails.


*The changes will be made in the latest version of the {{#var:System}} system.

{{ #vardefine: SCR | 0 }}


= Client Requirements =
There are two separate requirements covered in this document, as detailed below.
The intention is that both requirements will be developed and delivered together in a single release.

== Report by Planned Date ==
The requirement here is to allow the report to select by planned date instead of the current actual date, so that it will include any orders that have not yet been delivered.
The Proposed solution for this is an option on when requesting the report to select whether the entered date range applies to actual or planned date. Selecting by actual data would run the report as now; selecting by planned date would
Note that incomplete orders without an actual date would be classed as 'not on time' even if the planned date is in the future.

== Report to XML ==
The requirement here is stated as follows

We are looking to take the output direct from the point of creation (whilst keeping the option to open the spreadsheet as currently happens) into a dedicated directory where it can be picked up from and taken into a site based reports generator where the data will be manipulated to provide graphics, on time reports etc.
So effectively:-
* We run the report as normal
* If we want open the spreadsheet the options remains
* At the time the report is run it is copied to a dedicated directory (folder), preferably in XML format
* The file is picked up each time it is run from the report option and dropped into the folder by a site based package which will create dedicated kpis / statistical information, updating each time we run the report

The proposed solution for this is to provide a web service which can be called by specifying the report parameters and will return the report as XML.

The call to the web service would supply an XML request payload with authorisation, the report to be run and the parameters.
For example, the payload would look similar to this:

<EPOD_REPORT_REQUEST EPL_SITE_ID="" EPL_USER_ID="" EPL_USER_PASSWORD="">
<REPORT>MashOTIFReport</REPORT>
<SITE></SITE>
<DATE_SELECT_METHOD>PLANNED_DATE</DATE_SELECT_METHOD>
<DATE_FROM></DATE_FROM>
<DATE_TO></DATE_TO>
<CUSTOMER_CODE></CUSTOMER_CODE>
<ROUTE_CODE></ROUTE_CODE>
<LOAD_ID></LOAD_ID>
<JOB_TYPE></JOB_TYPE>
</EPOD_REPORT_REQUEST>

ePOD would respond with the XML in a response message similar to this:

<EPOD_REPORT_RESPONSE RESULT="ACK">
<NewDataSet>
<MashOTIFReport>
<Customer_Code>M1</Customer_Code>
<Customer_Name>Manchester Blood Centre</Customer_Name>
<Load_ID>TRN-00001432</Load_ID>
<Job_Code>NHS1432-1</Job_Code>
<Status>C</Status>
<Reason />
<Sequence>1</Sequence>
<Service />
<Planned_Date>23/10/2014</Planned_Date>
<Planned_Time>14:44</Planned_Time>
<Arrival_Date />
<Arrival_Time />
<On_Time>N</On_Time>
</MashOTIFReport>
<MashOTIFReport>
...
</MashOTIFReport>
</NewDataSet>
</EPOD_REPORT_RESPONSE>

Failures when running the report or with parameters would be returned in the standard mechanism, e.g.:

<EPOD_REPORT_RESPONSE RESULT="NAK">
<ERRORS>
<ERROR error="USER DETAILS NOT VALID"/>
</ERRORS>
</EPOD_REPORT_RESPONSE>




{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

FS 354567 JB Global POD Note Changes

2019-02-26T11:47:23Z

BAP: v1.0 - Issue for development

<div class="noprint">
{{#vardefine:Client|JBG}}
{{#vardefine:ClientName|Oak Furnitureland}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|JB Global POD Note Changes}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|26th February 2019}}
{{#vardefine:Reference|354567}}
{{#vardefine:Year|2019}}
{{ #vardefine: Figure | 0 }}{{ #vardefine: Example | 0 }}

</div>
{{Doc_TitleNew
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= FUNCTIONAL OVERVIEW =
== Client Requirement ==
I have attached the new POD to this email. Please generate an estimate for the changes required and let me know when you can make them. Just to note, any config changes will need to be applied to all ePod sites, as we'd need these changes to be applied system wide.

== Additional points confirmed ==
* Print images on a following page as with the current delivery note.
* ePOD has no telephone number 3 so this will be blank.
* Print the name and signature side by side to allow more vertical room for the signature.
* If the delivery has more than 14 lines then the report will throw a page after the 14th line (the footer area will be blank). The next page will include the header again, the rest of the lines and the footer. The third page will then be the disclaimer.
* Using multiple fonts for the T&Cs is not necessary if this requires the text to be hard-coded. It is more important that the T&Cs can be edited in future.
* To support the new POD design, corresponding changes will be required to the configuration of the User-defined Field (UDF) forms currently in use:
** The "Difficult Delivery" information dialogue will be on a new UDF form for "Arrivals Terms and Conditions for Deliveries".
*** This will include capture of the driver's Q&A and the customer's signature. The driver will answer the questions then hand the PDA to the customer to sign.
*** The difficult delivery disclaimer will appear as the terms & conditions below the signature box and the driver's Q&A below that (so the customer will sign against both the disclaimer and the driver's answers, which also both appear on the disclaimer page of the POD).
*** If there isn’t a problem with access then the driver can skip the form.
** The existing form for capturing the "Difficult Delivery" information is no longer required and will be removed. This is the "Job Details - When Amended" UDF form.
** The Returns disclaimer will be on a new UDF form for "Arrivals Terms and Conditions for Collections". This will include capture of the customer's signature with the disclaimer text below the signature box.
** The failure reason, return no. and card no. are entered on a "Job Cancellation" UDF form, which will remain in use.
* Collection jobs will show alternative text to delivery notes in these places:
** The document title will change from "DELIVERY NOTE" to "COLLECTION NOTE".
** The text against the customer signature will change from "I, the customer, acknowledge receipt of goods" to "I, the customer, acknowledge collection of goods".
** The text "FAILED DELIVERY CHECKLIST TO BE COMPLETED BY DRIVER" will become "FAILED COLLECTION CHECKLIST TO BE COMPLETED BY DRIVER"

[[File:JBG POD page 1.jpg|border|600px]]

[[File:JBG POD page 2.jpg|border|600px]]

== Solution Overview ==
The Configurable POD Report will be modified to match the requirements.

== Scope ==
This change will be completed in the latest versions of ''CALIDUS'' ePOD server and mobile device software.

== Impact ==
Once the new format and UDF is applied, any jobs completed without the new data will not produce a POD correctly. If this is required, the following is recommended:
* The POD note format is created as a new format, retaining the original.
* New job groups are created for collections and deliveries, configured to use the new report format.
* These job groups are used on any new jobs that require the new format.
This will require modifications to the interface passed to C-ePOD from the WMS/ERP.


= CONFIGURATION SET-UP =
== Pre-requisites ==
A configured ''CALIDUS'' ePOD system connected to the WMS/ERP.

== Menu Structure ==
N/A

== Data ==
The new POD format will be applied either to the existing (non-warehouse) collection and delivery job groups, or to the new job groups created for this purpose, using the Job Group Maintenance screen.

The terms and conditions will be set against the appropriate job groups as follows:
* "I, the customer, acknowledge receipt of goods" for the delivery job group.
* "I, the customer, acknowledge collection of goods" for the collection job group.

UDF configurations will be created for the following:
* Difficult Delivery - pre-job T&Cs for Deliveries.
* Returns Only - pre-job T&Cs for Collections.
{{Note}} These UDF configurations will be applied either to the existing (non-warehouse) collection and delivery job groups, or to the new job groups created for this purpose, using the UDF Maintenance screen.

=== Pre-job T&Cs for Deliveries ===
<FORM NAME="Difficult Delivery" REQUIRED="N">
<FIELD ID="SECTION1">
<TEXT>SECTION 1: To be completed by the Oak Furniture Land Delivery Team</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="DIFFICULT_DELIVERY">
<TEXT>Why is the delivery difficult? Please tick the relevant box(es) below.</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="NARROW_ACCESS">
<TEXT>Narrow access issue</TEXT>
<FORMAT>X</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
<ITEMS>
<ITEM ID="NARROW_ACCESS__1" DEFAULT="N" VALUE="N">Property entrance (front door)</ITEM>
<ITEM ID="NARROW_ACCESS__2" DEFAULT="N" VALUE="Y">Entrance to room of choice</ITEM>
<ITEM ID="NARROW_ACCESS__3" DEFAULT="N" VALUE="N">Tight turn within the delivery route</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="OBSTRUCTION">
<TEXT>Obstruction that can't be easily moved</TEXT>
<FORMAT>X</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
<ITEMS>
<ITEM ID="OBSTRUCTION__1" DEFAULT="N" VALUE="N">Low ceiling</ITEM>
<ITEM ID="OBSTRUCTION__2" DEFAULT="N" VALUE="Y">Bannister that reduces space to move need to manoeuvre item</ITEM>
<ITEM ID="OBSTRUCTION__3" DEFAULT="N" VALUE="N">Low hanging light fitting</ITEM>
<ITEM ID="OBSTRUCTION__4" DEFAULT="N" VALUE="N">Existing large furniture</ITEM>
</ITEMS>
</FIELD>
<FIELD ID="OTHER">
<TEXT>OTHER</TEXT>
<FORMAT>A</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
<VALUE></VALUE>
</FIELD>
<FIELD ID="SECTION2">
<TEXT>SECTION 2: To be signed by the customer</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="ACKNOWLEDGE">
<TEXT>I acknowledge that there is not safe, clear and adequate access for delivery, as required under sections 9.8.1 and 9.8.2 of the JB Global Limited's terms and conditions. I wish to proceed with the delivery and have been advised of the risk of damage to property which might occur as a result.</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="SECTION81">
<TEXT>8.1 | Please check the measurements and delivery access to Your home. It is important to check the measurements of Your Products by visiting Our Website or by calling Our customer service team. Please ensure that there is adequate doorway and stair access. We cannot accept any liability for any extra costs incurred by You as a result of incorrect or incomplete measurements or information supplied by You</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="SECTION82">
<TEXT>8.2 | Please check that the route from the lorry to Your room of choice is safe and free from potential problems or hazards. As Our staff have not visited Your home and cannot advise whether Your Products will fit, We ask that You take reasonable steps to ensure that the Products can be successfully delivered to You. This includes making sure that the lorry can get to You and measuring any door or ceiling heights, plus twists and turns (including Your stair banister) that might cause difficulties when We deliver. Your order will typically be delivered via a large lorry, so please be sure Your property is accessible for this type of vehicle. If You think there may be an issue, please call Us prior to delivery.</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
</FORM>

=== Pre-job T&Cs for Collections ===
<FORM NAME="Returns Only" REQUIRED="Y">
<FIELD ID="TITLE">
<TEXT>RETURNS ONLY</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
<FIELD ID="TANDCS">
<TEXT>I, the customer, confirm all delivery labels containing my personal details have been removed prior to the item being returned.</TEXT>
<FORMAT>L</FORMAT>
<SUBTEXT></SUBTEXT>
<REQUIRED>N</REQUIRED>
<GROUP></GROUP>
<POST></POST>
</FIELD>
</FORM>

== Implementation Advice ==
The changes to the POD require additional changes to the server and the mobile device application in order to populate the new back page. Both will be required to be released ''before'' the new POD report format can be implemented.


= FUNCTIONAL DESCRIPTION =
== Pre-Job Signature and T&C Changes ==
Configurable UDF T&Cs will be used for the Difficult Delivery Disclaimer and Returns Only sections. Currently, the device does not return these values.

Furthermore, the server does not store these values correctly.

These bugs will be fixed and released with the modifications in this specification.

== Mobile Device Process ==
After these changes are implemented, the mobile device process upon arrival to the customer's location will be as described below.

For deliveries:
* After arrival, the mobile device application will present the driver with the Arrival Signature process, displaying the Difficult Delivery Disclaimer form (both sections) in the T&Cs for the signature.
* The driver will determine whether the delivery will be difficult for any reason.
* If not, the driver will skip the signature and move on to the delivery.
* If the driver determines that the delivery will be difficult, the driver will check the appropriate boxes on section 1 of the T&Cs, or enter any other reason where prompted. The driver will then obtain the customer's signature.
* The driver will move on to the delivery, as now.

For collections:
* After arrival, the mobile device application will present the driver with the Arrival Signature process, displaying the Returns Only form in the T&Cs for the signature.
* The driver will then obtain the customer's signature - this process cannot be skipped.
* The driver will move on to the collection, as now.

== New POD Report Format ==
The new POD report will be formatted as described in the requirements.

A prototype has been created, resulting in the following:

[[File:FS_354567_POD1.PNG|border|600px]]
[[File:FS_354567_POD2.PNG|border|600px]]


= TECHNICAL NOTES =
== Modules Changed ==
{| class="wikitable" border="1" width="100%"
|-bgcolor="#FFFF99"
!width="20%" | Module Name || width="40%" | Module Type || width="40%" | Notes
|-
| ConfigPOD.aspx.cs || EPOD Server Report ||  
|-
| MessageProcess.cs || EPOD Server Web Service Processing ||  
|-
| SystemUtilities.js || EPOD Mobile Device module ||  
|}

== Table Updates ==
None.

== Developer Notes ==
Config Report Changes:
* Add function to extract UDF in one grab
* Change styling of UDF fields
* Add standard CSS styles for UDF fields.

Data:
* New Products POD Report format for Oak Furnitureland

Mobile Device Changes:
* Send pre-job UDF T&Cs back to the server for printing on the POD note.

=== Configurable POD Changes ===
A New GetUDFForm function will be created. This function will retrieve all of the UDF form within the specified field and return strongly formatted and classed HTML for each field and item.

The following rules are followed:
* Form is a DIV classed as UDFForm , ID'd using the class and UDF name. The name will have all characters other than alphanumeric, period, underscore, colon and dash replaced with an underscore character. For example:
** If this is a form named "Difficult Delivery Disclaimer", this will be named "UDFForm_Difficult_Delivery_Disclaimer".
** If this is a form named "MyForm&1234\2#", this will be named "UDFForm_MyForm_1234_2_".
* Each field is a DIV classed as UDFField and by their field type:
** UDFFieldT - Text
** UDFFieldN - Numeric
** UDFFieldB - CheckBox
** UDFFieldX - Checkbox List
** UDFFieldTSC - Tri-state Check
** UDFFieldX2 - Tri-state Check List
** UDFFieldDDL - Drop-down List
** UDFFieldA - Text Area
** UDFFieldL - Label
** Button/Photo - omitted
* Each Text, Numeric, DDL and Text Area field will show the following in this order:
** The label classed as UDFFieldTitle.
** The value classed as UDFFieldValue.
** The subtext classed as UDFFieldSubtext, if present.
** The post text classed as UDFFieldPost, if present.

* Each field is strongly ID'd with the form ID and field ID, for example, for a UDF pre-job TNCs form called "Difficult Delivery Disclaimer":
** UDFFieldT - Text
<div class="UDFField UDFFieldT" id="UDFForm_Difficult_Delivery_Disclaimer_TRAILER">
<span class="UDFFieldTitle">Trailer ID</span>
<span class="UDFFieldValue">TRAIL1</span>
<span class="UDFFieldSubtext">Sub</span>
<span class="UDFFieldPost">Post</span>
</div>
** UDFFieldN - Numeric
<div class="UDFField UDFFieldN" id="UDFForm_Difficult_Delivery_Disclaimer_WEIGHT">
<span class="UDFFieldTitle">Weight</span>
<span class="UDFFieldValue">123.456</span>
</div>
** UDFFieldB - CheckBox
<div class="UDFField UDFFieldB" id="UDFForm_Difficult_Delivery_Disclaimer_CHECKED">
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Checked</label>
</span>
</div>
** {{Note}} The value will be transformed as follows:
*** "Y" - "checked="checked""
*** any other value - ""
** UDFFieldX - Checkbox List
<div class="UDFField UDFFieldX" id="UDFForm_Difficult_Delivery_Disclaimer_NARROW_ACCESS">
<span class="UDFFieldTitle">Narrow access issue</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Property entrance (front door)</label>
</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Entrance to room of choice</label>
</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Tight turn within the delivery route</label>
</span>
</div>
** UDFFieldTSC - Tri-state Check.
<div class="UDFField UDFFieldTSC" id="UDFForm_Difficult_Delivery_Disclaimer_CHECKED">
<span class="UDFFieldItem"><label><span class="UDF_TSC">X</span>Tight turn within the delivery route</label></span>
</div>
** {{Note}} The value will be transformed as follows:
*** "Y" - "&#10004;"
*** "N" - "X"
*** "N/A" 0 "N/A"
*** "" - "&nbsp;"
*** null - "&nbsp;"
** UDFFieldX2 - Tri-state Check List
<div class="UDFField UDFFieldX2" id="UDFForm_Difficult_Delivery_Disclaimer_NARROW_ACCESS">
<span class="UDFFieldTitle">Narrow access issue</span>
<span class="UDFFieldItem"><label><span class="UDF_TSC">&#10004;</span>Property entrance (front door)</label></span>
<span class="UDFFieldItem"><label><span class="UDF_TSC">N/A</span>Entrance to room of choice</label></span>
<span class="UDFFieldItem"><label><span class="UDF_TSC">X</span>Tight turn within the delivery route</label></span>
</div>
** UDFFieldDDL - Drop-down List
<div class="UDFField UDFFieldDDL" id="UDFForm_Difficult_Delivery_Disclaimer_LEVEL">
<span class="UDFFieldTitle">Enter Level</span>
<span class="UDFFieldValue">Half</span>
</div>
** UDFFieldA - Text Area
<div class="UDFField UDFFieldA" id="UDFForm_Difficult_Delivery_Disclaimer_COMMENTS">
<span class="UDFFieldTitle">Comments</span>
<span class="UDFFieldValue">Some comments</span>
</div>
** UDFFieldL - Label
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_SECTION1">SECTION 1:</div>

Example:
<code>
<div class="UDFForm" id="UDFForm_TNCSPREJOBD">
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_SECTION1">SECTION 1: To be completed by the Oak Furniture Land Delivery Team</div>
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_DIFFICULT_DELIVERY">Why is the delivery difficult? Please tick the relevant box(es) below.</div>
<div class="UDFField UDFFieldX" id="UDFForm_Difficult_Delivery_Disclaimer_NARROW_ACCESS">
<span class="UDFFieldTitle">Narrow access issue</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Property entrance (front door)</label>
</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Entrance to room of choice</label>
</span>
<span class="UDFFieldItem">
<label><input type="checkbox" checked="checked" />Tight turn within the delivery route</label>
</span>
</div>
<div class="UDFField UDFFieldX" id="UDFForm_Difficult_Delivery_Disclaimer_OBSTRUCTION">
<span class="UDFFieldTitle">Obstruction that can't be easily moved</span>
<span class="UDFFieldItem">
<label>
<input type="checkbox" checked="checked" />Low ceiling</label>
</span>
<span class="UDFFieldItem">
<label>
<input type="checkbox" checked="checked" />Bannister that reduces space to move need to manoeuvre item</label>
</span>
<span class="UDFFieldItem">
<label>
<input type="checkbox" checked="checked" />Low hanging light fitting</label>
</span>
<span class="UDFFieldItem">
<label>
<input type="checkbox" checked="checked" />Existing large furniture</label>
</span>
</div>
<div class="UDFField UDFFieldA" id="UDFForm_Difficult_Delivery_Disclaimer_OTHER">
<span class="UDFFieldTitle">Other, please give details</span>
<span class="UDFFieldValue"></span>
</div>
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_SECTION2">SECTION 2: To be signed by the customer</div>
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_ACKNOWLEDGE">I acknowledge that there is not safe, clear and adequate access for delivery, as required under sections 9.8.1 and 9.8.2 of the JB Global Limited's terms and conditions. I wish to proceed with the delivery and have been advised of the risk of damage to property which might occur as a result.</div>
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_SECTION81">8.1 | Please check the measurements and delivery access to Your home. It is important to check the measurements of Your Products by visiting Our Website or by calling Our customer service team. Please ensure that there is adequate doorway and stair access. We cannot accept any liability for any extra costs incurred by You as a result of incorrect or incomplete measurements or information supplied by You.</div>
<div class="UDFField UDFFieldL" id="UDFForm_Difficult_Delivery_Disclaimer_SECTION82">8.2 | Please check that the route from the lorry to Your room of choice is safe and free from potential problems or hazards. As Our staff have not visited Your home and cannot advise whether Your Products will fit, We ask that You take reasonable steps to ensure that the Products can be successfully delivered to You. This includes making sure that the lorry can get to You and measuring any door or ceiling heights, plus twists and turns (including Your stair banister) that might cause difficulties when We deliver. Your order will typically be delivered via a large lorry, so please be sure Your property is accessible for this type of vehicle. If You think there may be an issue, please call Us prior to delivery.</div>
</div>
...
<div class="UDFForm" id="UDFForm_Returns_Only">
<div class="UDFField UDFFieldL" id="UDFForm_Returns_Only_TITLE">RETURNS ONLY</div>
<div class="UDFField UDFFieldL" id="UDFForm_Returns_Only_TANDCS">
I, the customer, confirm all delivery labels containing my personal details have been removed prior to the item being returned.
</div>
</div>
</code>

=== UDF Formatting ===
The following standard styles will then be available to be used:
.UDFForm {}
.UDFForm > div {}

.UDFField {}
.UDFFieldL {}
.UDFFieldT {}
.UDFFieldN {}
.UDFFieldB {}
.UDFFieldX2 {}
.UDFFieldTSC {}
.UDFFieldDDL {}
.UDFFieldX {}
.UDFFieldA {}

.UDFFieldTitle {}
.UDFFieldValue {}
.UDFFieldSubtext {}
.UDFFieldPost {}
.UDFFieldItem {}

The following style elements will be added as a defauklt:
.UDFFieldA .UDFFieldValue {
min-height: 3em;
}
.UDFFieldItem {
padding: 0.2em;
}
.UDFFieldX > span {
padding: 0.5em;
display: block;
}
.UDFFieldSubtext {
width: 65%;
float: left;
font-size: 0.5em;
}
.UDFFieldPost {
width: 30%;
float: right;
font-size: 0.5em;
}
.UDF_TSC .UDF_CHECK{
display: inline-block;
min-width: 2em;
padding: 0.3em 0.0em 0.3em 0.0em;
font-size: 0.7em;
border: solid #AAA 1px;
background-color: #EEE;
color: black;
text-align: center;
margin-right: 1.0em;
min-height: 1.4em;
vertical-align: middle;
border-radius: 3px;
}
All default styling will be added to the standard Configurable POD report in a new style tag applied to the ConfigPOD.aspx file.

==== Design considerations ====
Each field can be styled by ID or class, with class per field or class per field type.

Each element of a field type can be classed individually by chaining the styles. So, title can be styled generically through ".UDFFieldTitle", and specifically for Text Areas using ".UDFFieldA .UDFFieldTitle".

As forms are ID'd by the UDF type, each UDF form can be styled completely separately by chaining the the styles. So, a field in one form may have a black border, whilst a field in another may have a red border. This would be styled as follows:
div#UDFForm_Returns_Only .UDFField { border: solid black 1px;}
div#UDFForm_Difficult_Delivery_Disclaimer .UDFField { border: solid red 1px;}

This allows for generic styling of all fields uniformly, with exceptions for certain forms, field types or specific fields.

=== Mobile Device Changes ===
Code in SystemUtilities.js will be modified for this fix.

On completion of a pre-job signature, the callback function (defined in SystemUtilities.funNextJobStartTask, case EPOD.jobStartTask.PRE_JOB_SIGNATURE) will be modified to check the index of the T&Cs used (p_intTncId). If this index is non-0, then the T&Cs used are from the standards created against the job group - this functionality will remain unchanged.

If the index is 0, the completed T&Cs will be saved in SIG_TNC_CHECKS of the PDASIGNATURE record created.

The process of sending back these checks will ensure that they are XML-encoded in the message, if this is necessary to store the values correctly in the server when processing the message.

=== Changes to the Web Service from Mobile Devices ===
The mobile device web services processing module (MessageProcess.cs) will be modified to store the XML in SIG_TNC_CHECKS as XML, when updating the job in MessageProcess.ProcessJob. The structure, regardless of whether this is standard or UDF T&Cs is as follows:

For UDF:
<SIG_TNC_CHECKS>
<FORM ...>
...
</FORM>
</SIG_TNC_CHECKS>

For Standard T&Cs
<SIG_TNC_CHECKS>
<INPUT type="checkbox" checked="checked">First Check</INPUT>
<INPUT type="checkbox" checked="checked">SecondCheck</INPUT>
<INPUT type="checkbox" checked="checked">Third Check</INPUT>
</SIG_TNC_CHECKS>

=== New POD Report Format ===
The new POD report will be formatted as described in the requirements.

A prototype has been created in the development environment, as shown in the overview section.

Notes:
* "I, the customer"... - This will be taken from the standard terms and conditions of the job group for that job (EPOD_JOB.EPL_TNCS). The text will be as configured for that job group. It is expected that this will be configured as "I, the customer, acknowledge receipt of goods" for deliveries and "I, the customer, acknowledge collection of goods" for collections.
* The Failed Delivery Checklist section will be displayed only if the job has been cancelled.
* The new back page and footer will be part of the final footer, not the page footer.
* The new back page will be sectioned in a div that will throw a page break when printed, repeating the header and populated from pre-job T&Cs.
* The Difficult Delivery Disclaimer (sections 1 and 2 and signature section on the back page) will be produced from the pre-job T&Cs for delivery jobs. This will be created from the UDF element directly i.e. EPOD_SIGNATURE.SIG_TNC_CHECKS.
* The Difficult Delivery Disclaimer signature section will be populated from the data on EPOD_SIGNATURE.
* The Returns Only section will be produced from the pre-job T&Cs for delivery jobs.
* The Returns Only signature section will be populated from the data on EPOD_SIGNATURE.
* The Difficult Delivery Disclaimer will only be present if there is a pre-job signature for a delivery job.
* The Returns Only section will only be present if there is a pre-job signature for a collection job.
* In the case where this is a delivery job and no difficult delivery disclaimer has been issued, the back page will be omitted (hidden).
* The pre-job T&Cs will be formatted using the new classes for styling UDF forms.

The report will be created as a new POD report, ''not'' over-writing the existing report.


= TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test the new JB Global POD report
|MenuAccess=N/A
|Prerequisites=As shown in the specification
|Objective=To test that the POD report displays in the correct format, displaying the correct elements on the final page
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Area being tested in this cycle
|Notes=Ensure that the system is configured as per the specification (with Pre-job Signature UDF T&Cs for collections and deliveries). Ensure that the system is configured for optional pre-job signatures for a delivery job group and required pre-job signatures for a collection job group. Ensure that both job groups are configured for the new POD report format. Create 3 jobs (2 deliveries and 1 collection).
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the first delivery job, selecting several reasons and entering additional text in the OTHER text box. Run the report.
|Result=The report is produced in the correct format and includes the final page, showing the details of the entered delivery disclaimer.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the second delivery job, skipping pre-job signature entirely. Run the report.
|Result=The report is produced in the correct format and does not include the final page.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the collection job, entering the Return Only arrival signature. Run the report.
|Result=The report is produced in the correct format and includes the final page, showing the Return Only section without other details.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_AppendixNew
|Appendix=A
|Estimate=Y
|Glossary=EPOD2
|Ref1=[[REQ 354567 JB Global POD Note Changes]]
|RefV1=1.1
|RefDate1=18/02/2019
|REQ=3.25
|EST=0
|FS=1.5
|TS=0
|DEV=2.0
|ST=0.75
|IMP=1.0
|PM=0.5
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
|Rev2=Nav Mohammed
|Rev2Title=Customer Representative
}}</div>
[[Category:{{#var:Client}} FS]]

REQ 354567 JB Global POD Note Changes

2019-02-18T14:30:33Z

BAP: v1.1 - Initial release to client

<div class="noprint">
{{#vardefine:Client|JGB}}
{{#vardefine:ClientName|JB Global}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|JB Global POD Note Changes}}
{{#vardefine:Version|1.1}}
{{#vardefine:Date|18th February 2019}}
{{#vardefine:Reference|354567}}
{{#vardefine:Year|2019}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Introduction =

This document relates to {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to describe the requirements gathered from {{#var:ClientName}} regarding changes required to the POD note.

This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
This document is based on the documentation provided by {{#var:ClientName}} and additional points clarified and confirmed by {{#var:ClientName}} in subsequent discussions and emails.


* The changes will be made in the latest version of the {{#var:System}} system, operating the Android version of the C-ePOD Client application.


{{ #vardefine: SCR | 0 }}


= Client Requirements =
I have attached the new POD to this email. Please generate an estimate for the changes required and let me know when you can make them. Just to note, any config changes will need to be applied to all ePod sites, as we'd need these changes to be applied system wide.

== Additional points confirmed ==
* Print images on a following page as with the current delivery note.
* ePOD has no telephone number 3 so this will be blank.
* Print the name and signature side by side to allow more vertical room for the signature.
* If the delivery has more than 14 lines then the report will throw a page after the 14th line (the footer area will be blank). The next page will include the header again, the rest of the lines and the footer. The third page will then be the disclaimer.
* Using multiple fonts for the T&Cs is not necessary if this requires the text to be hard-coded. It is more important that the T&Cs can be edited in future.
* To support the new POD design, corresponding changes will be required to the configuration of the User-defined Field (UDF) forms currently in use:
** The "Difficult Delivery" information dialogue will be on a new UDF form for "Arrivals Terms and Conditions for Deliveries".
*** This will include capture of the driver's Q&A and the customer's signature. The driver will answer the questions then hand the PDA to the customer to sign.
*** The difficult delivery disclaimer will appear as the terms & conditions below the signature box and the driver's Q&A below that (so the customer will sign against both the disclaimer and the driver's answers, which also both appear on the disclaimer page of the POD).
*** If there isn’t a problem with access then the driver can skip the form.
** The existing form for capturing the "Difficult Delivery" information is no longer required and will be removed. This is the "Job Details - When Amended" UDF form.
** The Returns disclaimer will be on a new UDF form for "Arrivals Terms and Conditions for Collections". This will include capture of the customer's signature with the disclaimer text below the signature box.
** The failure reason, return no. and card no. are entered on a "Job Cancellation" UDF form, which will remain in use.
* Collection jobs will show alternative text to delivery notes in these places:
** The document title will change from "DELIVERY NOTE" to "COLLECTION NOTE".
** The text against the customer signature will change from "I, the customer, acknowledge receipt of goods" to "I, the customer, acknowledge collection of goods".
** The text "FAILED DELIVERY CHECKLIST TO BE COMPLETED BY DRIVER" will become "FAILED COLLECTION CHECKLIST TO BE COMPLETED BY DRIVER"

[[File:JBG POD page 1.jpg|border|600px]]

[[File:JBG POD page 2.jpg|border|600px]]


{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

REQ 354567 JB Global POD Note Changes

2018-12-21T12:28:37Z

BAP: V 0.1 - Initial draft

<div class="noprint">
{{#vardefine:Client|JBG}}
{{#vardefine:ClientName|JB Global}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|ePOD - Changes to JB Global POD Note}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|21st December 2018}}
{{#vardefine:Reference|354567}}
{{#vardefine:Year|2018}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
=Requirements=
I have attached the new POD to this email. Please generate an estimate for the changes required and let me know when you can make them. Just to note, any config changes will need to be applied to all ePod sites, as we'd need these changes to be applied system wide.

Points confirmed:
* Print images on a following page as with the current delivery note.
* ePOD has no telephone number 3 so will be blank.
* Print the name and signature side by side to allow more vertical room for the signature.
* If the delivery has more than 14 lines then the report will throw a page after the 14th line (the footer area will be blank). The next page will include the header again, the rest of the lines and the footer. The third page will then be the disclaimer.
* Using multiple fonts for the T&Cs is not necessary if this requires the text to be hard-coded. It is more important that the T&Cs can be edited in future.
[[File:JBG POD page 1.jpg|caption "POD note - Front page"]]
[[File:JBG POD page 2.jpg|caption "POD note - Disclaimer"]]

{{Doc_Appendix
|Appendix=A
|Estimate=N
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>

File:JBG POD page 2.jpg

2018-12-21T12:02:42Z

BAP: uploaded a new version of "File:JBG POD page 2.jpg": Adjusted crop to remove left border

JB Global POD layout page 2 (disclaimer) for REQ 354567

File:JBG POD page 2.jpg

2018-12-21T11:48:31Z

BAP: JB Global POD layout page 2 (disclaimer) for REQ 354567

JB Global POD layout page 2 (disclaimer) for REQ 354567

File:JBG POD page 1.jpg

2018-12-21T11:47:45Z

BAP: JB Global POD layout page 1 for REQ 354567

JB Global POD layout page 1 for REQ 354567

EPOD - Changes to FH Brundle POD Note

2018-11-14T18:15:21Z

BAP: V 0.1 - Initial draft

<div class="noprint">
{{#vardefine:Client|BRU}}
{{#vardefine:ClientName|FH Brundle}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|ePOD - Changes to FH Brundle POD Note}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|14th November 2018}}
{{#vardefine:Reference|354175}}
{{#vardefine:Year|2013}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=REQ {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
=Requirements=
* Show long description instead of short description.
* Remove Salesperson from the header.
* Show driver name and signature for unmanned deliveries.
** Note - To be confirmed - Where this should appear and how to indicate the that the customer was not present.
* Include photos for quantity changes & cancelled items.
** Note - If other photos are taken, they will be included also, e.g. job photo, driver signature.
* Note - Possible layout improvements (to be confirmed).
** Reduce spacing between heading items (logo, title, customer details).
** Move the 'Ordered By' block onto the same row as 'Deliver To' and delivery references.
* Note - This development is to be released with a fix to the report pagination.

{{Doc_Appendix
|Appendix=A
|Estimate=N
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=N
|Rev1=Barry Preece
|Rev1Title=OBS Project Manager
}}</div>

FS 353641 WEBFLEET Concurrent Updates to EPOD

2018-11-08T09:40:36Z

BAP: v1.0 - Issue for development

<div class="noprint">
{{#vardefine:Client|PROD}}
{{#vardefine:ClientName|OBS Logistics Ltd}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|WEBFLEET Concurrent Updates to EPOD}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|8th November 2018}}
{{#vardefine:Reference|353641}}
{{#vardefine:Year|2018}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
This is a product enhancement.

To enhance WEBFLEET integration to filter and accept status updates from both WEBFLEET and the ''CALIDUS'' ePOD mobile device application.

The WEBFLEET update interface was developed for Greene King which does not include the ''CALIDUS'' ePOD mobile application, so for example an arrival message from TomTom and ePOD mobile device applications can overwrite each other when they are processed into ''CALIDUS'' ePOD.

We require the ability to select which messages are accepted from which source when ePOD mobile is implemented alongside TomTom WEBFLEET, so we have a generic integrated solution.

This requirement arose from the sale to AB Texel.

== Solution Overview ==
EPOD has functionality to:
* Create WEBFLEET orders assigned to a vehicle
* On-device integration
** Show maps (ad hoc)
** Switch to WEBFLEET
** Get User
** Get Vehicle
* Get updates in from WEBFLEET (based on WEBFLEET orders above)

The interface currently works as follows, with the restrictions as shown below:
* WEBFLEET orders are assigned to a vehicle, not a trailer or driver.
* WEBFLEET always updates the applicable dates if we get the messages in, so a job completion will update the END date in EPOD, a job start will always update the START date, etc.
* C-ePOD mobile devices also always update the dates when the data is received in:
** Job Lock always sets the Actual Start Date and Time and GPS
** Job Arrival always sets the Arrival Date and Time and GPS
** Job Update always sets the Actual Start and End Date and time.
* Therefore both updates will overwrite the other, depending on which update is processed into the system first- there is currently no way or predicting which will process first, given the delay receiving data from WEBFLEET.
* It is not possible to control which order updates the system receives from WEBFLEET - the system either receives ALL the order updates or none of them.
* Although it is possible to control the WEBFLEET workflow i.e. remove job completion, it is believed that this simply marks the job as complete when the drivers arrive at the order's address and therefore the system would still receive a final order completion update message, which for certain operations (like AB Texel) is undesirable.

The development required is to acknowledge that there are updates from multiple sources and identify which source is the primary source of data. The data being controlled by this will be:
* Actual Start Date/Time
* Arrival Date/Time
* Actual End Date/Time
This will be configured against the site.

The WEBFLEET updates import and EPOD Device web service will be modified to obey the following rules:
* When primary, ALWAYS update data fields being affected.
* When not primary, ONLY update data if there is nothing already in the data fields being affected.

Additionally, the WEBFLEET updates import process will include configuration within the WEBFLEET import configuration itself to control which order update messages the process will deal with, so that the process can block WEBFLEET Complete messages.

Additional time will be added for analysis and testing of this change.

== Scope ==
It should also be noted that certain parts of this WEBFLEET update interface are explicitly blocked from working when running alongside the ''CALIDUS'' ePOD mobile device application, namely:
* Status Updates (i.e. order rejections, cancellations and completions on WEBFLEET to not update the status in EPOD).
* Ad Hoc Breaks created in WEBFLEET do not create when EPOD is working.
Changes to these areas are not included as part of this change.

This change assumes that each process can update only once from the core messages (WEBFLEET and C-ePOD Mobile Device).

The changes specified here will allow control of which interface is the primary source of data for Start, Arrival and End Date only and the configuration of whether messages are processed ONLY. The changes here do not allow for storing the data from both systems concurrently for later viewing. If the primary source of data for those fields has been provided, it will be stored and displayed. If the primary source of data for those fields has not been provided and the secondary source has, then the secondary source will be stored and displayed.


= Set-up =
== Pre-requisites ==

== Menu Structure ==

== Data ==
The following Import/Export Interface Configuration is required:
* C-ePOD Import and Export interfaces will be configured to send orders to WEBFLEET and to accept updates from WEBFLEET.
Note that the expected configuration of the TomTom Orders Update interface (inbound direction) is expected to be configured for the primary implementation for Start and Arrival message types ("S|A") only.

The following Site configuration is required:
* C-ePOD NOT set up as PvA system.
* C-ePOD set up to have no Arrive functionality.
* WEBFLEET Updates configured.
Note that the expected configuration for the primary implementation for WEBFLEET to be the primary source of Start and Arrival data only.

The following Standing Data is required:
* WEBFLEET Object IDs must be configured against the vehicles in C-ePOD.
* WEBFLEET user names and C-ePOD PDA user names must be the same for automatic logon to WEBFLEET devices to work.

The following TomTom WEBFLEET configuration is required:
* The WEBFLEET work-flow modified to have Start and Arrive but no Complete stage.
* A listening queue is created in WEBFLEET through the web services.
* WEBFLEET user names and C-ePOD PDA user names must be the same for automatic log-on to WEBFLEET devices to work.


= Functional Description =
== Database/DAL ==
New fields will be added to EPOD_SITE:
* EPL_XFI_START_IND - int, default 0
* EPL_XFI_ARRIVAL_IND - int, default 0
* EPL_XFI_END_IND - int, default 0

These fields will be added to all stored procedures in the database that require them.

These fields are not required on the device.

These fields are not required to be contained within the Export.

These fields are not required to be used when filtering data for selection.

== C-ePOD Admin ==
=== Site Configuration Screen ===
The Site configuration screen (Site.aspx) will be modified to allow the new Site flags to be maintained.

A new tab will be added to the Tab Group, labelled as "Import/Export".

The existing flags in Import/Export panel of the Admin tab will be moved here.

The new tab will be organised in two sections:
* The left will be the existing flags
* The right will be WEBFLEET-related flags, labelled as such.

The new flags will be added to the WEBFLEET area. Each will be added as check boxes, with pop-up help
* Field EPL_XFI_START_IND, Label "WEBFLEET Update Job Start", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job Start Date and Time?".
* Field EPL_XFI_ARRIVAL_IND, Label "WEBFLEET Update Job Arrival", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job Arrival Date and Time?".
* Field EPL_XFI_END_IND, Label "WEBFLEET Update Job End", pop-up help (title) "If the WEBFLEET update is enabled, is this process the primary source of data for the Job End Date and Time?".
The default state of these flags will be unchecked.

Each flag will allow the following values:
* "Primary" (checked)
* "Secondary" (unchecked)

All tabs affected will be checked to ensure that the fields are displayed using available space on multiple window sizes - a clean display using available space is required.

=== Import/Export Interface Screen ===
The Import/Export Interface screen (XF_Config.aspx) will be modified for this change.

Field EPL_EXPORT_JOB_TYPES will be enabled for "TO" ID configurations, Inbound direction (value "I") only. This will control what types of updates are processed:
* "S" - Job Start
* "C" - Job Complete
* "A" - Job Arrival
* "X" - Job Cancel/Reject
Each value will be specified in the parameter if the messages of this type are to be processed, typically in a single string, for example:
* "SCAX" - all updates allowed
* "SAX" - all except Complete messages
* "SA" - Start and Arrival only
It is recommended that these values are delimited with vertical bar for clarity, for example:
* "S|C|A|X"

The entry field (currently txtExportJobTypes) will be displayed with a label "Message Types" and will have a custom validator to validate the entry (in this case) to variants of "S", "C", "A", "X" or a blank field.

== Mobile Device Update Process ==
The web services processing update messages from the mobile devices will be modified for this change.

The following message types are affected:
* JOB_LOCK_REQUEST - when a job is started
* JOB_ARRIVAL_REQUEST - when a job is arrived
* JOB_UPDATE - when a job is finally updated as complete or cancelled.

These are processed in MessageProcess.cs.

When processing Job Lock messages (in function ProcessJobLockRequest), the process will check the site configuration. If EPL_XFI_START_IND is set to 0, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 1, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.

Note that this process is also responsible for the setting of Arrival date and time (in EPL_ARRIVAL_DATE/TIME). When updating arrival date and time from this message, the process will check the site configuration. If EPL_XFI_ARRIVAL_IND is set to 0, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.

Job Update processing can be used to set Job Start, Arrival and End dates, as it is a final update of all data after the job is completed.

When processing Job Update messages (in function ProcessJobUpdate), the process will check the site configuration.

When updating the Start Date and Time, if EPL_XFI_START_IND is set to 0, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 1, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.

When updating the Start Date and Time, if EPL_XFI_ARRIVAL_IND is set to 0, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.

When updating the End Date and Time, if EPL_XFI_END_IND is set to 0, then the process will over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME. If EPL_XFI_END_IND is set to 1, then the process will check the value of EPL_END_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME.

== Auto-Import Process ==
The Auto-Import process will be modified to handle this new configuration.

The core changes are to module EPOD_TOMTOM_WEBFLEET.cs, in the following procedures:
* ProcessTomTomWEBFLEETImport
* ProcessMsgQueueResponse
* PopulateFromMsgQueueResponse
These processes require an additional parameter passed to them (from EPOD_XF_CONFIG.EPL_EXPORT_JOB_TYPES) to pick up the message types that the process is going to deal with (and more importantly to filter out).

Class OrderType is used defines the types of messages - the process uses this to determine what action to take based on the message from WEBFLEET.

The parameter set from EPL_EXPORT_JOB_TYPES will be checked for the configuration of which messages to process.
* If the field is empty, all messages will be processed as now.
* If the field contains "S", messages of OrderType.JobStart will be processed.
* If the field contains "A", messages of OrderType.JobArrival will be processed.
* If the field contains "C", messages of OrderType.JobComplete will be processed.
* If the field contains "X", messages of OrderType.JobCancelOrReject will be processed.

When processing OrderType.JobStart messages, the process will check the site configuration. If EPL_XFI_START_IND is set to 1, then the process will over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME. If EPL_XFI_START_IND is set to 0, then the process will check the value of EPL_START_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_START_ACTUAL_DATE and EPL_START_ACTUAL_TIME.

When processing OrderType.JobArrival messages, the process will check the site configuration. If EPL_XFI_ARRIVAL_IND is set to 1, then the process will over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME. If EPL_XFI_ARRIVAL_IND is set to 0, then the process will check the value of EPL_ARRIVAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_ARRIVAL_DATE and EPL_ARRIVAL_TIME.

When processing OrderType.JobComplete messages, the process will check the site configuration. If EPL_XFI_END_IND is set to 1, then the process will over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME. If EPL_XFI_END_IND is set to 0, then the process will check the value of EPL_END_ACTUAL_DATE. If this is set no a non-0 or non-null value, then the process will not over-write the data in EPL_END_ACTUAL_DATE and EPL_END_ACTUAL_TIME.

Regardless of the setting of these new Site flags, the process will log the message from TomTom WEBFLEET in the audit log as now.


= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=A test of WEBFLEET and EPOD updating together.
|MenuAccess= 
|Prerequisites=A configured and connected EPOD and WEBFLEET system and a TomTom PRO device.
|Objective=The test is designed to check the functionality as required by the primary implementation only.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Job Updates
|Notes=Configure as the primary implementation requires (as identified in the specification).
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Create a Load and a Job. Assign the load to a vehicle linked to a WEBFLEET vehicle. on the PRO device, ensure that the device is logged in to WEBFLEET. Start EPOD and log in (if not automatically logged in)
|Result=The load is assigned to the user/vehicle in EPOD, as status "In Progress". The order is seen against the vehicle in WEBFLEET.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the job in EPOD, then click the Map icon in Job Details
|Result=WEBFLEET starts on the device.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the order from the work list. Accept it, the start it.
|Result=EPOD is updated with the Start Date and Time.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Arrive the job in WEBFLEET.
|Result=EPOD is updated with the Arrival Date and Time.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Return to the EPOD application on the PRO device and click Start.
|Result=The start date and time in EPOD is not overwritten.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Complete the job on EPOD.
|Result=EPOD is updated with the End Date and Time. The start and Arrival dates and times in EPOD are not overwritten.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0
|FS=1
|TS=0
|DEV=3
|ST=1.75
|IMP=.50
|PM=0.25
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Matt Turner
|Rev1Title=''CALIDUS'' ePOD Account Manager
|Rev2=Barry Preece
|Rev2Title=Primary Implementation Project Manager
}}</div>
[[Category:{{#var:Client}} FS]]

FS 352946 Mash OTIF Report

2018-10-23T11:10:53Z

BAP: v1.0 - Initial release to client

<div class="noprint">
{{#vardefine:Client|MASH}}
{{#vardefine:ClientName|Mash Purveyors}}
{{#vardefine:System|''CALIDUS'' ePOD}}
{{#vardefine:Doc_Title|Mash OTIF report}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|23rd October 2018}}
{{#vardefine:Reference|352946}}
{{#vardefine:Year|2018}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =
== Client Requirement ==
The requirement is for ''CALIDUS'' ePOD to report On Time delivery performance.

{{Note}} Jobs with no arrival date must also be reported.

== Solution Overview ==
The report will be added to the Reports menu.

On selection of the Mash On Time report, the screen will offer the user to enter the following parameters.
* Date Range - a date range from/to. Today's date will be selected and a date range must be entered.
* Customer - a drop-down list of all customers. "All" may be selected and is the default.
* Route - a drop-down list of all routes within the date range. "All" may be selected and is the default.
* Load - a drop-down list of all routes within the date range, for the route (if selected). "All" may be selected and is the default.
* Type - A drop-down list selecting whether collections, deliveries or all job types are reported on. "All" is the default.

On confirming the parameters, the report will be generated, displaying the following fields:
* Customer account code
* Customer name
* Load ID
* Job Code (Mash order ref)
* Job Status (C = Complete, X = Cancelled)
* Job level reason code
* Job sequence number (within the load)
* Service Level
* Start Planned Time
* Actual arrival time confirmed by the driver
* OT Status

C-ePOD reports are in the form of a spreadsheet extract which can be requested by users and then edited and manipulated in Excel, etc.

== Scope ==
Note that the ‘In Full’ requirement is not part of this request (it may be reported from the Chefserve ERP system or added later in ePOD).

Note that there is no feature in ePOD to schedule reports to run automatically.

This format requires that Route Code is provided on data import through the field EPOD_LOAD.EPL_ROUTE_CODE. If this is not provided, then Route Code selection will allow only the option of "All Routes for Date Range".


= Set-up =
== Pre-requisites ==
N/A

== Menu Structure ==
N/A

== Data ==
The default values for the Job Type selection will be set up in the database:
* All - NULL (default value)
* Collection Only - "C"
* Delivery Only - "D"

A new option of "Mash On Time Report" (value 5) will be added to the drop-down list of reports, through the data on table EPOD_LIST_ITEMS, for ListName "ddlReportSelect".

These options will be pre-set in the database through an amendment to the EPOD_SETUP_LISTS database procedure.


= Functional Description =
== Database/DAL ==
Table EPOD_LOAD may require modification to have the following index created:
* EPL_SITE_ID, EPL_ROUTE_CODE, EPL_LOAD_ID
To accommodate this, the EPL_ROUTE_CODE field may need data-fixing to default Route Code to Blank rather than NULL.

{{Note}} To be evaluated as part of development.

== Admin Reports Screen ==
The existing screen ExcelReports will be modified for this change.

A new option of "Mash On Time Report" will be added to the drop-down list of reports, through the data on table EPOD_LIST_ITEMS.

When selected, the screen will offer the following parameters:

* ''Customer Code'' - a drop-down list of customers. Required selection?
* ''Date Range'' (From/To) - date selection. Required. Date From and To will default to today. If modifying these criteria, the Date To must be later than Date From.
* ''Route'' - A drop-down list of field EPL_ROUTE_CODE from table EPOD_LOAD, for Loads within the specified range and default site only. The data for this will be selected based on the Date Range entered (and triggered from either change of these fields or immediately upon clicking this drop-down list). The default value is "All Routes for Date Range".
* ''Load'' - A Drop-down list of field EPL_LOAD_ID from table EPOD_LOAD where EPL_SITE_ID is the current site and an EPL_START_ACTUAL_DATE is populated and within the Date Range selected. If a route is selected, it is also only for loads of that Route Code only. The data for this will be selected based on the Date Range and Route entered (and triggered from either change of these fields or immediately upon clicking this drop-down list). The default value is "All Loads for Date Range/Route".
* ''Job Type'' - A drop-down list to determine which of these should be included in the report (All/Collection Only/Delivery Only). Values should be based on predefined values set up in the database table EPOD_LIST_ITEMS. Default value is "All".

{{Note}} All data selection for the parameters will be pre-filtered by the logged-on user's defined Site.

{{Note}} The method of triggering data refresh for the Route and Load drop-down lists will be evaluated during development.

Once entered and the Create Excel Spreadsheet button is clicked, the parameters will be validated as above.

If the parameters pass validation, the report will select data and create the spreadsheet. All procedures in this screen will be modified to support this new report, running a new method of XLReports, called MashOTIFReport to generate the SQL and get the results.

This method will select the data by generating a SQL query and returning a data table.

This method will accept parameters of all the parameters listed above, also including:
* db - the database connection
* EPL_SITE_ID - the current site.

Data will be selected from the following tables:
* EPOD_JOB
* EPOD_LOAD
* EPOD_CUSTOMER
These records will be joined in the order above, through their proper indexes and are required to be present to select data (INNER JOIN).

EPOD_JOB will be selected as follows (parameters in {Curly Brackets}):
* EPL_SITE_ID = {Current Site}
* EPL_CUSTOMER_CODE = {Customer ID} if provided.
* EPL_END_ACTUAL_DATE >={Date From}
* EPL_END_ACTUAL_DATE <={Date To}
* EPL_JOB_TYPE = {Job Type} (if provided)
* EPL_LOADING_TYPE = "" (i.e. not Loading or Unloading jobs at the depot)
* EPL_STATUS = "C" or "X".

EPOD_LOAD will be selected as follows:
* EPL_SITE_ID = {Current Site}
* EPL_ROUTE_CODE = {Route Code} if provided.
* EPL_LOAD_ID = {Load ID} if provided.

{{Note}} With this mechanism, ''only'' jobs that have been completed - status Cancelled (X) or confirmed delivered/collected (C) - will be selected. They will appear on the report on the day that they were completed.

The process will run this generated SQL, then format the results into an Excel spreadsheet format. Note that the titles of each field must be set as shown in the Column Title below.

The resulting dataset will be loaded into a datatable and the dataset returned.

The process will populate the Excel report in exactly the same way that it does for other reports.

The output in Excel format. Column titles will be formatted as normal, with no additional formatting in fields or additional rows.

Columns reported:
{| class="wikitable" border="1"
|- bgcolor="silver"
!Title !!Field name !!Notes
|-
| Customer Code || EPL_CUSTOMER_CODE || Customer account code
|-
| Customer Name || EPL_CUSTOMER_NAME || Customer name
|-
| Load ID || EPL_LOAD_ID || Load ID
|-
| Job Code || EPL_JOB_CODE || Job Code (Mash order ref)
|-
| Status || EPL_STATUS || Job Status (C = Complete, X = Cancelled, I = In Progress, P = Pending)
|-
| Reason || EPL_REASON_CODE || Job level reason code
|-
| Sequence || EPL_SEQUENCE || Job sequence number (within the load)
|-
| Service || EPL_SERVICE_LEVEL || e.g. "09:30 - 12:00"
|-
| Planned || EPL_START_PLANNED_DATE/TIME (formatted) || Will match the 'to' time in the service level (12:00 in above example)
|-
| Actual || EPL_ARRIVAL_DATE/TIME (formatted) || Actual arrival time confirmed by the driver
|-
| On Time || Calculated || If actual arrival date/time is later than planned date/time then "N", if there is no arrival date/time then "N" otherwise "Y".
|}

{{Note}} Dates and Times will be formatted as a Date/Time column in Excel and can then be formatted as desired when viewed (for example, to just show the time).



= Appendix A: TEST PLAN =
{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Testing the Mash On Time Report
|MenuAccess=Reports
|Prerequisites=None
|Objective=To test that: the report exists; the report parameters are present and validated correctly and: the report produces correctly showing the correct data.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Admin Reports
|Notes=Ensure that there is a variety of load and job data, with Routes.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select the reports screen and select the Mash On Time report.
|Result=The option is present and the report requires the correct parameters.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter a date range
|Result=The dates are validated correctly. The Route and Load drop-down lists are refreshed with appropriate data.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Customer
|Result=The customers displayed are appropriate to the site.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a route
|Result=The routes displayed are appropriate to the date range. The Load drop-down list is refreshed with appropriate data.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select a Job Type
|Result=The correct values are displayed in the list.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Select to run the report with a variety of parameters designed to select different data based on your configured data.
|Result=The expected data is shown in the report, with the correct columns, title and sequence. On-time is correctly identified in the report.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=EPOD
|Ref1= 
|RefV1= 
|RefDate1= 
|REQ=0
|EST=0.25
|FS=0.25
|TS=0
|DEV=1.75
|ST=0.25
|IMP=0.25
|PM=0.25
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Barry Preece
|Rev1Title=OBSL Project Manager
|Rev2=Steve Carter
|Rev2Title=Customer Representative
}}</div>
[[Category:{{#var:Client}} FS]]