1. Суть задачи

1. Открыть JPOS в браузере на телефоне.
2. Выбрать блюда из меню.
3. Добавить их в заказ с нужным количеством.
4. Видеть итоговую цену корзины.
5. Оплатить заказ через СБП.
6. Получить экран с QR-кодом заказа.
7. Показать QR-код на раздаче.
8. Получить заказ и подтвердить получение.

1. Отсканировать QR-код клиента.
2. Увидеть заказ в Юпитере.
3. Закрыть заказ одним кликом.
4. Напечатать фискальный чек при закрытии заказа.

2. Общая архитектура

• Клиентская часть JPOS работает в браузере.
• Серверная часть JPOS размещается в облаке, на сервере CLOUD.
• Юпитер также размещается в облаке, рядом с JPOS, чтобы уменьшить задержки.
• На раздаче используется рабочее место с доступом к Юпитеру и локальной базой с обменом данными с облачным сервером. 
• Для выдачи заказов используется существующее окно проверки заказов в Юпитере.
• Заказ передаётся в Юпитер только после подтверждения оплаты.
• Оплата выполняется через индивидуальную платёжную ссылку СБП.

3. Основной пользовательский сценарий

3.1. Открытие меню

• 2 позиции блюд;
• фото блюда;
• описание блюда;
• цена;
• возможность выбрать количество;
• кнопка добавления в корзину/заказ.

• Интерфейс должен быть адаптирован под мобильный браузер.
• Пользователь должен видеть состав заказа и итоговую сумму.

3.2. Формирование заказа

1. Выбирает блюда.
2. Указывает количество.
3. Видит состав заказа.
4. Видит итоговую цену корзины.
5. Переходит к оплате.

• Должна отображаться актуальная сумма заказа.
• Должна быть возможность изменить количество или убрать позицию до оплаты.
• До успешной оплаты заказ не должен передаваться в Юпитер как готовый заказ к выдаче.

4. Оплата через СБП

4.1. Формирование ссылки на оплату

1. Клиентская часть JPOS отправляет запрос в backend JPOS.
2. Backend JPOS формирует запрос к банку/платёжному сервису.
3. Банк/платёжный сервис возвращает индивидуальную ссылку на оплату.
4. Backend JPOS передаёт эту ссылку в браузер клиента.
5. Клиент переходит к процедуре оплаты.

• Для каждого заказа формируется отдельная платёжная ссылка.
• Фиксированный общий QR-код не используется, так как суммы и состав заказов отличаются.
• Оплата выполняется через СБП.

4.2. Контроль оплаты

1. Клиент уходит на оплату.
2. Backend JPOS периодически проверяет статус платежа.
3. Если оплата подтверждена — процесс идёт дальше.
4. Если оплата не подтверждена — клиенту показывается экран с предложением оплатить заказ.

• Нельзя передавать заказ в Юпитер до подтверждения оплаты.
• При ошибке оплаты клиент должен иметь возможность вернуться к заказу и повторить оплату.
• Статус оплаты должен определяться серверной частью, а не только фактом возврата пользователя на страницу.

5. Создание заказа в Юпитере

5.1. Передача заказа после оплаты

1. Backend JPOS передаёт информацию о заказе в Юпитер.
2. Юпитер создаёт заказ у себя.
3. Юпитер возвращает в JPOS номер созданного заказа.
4. JPOS показывает клиенту экран с номером заказа и QR-кодом.

• Заказ в Юпитере создаётся только после успешной оплаты.
• Клиент должен увидеть номер заказа.
• Клиент должен получить QR-код, содержащий номер заказа или иной идентификатор, по которому заказ можно найти в Юпитере.

5.2. Экран клиента после оплаты

• номер заказа;
• QR-код заказа;
• кнопку «Заказ получен».

• QR-код должен сохраняться при обновлении страницы.
• Можно предусмотреть кнопку сохранения изображения QR-кода, но это не является обязательным для первого этапа.

6. Поведение кнопки «Заказ получен»

«Заказ получен»

6.1. Если клиент нажал кнопку до фактической выдачи

• Клиенту показывается сообщение: нужно подойти на раздачу и получить заказ.
• Заказ не считается полученным.
• Меню заново не открывается.

6.2. Если клиент нажал кнопку после фактической выдачи

• Клиенту снова отображается меню для выбора товаров.
• Это означает, что заказ успешно завершён.

• Фактом получения заказа считается изменение статуса заказа в Юпитере на «Закрыт» или «Удаление заказа».
• Не нужно пока добавлять таймеры и автоматическое закрытие заказа.
• Не нужно автоматически считать заказ полученным по времени.

7. Выдача заказа на раздаче

7.1. Рабочее место выдачи

• Используется Windows-устройство.
• Доступ к Юпитеру осуществляется через локальное оборудование в столовой.
• На экране открыто окно проверки заказов Юпитера.

