Воеводский Михаил

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

Исправлю ситуацию, публикую оставшиеся части. На этот раз без картинок, да простят меня читающие :)

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Текущие функциональные возможности АСУ

1. Прием заказов в кофейне сотрудником с использованием сенсорного моноблока
2. Логирование действий барменов
3. Путеводитель по процессу создания заказа (вопрос-ответ)
4. Печать чеков на фискальном регистраторе
5. Центральный сервер (далее ЦС) для агрегации данных
6. Централизованное управление товарами и их составом
7. Отчетность (статистика) для по продажам локально в кофейне и централизованно
8. Синхронизация между всеми серверами в реальном времени
9. Комплексные предложения (наборы товаров)
10. Предложение доп. продаж позиций, соответствующих добавленным в заказ
11. Флаеры
12. Складской учет
13. Интеграция с системой видеонаблюдения Video.NET
14. Сотрудники – карточка сотрудника
15. Программа лояльности, гости
    • Карточка гостя
    • Лицевой счет
    
    
    • Оплата заказов с карты гостя
    • Система подарков
    • Самостоятельная регистрация гостей на отдельном сайте
16. Сканирование штрих-кодов на картах сотрудников и гостей
17. Система резервного копирования всей сети в облачное хранилище

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Пути решения проблем при «непонятном» поведении движка/компонентов

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



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

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Синхронизация данных и обновление компонентов АСУ

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

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Работа с оборудованием

Фискальные регистраторы

Главным нюансом было взаимодействие с фискальным регистратором, который в 2014 году в качестве коммуникационного поддерживал только COM-порт. Второй сложностью в работе с ФР был протокол работы, основанный на бинарном обмене данными.

После подготовки статей решил довести до ума удобный компонент, который изначально был задуман как публичный и создан для нужд АСУ. Удобен, чтобы в каждом из компонентов, где требуется очередь, не реализовывать одно и то же.

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



Простой пример: отправка писем. В основном процессе добавляется сообщение о новом исходящем письме, а отдельным скриптом осуществляется отправка письма.

Вторая статья из цикла.

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Почему выбран MODX Revolution

Ключевые технические требования к АСУ, которые были выявлены до начала технических работ:

• Язык программирования — PHP;
• WEB-сервис для упрощения процесса замены клиентского терминала;
• Локальный сервер в каждой кофейне для минимизации влияния отсутствующего интернета;
• Возможность передачи проекта для развития сторонним разработчикам;

Главная причина выбора MODX Revolution банальна: на момент начала работ я знал данный инструмент лучше всех остальных. Из-за ограниченных сроков сравнение с другими инструментами не рассматривалось, так как любой из других движков/фреймворков, помимо чтения теории о них, потребовал бы значительного времени на вникание в его подходы.

Данная статья открывает цикл статей о создании и функционировании крупной автоматизированной системы учета для федеральной сети кофеен, о которой я так или иначе многократно упоминал в сообществе. В частности, мои доклады в Минске в декабре 2015 г. и ноябре 2017 г. основаны на отдельных составляющих данной АСУ.

Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Предыстория

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

Команда CompAero разыскивает PHP-разработчика (а еще лучше — двух), который обожает код и не представляет, как можно жить без кода; который заботится о «чистоте» и понятности его кода; который всегда готов браться за сложные задачи и реализовывать их.

Как многим известно, сегодня вступают в силу изменения ФЗ-54 «О применении контрольно-кассовой техники», в соответствии с которым практически все юридические лица обязаны пробивать кассовые чеки в момент расчета.



Небольшое отступление:
Эта участь не обошла стороной и интернет-магазины. В Законе расплывчато говорится о времени, которое может пройти с момента расчета до момента пробития чека, но это однозначно должно быть какое-то малое разумное время. Таким образом, если покупка в ИМ осуществляется ночью, то и чек должен быть ночью, но никак не утром, когда проснется и придет на работу продавец/оператор.

Команда CompAero разыскивает PHP-разработчика: который разделит нашу страсть к проектированию и созданию новых сложных проектов, который не только не испугается необходимости в сжатые сроки решить поставленную задачу, но сделает это наиболее оптимальным способом. А так же, который умеет нешаблонно мыслить в случаях, когда требуется проявить находчивость и смекалку.