Version Number | 2.5.0 |
|---|---|
Release Date | TBC |
Other Application Requirements | SQL 2016 or late is required. |
Warnings or Notices | See marked items below - there are version requirements. |
ID | Summary | Issue Type | Affects versions | Description | Linked to | Config Needed | Licenced Module |
Report Template - Arc Field Width | Report | 2.3.0 | ARC field to be widened on the customer template. | RFC-615 | No | No | |
Reports - Performance report | Report | 2.1.0 | This has been modified as follows : Barcode - modified to show the PICKID not the order ID DP Account Ref - added to the report Date - add the Date Delivered as a new column to the report and have the search options filter by this date. | RFC-240 | No | No | |
Application licensing | New Feature | 2.4.0 | Changes to the application to integrate with the Vision licensing server, which will deliver your application licenses automatically to your desktop applications. | VC-1740 | No | No | |
Driver Duty master page | New Feature | 2.1.4 | Create a master page for adding duty instructions the database | EPOD-244 | No | No | |
GDPR changes | New Feature | 2.1.1 | GDPR changes required to Vision Distribution. You MUST have SQL 2016 or later for this version of Distribution | No | No | ||
Delivery terms & conditions | New Feature | 2.1.0 | Linked with EPOD-204, recent changes to ePOD can now require customers to accept terms & conditions prior to signing for a delivery, these can be configured by users within the application and will also be shown on the delivery notes. | EPOD-204 | No | No | |
Postal areas for non GB deliveries | New Feature | 2.1.1 | The system currently allows countries to be configured to 'use postcodes' or not, yet the postal areas are not linked to any country. Meaning postal areas Currently apply to any country if the country has 'Uses postcode' ticked. This will link postal areas to a country, so for example DE postcode 76405 will not conflict with the same postcode for FR and users will be able to define different postal areas for each country. Countries can be configured to make the postcode mandatory or not. The users base country will be mandatory We may have NL for example set up to use postcodes so if the order provides a postcode then we'll attempt to use the postal areas to set the delivery area etc, but if it's not available then we'll use the delivery area set up against the country instead as a fallback. Requires VCISB-40 and VCISB-41 to make this work (Private Client Site) | VW-3301 | No | No | |
Supplier Invoice Recording | New Feature | 2.1.0 | The ability to record your supplier invoices against the manifest. This assumes your haulier will be invoicing you for an entire manifest EXCEPT when the "Single Drops Priced" option is set when the charge needs to be per delivery on the invoice. The invoice will be recorded on the screen, you will select which manifests (or deliveries) this invoice relates to, therefore it is important to have one carrier per supplier otherwise you will find it difficult to find the entries. Each manifest will only show if there is outstanding invoice. Once this has been entered, you will be able to scan the invoice onto the system, the system will then send a copy of the scanned document and embed the manifests onto the scan/document and forward to your accounts team for payment, an accounts extract for the invoice can also be provided in Sage200 format. the assumption is that if the invoice is entered and checked on your system and you are not able to double associate invoices with manifests that effectively this is the approval for payment process. Initial Entry of the invoice will take details such as the invoice number, invoice date, supplier (carrier needs to have the accounts system code on the form) invoice amount, vat elements. You will then be able to pick up and associate either deliveries or manifests with the invoice. Only if it is complete and agrees will this be marked as AUTHORISED otherwise you will be able to save and leave items NOT associated hence a value difference and this will be marked as "CHECK INVOICE" on the information sent to the accounts team | No | Yes | ||
Manifest print - incorrectly showing ready to print | Issue | 2.4.0 | An issue was resolved - When we have a manifest which has not been finalised, and has only a single delivery on it which was then removed. the manifest then shows as ready to be printed and VDG continually keeps trying and failing to print notes for it until more deliveries are added and the load is finalised. | No | No | ||
Carrier plan - delivery defaulting to wrong carrier | Issue | 2.4.0 | Deliveries which charge pallets calculate 0 total invoice cases and as such remain with the case carrier in the carrier planning screen when they should be based off of the total calculated invoice cases. | No | No | ||
Create Delivery - Product line issue | Issue | 2.5.0 | When creating a delivery,on product line details tab it shows error upon a product entry. | No | No | ||
Coordinate retrieval - delayed status update | Issue | 2.3.4 | Once a delivery is created from a VW order the status will be P while it waits to be picked (or added to a Bulk Pick) and for it to get the coordinates. When the order is picked, and coordinates retrieved afterwards, users are kept waiting for the next scheduled execution of the VW > VD job for the status to be updated from P to O, even though it has already received the pick information. This has been improved. | No | No | ||
GeoLocation Restrictions - Route Plan | Issue | 2.3.4 | When adding a Disallowed vehicle Types on the Geolocation Restrictions - Route Planner is planning it for the transport Item that is that vehicle | VLIVE-220 | No | No | |
Deliveries - invoice pallets calculation | Issue | 2.3.3 | The invoice pallets calculation is currently using the transport discount when the cases per pallet is sufficient. | EPOD-299 | No | No | |
External carrier customer service - tracking | Improvement | 2.4.0 | Introduction of delivery tracking for supported carriers in 'External carrier customer service'. | No | No | ||
Transport BI dashboard | Improvement | 2.3.0 | Add a new view on the transport dashboard per delivery depot showing any deliveries flagged with special Handling codes on the day of delivery | RFC-679 | No | No | |
Costings module - reporting | Improvement | 2.3.4 | Creation of the following two new reports, to complement the work done in other issues in this version related to costings. | No | No | ||
Map - Pickups | Improvement | 2.1.0 | Pickups / deliveries will be made more obvious from looking at the map, the marker will be different for each and in the tooltip shown when hovering the cursor over the marker it will also tell the user what type of delivery it's for. | VLIVE-254 | No | No | |
Delivery screen - Pickups | Improvement | 2.1.0 | A PD delivery will have separate delivery and pickup records, which are linked. It's difficult to identify in this scenario which is a pickup and which is the delivery, so this will be made clear on the screen. | No | No | ||
Routing engine - Ability to specify operating times | Improvement | 2.1.0 | During the integration of the routing engine with Vision Distribution the driver's "operating times" were missed and are now being added as optional fields | No | No | ||
Costings module - recording costs | Improvement | 2.1.0 | Utilise the allow single drops check box on the carrier setup. When set the vehicle will require costs for each individual drop to be entered by the user. If not set then the cost for the manifest needs to be inserted. The boxes used on the planning forms should allow for this entry and ensure its integrity is maintained. e.g. If you enter manifest price then we do not have drop prices or vice versa. We will then modify the delivery costs when each drop is set with its own price to then work out a cost per case to allow this to be proportioned over all the product lines. Where the price is per manifest it will continue to be divided equally by the invoice cases and apportioned per delivery and then down to the delivery line level. | No | No | ||
Carrier Improvements | Improvement | 2.1.0 | The following improvements are to be made to the carrier. #1 Insurance details can be held against the carrier instead of the vehicles, checking will look at the carrier, if not present will check the vehicle. and provide same message regarding insurance. Additional fields will also be Approved and Approved Date (approved for haulage) which are just for reporting on BI Enquiry #2 Specify the types of goods a carrier cannot have on their vehicles, these will be independent lists in VD which the users can manually setup and match to VW codes to also apply the checks to deliveries imported from VW. This will be needed at carrier level only and similar to insurance will check carrier then vehicle. Check boxes are needed as there may be multiple. Also make this visible on the depot plan screen / carrier search result (F11 / F12) #3 Add an information tab against the carrier, having three sections, 2 of which are same as the carrier item, the third will be carrier conditions, this will allow formatting using html and there will be a check box stating show conditions on carrier documents. If this is ticked then print this on the bottom of the manifest and estimation/confirmation of job emails(paperwork) #4 The ability to free type a delivery or collection will also need to ask at header level (not against delivery line level) which product types this delivery is for. #5 BI Enquiry needed to provide details of carriers with this additional information shown, so insurance expiry dates and approval dates can be checked. | No | No | ||
All drivers shown | Improvement | 1.12.3 | When selecting a driver for a specific haulier on a delivery using the navigation panel all drivers are shown instead of the selected haulier. | No | No | ||
Deliveries - additional charges | Improvement | 2.2.0 | Implementing the remaining functionality (from [VDIST-858]) for the costings module This will be implemented in stages and will be part of the licensed module introduced in VDIST-860.
| No | Yes | ||
Delivery service level enhancements | Improvement | 2.1.0 | In [VEDI-364] a new segment was added in the xml order "Delivery Options", this is solely for the transport system and receive the fields shown on the wiki [https://visionsoftware.atlassian.net/wiki/display/VEDI/Sales+Order+-+XML+Format|https://visionsoftware.atlassian.net/wiki/display/VEDI/Sales+Order+-+XML+Format] Here we will map the Delivery Service Level to a potential Delivery Charge (optional) or a uplift % on the existing costs. Only accept Delivery Service Levels if they exist, if they do not then they are to be removed. e.g. HOME would come into here and use the HOME charge band 24 would come in and use standard charging SAT would come in and use standard charging with an uplift of say 50% AM would come in and use standard charging with an uplift of say 20% In addition the service level could over ride the default pick calculation - e.g. 48 means delivery within 2 working days of the current date, 24 means delivery next working day, SD means Same Day Delivery, SAT would force delivery on a Saturday even if the delivery day is non standard. We have to be able to derive from this code
This implements the calculations in VDIST so they're ready to be used for manual deliveries immediately, VW will be updated later in [https://visionsoftware.atlassian.net/browse/VW-5067|https://visionsoftware.atlassian.net/browse/VW-5067|smart-link] to also work with the new calculations, in the meantime it'll continue to calculate pick / delivery dates as it did previously. | VEDI-406 | No | No | |
Delivery notes - generated before pick confirmation | Design Change | 2.3.3 | If a manifest and it's delivery notes are generated by VDG for orders on a bulk pick, prior to pick confirmation, the delivery notes will incorrectly display the quantities as zero. Important note: now the service will only print the manifest & delivery notes after pick confirmation. | VSUP-9717 | No | No | |
Postcode lookup | Design Change | 2.2.0.1 | The postcode lookup address field population has been standardised across all Vision products, therefore all Vision apps will populate the address in the same way, which is centrally controlled from our online postcode service. | No | No | ||
Delivery - security pin | Design Change | 2.1.5 | The delivery PIN field accepted for incoming sales order files currently allows alphanumeric entries, this will be changed to allow numeric only. | VEDI-690 | No | No | |
Navigation Search - Issues with search for a delivery | Bug | 2.4.0 | There seems to be some issues with the navigation result search for a delivery if search on a specific doc ref or pick UID it returns the result all the time, but if search for some customer alone it doesn't return anything. | VSUP-14741 | No | No | |
Manifest - not printing | Bug | 2.4.0 | A manifest is not showing to be printed when it had a delivery which was then removed from the manifest. | No | No | ||
EPOD - Generation Failure | Bug | 2.3.3 | If a customer has a long domain ePODs are not generating when requested from VD | VSUP-14187 | No | No | |
Delivery - DPAccountRef populating wrong | Bug | 2.3.5 | The DPAccountRef from VW is populating the wrong field, resulting in it being shortened from 30 > 6 characters | VSUP-13318 | No | No | |
Delivery - saving without VL access | Bug | 2.3.5 | Cannot save changes to an existing delivery when Vision Live is down. | No | No | ||
Delivery Lines - Disc/Surc % reverts to previous value when saving changes | Bug | 2.3.3.1 | When Editing a Delivery and amending the Discount / Surcharge field on the line to 0 and then saving it will revert it back to previous value and not save to 0. | VSUP-12648 | No | No |