Но то что Ваш заказчик требует запустить все на одном моноблоке, это не значит что это нужно всем ресторанам.При большом желании можно, наверное это реализовать. Но это будет явный костыль. Продуктивную и удобную работу такая схема вряд-ли сможет обеспечить. Нужна реализация "из коробки". Продуманная и удобная для кассиров-бабушек.
VDU задумывался запускать на отдельном миниПК и если у Вас нестандартная конфигурация которая нужна только одному-двум заказчикам, то и костыль можно считать рабочим вариантом.
Или платим отдельные деньги за доработку UCS. Также ни что не мешает Вам доказать UCS что данная доработка нужен будет многим ресторанам и за часы работы программиста UCS возьмет на себя.
А что Вы хотели, прогресс не стоит на месте, любые красивости требуют ресурсов и затрат на оборудование.Ну да, вот одна строчка сразу увеличивает стоимость реализации тысяч так на 10.
Я пока останусь с RKEEPER.Это всего лишь одна из причин. И на самом деле не основная.
Сможете сделать лучше UCS, так напишите свой софт. Будет лучше у Вас чем Rkeeper, обязательно буду рекомендовать Вас.
Не в последнее время, а это было всегда. Пора бы уж привыкнуть.Спасибо им, конечно за это. Но в последнее время стало все сложнее "отмазываться" перед клиентами за косяки UCS. Мне уже самому стыдно за них (UCS).
Ну я знаю что сложно, но я всегда стараюсь всю схему сложного клиента проверить на демостенде, прежде чем запускать или обновлять.Да он мне, собственно и не нужен. Потому, что протестировать новые версии на баги, ни вы, ни мы не сможем в полной мере. Это даже у UCS не получается. Поэтому только на живом бизнесе.
Конечно всего не проверишь, попадаем на баги и ошибки и ставим кривое - трекеруем.
Вот честно, я иногда Вам не завидую с законами РФ, я о онлайн ФР, ЕГАИС и т.д., у нас такого нет.Ну так и мы работаем. И в последнее время "на поплакаться" остается все меньше и меньше времени
И нам проще хоть в этом.
Ответить с цитированием