Имеется столовая (внутренняя).Количество сотрудников достаточное, чтобы подумать об оптимизации процесса заказа обедов и учета этих заказов. В текущий момент времени учет взятых обедов сотрудником ведется просто: работник столовой сидит на выдаче, слушает заказа, подсчитывает его сумму, записывает результат в журнал, дает на подпись сотруднику. Такая ситуация не нравится директору: человек отвлекается на ведение учета, учет ведется вручную, оперативности нет, получить данные по сотруднику сложно, нет детализирования, трудно вести статистику.

Кстати, уважаемый, Galogen, пора бы уточнить первоначальную постановку указав там те ограничения что выявились в процессе обсуждения вариантов:
"Отказ от кассира"
"Ограничение по бюджету"
"Отсутствие необходимости оплаты"
и т.п.

1. кассир не нужен
2. естественно есть ограничение по бюджету. вариант со считывтелем на каждом образце блюда - это по-моему через чур
3. оплата через удержания из заработной платы

А можно пофантазировать?

Нужно

Каждому блюду на текущий день после фиксирования меню присваивается числовой код.
Все тарелки и емкости унифицированы по типам (одинаковые глубокие, одинаковые неглубокие)
На раздаче одно блюдо помещается только в одну емкость (тарелку).
Сверху тарелка накрывается крышкой с кодом блюда.
Обедающий при входе на раздачу сканирует свою карту (типа приступил к выбору).
Обедающий как в обычной столовой набирает блюда, расставляет их на поднос.
На выходе с раздачи устанавливает поднос в специально обозначенное место, сканирует карту.
Система фотографирует изображение подноса, сохраняет его в систему. По данному изображению выполняется распознавание кодов блюд. После этого открывается барьер для выхода обедающего (чтобы не получилось что ушел не сфотографировавшись)
Минусы:
- нужна специальная посуда с крышками или удобный способ прикрепления кода к тарелке чтобы обеспечить корректное считывание
- если много тарелок сложно поместить на один поднос
- есть возможность махинаций сокрытия блюд путем установки тарелок друг на друга (лечится созданием снимка с другой камеры расположенной в другой плоскости).

очень оригинально, но сложно на мой взгляд и требует высокой квалификации не просто программиста, а математика, чтобы все это замоделировать

В том варианте, который был реализован у нас - не было сохранения стоимости обеда, оплата происходила сразу же.
Поэтому работник на кассе, да не нужный элемент.
Вообще для предложенной схемы подойдет любая система с электронным меню.
Понадобится два терминала один для сотудника, второй у повора на раздаче  с правами администратора (блокировка, разблокировка блюд, закрытие заказа и т.д.)
Сотруднику после подтверждения заказа выдается чек с номером заказа. Подходя к раздаче он говорит работнику столовой номер, который напечатан на чеке. У работника столовой на терминале отображается заказ - он его формирует и помечает как исполененый. При этом сотруник  на раздаче может внести изменения в заказ (возможно стоит подверждать внесенные изменения пропуском сотрудника).
При этом система может отслеживать количество заказанных порций блюд (если их заранее внести в систему) и блокировать блюдо в меню при исчерпании

По-моему это очень похоже на мой второй вариант.
Даю определеную вводную: заказчик полаает(и выдвигает такое требование). чтобы у работника на выдаче никаких компьютеров не было- "Еще чего ставить терминал для работника. Он же пищу выдает и этими руками будет в монитор тыкать?" Будет ли это определяющим требованием?

Может все-таки определим критерии оптимальности?
Типа таких:
 - разумная минимизация затрат на обслуживание (считаем, что затраты на приготовление блюд постоянны)
 - минимизация затрат на контроль (при этом не исключение затрат и, собственно, контроля)
 - минимизация затрат на учет (наверное еще достоверность учета)
 - минимизация времени (затрат?) на формирование отчетности (разумеется, возможность формирования отчетности в различных разрезах)

Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.

если говорить на уровне автоматов и предельной фантазии (вспоминая не то носова, не то шекли):
 - сотрудник подходит к стойке,
 - сует куда-нить свою карточку (скажем так - в считыватель)
 - открывается дверца
 - и оттуда выезжает на подносике полностью укомплектованный бизнес ланч (вариант: сотрудник самостоятельно берет subj из открывшейся ниши)
всё!

Может все-таки определим критерии оптимальности?

- минимизация затрат на контроль (при этом не исключение затрат и, собственно, контроля)
 - минимизация затрат на учет (наверное еще достоверность учета)
 - минимизация времени (затрат?) на формирование отчетности (разумеется, возможность формирования отчетности в различных разрезах)
 - возможность получать информацию в разрезах блюд, сумм, дней, сотрудников и т.п.

Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.

Ну не надо усложнять. У тебя есть некий набор блюд, который приготовил повар - как творческая натура он делает творческое меню.

