АСУ для кофеен. Часть 5
Часть 1. Предыстория.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение
В далеком 2014 году, когда я приступил к активной реализации проекта, я не знал и десятой доли всего того, с чем столкнулся в процессе и что пришлось изучить. В условиях катастрофической нехватки времени очень быстро (почти мгновенно) пришло понимание, что официальная документация весьма скромна в плане описания определенных механизмов, по которым появляются вопросы. Естественно, времени на написание вопросов в сообществе и ожидание ответов на них у меня не было.
Причем, после первой же недели начали появляться такие вопросы, ответить на которые могло крайне ограниченное количество людей в сообществе. Имена этих людей и сейчас все знают очень хорошо. Но кроме них почти никого и не было, кто бы знал MODX на настолько глубоком уровне.
Изучение исходников — единственный путь решения вопроса при отсутствии документации к нужному методу или классу.
Я тогда «рыл» исходники MODX и miniShop2 по несколько часов в день, так как это оказывалось несравнимо быстрее, чем искать ответы на просторах сети. Особенно, если это были отсутствующие ответы.
НО!!! Даже при таком подходе все равно нужно адекватно оценивать свои силы и отдавать себе отчет в том, что есть шанс провала. Соответственно, если нет 100% уверенности в результате, вспомните русскую народную поговорку «Семь раз отмерь, один раз отрежь».
И еще: будьте готовы на начальных этапах к переписыванию отдельных частей кода по несколько раз в течение всего лишь 2-3 дней. Причина проста: при таких масштабных проектах прокачка знаний идет не по дням и не по часам. Счет на минуты и секунды. В результате то, что вы делали утром, уже к вечеру может показаться убожеством новичка. Суровая правда жизни.
Помимо этого, в связи со значительным продвижением вперед технологий фронт-разработки, все больше желания доработать всю серверную логику до работы через REST для возможности последующего прикручивания отдельного фронта.
Что же касается компонентов, неприятность случилась с minishop2. Реализация складского учета началась в момент выпуска minishop 2.3-alpha, что внушало большие надежды в его судьбу. Ввиду существенных отличий данной ветки от предыдущих, было принято делать учет сразу на этой версии. Как я тогда ошибся, стало понятно лишь спустя полгода-год, когда Василий взял разработку ms2 снова в свои руки и отбросил ветвь 2.3. В итоге на текущий момент работает достаточно интересная система учета остатков, которая заточена под неактуальную версию 2.3. Жду, когда же появится возможность для создания отдельного компонента учета на базе накопленного опыта для текущей версии ms2.
Другие неприятные моменты тоже имеются, но они почти несущественны на фоне вышеописанных.
Складской учет потребовался достаточно подробный, чтобы на его основе менеджеры могли корректно заказывать у поставщиков товары, а руководство получало бы, помимо отчетов о продажах, отчеты по себестоимости продаваемых товаров.
После беглого анализа компонентов и решений для учета остатков стало ясно, что за основу брать нечего. И здесь придется писать свое.
Основная причина: мы не можем учитывать остаток позиции «латте с вишневым сиропом». Требуется отдельно считать кофе, молоко и вишневый сироп. Как видно, один товар состоит из трех ингредиентов, остатки которых необходимо учитывать по отдельности.
После добавления ингредиентов потребовалось реализовать механизм ввода состава для каждого товара. Когда сделали, менеджерам предстояла крайне веселая и разнообразная задача — пройти по каждому товару и указать в его свойствах состав.
Изначально система ингредиентов и состава товаров проектировалась для использования в расширенном режиме, как для кофеен, когда товар может состоять из нескольких ингредиентов с разным количеством, так и в упрощенном режиме, когда включался бы механизм соответствия «один товар = один ингредиент». По ряду объективных причин данный механизм остался нереализованным, что не лишает его права на жизнь при благоприятных условиях.
Помимо состава отличительной особенностью реализованной системы учета является поддержка приходов и списаний, а также инвентаризаций. Вкратце о данных операциях:
Дополнительной сильной стороной учета стала фиксация остатков от приходов в реальном времени в соответствии с продажами. Следствием данного фактора стала возможность точного расчета себестоимости каждой проданной единицы товара даже в случаях, когда на его изготовление затрачены ингредиенты из разных поставок по разным ценам.
Например, когда для одной чашки кофе использованы 3 г кофе из поставки по 1 р./г, а еще 5 г из следующей поставки по 1.5 р./г. Как нетрудно посчитать, себестоимость такой чашки кофе составляет 10.5 р., но такой простой расчет возможен только при отсутствии сведений о других приходах. Поэтому после каждой продажи требовалось списывать не только текущие остатки, но и контролировать остатки от каждого прихода.
Помимо отчетов о текущих остатках и себестоимости проданных товаров появилась возможность отслеживать текущие стоп-листы и строить прогнозы по окончанию ингредиентов на несколько дней вперед. Конечно, сейчас такие прогнозы не являются интеллектуальными и основаны исключительно на сведениях о продажах за последние несколько дней. Однако, и это крайне сильно облегчает жизнь менеджерам.
Часть 2. Почему выбран MODX Revolution. Серверная часть.
Часть 3. Работа с оборудованием. Примерная хронология проекта.
Часть 4. Синхронизация данных и обновление компонентов АСУ
Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета
Часть 6, 7. Текущие функциональные возможности АСУ
Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение
Пути решения проблем при «непонятном» поведении движка/компонентов
В далеком 2014 году, когда я приступил к активной реализации проекта, я не знал и десятой доли всего того, с чем столкнулся в процессе и что пришлось изучить. В условиях катастрофической нехватки времени очень быстро (почти мгновенно) пришло понимание, что официальная документация весьма скромна в плане описания определенных механизмов, по которым появляются вопросы. Естественно, времени на написание вопросов в сообществе и ожидание ответов на них у меня не было.
Причем, после первой же недели начали появляться такие вопросы, ответить на которые могло крайне ограниченное количество людей в сообществе. Имена этих людей и сейчас все знают очень хорошо. Но кроме них почти никого и не было, кто бы знал MODX на настолько глубоком уровне.
Следствие №1
Изучение исходников — единственный путь решения вопроса при отсутствии документации к нужному методу или классу.
Я тогда «рыл» исходники MODX и miniShop2 по несколько часов в день, так как это оказывалось несравнимо быстрее, чем искать ответы на просторах сети. Особенно, если это были отсутствующие ответы.
Следствие №2
Если хочешь повысить свой уровень — бери в работу максимально сложный проект, который значительно превышает по сложности все предыдущие задачи вместе взятые.НО!!! Даже при таком подходе все равно нужно адекватно оценивать свои силы и отдавать себе отчет в том, что есть шанс провала. Соответственно, если нет 100% уверенности в результате, вспомните русскую народную поговорку «Семь раз отмерь, один раз отрежь».
И еще: будьте готовы на начальных этапах к переписыванию отдельных частей кода по несколько раз в течение всего лишь 2-3 дней. Причина проста: при таких масштабных проектах прокачка знаний идет не по дням и не по часам. Счет на минуты и секунды. В результате то, что вы делали утром, уже к вечеру может показаться убожеством новичка. Суровая правда жизни.
Текущие технологические «боли»
На данный момент осталось наследие первых версий системы — недостаточно структурированные элементы и множество JQ лапши, которая тоже нормально не структурирована.Помимо этого, в связи со значительным продвижением вперед технологий фронт-разработки, все больше желания доработать всю серверную логику до работы через REST для возможности последующего прикручивания отдельного фронта.
Что же касается компонентов, неприятность случилась с minishop2. Реализация складского учета началась в момент выпуска minishop 2.3-alpha, что внушало большие надежды в его судьбу. Ввиду существенных отличий данной ветки от предыдущих, было принято делать учет сразу на этой версии. Как я тогда ошибся, стало понятно лишь спустя полгода-год, когда Василий взял разработку ms2 снова в свои руки и отбросил ветвь 2.3. В итоге на текущий момент работает достаточно интересная система учета остатков, которая заточена под неактуальную версию 2.3. Жду, когда же появится возможность для создания отдельного компонента учета на базе накопленного опыта для текущей версии ms2.
Другие неприятные моменты тоже имеются, но они почти несущественны на фоне вышеописанных.
Реализация складского учета
Складской учет потребовался достаточно подробный, чтобы на его основе менеджеры могли корректно заказывать у поставщиков товары, а руководство получало бы, помимо отчетов о продажах, отчеты по себестоимости продаваемых товаров.
После беглого анализа компонентов и решений для учета остатков стало ясно, что за основу брать нечего. И здесь придется писать свое.
Основная причина: мы не можем учитывать остаток позиции «латте с вишневым сиропом». Требуется отдельно считать кофе, молоко и вишневый сироп. Как видно, один товар состоит из трех ингредиентов, остатки которых необходимо учитывать по отдельности.
После добавления ингредиентов потребовалось реализовать механизм ввода состава для каждого товара. Когда сделали, менеджерам предстояла крайне веселая и разнообразная задача — пройти по каждому товару и указать в его свойствах состав.
Изначально система ингредиентов и состава товаров проектировалась для использования в расширенном режиме, как для кофеен, когда товар может состоять из нескольких ингредиентов с разным количеством, так и в упрощенном режиме, когда включался бы механизм соответствия «один товар = один ингредиент». По ряду объективных причин данный механизм остался нереализованным, что не лишает его права на жизнь при благоприятных условиях.
Помимо состава отличительной особенностью реализованной системы учета является поддержка приходов и списаний, а также инвентаризаций. Вкратце о данных операциях:
- Приходы — увеличение остатков на введенную величину;
- Списания — уменьшение остатков на введенную величину;
- Инвентаризация — установка текущих остатков в соответствии с введенными значениями. При несоответствии введенных значений должны произойти автоматические приходы и списания соответственно для корректности сквозного учета и отчетности.
Дополнительной сильной стороной учета стала фиксация остатков от приходов в реальном времени в соответствии с продажами. Следствием данного фактора стала возможность точного расчета себестоимости каждой проданной единицы товара даже в случаях, когда на его изготовление затрачены ингредиенты из разных поставок по разным ценам.
Например, когда для одной чашки кофе использованы 3 г кофе из поставки по 1 р./г, а еще 5 г из следующей поставки по 1.5 р./г. Как нетрудно посчитать, себестоимость такой чашки кофе составляет 10.5 р., но такой простой расчет возможен только при отсутствии сведений о других приходах. Поэтому после каждой продажи требовалось списывать не только текущие остатки, но и контролировать остатки от каждого прихода.
Помимо отчетов о текущих остатках и себестоимости проданных товаров появилась возможность отслеживать текущие стоп-листы и строить прогнозы по окончанию ингредиентов на несколько дней вперед. Конечно, сейчас такие прогнозы не являются интеллектуальными и основаны исключительно на сведениях о продажах за последние несколько дней. Однако, и это крайне сильно облегчает жизнь менеджерам.
Комментарии: 9
Здравствуйте, Михаил. Вы, наверное, хороший и опытный разработчик, но… Было бы неплохо, хотя бы для приличия, указать хоть несколько случаев «непонятного поведения» движка/компонентов, а то статья получилась ну, извините, вообще ни о чем. Я понимаю, что может быть договор NDA или еще что-то подобное, и я не говорю о том, что статьи данного цикла должны быть а-ля «Создаем АСУ для кофеен с нуля — код под катом и ссылка на github», но хотелось бы чуть больше конкретики. Слишком поверхностно. Подобного рода информацию можно было осветить в рамках одной статьи — на MODX я сделал такой то функционал, применил примерно такие технологии, вот такой примерно принцип работы и что в итоге имеем на выходе. Я понимаю, что не в праве требовать от вас что-либо, но я думаю не только мне хотелось бы видеть чуть-чуть больше деталей.
Технические детали постараюсь вспомнить.
Что же касается остального, есть различные аспекты:
1. Не весь код оптимален. Особенно при том, что для понимания контекста иногда необходимы достаточно большие куски кода. Поэтому предполагаю, что особенно заинтересовавшие части системы читатели попросят разъяснить в комментариях;
2. Спустя 3 года вспомнить все нюансы по коду — мало кому под силу. В том числе и мне;
3. «Создаем АСУ для кофеен с нуля — код под катом и ссылка на github» — чересчур уж громко. Реализацию таких систем, включая весь основной код, практически невозможно описать в статьях.
Вывод:
1. Какие сложности вспомню, напишу;
2. Если интересует что-то определенное — задавайте вопросы.
Что же касается остального, есть различные аспекты:
1. Не весь код оптимален. Особенно при том, что для понимания контекста иногда необходимы достаточно большие куски кода. Поэтому предполагаю, что особенно заинтересовавшие части системы читатели попросят разъяснить в комментариях;
2. Спустя 3 года вспомнить все нюансы по коду — мало кому под силу. В том числе и мне;
3. «Создаем АСУ для кофеен с нуля — код под катом и ссылка на github» — чересчур уж громко. Реализацию таких систем, включая весь основной код, практически невозможно описать в статьях.
Вывод:
1. Какие сложности вспомню, напишу;
2. Если интересует что-то определенное — задавайте вопросы.
все больше желания доработать всю серверную логику до работы через REST для возможности последующего прикручивания отдельного фронта.Меня тоже давно уже посещают подобные мысли. Оформить все в отдельный компонент ( на примере как это сделали в друпал 8 ), который делает систему максимально restfull. Вопрос на сколько это будет актуально\востребовано для сообщества.
В MODX уже есть встроенные возможности для реализации REST сервисов и клиентов. Класс так и называется: modRest.
Кстати есть ли где-то обзор работы с эти классом? Давно интересуюсь этим функционалом, но как-то ничего конкретного не нашел(
Не находил. Только в официальной доке небольшая статья.
После MODXpo, где я рассказывал о встроенном REST, собирался написать такую статью, но все никак не собраться. Другие задачи перевешивают.
После MODXpo, где я рассказывал о встроенном REST, собирался написать такую статью, но все никак не собраться. Другие задачи перевешивают.
с горем пополам оттолкнулся от docs.modx.com/revolution/2.x/developing-in-modx/advanced-development/developing-rest-servers
ссылка на главу 4 неправильная — стоит modx.pro/topic/13984/ (там соответственно мы не можем читать) а я так понял должно быть modx.pro/sites/13984/
Поправил, спасибо.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.