• Устройство должно быть удобно расположено для сотрудника выдачи.
• Должен быть подключён сканер QR-кодов.
• Сотрудник должен видеть состав заказа перед выдачей.

7.2. Процесс выдачи

1. Клиент подходит на раздачу.
2. Показывает экран телефона с QR-кодом.
3. Сотрудник сканирует QR-код.
4. Юпитер находит заказ.
5. Сотрудник видит состав заказа.
6. Сотрудник выдаёт заказ.
7. Сотрудник закрывает заказ одним кликом.
8. При закрытии заказа выполняется фискализация и печать чека.

• Окно на раздаче должно находиться в режиме ожидания сканирования.
• После успешного закрытия заказа окно должно возвращаться к ожиданию следующего сканирования.
• Сотрудник должен видеть состав заказа, так как в заказе может быть несколько позиций.

8. Фискализация и чек

8.1. Базовый сценарий

• Чек печатается при закрытии заказа на раздаче.
• Фискальный регистратор находится на раздаче или подключён к рабочему месту выдачи.
• Фискализация происходит в момент закрытия заказа сотрудником.

• Серверный Юпитер не знает, на какой клиентской машине находятся FR-сервер и фискальник.
• Фискализация должна выполняться там, где доступна клиентская машина с подключённым фискальником.

8.2. Если фискальник только на кассе

• Фискальник остаётся на кассе.
• Рабочее место раздачи и кассовое рабочее место связываются через локальную сеть.
• Передача данных возможна через общую папку и/или отдельный обмен.

8.3. Электронный чек

• Зависит от возможностей фискальника.
• Зависит от подписки/возможностей ОФД.
• При неподдерживаемом режиме устройство может вместо электронного чека печатать бумажный.

9. Интеграции

9.1. JPOS → Банк/СБП

• формировать платёжную ссылку для конкретного заказа;
• передавать ссылку клиенту;
• проверять статус платежа;
• получать подтверждение оплаты;
• корректно обрабатывать ошибки и таймауты.

• Для взаимодействия могут требоваться специальные сертификаты/ключи.
• Документация Сбербанка по созданию и проверке платежа должна быть доступна.
• Поведение платёжной ссылки и возврат клиента на страницу ещё нужно проверить.

9.2. JPOS → Юпитер

• передавать заказ в Юпитер только после подтверждения оплаты;
• получать номер созданного заказа;
• возвращать номер заказа в клиентскую часть;
• при необходимости получать статус заказа для экрана клиента.

• Нельзя создавать заказ в Юпитере до оплаты.
• Нужно обеспечить корректную связку заказа в JPOS и заказа в Юпитере.

9.3. Юпитер → рабочее место выдачи

• передать заказ на точку/в кассовую зону;
• обеспечить отображение заказа в окне проверки;
• позволять найти заказ по отсканированному коду;
• показывать состав заказа;
• давать закрыть заказ одним действием;
• инициировать печать фискального чека при закрытии.

10. Требования к инфраструктуре

10.1. Серверная часть

• Размещение JPOS и базы Юпитера в облаке рядом друг с другом.
• Доступ сотрудников к Юпитеру через локальное оборудование в столовой.
• Внешний порт для работы серверной части JPOS.

10.2. Оборудование на раздаче

• Тип устройства: Windows-ПК, моноблок, планшет или другое.
• Способ подключения к Юпитеру.
• Возможность работы сканера штрих-кодов/QR-кодов.
• Способ крепления устройства на раздаче.
• Наличие интернета на точке.
• Наличие фискального регистратора.
• Схему подключения фискального регистратора.

11. Организационные вопросы

11.1 Инструкция Сбербанка

• Инструкцию передать Лене.
• Первые 9 пунктов инструкции выполняет клиент на своей стороне.
• Если Лена не справится, она должна обратиться в техподдержку.
• Техподдержка должна быть заранее в курсе задачи и быть готова помочь.

• Инструкция или ссылки в ней могут измениться, это нужно учитывать.

12. Спорные моменты и открытые вопросы

Спорный момент 1. Место установки фискальника

• Удобно, когда фискальник стоит на раздаче, и клиент получает чек сразу вместе с заказом.
• Если фискальник только на кассе, клиенту придётся идти к кассе с подносом, что неудобно.

• Фискальник устанавливается на раздаче.
• Чек печатается при закрытии заказа.

• Можно ли физически установить фискальник на раздаче.
• Согласна ли Лена на полноценное рабочее место с моноблоком и фискальником.
• Если фискальник на раздаче невозможен, как организовать печать чека на кассе.

Спорный момент 2. Момент фискализации

• Обсуждался вариант фискализировать заказ сразу после онлайн-оплаты.
• Но серверный Юпитер не знает, на какой клиентской машине находятся FR-сервер и фискальник.
• Поэтому фискализация сразу после оплаты технически не обеспечена.

• Фискализация происходит при обработке/закрытии заказа на раздаче.

