I am sure we can all see that the web client will be the only real client of choice (in a version or two of NAV).
This presents some challenges with connecting specific devices and related subsystems that can run along with NAV.
For instance setting a particular printer to a report, integrating with OPOS, equipment controllers (production line), scales or barcode generators/verifyiers etc.
Due to nature of using any device to work, it makes sense that we wouldn't want additional software installed as a layer but would just want to load the webclient and get going to keep low overhead install and maintenance.
With this flexible environment we still have real physical limitations IE my PC in the office is linked 3 big betha Printers, yet my tablet at home is to my officejet and my phone likes PDFs.. Yet when printing sensitive information it must go to a particular printer in the office. (Like the old NAV Printer selections allowed) but we don't seem to have any solution for the current web clients (admittedly have not checked 2018 yet).
Also bear in mind it most likely that the NAV service Tier is MS hosted or in the cloud so these also do not have a connection to the remote network or users environment, just picking the attached device defaults would be somewhat too limited let alone lose support for an array of other functions/devices.
I am struggling with the concept of not being able to bind devices to computer name so these devices can be defined. Surely getting the computer name from a webclient connected user isn't easy either, guessing we would need to write a NAV function the calls some java script (or some other mystical process) to get this data from the users machine whilst not leaving a hole in security - doesn't sound simple or ideal.
I am sure MS has already considered this, especially as they are likely to phase out the RTC client relatively soon and the future webclients will support more than PDF output when printing. So just wondered if anyone else has developed something, has any news or just thought of a different approach.
Regards
Matt
