-
Data purging
There is significant problem to test data upgrade scripts in a case of real transaction database due to the size. The database cannot be normally exported to developer box (T-1), there is no enough storage space.
We must have data purging process at least for keeping data structure and some data for data upgrade testing process. Historical and temporary data should be purged by a service from LCS available for T-1 and T-2 (Dev and Sandbox). There were many standard periodic functions in the previous versions, we can purge data for a selected closed period.
-
Fiscal Printer for Italy - IP configuration must be aligned with standard approach and cost of the maintenance should be not so high
The current approach for fiscal integration does not allow to manage fiscal printer's IP address in proper way in large scaling deployment scenarios. The current design to have Technical profile specified in POS Hardware profile results into:
- Changing hosts file in Windows operation system on every machine which requires separate profile per machine, and high cost of maintenance from OS point of view, OR
- Having Retail Hardware profile per fiscal printer, which means Retail Hardware profile per every registry which means hundreds of the hardware profile to manage in D365.
Moreover, the current design does not align to standard approach to configure IP address for a device for registry in specific form “IP address configuration” at Retail/Channel Setup/PoS Setup/Registers/<Register tab> - <Configure IP addresses>
The design must be changes to the standard design and the IP address of the fiscal printer should be configured in this IP addresses configuration form. mPOS should be able to get this configuration for fiscal printer from there and use it accordantly.
That allows to avoid significant drawbacks for hosts file or hardware profiles mentioned above.