если говорить на уровне автоматов и предельной фантазии (вспоминая не то носова, не то шекли):
 ....
 - и оттуда выезжает на подносике полностью укомплектованный бизнес ланч (вариант: сотрудник самостоятельно берет subj из открывшейся ниши)
всё!

Дался тебе этот бизнес-ланч

Дался тебе этот бизнес-ланч

а что? простой и понятный (теперь) термин :о)))

предлагаю все-таки двигаться в сторону традиционного управленческого цикла, а не продавать сотрудникам то, что повар-творец натворит :о)))

т.е. планируем и организуем деятельность - реализуем/контролируем - учитываем - строим отчеты и анализируем достигнутые результаты

Все! Концепция продана. К моему сожалению. Найден какой-то 1с программист, который типа сделает все качественно, быстро и дешево. И .. без наших аналитических рефлексий.

Все! Концепция продана. К моему сожалению. Найден какой-то 1с программист, который типа сделает все качественно, быстро и дешево. И .. без наших аналитических рефлексий.

ну вот и я думаю...зачем аналитики нужны?

Все! Концепция продана... Найден какой-то 1с программист...

Вы ж уже накалывались на этом и, насколько я понимаю, неоднократно. Впрочем, скупой хозяин-барин платит дважды.

Для "хотелок", не связанных с основными бизнес-процессами использование такого подхода (нанять специалиста по конкретной системе) вполне оправдано.
Главное чтобы специалист не начал изобретать велосипед, и писать уникальную систему с 0.
Есть готовое решение 1С:Ресторан+Бар+Кафе на 7.7.

Вот мой еще один вариант минимизирующий оборудование и затраты на ПО.
1. Система (С) находится в режиме ожидания выбора пользователя:
Заказ
Отмена.
2. Обедающий (О) выбирает вариант Заказ.
2.1. С запрашивает сканирование карты, ожидает сканирования.
2.2. О сканирует карту
2.3. С переходит в режим формирования заказа, высвечивает текущее меню.
2.4. О выбирает блюда, завершает оформление заказа. Если отказывается от заказа возврат на шаг 1.
2.5. С печатает чек с составом заказа и шк заказа.
2.6. О передает чек работнику столовой (РС)
2.7. РС выдает блюда. Если выданы все блюда то сканирует ш/к, переход на ш. 2.8.
Исключение если блюда нет просит О отказаться от заказа и оформить новый. Обслуживание завершено. Возврат на ш. 1.
2.8. С по шк чека находит заказ, проставляет статус выдан. Обслуживание завершено. Возврат на ш. 1.
3. О выбирает вариант Отмена заказа
3.1. С ожидает сканирования шк на чеке
3.2. О сканирует шк чека
3.3. С отменяет действие заказа (если он не еще не отменен или не выдан). Обслуживание завершено. Возврат на ш. 1.

Оборудование: Касса на базе ПК, с сенсорным экраном, с доп оборудованием ридер магнитных карт, принтер чеков, сканер ШК (порядка 30 т.р.).
Поскольку реальных денег не пробивается то фискальный регистратор не нужен, кассовый ящик тоже, то можно взять обычнй моноблок и подключить к нему ридер и сканер ШК.
ПО: готовое решение 1С:Ресторан+Бар+Кафе на 7.7.
Доработка ПО под бизнес-процесс, без серьезного изменения основной функциональности конфигурации, 2-3 рабочих дня (порядка 20-30 т.р.).
В зависимости от перспектив "касса" подключается к локальной сети, для удаленного администрирования и управления. Для большей надежности базу можно разместить на сервере. Функциональность конфигурации используется только в той части какой нужно (либо тупо: "ведение меню, заказ, подтверждение, статистика" либо дополнительно: учет блюд, раскладка, учет продуктов, выгрузка в БД бухгалтерии и т.п).

Вы ж уже накалывались на этом и, насколько я понимаю, неоднократно. Впрочем, скупой хозяин-барин платит дважды.

Ты в данном случае ошибаешься. это два независмых события и точки принятия решения.

Интересное решение. Простое и, кажется, отработанное. Единственно - как это выглядит 1С:Ресторан+Бар+Кафе на 7.7 и удобно ли этим пользоваться?

Интересное решение. Простое и, кажется, отработанное. Единственно - как это выглядит 1С:Ресторан+Бар+Кафе на 7.7 и удобно ли этим пользоваться?

Базовые формы экранные рассчитаны на работу кассира.
Формы в данной конфигурации не заточены под ввод с экрана и там стандартный интерфейс.
В том варианте что я видел не очень удачный был экран - маленький и тыкать нужно было в экран каким либо предметом типа карандаша (или той же карточкой). Однако это не мешало достаточно быстро кассиру выбирать позиции.
Администратор может работает с системой удаленно используя обычную клавиатуру и мышь.