• Окончательно подтвердить, что фискализация выполняется при закрытии заказа на раздаче.
• Проверить, соответствует ли это требованиям закона для конкретной схемы общепита.

Спорный момент 3. Правовая схема чеков

• Обсуждалось, что для общепита чек должен предшествовать приёму денег.
• Также звучало мнение, что нужны два чека: при оформлении заказа и после оплаты.
• Единая правовая схема не согласована.

• Уточнить требования законодательства для выбранной схемы.
• Определить, сколько чеков нужно печатать и в какой момент.
• Зафиксировать это отдельно до запуска.

Спорный момент 5. Готовность клиентской части

• Есть серверная часть JPOS, которая умеет работать с меню, корзиной, скидками и модификаторами.
• Но полноценный клиентский сайт/витрина может быть не готов как законченный продукт.
• Обсуждалось, что для клиента нужен удобный интерфейс с меню, фото, описанием и оплатой.

• Для данной столовой сделать минимальный клиентский экран с двумя позициями.

• Достаточно ли текущего интерфейса для запуска.
• Нужна ли отдельная полноценная витрина.
• Как будет публиковаться меню, описания, фото и цены.

Спорный момент 6. Возврат клиента на страницу после оплаты

• После перехода в платёжную форму клиента нужно вернуть на правильную страницу JPOS.
• Поведение платёжной ссылки ещё нужно проверить.

• Как клиент возвращается на страницу заказа после оплаты.
• Нужно ли передавать параметры заказа в ссылке.
• Как обрабатывать сценарий, если клиент закрыл браузер и вернулся позже.

Спорный момент 7. Домен и SSL

• Для работы серверной части может требоваться внешний порт.
• Вопросы домена и SSL-запросов до конца не закрыты.

• Используется ли домен.
• Нужен ли SSL-сертификат.
• Как организовать защищённое взаимодействие между JPOS, банком и клиентской частью.

Спорный момент 9. Производительность Юпитера при проверке оплаты

• Проверка статуса платежа может идти через Юпитер.
• Если Юпитер однопоточный, возможны задержки при множественных одновременных запросах.

• Проверить нагрузку.
• Оценить задержки.
• При необходимости использовать альтернативную схему оплаты через Юпитер или отдельный механизм проверки статуса.

Спорный момент 10. Количество позиций в меню

• В текущей постановке указано меню из двух позиций.
• В обсуждениях также упоминался вариант меню с тремя кнопками.

• 2 позиции.

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

Спорный момент 11. Поведение при ошибке печати чека

• Если при закрытии заказа фискальник не напечатал чек, это может остановить выдачу.

• Что делает сотрудник при ошибке печати.
• Можно ли закрыть заказ без чека.
• Нужно ли повторять печать.
• Какие ошибки показывать сотруднику.
• Нужно ли логировать ошибки фискализации.

13. Итоговая целевая схема

1. Клиент открывает JPOS в браузере.
2. Видит меню из двух позиций.
3. Добавляет блюда в заказ.
4. Видит цену корзины.
5. Нажимает оплату.
6. Backend JPOS запрашивает платёжную ссылку СБП.
7. Клиент получает ссылку и переходит к оплате.
8. Backend JPOS следит за оплатой.
9. Если оплата не подтверждена — клиенту предлагается оплатить заказ.
10. Если оплата подтверждена — JPOS передаёт заказ в Юпитер.
11. Юпитер создаёт заказ.
12. Юпитер возвращает номер заказа в JPOS.
13. JPOS показывает клиенту номер заказа и QR-код.
14. Юпитер передаёт заказ на точку выдачи.
15. Клиент показывает QR-код на раздаче.
16. Сотрудник сканирует код.
17. Юпитер находит заказ.
18. Сотрудник видит заказ и закрывает его одним кликом.
19. При закрытии печатается фискальный чек.
20. Клиент нажимает «Заказ получен».
21. Если заказ уже закрыт/удалён — клиент возвращается в меню.
22. Если заказ ещё не закрыт — клиенту предлагается подойти на раздачу.

15. Критерии готовности к тестированию

1. Клиент может открыть JPOS в браузере.
2. Меню отображается с фото, описанием и ценой.
3. Можно добавить блюда в заказ.
4. Видна итоговая сумма.
5. Можно сформировать платёжную ссылку СБП.
6. Оплата проходит и подтверждается.
7. Backend JPOS корректно определяет статус оплаты.
8. Заказ передаётся в Юпитер только после оплаты.
9. Юпитер создаёт заказ и возвращает номер.
10. Клиент видит номер заказа и QR-код.
11. На раздаче можно отсканировать QR-код.
12. Юпитер находит заказ по коду.
13. Сотрудник видит состав заказа.
14. Заказ можно закрыть одним кликом.
15. При закрытии заказа печатается фискальный чек.
16. Кнопка «Заказ получен» корректно работает до и после закрытия заказа.