Comments 43
А почему «Елен\nа Геннадиевна»? В чем прикол повару смотреть на стикер, почему нельзя было согратить шапку до:
12:30:05 №123
Ресторан №03
Н. Елена Геннадиевна
==============
5 х Название блюда
12:30:05 №123
Ресторан №03
Н. Елена Геннадиевна
==============
5 х Название блюда
Сложно сказать есть два варианта. Первый это длина строки 24 символа и по мнению 1с что то не помещается и она так подробила. Можно указать любую длину, но что бы листочки помещались на экране была выбрана 24 символа в 1с. Второй вариант по какой то причине 1с поставила там перенос. Дальше я вообще думаю парсить и переформатировать весь чек на этой стороне.
Ну и в тексте я уточнил, что я не вносил никаких изменений в FrontOffice который этот чек формирует.
Основная задача не вносить изменений в FrontOffice систему, и для ПО не отличаться от принтера чеков/заказов.Задача, все же — показывать заказы.
А то, что вы обозвали основной задачей — всего лишь дополнительное требование.
Работникам кухни, если это не кухня Макдональдса или подобная, проще всё-таки работать с принтером. Кухней бывает несколько в одном ресторане (горячая, холодная, кондитерская) и система настраивается таким образом, что при неудачной печати на одном принтере, чек будет отправлен на резервный принтер, то есть на другую кухню и работник этой кухни передаст чек куда надо.
Принтеры Epson стоят возможно дороже аналогов, но они работают по 25 лет при очень редком обслуживании.
Принтеры Epson стоят возможно дороже аналогов, но они работают по 25 лет при очень редком обслуживании.
Принтеры Epson работает хорошо. Стоят космически. Основные поломки вызывает конечно персонал при печати клин ножа, который затем надо крутить через винт отверткой. Персонал обычно просто пытается открыть его в результате залом ножа — ремонт не дешевый. У принтеров есть свои преимущества и недостатки. В данном случае кухня сама так попросила и пока довольна. Ну и я не первый обратите внимание на r-keeper, iiko и т.д. У них так же продаются аналогичные мониторы с ПО под Windows.
Если реализовать возможность звукового оповещения о новом заказе кухня будет довольна еще больше.
Обычно чеки из принтера подкладывают под блюда или прикалывают рядом (над блюдом) на столе выдачи, что бы официант мог определить блюдо из конкретного заказа. Как это реализовано в случае с монитором и отсутствия чеков?
Обычно чеки из принтера подкладывают под блюда или прикалывают рядом (над блюдом) на столе выдачи, что бы официант мог определить блюдо из конкретного заказа. Как это реализовано в случае с монитором и отсутствия чеков?
И добавим сигнал — уведомление о приходе нового заказа, воспроизводить будем через hdmi на колонках монитора. Вывод звука активируем через raspi-config.
Кухня не прикладывает чеки, официанты и так хорошо знают что и кому. Это проблема памяти официантов.
Ситуация. Два стола заказали одно и тоже блюдо с разницей по времени 10 минут, сначала первый потом второй. У столов разные официанты.
Официант второго стола, не имея инфы кому блюдо, запросто может унести «блюдо для первого стола» на второй. В результате гости с первого стола будут ждать свой заказ дольше обычного.
Вот для чего в основном прикладывают чеки (особенно актуально в прайм-тайм)
Официант второго стола, не имея инфы кому блюдо, запросто может унести «блюдо для первого стола» на второй. В результате гости с первого стола будут ждать свой заказ дольше обычного.
Вот для чего в основном прикладывают чеки (особенно актуально в прайм-тайм)
Для этого существует обратная связь от кухни к официантам о готовности блюд.
С чеками тоже не все так просто, если ресторан большой и на нем например 5 кухонь. Если их положить на поднос рядом с блюдом они улетают с него еще на этапе погрузки в лифт. Подкладывать под блюдо можно, но если чек маленький его не видно. Да и официанту к разным выдачам лишние круги наматывать, причем в цикле.
UFO just landed and posted this here
Ой не заметил, что оповещение есть.
А не лучше ли было сделать без дизайнерских изысков, максимально контрастно и информативно, примерно как в бургер кинге, например. Или это и есть то самое «и для ПО не отличаться от принтера чеков/заказов»? 
Я смотрел дизайны, мне показалось что подобного типа дизайны слишком контрастные. Вы бы смогли смотреть на яркие DOS тона целый день. Думаю скорее так исторически сложилось. Возможно эти системы и писались под DOS.
Это так называемые VDU. Сзади монитора висит миникомп, обычно под WindowsCE и там крутится эта софтинка, насколько помню это уже готовое решение от R-Keeper. И еще к ним подключены VDU-клавиатуры, где можно закрыть заказ, отменить и полистать если их много. Вот такая:
А в KFC, фон заказа может быть голубым а не белым, это значит заказ «с собой», и его сразу собирают в пакет а не на поднос.
А в KFC, фон заказа может быть голубым а не белым, это значит заказ «с собой», и его сразу собирают в пакет а не на поднос.
Ниже я как раз говорил именно про такие клавиатуры, есть мысль вместо них использовать энкодер.
Так выглядит чек с принтера
@ProstoTyoma спросил почему не в такой стилистике
А так например выглядит монитор современной системы iiko
У всех свои вкусы в дизайне.
Но везде текст ровный и крупный, про это и говорил ProstoTyoma
Поясните пожалуйста, откуда берется фон и повернутые под углом листочки? В шаблоне ничего такого не увидел.
И еще:
Но сервер же ничего не обновляет, это клиент ходит к нему каждые 30 секунд?
И еще:
веб-сервер на flask с автообновление каждые 15
Но сервер же ничего не обновляет, это клиент ходит к нему каждые 30 секунд?
meta http-equiv=«refresh» content=«30»
Перечитал 2 раза, но так и не понял при чём тут ERP?
Это актуально практически для любой системы erp (все современные 1С системы в торговом оборудовании поддерживают чековые принтеры, аналогично и с другими системами).Есть полно ERP систем, которые как-бы и не поддерживают торговое оборудование, не их это задача, или поддерживают через костыли.
Возможно и есть изолированные экосистемы erp, но навскидку таких не помню. Приведите пример.
Изолированные от чего? По вашей логике получается — давайте натянем erp-систему на принтер, а потом откажемся от принтера и заменим его на моник. Если по функционалу требуется печать на принтерах. будет дано ТЗ на разработку функционала и всё будет печататься, выводиться на нужные девайсы в нужном виде.
Объясните это разработчикам проприетарных систем без возможности изменений последних. На сколько возрастет стоимость разработки? Вы говорите о корпорациях? С малым бизнесом все несколько иначе.
Я не вижу надобности сгородить еще один формат обмена. Данных выдаваемых софтом вполне достаточно. Выше я уже сказал что позже я приведу стикеры к удобочитаемому виду.
Да, именно про проприетарные системы речь и идёт. Ведь именно из них на 99% состоит весь объём внедрений erp-систем. И творение от 1С более чем относится к проприетарному софту, учитывая её политику продаж, лицензирования и отслеживания «легальности» их программ.
Что касается внедрения систем такого класса на малые предприятия, у меня возникает вопрос — что это за предприятия такие «малые»? Допускаю конечно такую модель, что некая компания на аутсорсе ведёт дела крупной компании в erp-системе (может предоставлять штат операторов, администраторов, программистов), но сама-то она пользуется простенькой системой для ведения своих дел.
Что касается внедрения систем такого класса на малые предприятия, у меня возникает вопрос — что это за предприятия такие «малые»? Допускаю конечно такую модель, что некая компания на аутсорсе ведёт дела крупной компании в erp-системе (может предоставлять штат операторов, администраторов, программистов), но сама-то она пользуется простенькой системой для ведения своих дел.
Интересно посмотреть на мнение тех, кто с этой системой теперь работает. Сдается мне, листочки удобнее.
Как работник взаимодействует с монитором заказов? Кликает мышкой? Неудобно наверное?
Пока мышью. Есть специализированные 12 клавишные контроллеры. Есть задумка с энкодером и парой кнопок.
Что делать, если 3 одинаковых блюда идут на три разных стола? Выносит блюда не тот официант, которых их пробивал. Если есть принтер, то чек лежит рядом с тарелкой и понятно на какой стол нести. А так что делать, экран рядом с тарелкой класть? Тарелок рядом может и пять и восемь стоять. Никакого места не напасёшься. Новенькие работники могут не знать названий всех блюд, но если рядом лежит чек он в состоянии прочитать что это. Как этот вопрос решит экран?
Выше уже обсуждалось. В нормальных заведениях официанта не допустят до работы пока он не будет знать ассортимент блюд.
Дааа, классический пример. Похоже что тут веб-разработчик решил решить простенькую десктопную задачку, но вместо того чтобы изучить существующий для этого инструментарий, он притащил на десктоп весь свой серверный стек. По нормальному тут очевидно не нужен ни redis, ни браузер, ни внутренний веб-сервер. Изначальное приложение автора (для прослушивания сокета) элементарно расширяется до требуемой ему функциональности буквально за десяток строчек кода (если использовать какую-то из приличных десктопных GUI-библиотек). Т.е. по факту имеем дикий оверинжениринг и трату ресурсов железа впустую. Однако для данного проекта это всё видимо не принципиально, так что можно наверное и его назвать успешным…
Приведите пример 10 строчек кросплатформенного приложения. Не забываем про гибкость дизайна и гибкость его изменения. Это все лишь микросервисная архитектура. Фактически это аналог разработки на Electron, только на python. Redis позволяет иным приложениям получать доступ к тем же данным ( парралельный доступ), я упоминул в статье подписки.
Приведите пример 10 строчек кросплатформенного приложения. Не забываем про гибкость дизайна и гибкость его изменения.
Вместо redis'а будет банальным питоновский словарь. Для отображения возьмём любую приличную GUI библиотеку (типа PyQt или wxPython), тогда основной код будет выглядеть как «main_window.show()», плюс «main_window.update()» после принятия сообщения из сокета (несравнимо с постоянно долбящейся автообновлением страничкой, да?) и плюс код типа del orders[id] в обработчики нажатия OnOrderClick. Визуальная часть интерфейса накидывается мышкой за пару минут в соответствующем профессиональном инструменте библиотеки (типа Qt Designer или wxFormBuilder). Собственно на этом всё.
Это все лишь микросервисная архитектура.
Такого понятия в разработке десктопного По нет.
Фактически это аналог разработки на Electron, только на python.
Как будто бы это хорошо.
. Redis позволяет иным приложениям получать доступ к тем же данным ( парралельный доступ), я упоминул в статье подписки.
В данной конкретной задаче это не требовалось вообще. Но даже если вдруг понадобится в будущем, то в своё приложение на Питоне это добавляется буквально в пару строчек.
redis позволяет одновременно многопоточно читать и писать, не уверен что это позволяет словарь. В интерфейсе присутствуют анимации (листки анимированны). На Qt это можно реализовать, но сделать это гораздо сложнее. Все же html, css, JS дают больше возможностей в дизайне интерфейса. По поводу Electron, на нем написан Visual Studio Code, по моему хорошо.
Sign up to leave a comment.
Монитор заказов вместо кухонного термопринтера