FS 294838 Proctor ePOD Modifications: Difference between revisions
From Calidus HUB
No edit summary |
(0.3 - Completed Overview section and some details; Added basic estimate figures) |
||
| Line 4: | Line 4: | ||
{{#vardefine:System|''CALIDUS'' ePOD}} | {{#vardefine:System|''CALIDUS'' ePOD}} | ||
{{#vardefine:Doc_Title|Proctors ePOD Modifications}} | {{#vardefine:Doc_Title|Proctors ePOD Modifications}} | ||
{{#vardefine:Version|0. | {{#vardefine:Version|0.3}} | ||
{{#vardefine:Date|09th January 2012}} | {{#vardefine:Date|09th January 2012}} | ||
{{#vardefine:Reference|294838}} | {{#vardefine:Reference|294838}} | ||
| Line 26: | Line 26: | ||
Jobs will be received for Collection and Delivery from the following main | Jobs will be received for Collection and Delivery from the following main customer types: | ||
*Suppliers | *Suppliers | ||
*Customers | *Customers | ||
*Proctors-operated Warehouses | *Proctors-operated Warehouses | ||
*3rd Party Warehouses | *3rd Party Warehouses | ||
The jobs will be updated into the CALIDUS EPOD system through the standard WebService interface. | The jobs will be updated into the CALIDUS EPOD system through the standard WebService interface. | ||
| Line 40: | Line 38: | ||
*A Collection Job | *A Collection Job | ||
*A Delivery Job | *A Delivery Job | ||
Every Collection and Delivery will be specified separately within the interface, with the Product and Quantity specified for all jobs. Linked collections and deliveries will have the same Job ID, but will be distinguished by the Job Type (i.e. Collection, Delivery, Loading). | |||
The Upload system will also identify the Loads onto which jobs are planned, as all planning is completed through the Proctors' ERP system. | The Upload system will also identify the Loads onto which jobs are planned, as all planning is completed through the Proctors' ERP system. | ||
| Line 57: | Line 57: | ||
* Scan pallets on to the load. These will be scanned from the customers' own labels. | * Scan pallets on to the load. These will be scanned from the customers' own labels. | ||
* Complete the load and update the CALIDUS EPOD system. | * Complete the load and update the CALIDUS EPOD system. | ||
The Loading job will contain no validation or product entry - just an ad-hoc scanning of containers. | The Loading job will contain no validation or product entry - just an ad-hoc scanning of containers/pallets. | ||
The loading update process within the EPOD server will query the ERP system for details on the quantity for each pallet loaded. | The loading update process within the EPOD server will query the ERP system for details on the quantity for each pallet loaded. | ||
The pallet details will be passed to the delivery job associated to the load/collection, updating the Container and Product details with the Pallet and Product/Quantity details from the ERP system. | The pallet details will be passed to the delivery job associated to the load/collection, updating the Container and Product details with the Pallet and Product/Quantity details from the ERP system. | ||
{{Note}} If this data is not available at the time of Loading update, the system will check periodically through a regularly-scheduled automatic process. | |||
Collection jobs from a Proctors-operated warehouse will have no details associated to them - this job will simply be in instruction for a driver to drive to a location (defined by the customer code). | Collection jobs from a Proctors-operated warehouse will have no details associated to them - this job will simply be in instruction for a driver to drive to a location (defined by the customer code). | ||
| Line 67: | Line 69: | ||
The process for a Collection of this type will simply be to confirm collection through a signature. | The process for a Collection of this type will simply be to confirm collection through a signature. | ||
Collection jobs from a Customer, Supplier or 3rd party warehouse (i.e. non-Proctors) will have the Product and Quantity created against them (i.e. no containers). The process will be: | Collection jobs from a Customer, Supplier or 3rd party warehouse (i.e. non-Proctors) will have the Product and Quantity created against them (i.e. no containers/pallets). The process will be: | ||
* Confirm arrival to customer/supplier/warehouse. | * Confirm arrival to customer/supplier/warehouse. | ||
* Scan/Enter/Select Products to be collected. | * Scan/Enter/Select Products to be collected. | ||
| Line 83: | Line 85: | ||
* Scan/Enter/Select pallets being delivered | * Scan/Enter/Select pallets being delivered | ||
* Once completed, confirm delivery through customer/depot signature. | * Once completed, confirm delivery through customer/depot signature. | ||
If the Delivery has not been updated with the container details from the Loading process, the PDA will check at this time and force the retrieval of this data. If this is not available (either that the PDA cannot connect to retrieve this or the data is unavailable from the ERP system), the user will be offered the ability to scan products and quantities instead. | |||
Two new POD document formats will be created: | Two new POD document formats will be created: | ||
| Line 93: | Line 96: | ||
CALIDUS EPOD will be set up to allow certain customers to be automatically emailed upon completion of jobs to and from them. When enabled, the format associated to the Job Group will be sent to the Customer's associated email address, if there is one. | CALIDUS EPOD will be set up to allow certain customers to be automatically emailed upon completion of jobs to and from them. When enabled, the format associated to the Job Group will be sent to the Customer's associated email address, if there is one. | ||
Confirmation or cancellation of the final job on a particular reference (i.e. the final delivery of a job) will trigger an automatic update of the ERP system. This will be configurable but is expected to be through an email of the standard EPOD XML job update message. | Confirmation or cancellation of the final job on a particular reference (i.e. the final delivery of a job) will trigger an automatic update of the ERP system. This will be configurable but is expected to be through an email of the standard EPOD XML job update message. If this update is not successful, there will be a scheduled process that will regularly check and attempt to update when possible. | ||
== Scope == | == Scope == | ||
| Line 102: | Line 105: | ||
== Pre-requisites == | == Pre-requisites == | ||
For automatic updates through email and automatic emailing of POD/POC documents, the EPOD server must be configured with access to the customer's Email server. | |||
== Menu Structure == | == Menu Structure == | ||
| Line 110: | Line 114: | ||
= Functional Description = | = Functional Description = | ||
* UPLOAD - Add new fields to the Upload process | |||
* UPLOAD - Create Loading task from collection job if required | |||
* UPLOAD - Specify Job Group based on customer type | |||
* CUSTOMERS - Add Customer Type | |||
* CUSTOMERS - Add Auto Email configuration | |||
* New Loading Process | |||
* Allow Loading tasks to be visible/enterable through Admin screens | |||
* LOADING - ERP Direct Connect for Delivery Pallets information | |||
* Pass Collection modifications to associated Deliveries. | |||
* DELIVERY - Force Update to check for Loading details | |||
* Update system to identify Jobs through ID and Type. | |||
* DELIVERY - Container Only Delivery process | |||
* Auto-update Client Systems | |||
* Scheduled Auto-update process | |||
== CUSTOMERS - Add Customer Type == | |||
The ''CALIDUS'' EPOD Customers table will be modified to allow identification of the 4 main types of customer through the use of a new Customer Type field. | |||
== Loading Process == | == Loading Process == | ||
| Line 118: | Line 141: | ||
User logs on with: | User logs on with: | ||
Customer | * Customer - Valid Depot customer | ||
Username | * Username | ||
Password | * Password | ||
==== Load list ==== | ==== Load list ==== | ||
After logon users are presented with a list of loads being dispatched from Customer(Depot), at status Ready for Loading. | After logon users are presented with a list of loads being dispatched from Customer(Depot), at status Ready for Loading. | ||
As with exceptions a refresh will be sent every X seconds to update this data (only interested in changes or updates) | As with exceptions a refresh will be sent every X seconds to update this data (only interested in changes or updates) | ||
Load details: | Load details: | ||
Clicking a load will present the user with the load details. | Clicking a load will present the user with the load details. | ||
Here users can either select to begin loading or cancel to return to the previous menu. | Here users can either select to begin loading or cancel to return to the previous menu. | ||
If a user select to being loading, a message is sent back to the server advising that loading has begun, updating the status, to prevent other users from loading this load. If the load is already being loaded/ has been updated/ has been removed, the server will respond advising of this. | If a user select to being loading, a message is sent back to the server advising that loading has begun, updating the status, to prevent other users from loading this load. If the load is already being loaded/ has been updated/ has been removed, the server will respond advising of this. | ||
| Line 134: | Line 162: | ||
The user will be presented with the list of products to be loaded. Clicking a product will allow the user to specify a container either through entry or scanner and a quantity of the product to be assigned to this container. | The user will be presented with the list of products to be loaded. Clicking a product will allow the user to specify a container either through entry or scanner and a quantity of the product to be assigned to this container. | ||
Once entered a container record will be created and the proportion of the product assigned to this container will be removed from the original product record. | Once entered a container record will be created and the proportion of the product assigned to this container will be removed from the original product record. | ||
The user will then be directed to the original product list which will be updated to reflect the update. | The user will then be directed to the original product list which will be updated to reflect the update. | ||
Once all products have been loaded, the user will be asked to confirm this and the updated load details will be sent back to the server. If there are discrepancies the user will be advised, giving them the option to | Once all products have been loaded, the user will be asked to confirm this and the updated load details will be sent back to the server. If there are discrepancies the user will be advised, giving them the option to re-enter the products list. If they choose to ignore this the product record on the loose product record will be updated to advise that the actual quantity will be zero. | ||
The user will then be navigated back to the Load List. | The user will then be navigated back to the Load List. | ||
| Line 144: | Line 175: | ||
This will need to be modified to allow for customer to be used instead of site. | This will need to be modified to allow for customer to be used instead of site. | ||
The static data download will need to be altered ; | The static data download will need to be altered ; | ||
Removing: | Removing: | ||
*Service Products | *Service Products | ||
| Line 152: | Line 185: | ||
===== XML ===== | ===== XML ===== | ||
<pre> | |||
<LOGON_REQUEST_LOADING ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | <LOGON_REQUEST_LOADING ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | ||
<EPL_SITE_ID>LSM</EPL_SITE_ID> | <EPL_SITE_ID>LSM</EPL_SITE_ID> | ||
| Line 178: | Line 211: | ||
</DATA> | </DATA> | ||
</LOGON_RESPONSE_LOADING> | </LOGON_RESPONSE_LOADING> | ||
</pre> | |||
==== Job List ==== | ==== Job List ==== | ||
| Line 183: | Line 217: | ||
A job list method will need to be added providing a list of current loads. | A job list method will need to be added providing a list of current loads. | ||
<pre> | |||
<LOADING_LIST_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | <LOADING_LIST_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | ||
<EPL_SITE_ID>LSM</EPL_SITE_ID> | <EPL_SITE_ID>LSM</EPL_SITE_ID> | ||
| Line 193: | Line 228: | ||
</EPOD_JOBS> | </EPOD_JOBS> | ||
</LOADING_LIST_RESPONSE> | </LOADING_LIST_RESPONSE> | ||
</pre> | |||
==== Job Update ==== | ==== Job Update ==== | ||
| Line 198: | Line 234: | ||
A Job update method will need to be added | A Job update method will need to be added | ||
<pre> | |||
<LOADING_UPDATE_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | <LOADING_UPDATE_REQUEST ID="0" SITE="LSM" USER="ADM" PASSWORD="TEST"> | ||
<EPOD_JOB>..</EPOD_JOB> | <EPOD_JOB>..</EPOD_JOB> | ||
| Line 203: | Line 240: | ||
<LOADING_UPDATE_RESPONSE ID="0" RESULT="ACK"> | <LOADING_UPDATE_RESPONSE ID="0" RESULT="ACK"> | ||
</ | </LOADING_UPDATE_RESPONSE> | ||
</pre> | |||
== Auto Export == | == Auto Export == | ||
| Line 209: | Line 247: | ||
=== Process === | === Process === | ||
When Job update messages are | When Job update messages are received by the server and the changes are committed, the Auto Export flag will be checked against the Job Group and Site. If this flag is present the server will load the details of this export (Destination and Type), it will then generate the XML export as per the standard for currently existing exports and attempt to transfer this to the destination. | ||
If this process if | If this process if successful then a flag on the Job record will be set to Y, and a success audit record written. If this fails the flag on the job will be set to N and a record will be written to a audit table with details of the failure. If the file is send successfully but a message is received from the destination advising of this problem then a audit record will be written and the flag will be set to N. | ||
A timed process will be running to resend any Jobs with the flag of N, again | A timed process will be running to resend any Jobs with the flag of N, again writing audit records based on the result. | ||
Audit records will be written with the following status's S for success, SF for success send but error at the | Audit records will be written with the following status's S for success, SF for success send but error at the receivers, and F for failure to send. These records will be cleared down once they are older than X. | ||
==== DB Modifications ==== | ==== DB Modifications ==== | ||
| Line 248: | Line 286: | ||
Three new DAL objects will need to be created for the new tables. | Three new DAL objects will need to be created for the new tables. | ||
The JOB_UPDATE process within the Message_Process class needs to be modified to utilise the existing Data Service to perform the exports and written audit records. This should be done only once the data | The JOB_UPDATE process within the Message_Process class needs to be modified to utilise the existing Data Service to perform the exports and written audit records. This should be done only once the data received from the PDA has been successfully committed. | ||
==== Admin Modifications ==== | ==== Admin Modifications ==== | ||
A new screen will be required to | A new screen will be required to set-up and configuration data within EPOD_XF_CONFIG. | ||
EPOD_SITE and EPOD_JOB_GROUP screens will need to be altered with the addition of the EPOD_XF_CONFIG field. | EPOD_SITE and EPOD_JOB_GROUP screens will need to be altered with the addition of the EPOD_XF_CONFIG field. | ||
<!-- NEW PAGE --> | <!-- NEW PAGE --> | ||
{{Doc_Appendix | {{Doc_Appendix | ||
|Appendix=A | |Appendix=A | ||
| Line 267: | Line 304: | ||
|REQ=0 | |REQ=0 | ||
|EST=0 | |EST=0 | ||
|FS=0 | |FS=5.0 | ||
|TS=0 | |TS=0 | ||
|DEV= | |DEV=35 | ||
|ST= | |ST=5.00 | ||
|IMP=0 | |IMP=2.0 | ||
|Client={{#var:Client}} | |Client={{#var:Client}} | ||
|Year=2011 | |Year=2011 | ||
Revision as of 18:43, 9 January 2012
Proctors
Proctors ePOD Modifications
CALIDUS ePOD
09th January 2012 - 0.3
Reference: FS 294838
Note: If this data is not available at the time of Loading update, the system will check periodically through a regularly-scheduled automatic process.