Но собственно это и есть предмет доработки системы (на это я оптимистично отвел 2-3 рабочих дня программиста 1С).
Несколько дополнений.
При включении терминала обеспечивается запуск двух сессий системы.
1. Сессия для работы с заказами. В этой сессии работа выполняется только с тремя формами.
"выбора варианта"
"ввода заказа"
"отказа от заказа"
При выборе варианта модально открывается соответствующая форма.
На форме "ввода заказа" в виде картинок размещается содержимое текущего меню, над дизайном можно подумать.
Вариант размещения меню на форме может зависеть от нескольких факторов, но это уже детали.
Далее эта форма использует стандартный документ системы Заказ его программно создает, заполняет, дает команду печатать чек.
После закрытия формы "ввода заказа"система снова возвращается в форму "выбора вариантов".
Закрыть работу сессии может только пользователь знающий специальный пароль.
2. Сессия для работника столовой. В этой сессии работа с системой визуально не выполняется, программно открывается специальная форма, в которой обрабатывается только событие считывания шк.

Необходимо покупать многопользовательскую версию, как минимум на трех одновременно работающих пользователей: 2 сессии рабочие + сессия для администрирования (ввод номенклатуры, меню, цен и т.п.). Это чтобы в случае необходимости вносить изменения в справочники, меню, цены и т.п. не завершая рабочие сессии.

http://rarus.ru/1c-restoran/1c-rarus-restoran-bar-kafe2-5-st-s/
Единственный минус, новые версии системы не поддерживаются, и платформа 7.7 устаревшая. Хотя для таких задач очень даже подходит, требования к ресурсам низкие, надежность работы.

Стоимость работ на мой взгляд великовата: 20-30 тыс. за оптимистичные 2-3 дня или пессимистичную неделю.

Я, правда, не знаю каким образом формируются расценки. Хотя понятно, что заказчик стремится заплатить меньше, исполнитель наоборот получить больше.

Интерфейсные возможности 1С ограничены, Вы полагает, что легко сделать простой и вместе с тем приятный в использовании интерфейс?

Стоимость работ на мой взгляд великовата: 20-30 тыс. за оптимистичные 2-3 дня или пессимистичную неделю.
Я, правда, не знаю каким образом формируются расценки. Хотя понятно, что заказчик стремится заплатить меньше, исполнитель наоборот получить больше.

Я очень усредненно посчитал, по ставке 1250 руб в час. так 3(дня)*8(часов)* 1250 руб. = 30'000 руб.
У фрилансеров можно подешевле найти, у франчайзи дороже.

Интерфейсные возможности 1С ограничены, Вы полагает, что легко сделать простой и вместе с тем приятный в использовании интерфейс?

Даже на 7.7 можно сделать красиво, удобно и быстро.
Вариант 1.
Все блюда на одной закладке.
Подходит при известном и не очень большом количестве блюд в категории (4-5)
При количестве категорий 4-5.
Форма делится ряды. Один ряд соответствует одной категории.
В ряду для каждого блюда размещается три элемента кнопка выбора блюда, картинка блюда, название блюда.
К сожалению не помню есть ли возможность в 7.7 изображение программно для кнопки менять (в 8-ке реально). Если можно то тогда прямо на кнопке выводится изображение блюда и лишний элемент не нужен.
При этом дополнительно можно для каждого блюда галочками отмечать что оно уже выбрано.
Можно сделать одну кнопку для выбора блюда в категории и одно поле для картинки, и кнопки листать картинки вперед - назад. При нажатии вперед выводится картинка следующего блюда, назад предыдущего.
Вариант 2.
На каждую категорию блюд своя закладка.
Закуски, Первое, Гарнир, Горячее, Напитки и т.п.
На каждой закладке перечень картинок с блюдами текущего меню, как в варианте 1.
Этот вариант если блюд в категории много и нужно много кнопок и картинок разместить.
Заголовок и подвал одинаковые для обоих вариантов.
Количество кнопок и картинок изначально избыточное размещается, при открытии формы лишние кнопки "прячутся".
В заголовке формы имя сотрудника и номер карты (пропуска, табельный)
В подвале формы в виде таблицы перечень отмеченных блюд и кнопки принять заказ и отказ от заказа.
При нажатии принять заказ программно формируется заказ, в котором в виде строк перечисляются номенклатуры соответствующие выбранным позициям (в принципе в таблице выбранных уже эти позиции определены).

Ваша идея, очень близкая к моей первоначальной.

Однако потом в ходе дискуссий мы с товарищем придумали нечто такое, см. вложение.

Т.е. поскольку меню будет не очень большим, то нет нужды делать дополнительную таблицу. Даже если меню будет куда разнообразнее, тоже можно придумать что-то похожее, но уйти от концепции таблицы или какого-то списка.

Идея я надеюсь понятная. Это конечно только одно состояние скрина. Но в целом, каждый элемент экрана представляется как автомат реагирующий на конечное множество входных сообщений=событий