- Print
- DarkLight
- PDF
Release notes RetailVista ERP spring 2022 update version 22.9
From now on, RetailVista has an integration with Woocommerce. The orders are retrieved from Woocommerce, and vice versa, the inventory and/or price of products in Woocommerce can be automatically updated with the inventory from RetailVista.
Both the retrieval of orders and the updating of product information can be configured via the webshop settings.
For more information about this integration, a separate QA is available.
(Version 21.18.7993.29064) Task 20260 - Realize Spaaza integration
RetailVista now has an integration with Spaaza, a comprehensive loyalty system with many connections to social media. For more details, please contact our sales department.
(Version 22.3.8063.27099) Task 20204 - Do not explode collections upon product receipt
In a DC/WMS environment, exploding purchase collection products upon product receipt is undesirable. In such environments, the ordering process only involves the 'Main' collection products, and the underlying collection components are not individually picked and delivered. At the store level, it is now possible to configure whether or not exploding collections is desired. By default, this setting is 'on' so that there is no change in behavior after installing this update. In DC/WMS environments, this setting will need to be consciously adjusted to achieve different behavior.
(Version 21.17.7961.30103) Task 20203 - Enable collection import via Excel in Exchange
From now on, collection fields can also be imported in Excel via Exchange. In the column mapping, the collection fields are now located at the very bottom in a separate block.
25632) Task 20463 - Sending outgoing emails via own email server
From now on it is possible to have emails sent by your own/another SMTP server instead of the default setting of RetailVista.
A new screen 'Outgoing emails' has been created. Currently, gift card emails are placed in this screen, but in future updates of RetailVista, all outgoing emails will be sent through this route.
In order to ensure successful delivery, it is necessary to specify an 'SMTP server' definition. This can be done through the new screen 'SMTP servers'.
Another major advantage of this new method of sending is that an SMTP send log is created for each outgoing message. This log can be found behind every outgoing email.
This log can be small when using default settings, or much larger when, for example, using 'debug' log settings. This way, it is easier to determine what happened if a recipient claims not to have received an email.
(Version 21.19.8007.26033) Task 15511 - Implementing timezone support
In anticipation of a database adjustment in RetailVista, it is now possible to indicate the timezone per location. By default, NL operates with a timezone +1. By setting a different timezone, in a future release, the issue will be resolved where a store opens at 9 am local time in the UK, but RetailVista considers the opening time as 10:00 am in local NL time. Therefore, it is important to adjust the timezone per location once, if it needs to be different from +1.
Product Maintenance
(Version 22.7.8117.25632) Task 20463 - Sending outgoing emails via own email server
From now on it is possible to have emails sent by your own/another SMTP server instead of the default setting of RetailVista.
A new screen 'Outgoing emails' has been created. Currently, gift card emails are placed in this screen, but in future updates of RetailVista, all outgoing emails will be sent through this route.
In order to ensure successful delivery, it is necessary to specify an 'SMTP server' definition. This can be done through the new screen 'SMTP servers'.
Another major advantage of this new method of sending is that an SMTP send log is created for each outgoing message. This log can be found behind every outgoing email.
This log can be small when using default settings, or much larger when, for example, using 'debug' log settings. This way, it is easier to determine what happened if a recipient claims not to have received an email.
(Version 21.19.8007.26033) Task 15511 - Implementing timezone support
In anticipation of a database adjustment in RetailVista, it is now possible to indicate the timezone per location. By default, NL operates with a timezone +1. By setting a different timezone, in a future release, the issue will be resolved where a store opens at 9 am local time in the UK, but RetailVista considers the opening time as 10:00 am in local NL time. Therefore, it is important to adjust the timezone per location once, if it needs to be different from +1.
21578) Task 20444 - Please extend external code from c16 to 25
The field 'External code' of a product has been extended to 25 characters.
(Version 21.16.7947.25966) Task 20208 - Ability to search by collection barcode and collection identification barcode
In the product search screen, it is now possible to search by these two fields. These are respectively the barcode of a collection item and the barcode of the entire collection itself.
(Version 21.16.7947.25966) Task 19786 - Active product assortment
From now on, a task can be scheduled in RetailVista to determine the active product assortment. The product search screen can by default take into account the active product assortment by only searching within that assortment. As a result, the default number of search results decreases significantly. The active assortment is automatically calculated every day through task planning.
EDI
(Version 21.21.8035.24990) Task 20253 - Smarter search for product number/recognition indication when processing Abbyy messages
The recognition of lines from Abbyy has been improved in terms of product recognition. From now on, it automatically searches, initially based on the barcode of the purchase packaging, then on the consumer barcode, and finally on the order code.
This is expected to further improve the success of finding products.
(Version 22.4.8077.27906) Task 20234 - Retrieve RetailLink messages via task
The RetailLink EDI messages were previously retrieved through housekeeping or the RetailClient. This is no longer supported, retrieving EDI messages from RetailLink is now part of the standard RetailVista software. Users do not need to do anything, this conversion takes place automatically.
(Version 21.16.7947.25966) Task 20030 - Payments within the webshop order message can be empty
From now on, it is possible to not include any payments in a webshop order message.
Of course, a different handling will have to be chosen for fulfillment, in most cases a delivery on account.
Product
(Version 21.18.7993.29064) Task 20249 - Remove PriCat import and processing from RetailVista
The EDI Pricat import and processing has been removed from RetailVista. Only a few customers used this format, and in practice it has been found that the format leaves much to be desired in terms of possibilities. This format has been replaced by the Retail3000 article XML import, which is much richer and more flexible in terms of data possibilities than the old EDI Pricat message. Users who used the old PriCat format have already been approached by us and have been or will be converted to the Retail3000 import format.
(Version 21.18.7993.29064) Task 20218 - Let Retail3000 import run via task scheduler
This adjustment only applies to so-called 'offline' RetailVista users.
The Retail3000 import has now become part of RetailVista itself. Previously, this was a separate application. That separate import will no longer be further developed. However, that import still works now, but the advice is to have that import converted to an import by RetailVista itself in the coming months with the support desk.
As part of the relocation of the import software, retrieving the files (via WebConnect) has also become part of RetailVista.
The conversion to RetailVista has several advantages:
- Logging can be easily viewed afterwards (currently logs are on disk, hardly or not accessible to end users)
- Starting an import is now possible by the user (currently not possible, end user cannot access the import server to start an import manually)
- Import time can now be set by end users themselves, no longer through Retail3000 import software where you have no control as an end user
- This allows an import to be started again in case of missing PriCat mapping
- No separate FTP synchronizer installation/configuration required anymore, WebConnect retrieves the data
- No timing issue anymore with FTP sync versus starting import. Import retrieves the data itself and starts immediately afterwards
The settings from the offline Retail3000 import software can be automatically imported into the settings of RetailVista. For this, there is an 'Import' button in the settings, Import section, Advanced tab.
Exchange Excel import
(Version 21.16.7947.25966) Task 20066 - Please show active source protections for actual excel import
In the Excel import screen in Exchange, it is now indicated whether source protection is active.
Billing / Invoicing
(Version 22.3.8063.27099) Task 20370 - In Desadv message from RetailVista, the net unit price including VAT is sent, it should be unit price excluding VAT
In the Desadv EDI packing slip message created by RetailVista, purchase prices including VAT were mentioned. It should have been excluding VAT and this error has now been fixed.
Purchase orders
(Version 22.3.8063.27099) Task 20091 - Support purchase price group when importing Excel purchase order
When importing a purchase order from Excel, support for the purchase price group functionality has now been built-in.
During import, the purchase price group can be indicated, after which RetailVista will try to find and add the corresponding purchase price group purchase data to the purchase order lines.
Quotations
(Version 21.17.7961.30103) Task 20087 - Delivery address adjustment when converting quotation to sales order not always mandatory
The conversion of a quotation to a sales order has been further revised and expanded with regard to the address. If the sales order classification is 'delivery', then specifying a delivery address is mandatory. If the classification is 'pickup', then the address does not need to be specified.
POS
(Version 22.5.8097.29166) Task 20396 - Sales confirmation email extensions
The sending of a sales confirmation via email has been expanded. The functionality was previously very limited and it was almost impossible to determine whether a message had actually been sent or not.
The sending of this sales confirmation now goes through the new 'Outgoing emails' table. Each outgoing / to be sent email is first placed in a table, after which there is a separate task schedule that takes care of the sending of (all) emails. See the release notes for general information about sending emails.
Furthermore, from now on, purchase confirmations of cash sales are not only sent, but also of deliveries on account.
Whether purchase confirmations are sent can now be configured per POS terminal group. For example, it is possible to only do this sending on webshop cash registers so that webshop consumers receive a confirmation.
(Version 22.2.8056.26334) Task 20356 - Please realize sending purchase confirmation via POS terminal group setting
The sending or not sending of a purchase confirmation is no longer possible per location, but can now be configured per POS terminal group.
The old settings from the branch definition have been automatically converted to the POS terminal groups. With this adjustment, it is better adjustable whether a purchase confirmation is desired on certain cash registers or not. This setting is read from POS version 22.2 and higher.
It is possible from RetailVista POS version 22.1.8055 and higher to indicate via advanced settings whether sending a purchase confirmation for that cash register is desired or not. This works through the setting: AdvancedSetting:SendSaleConfirmation=<0,1> where 0 indicates that sending is not desired and 1 indicates that sending is desired. As long as this advanced setting exists, the default setting of RetailVista per POS terminal group will be ignored.
(Version 21.21.8035.24990) Task 20316 - Specify specific package service printer per POS terminal
In POS terminal maintenance, a specific package service printer can now be specified per POS terminal. If reservations are sold through that POS terminal (where registration is required, for example, to Post NL or SendCloud), the received address labels are printed on the specified printer. If no printer is specified at the POS terminal, the system will fall back on the package service settings at the webshop. If there is no webshop, or if the printer setting is not specified there either, the setting per branch will be used.
Reports
(Version 22.8.8124.27181) Task 20451 - Ability to specify quantity when printing product label report
From product maintenance, a label report (A4) can be started via the left menu choice. From now on, it is possible to choose manual entry for the quantity. A number field will then appear where the number of pieces of the product to be printed can be entered.
This concerns the A4 label report and has nothing to do with thermal labeling.
28197) Task 20405 - House number addition width should be changed from 5 to 10 characters
The width of the house number addition field has been changed from 5 to 10 characters. This seems to occur quite often in Belgium, and with this change, fewer webshop order messages will be rejected due to a too long house number 2 code.
(Version 21.16.7947.25966) Task 20163 - Relation export should be disabled
The ability to export relations can now also be disabled through permissions.
Reservations
(Version 22.4.8077.27906) Task 20292 - Re-enable support for multi-colli in package registration
SendCloud is now able to handle multi-collo shipments. For this reason, RetailVista has been adjusted and multi-collo is now also supported when sending to SendCloud.
Statistics
(Version 21.18.7993.29064) Task 20262 - Schedule ePlato export via task scheduler
This adjustment currently only applies to offline users of RetailVista.
Sending data to ePlato (BI) for offline users is done through the RetailClient. Nowadays, that client only had 2 tasks left, namely importing Retail3000 data and sending turnover information to ePlato.
The import of Retail3000 data has already been removed from the RetailClient through another task. And with the completion of this task, sending turnover information to ePlato has now become a task in the task scheduler.
The old sending method still works at the moment, but the advice for offline users is to contact NedFox support desk in the coming months to have this sending method converted to an automatic task within RetailVista.
Reservations
(Version 22.4.8077.27906) Task 20292 - Re-enable support for multi-collo in package registration
SendCloud is now able to handle multi-collo shipments. For this reason, RetailVista has been adjusted and multi-collo is now also supported when sending to SendCloud.
Statistics
(Version 21.18.7993.29064) Task 20262 - Schedule ePlato export via task scheduler
This adjustment currently only applies to offline users of RetailVista.
Sending data to ePlato (BI) for offline users is done through the RetailClient. Nowadays, that client only had 2 tasks left, namely importing Retail3000 data and sending turnover information to ePlato.
The import of Retail3000 data has already been removed from the RetailClient through another task. And with the completion of this task, sending turnover information to ePlato has now become a task in the task scheduler.
The old sending method still works at the moment, but the advice for offline users is to contact NedFox support desk in the coming months to have this sending method converted to an automatic task within RetailVista.
(Version 22.4.8077.28197) Task 20405 - House number addition width should be changed from 5 to 10 characters
The width of the house number addition field has been changed from 5 to 10 characters. This seems to occur quite often in Belgium, and with this change, fewer webshop order messages will be rejected due to a too long house number 2 code.
(Version 21.16.7947.25966) Task 20163 - Relation export should be disabled
The ability to export relations can now also be disabled through permissions.
Reservations
(Version 22.4.8077.27906) Task 20292 - Re-enable support for multi-collo in package registration
SendCloud is now able to handle multi-collo shipments. For this reason, RetailVista has been adjusted and multi-collo is now also supported when sending to SendCloud.
Statistics
(Version 21.18.7993.29064) Task 20262 - Schedule ePlato export via task scheduler
This adjustment currently only applies to offline users of RetailVista.
Sending data to ePlato (BI) for offline users is done through the RetailClient. Nowadays, that client only had 2 tasks left, namely importing Retail3000 data and sending turnover information to ePlato.
The import of Retail3000 data has already been removed from the RetailClient through another task. And with the completion of this task, sending turnover information to ePlato has now become a task in the task scheduler.
The old sending method still works at the moment, but the advice for offline users is to contact NedFox support desk in the coming months to have this sending method converted to an automatic task within RetailVista.
21578) Task 20437 - Realizing reporting for VAT remittance legislation as a result of international sales
In the statistics homepage, there is a standard report 208 that can be printed to meet the fiscal requirements for webshop sales in a specific period. There is a separate QA available that outlines the choices NedFox has made to implement this regulation as effectively as possible in RetailVista.
Sales Orders
(Version 22.7.8117.21578) Task 20437 - Improving the recording of delivery costs and performing VAT calculation on delivery costs
Several important/useful enhancements have been made regarding transport/shipping costs.
In the sales order classification, it is now possible to set what product should be used for shipping costs in webshop orders on the 'Sales Orders' tab.
A webshop no longer needs to include a fictitious additional article line with the shipping costs, but can simply include the amount of shipping costs in the header of the order message. RetailVista will then convert that amount by adding an article to the sales order with the specified value. It is also possible to specify a different transport product per webshop. This provides visibility into the transport costs for individual webshops.
In the sales order classification, it is now possible to set the VAT calculation that should be performed for the delivery costs. By default, the percentage of the transport product is simply applied. However, this calculation setting can change that percentage. In any case, in Ireland, the VAT percentage for the shipping costs must be equal to the highest VAT percentage of the articles in the order. It seems that this legislation applies in more countries, but at the time of writing these release notes, no further information is available.
(Version 22.6.8108.21578)28197) Task 20418 - Implement Bumbal integration
RetailVista now has an integration with Bumbal. This is a delivery administration system where consumers can choose the desired delivery time for their order. The reservations are placed in Bumbal by RetailVista, after which consumers automatically receive a notification to schedule their delivery/order. The date planned by the consumer is then read back into RetailVista and can be used to ensure that the order picking process for reservations does not start earlier than the actual delivery date. The number of days before the planned delivery date when the order picking process can be initiated is adjustable within the sales order classification.
(Version 22.6.8108.28197) Task 20371 - Do not transfer 'Main' set product when transferring sales order to purchase order
From now on, the 'Main' set product will no longer be transferred from a sales order to a purchase order. 'Set' product refer to combinations of product created on the sales side. Examples of this are garden sets consisting of a bench, a table, and an umbrella. These can be bundled into a main set product 'Sunny garden set' with a specific total selling price. This works fine, but when transferring a sales order to a purchase order, such a main product should not appear in the purchase order. The 'Components' of the set, such as the bench, table, and umbrella, need to be ordered from suppliers.
Previously, the 'Main' set product was transferred to a purchase order, but a supplier says that product means nothing to them.
If, in the example, the garden set should indeed be ordered from the supplier as a whole (meaning it is one inseparable unit, not separately ordering the bench, table, and umbrella), then the product should not be created as a set product but as a regular product.
By the way, sales sets should not be confused with purchase collections, which is something completely different and is on the purchasing side.
(Version 22.6.8108.28197) Task 20355 - Discount from product list not applied to sales order
There was an error in the discount conversion from a product list to a sales order. As a result, no total discount could be given later in the sales order, it simply wasn't taken into account. This issue has been resolved.
(Version 22.4.8077.27906) Task 20350 - Linking sales orders to other sales orders
From now on, a sales order can be linked to an original sales order. This can be seen in the 'Advanced' tab. This linkage makes it easy to see if an order was a result of a previous order. This can be the case with backorders, but can also be the case with credits. As part of this adjustment, the type 'Credit sales order' has also been added to the types of sales orders. In a credit sales order, only negative quantities can be used in the sales order lines. And as a result, only positive quantities can be used in a 'normal' sales order from now on. It is therefore no longer possible to combine returns/credits in the same sales order where normal (positive) order quantities are also present. We have deliberately chosen to separate these two types of orders. This is also a partial step towards a return module.
(Version 22.1.8049.25616) Task 20338 - Order picking reports should only be automatically printed after delivery/pickup is scheduled
In reservations, a planned delivery date can be specified. From now on, it is possible to configure RetailVista in such a way that order picking does not start until a configurable number of days before the planned delivery date.
This prevents a warehouse bulk location from becoming too full with picked products that need to be delivered in the future.
In the sales order classifications, in the 'Layout' tab, it can be set that order picking reports may not be printed until a specified number of days before the reservation is scheduled.
Combined with this change, it is now also possible to set on the same page that order picking reports are printed until a certain time (the so-called 'cutoff time'), after which printing is paused for a specified number of hours.
This opens up the possibility, for example, to print order picking reports until 3:00 PM, with the warehouse department committing to handle all orders by 3:00 PM on the same day (no matter how late it gets, so to speak).
If you do not make this commitment, there is a risk that more orders will remain every day, eventually causing a backlog. This commitment means that all printed orders (up to, for example, 3:00 PM) will be processed, after which the order pickers can go home. After a specified number of hours, printing will resume, and upon the return of the order pickers (next day), they will see these orders and restart the process.
(Version 21.21.8035.24990) Task 20319 - Printing of order picking reports also adjustable per webshop and location
RetailVista is capable of automatically printing order picking reports through a task scheduler. However, printing was only possible when using pickup locations. Even for delivery orders, pickup locations had to be used. This choice turned out to be illogical upon further consideration and has now been revised. The functionality of printing per pickup location still exists, but it is no longer mandatory to work in that way. The basis for printing order picking reports is now set at the corresponding location. It is now also possible to deviate from this per webshop.
The order is as follows:
Pick-up locations > Webshops > Locations
If nothing is set on, for example, pick-up locations (or pick-up locations are not used), the order picking settings from the webshop will be used. If those are also not specified, or the sales order is not a webshop order, the order picking settings per location will be used.
(Version 22.4.8077.27906) Task 20242 - Approval setting via classification
The approval settings have been moved to the sales order classification. It is now possible to set how the approval process should work per classification. It has been chosen not to provide a conversion script to convert the settings to the classification. Customers using approval will need to set these settings correctly in the desired classifications when this update goes live.
(Version 21.16.7947.25966) Task 20039 - Reopening sales order should still be possible even if you do not have reopening rights
From now on, it is possible to reopen sales orders even if you do not have the right to do so. The condition is that there are no reservations linked to the sales order or that the existing reservations still have the status 'New'. In fact, reopening is now allowed as long as it does not cause any problems.
Inventory / Stock control
(Version 22.6.8108.28197) Task 20383 - Virtual stock is not always displayed
This bug has been fixed, the virtual stock is now always displayed (in case of set articles).
Webshop
(Version 22.7.8117.21578) Task 20407 - Retrieving webshop orders from bol.com and updating track & trace info to bol.com
From now on, RetailVista has an integration with bol.com. The orders from bol.com can be retrieved and the track & trace information can be updated to bol.com.
The following text will be retrieved in RetailVista and sales orders will be created from it. This step allows for the entire order fulfillment to take place in RetailVista. Of course, the bol.com order reference will also be taken over.
The great advantage of this integration is that RetailVista automatically sends the Track & Trace codes back to bol.com. These are linked to the consumer's order. This way, the consumer is informed about the shipping status of orders. This is a very important aspect for bol.com when calculating the customer satisfaction score.
At a later time, consideration will be given to also sending inventory information to bol.com. At this time, this new functionality is limited to orders and track & trace codes.
(Version 22.2.8056.26334) Task 20357 - Being able to mark webshop as 'passive', successor of sub-location >0
With the revision of the screen with all webshop settings, a number of very specific ShopServer fields have been removed. An important field among these was 'Passive', which indicated that a (ShopServer) webshop was passive. This meant that no webshop products could be assigned to that webshop, a passive webshop automatically followed the assortment of the 'main' webshop. For this purpose, such a passive webshop received a 'sub-location' number. This information has been converted to two advanced settings by the RetailVista update, namely:
ShopServerStoreNumber=<shopserver location number>;
ShopServerSubStoreNumber=<shopserver sub-location number>
(Version 22.1.8049.25616) Task 20349 - Realize payment service provider integration (Buckaroo)
RetailVista now has a PSP integration, in this case Buckaroo. The advantage of this integration is that negative deposits (return payments) can be automatically processed to Buckaroo. It is no longer necessary to manually take them over.To make this possible, a new 'Payment Service Providers' screen has been implemented. In this screen, the type of PSP can be specified, among other things. Currently, only integration with Buckaroo has been implemented. It is expected that Pay.nl will be added to this at some point in the future.
As a result of this change, it is now possible to indicate the type of deposit, whether it is a PSP type deposit, a gift card deposit, a cash deposit, or a bank deposit. Only deposits of the 'PSP' type are eligible for automatic refund. In the PSP table itself, it can be indicated whether automatic refund is desired. If it is not activated, refunding remains a manual action via the PSP website.
In addition, the webshop definition must indicate which PSP belongs to that webshop. This makes it possible to work with a different PSP for each webshop, or the situation where each webshop works with, for example, Buckaroo, but each webshop has its own Buckaroo account.
Finally, as a result of this expansion, more data had to be recorded for the deposit. In the deposit detail screen, several additional fields have been added, including a separate 'Reference' field where the payment reference code from the PSP will be displayed. This was already part of the webshop order message. Separate fields have also been created for recording an IBAN account BIC number and account holder name, in case manual bank transfers need to be made. New fields 'Action' and 'Status' have also been added. The 'action' field indicates whether the deposit was a deposit, a counterbooking, or a refund. The status field can be used to indicate the current status of the deposit.This is especially useful for chargebacks: the PSP integration software will adjust the value of that field to 'Completed' in case of a successful automatic refund or 'Failed' if the PSP does not accept the refund request. In case of manual refunds (for example, via bank or manually through the PSP), the user can manually adjust this field to the correct value. In the 'Deposits' screen, advanced search can be used to search for deposits with a specific action and/or status. This makes it easy, for example, to see which chargebacks have failed, which ones still need to be executed, etc.
(Version 22.4.8077.27906) Task 20315 - Ability to specify separate settings per webshop
The entire webshop settings maintenance has been rewritten. The settings per webshop are now much more extensive than before. It is now possible to indicate per webshop whether article information can be sent to the webshop and whether orders can be retrieved from the webshop. The type of webshop can also be specified. RetailVista now has standard integration capabilities with (NedFox) ShopServer, Woocommerce, and bol.com. Magento 2, Shopware, and possibly other types of webshops are on the list for a future RetailVista update.
Around the order picking printers and reports, the behavior is now also adjustable per webshop.
As part of improved webshop integration, the Payment Service Provider (PSP) is now also adjustable per webshop. Currently, only Buckaroo is supported, but it is very likely that ePay.nl will also be added in a future update. With this PSP integration, RetailVista can automatically process refunds with the PSP in case of (partial or full) cancellations.
Finally, the parcel service settings have also been moved so that it can be indicated per webshop with which information the address package labels should be printed.
(Version 22.7.8117.21578) Task 16470 - bol.com integration
RetailVista now has an integration with bol.com. The orders on bol.com are retrieved and converted into sales orders. The track and trace codes for reservations are automatically sent back to bol.com so that consumers are automatically informed about the shipping status of their orders.