на чем писать erp систему
Как я писал собственную ERP систему и что из этого получилось
Некоторое время назад ко мне обратился знакомый, хозяин одного из филиалов крупной сети по доставке суши и пицц. Их нынешняя ERP его вообще не устраивала, так как не было контроля за кухней и доставщиками, а так как кухонь по городу у него 5, то это была серьёзная проблема. Он предложил мне написать под него новую систему. Единственное условие – так как он во франшизе, и особо с головниками портить отношения не хотел, необходимо интегрировать с существующей системой максимально скрытно.
Первый вопрос, который у меня возник – это средство разработки. Можно было взять что-то новомодное типа NodeJS для сервера, и отдавать web-интерфейс клиентам – самый простой, но самый тормозной вариант (аналогичные решения требуют i3). Можно прописывать отдельно серверную часть, отдельно каждое приложение (windows/android/ios). Или NodeJS сервер, и C# (xamarin если точнее) под все клиенты единый код. Или взять последнюю Rad studio и написать на единой кодовой базе всё. Так как я понимал, что разный код, описывающий одни и те же вещи – это потенциальная проблема, и что я буду работать над проектом один, я выбрал последний вариант.
Второй вопрос – это архитектура. Можно по-быстрому набросать на форму компоненты, ручками или через LiveBindings всё связать, и быстро получить результат. Но любое небольшое изменение в каком-то алгоритме требует пересборки и обновления всех программ, а это большие затраты по времени на тестирование, чтобы в другом месте ничего не сломалось. Поэтому я принял решение использовать xml для описания всех таблиц и интерфейсов, а всю логику убрать в скрипты.
Для этого я написал собственный редактор форм, через RTTI обращался ко всем свойствам и подсвойствам.
На скриншоте видно, что элемент связан с таблицей Orders, но отображает не её содержимое, а ссылку на customer, колонку FirstName (имя заказчика). Так же при нажатии будет вызван обработчик atApplyChanges, который применит все изменения на форме, и закроет её. Без единой строчки кода! Естественно, когда в таблице Orders что-то будет меняться, то вызовется скрипт, который проверит корректность изменения. Что-то типа:
То есть произойдёт проверка смены, кассы, если надо выпишутся приходники/расходники и т.д. Так же если поменять в этом алгоритме что-то, то не надо повторно пересобирать программы и обновлять всё везде. Достаточно клиенту перелогиниться.
Следующий момент, который безумно напрягает во всех нынешних решениях – это латентность. Любое действие приводит к select из базы. Т.е. время пинга+передачи пакета+select+gzip — это минимальное время, через которое у оператора что-то произойдёт. А когда праздники и мало того, что повышенная нагрузка на оператора да ещё и сервер начинает тормозить, вот тут начинаются реальные денежные потери. Что бы этого не происходило, я сделал кэширование всех нужных данных в ОЗУ, и выборку оттуда через запросы. Сервер напрягается лишь транзакциями update/insert, а потом изменённые и новые данные рассылает всем подписчикам.
С отображением информации тоже пришлось сделать интересные оптимизации. Так как у нас нет select из 10 таблиц, то как, например, из таблицы деталей доставки выяснить, куда везти заказ (у меня точка хранится в таблице домов ФИАС)? Примерно вот так:
Т.е. прошли через 3 промежуточные таблицы и сопоставили заказ с точкой на карте, что бы её нарисовать. Всё очень быстро, и без единого обращения на сервер. И нарисовали в браузере ручками через соответствующее api. То есть так как у гугла большие проблемы с картами в России “в замкадье”, на андроиде использую яндекс, у которого эти проблемы выражены гораздо меньше. Через api 1.1 даже кода разработчика получать не надо, что бы отобразить пункты назначения и пробки например.
Естественно, всё это надо было как-то сопрягать с (пока) основной бизнес-системой. Основная бизнес-система (не буду её называть) печатает на принтере заказы. Небольшое использование сниффера показало, что печатается pdf. Через пол дня была готова моя программа, которая полностью копировала протокол оригинальной (до байта, спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок не заморачиваясь с raw socket), но помимо печати на принтере парсила эти pdf и вычитывала оттуда заказ, загружая его в базу. Но этот метод носил некоторые ограничения. Во-первых, выгружалась не вся нужная информация, а пару полей приходилось перезаполнять оператору, а во-вторых, это была лишь синхронизация по заказам. Например, рейсы доставки приходилось формировать и там и там. Поэтому был написан прокси, который анализировал всю проходящую через него информацию и эта проблема решилась.
Курьерское приложение.
Оно отсылает в фоне на сервер трек. То есть оператор может в реальном времени наблюдать за перемещением курьеров. Так же для подтверждения доставки заказа курьер должен находиться в некотором заданном радиусе от точки доставки. Но при этом может отсутствовать интернет. И тогда программа передаст информацию о том, что заказ доставлен, как только интернет появится. Естественно, можно из программы запустить яндекс-навигатор, который автоматически проложит путь до адреса; можно посмотреть все адреса на карте, или позвонить клиенту, нажав 2 кнопки, и так далее.
В общем, система получилась очень мощной, с большим количеством возможностей реализованных, и с ещё большим количеством заложенных. И… оказалась не нужна. В последний момент заказчик стал изменять изначальные требования: начал в приказном тоне говорить, чтобы я делал так-то и так-то, потому что иначе это работать не будет (к слову, это требования полного переписывания всего на другом ЯП, просто «чтобы было»)… На резонный вопрос “а ведь работает”, “работает быстрее, чем текущая система” и т.д. меня будто не слышал. На этом мы расстались. В общем, сейчас у меня есть интересная, почти готовая, ERP система. Там не хватает каких-то отчётов, хорошо бы допилить (если это будет востребовано) изначально заложенный функционал автоматического разброса заказов по кухням, в зависимости от пробок и текущей загрузки точек и т.д. Доработать это, а так же реализовать дополнительный функционал – совершенно не сложно. А до тех пор моя ERP система ищет нового заказчика, а я новую работу. 🙂
P.S. Многим, я думаю, будет интересно узнать какого вообще разрабатывать кросс-платформенные приложения на RAD Studio. Выскажу своё субъективное и предвзятое мнение: на последней студии, со всеми апдейтами работать можно. Есть некоторые проблемные компоненты типа TWebBrowser, у которого сложности с удалением себя под всеми OS. Или проблемы у компонент типа TGrid на тач устройствах. Но это всё решаемо. Так же есть большая проблема, что установленный apk
это 100Mb. Да, жесть, согласен, но в остальном лишь преимущества. Единая кодовая база, куча компонент из коробки на все случаи жизни, причём под FireMonkey они стали гораздо гибче, чем vcl. Так что основная проблема нынешней Rad studio – это цена. Всё остальное в ней весьма достойно.
Разработка ERP
Два с половиной года назад появилась необходимость в системе управляющей работой предприятия, в данном случае небольшой сети магазинов. Начали они с какой-то минимальной коробочной программой, но это не была всем известная стандартная двухбуквенная система. Предложил приложить свои усилия, стало интересно написать полностью свою собственную ERP. В общем я приблизительно понимал во что это мне обойдется, работаю на контрактах с 95го года в основном в телекомах, банках, страховых компаниях, но иногда в производстве. Видел достаточно проектов чтобы осознавать масштаб задуманного, но решил что свинья не сьест, подавится, короче принялся за это мероприятие.
Первым делом нужно было поставить нормальное оборудование вместо того что там было, firewall приобрел в Монреале, два сервера заказал в Калифорнии. Заехал за ними из Онтарио (сам переезжаешь границу, налоги на свой риск), в общем L.A., Торонто, Франкфурт, Питер. Железо подбиралось по нескольким параметрам: база данных с возможностью добавления второго процессора, памяти до 96ГБ и до 16 3.5″ дисков. 1U программный сервер уже с двумя процессорами и 32ГБ. На программном сервере два жестких диска на RAID1. На БД два жестких диска под RAID1 и два SSD тоже на своем RAID1, все в коробке 2U. Главная база находится на SSD, на жестких дисках стоит OS и туда же идет резервное копирование. Firewall имеет 6 портов в коробке 1/2U, внутри жесткий диск и по желанию Flash карта, сериальный порт, VGA, и наружный электронный монитор здоровья. Потом установка Red Hat, конфигурация серверов, OpenBSD на firewall. Там была веселая история с носками в железных коробках и всей начинкой в ручной клади, но не в этом суть.
Для начала нужно было все это собрать и установить, что и было проделано с помощью неких ‘специалистов по металлу’ (еще одна веселая история). После этого была экскурсия по магазинам, где и началась собственно разработка. Первым делом нужно было собрать данные из уже существующих систем в одно целое. Для этого была написана система передающая данные через SSL (OpenBSD очень удобно для этого, кроме того мне импонирует Тео). Данные собирались по заданному расписанию, к счастью много думать о том что именно передавалось не было необходимости, все что шло из касс в сервер магазина и все что шло из сервера в кассы ловилось, записывалось в местную простую файловую ‘базу’ и ожидало времени для следующей передачи. Система делала попытку запустить модем и после этого передавала. Все данные скапливались у виртуального пользователя OS. Каждый магазин получил инструкцию, чтобы не выключали программу (запустить программу как сервис в не профессиональной версии MS Windows не вышло).
Следующий шаг это конечно разобраться в приходящих скапливающихся файлах, обработать и записать их в новую базу, которую тоже нужно аккуратно смоделировать. Это достаточно длинный не очень приятный процесс, часть файлов весьма не плохо документированы, но все что касается серверной части программы, которую тогда использовали для управления сетью, это был просто дикий запад и никакой документации — как хочешь так и понимай эту ненормальную модель. В какой-то момент данные поползли из firewall в новую базу. Было несколько заходов естественно, базу приходилось стирать, исправлять новые найденные проблемы и снова перегружать. В конце концов это было решено, данные стали приходить каждые двадцать минут и загружаться, что сделало жизнь легче. Теперь настал вопрос использования всего этого богатства.
Отступлю на минуту — зачем писать свою ERP? Какой смысл, ведь есть много коробочных решений и кроме того известно что в России большинство привыкли к одной широко известной программе? Простого ответа нет, есть много сложных, но можно сказать так: это надо было сделать потому что конкурировать новой небольшой сети с уже существующими сетями магазинов трудно. Нужно иметь какой-то способ оттолкнуться от всех других, нужен новый подход к конкуренции. Фактически это было большим риском с разных позиций, и с моей точки зрения (2 года уже все-таки) и с точки зрения сети — где гарантия что все пройдет нормально и что не проще установить что используют все? Но дело именно в том, что то, что все используют держит всех на одном уровне, а когда ты на одном уровне со всеми то гарантии на выживание такие-же как и у всех других, кто точно как ты.
Система началась как стандартная Java бизнес система (JVM, Tomcat, Struts, Apache Server, PostgreSQL, еще немного shell и expect), но для более быстрой разработки было создано большое количество генераторов кода. Стандартный код генерируется из стандартных конфигурационных файлов, так создаются первые заготовки общения с базой данных, весь презентационный фасад и все что их связывает (оболочка бизнес логики), это было правильное решение, это сэкономило невероятное количество времени. Буквально то, что делается руками 3-4 дня теперь делалось за пару часов. Скоро стало понятно что работать над этой программой как над ‘стандартной’ не получится, нужно делать несколько архитектурных решений, которые или сработают и поднимут скорость исполнения или все это вообще накроется, потому как я привык к пользователям, которые ожидают ответ от системы в течении 200-800 миллисекунд, не больше. Но здесь уже начали делать отчеты, которые охватывали около 15 магазинов и промежутки времени минимум в 1 месяц, но вскоре промежутки времени в отчетах выросли до года. То есть человек 40 директоров/менеджеров интересовали продажи категорий товара в 1 или всех магазинах и они хотели видеть данные за 1-12 месяцев сразу. Пришлось перерабатывать как использовалась обьектная модель, никто не хочет ждать отчета 30 минут, да и неприлично такое людям давать. После месяца работы решение было найдено, кроме того теперь каждый пользовательский запрос на отчет был занесен в базу, можно было смотреть уже через саму систему кто что делает, сколько это берет времени, какие они используют параметры. Это стало полезным для наблюдения за работой сотрудников и для обучения людей, потому как система позволяет пользователям писать упрощенный regex для фильтрации продуктов, а люди даже с максимально простым подобием regex имеют некоторые сложности. Но в общем результат оказался нормальным, девяносто процентов запросов теперь делались меньше чем за одну секунду, еще 9 процентов меньше чем за 10 секунд и еще один процент брал 1-2 минуты, что уже легче.
Конечно ERP это не только отчеты по собранным данным, это много другого, например управление входом данных, а здесь тоже свои закавыки. Каким образом обьединить данные из 15 магазинов в одну базу, если в каждом магазине товар заносят в базу по своему? Свои названия, иногда свои штрих кода, свои ‘папки’, даже свои цены. Для этого системе пришлось научиться автоматически обьединять товары в список возможных идентичных товаров, а потом позволять оператору изменять список, править части данных и записывать эти ассоциации как один товар. Естественно это не легкий процесс не только с точки зрения системы, но оператор сам должен быть в состоянии правильно этим управлять и система должна позволять эти ошибки ловить и потом исправлять (и для этого была создана специальная контрольная панель, в ней разные функции позволяли прогонять различную логику сразу над всеми данными в системе — задаешь несколько параметров, нажимаешь на клавишу и ждешь несколько минут пока она не выплюнет файл с возможными проблемами). Одновременно нужно уже быть в состоянии создавать продукты, и правильно их классифицировать, не хочу углубляться в это, но здесь появилось несколько решений, которых не существует в других системах подобного рода, особенно что касается способа классификации и ее иерархии.
С ERP конечно чем больше функций, тем лучше. Собранных данных стало хватать чтобы добавить к системе компонент для рассылки предложений и рекламы, а затем компонент для анализа данных по покупкам клиентов до и после рассылки. Клиенты стали получать поздравления с днем рождения (и некоторые даже отвечают на авто-поздравления, что весьма радует). Был развит еще один большой компонент для интеграции поставщиков в работу сети, но надо сказать что сначала поставщики весьма сопротивлялись даже идее такого подхода к работе, но так как некоторые все таки были уговорены и перешли на новый способ поставки, а в системе появились графические отчеты, которые в состоянии сравнивать продажи по любым характеристикам (например можно сравнить продажи групп товаров по брэндам и по поставщикам на одном графике за любой промежуток времени и по любым магазинам), то в течении года большинство поставщиков перешли на систему, потому что они просто увидели данные, и с данными, в отличии от голословных утверждений, не поспоришь. С поставщиками количество пользователей выросло в четыре раза, но никаких изменений в скорости не наблюдалось, а кроме того со скоростью помогло то, что было проделанно в следующем пункте.
От сбора и управления полученными данными, до ассоциации множества товаров в более общие товары, применимые сразу во всех магазинах, следующий вопрос: пора убирать существующую систему управления в магазинах и ставить свою, интегрированную, позволяющую полностью нормально работать с каждым магазином, позволяющую вести полный учет всех документов и товаров. С нуля это заняло около трети года, система как обычно двойная — сервер/клиент, сервер интегрирован через API главной платформы, во все стороны потекли документы, уже не файлы, настало время и можно было выключить первичный файловый обмен. В общем за 40 часов все магазины были переведены на новую систему управления, но это так же включило в себя переход на GNU/Linux (Ubuntu), в общем это экономит какие-то деньги на лицензиях, но даже важнее, меньше стало возможности получить какой-то вирус. Система автоматом общается с центральной платформой и с кассами/проверщиками цен, не нужны больше ручные проводки и так называемые z-отчеты больше не брали почти по 2 часа времени как на предидущем решении, это ушло в прошлое. Все это хорошо сказалось а скорости системы, потому что стало возможным переключить внутри кода логику с первичной, (той что работала по принципу — есть куча магазинов, но у них у всех могут быть свои продукты со своими ценами, и хотя это уже было все вместе ассоциированно в общей системе, обратно в магазины эти ассоциации не попадали), на логику второй версии — вся сеть работает на одной общей базе, и это уменьшает требования ко всему, и к используемой памяти и к сложности запросов к БД и к количеству запросов.
С появлением всего документо-оборота в платформе, стало возможным ублажить и бухгалтерию. До этого они были в ручном режиме, и их было просто весьма жалко. У них конечно были необходимые бухгалтерские программы и программы позволяющие оплату через банк в сети, но почти пол-года они мучались с загрузкой данных в свои программы. Они действительно были рады получить возможность автоматической выгрузки нужных им данных в нужном для них формате, а позже их настроение поднял отчет по оплате поставщикам.
Кстати всего этого еще не хватало чтобы показать отчет, который имел бы в себе остатки по любым товарам на любой промежуток времени — это не что-то, о чем сначала задумываешься особенно. Но позже видишь что есть информация, которую нужно собирать специфически только для одного типа отчета, а иначе пострадаешь конкретно если попытаешься что-то такое вычислить на ходу.
Еще предстоит сделать кучу всего и вообще программы такого рода никогда не могут завершиться, нельзя поставить последнюю точку и сказать: все, это максимум, больше здесь делать нечего. Но после двух лет над этим проектом если меня кто-то спросит — стоит ли писать что-то свое, большое, с нуля и с кучей неизвестных? Думаю что отвечу что нужно писать.
Если есть вопросы, пишите в комментариях, я отвечу.
Totum — open source конструктор CRM/ERP и произвольных учетных систем (PHP + PgSQL)
В двух словах — продвинутые таблицы. Ориентирован на отдельных разработчиков или микрокоманды из двух-трех человек. Подходит начинающим разработчикам и бизнес-аналитикам, желающим превратить свое понимание бизнеса в готовое решение или быстро разработать проект под конкретного клиента. Для небольших бизнес-ниш — в которых нет типовых решений. Small-code принцип — множество простых, ситуационных кодов. Есть подробная документация и видео. Устанавливается на собственный сервер за 5 мин. Со временем позволит выгружать разработанные на нем решения с коммерческими лицензиями с использованием встроенной защиты.
Для каких задач
Разработка custom CRM/ERP или любого другого учета для небольших компаний
Лично мы сделали и эксплуатируем несколько проектов с ценой разработки 300—1500К.
Быстрая разработка коробочных CRM/ERP для небольших ниш
В малом бизнесе есть множество небольших областей, в которых требуются специализированные CRM/ERP/Учетные системы. Так как сегменты рынка небольшие, в продуктах крупных разработчиков есть пробелы, не покрывающие мелкие специфические задачи. Идея Totum в том, чтобы упростить разработку нишевых CRM/ERP, сделав ее возможной для отдельных разработчиков и рентабельной для небольших команд из 2-3 человек.
Таблицы + код + браузер
Основа Totum — таблицы. Это чем-то похоже на недавно вышедший у Amazon Honeycode. Но в Totum таблицы выступают как общая концепция организации информации. Данные можно разместить не только в таблице со строками, но и над ней или после нее. Можно быстро накидать нужные поля мышкой или заморочиться и настроить их внешний вид, адаптивность, объединить в группы, сделать подсветку и тд.
Таблиц может быть много. Предусмотрены разные типы таблиц под разные задачи: хранение данных, циклические заказы или проекты, временные отчеты или всплывающие окна.
Для полей внутри мы сделали 15 типов:
Поля добавляются мышкой. Настройки полей выбираются мышкой и их не так много. Для числового поля это будут:
Часть полей в решении отвечает за ввод данных пользователем, часть за вычисление значений и выполнение действий или все вместе. Для того, чтобы это обеспечить, коды пишутся в специальных окнах в настройках поля. Totum обеспечивает подсветку, поиск и подстановку адресов таблиц и других полей, переменных и функций, а также автозаполняет параметры функций. Сделано это на основе codemirror. Про коды и их разделение я расскажу чуть дальше. Коды простые и с ними могут работать начинающие разработчики или бизнес-аналитики.
Интерфейс у Создателя-разработчика тот же, что и у пользователя, но с дополнительными элементами управления, которые создатель может быстро скрыть/показать. Можно на время переключиться в вид конкретного пользователя, чтобы оценить, как у него выглядит система. В одной и той же таблице различные роли могут видеть/изменять разные наборы полей и строк. Можно создать не только пользователя-человека, но и пользователя-API и настроить ему собственный доступ.
Разработчику не нужно быть full-stack программистом, чтобы собрать конечное решение на Totum. Знание html, адресация доменов и общие познания про то, как работает интернет, будут в плюс, но вообще нужно знать лишь сам Totum.
Small-code принцип
Totum основан на небольших кодах, разделенных по типам действия — одни коды вычисляют значение в поле аналогично формуле Excel, другие следят за триггерами изменений и — если они сработали — выполняют написанные в них действия. Третий тип кодов отвечает за внешний вид полей в зависимости от набора данных в схеме. Если эти коды выполняются для таблицы с несколькими строками, то их выполнение будет повторено для каждой изменяемой строки. Обычно коды маленькие. В реальных проектах у нас всего пару раз были коды более 100 строк — обычно 5-10. С таким кодом легко может разобраться начинающий разработчик. Преимущество же кода перед BPMS в том, что на нем проще и понятнее написать разветвленную логику (во избежание холивара по BPMS — это наше субъективное мнение).
Код, вычисляющий значение поля, не может выполнить действие или изменить форматирование — он замкнут сам в себе. Если в нем использованы какие-либо переменные, то они существуют только в момент выполнения этого кода в конкретном поле и никак не пересекаются с другими полями. Имеют декларативную логику:
Это не синтаксис, про синтаксис чуть дальше 🙂
Код действия выполняется только при срабатывании триггеров: изменение значения в поле, добавление или удаление стоки. Для кнопок триггер один — нажатие кнопки. Они тоже замкнуты в себе и никак не пересекаются с другими кодами. Можно использовать одинаковые переменные для кода значений и кода действий в одном поле. Коды действий работают в похожей логике:
Код форматирования может повлиять только на внешний вид своего поля. С ним все просто — он выполняется, если пользователь смотрит на таблицу, при любом изменении в этой таблице:
Чтобы это работало, должен быть известен порядок выполнения — он есть. У каждого поля в таблице есть порядковый номер sort. Сначала считаются значения полей в порядке sort, потом действия в таком же порядке и затем форматирование. В интерфейсе поля показываются в этом же порядке. Да, есть возможность показать поле не в том месте, в котором оно рассчитывается, но об этом сейчас не будем.
Таблицы же могут быть на миллионы строк — они же не будут целиком пересчитываться при изменении? Не будут. В Totum есть понятие «единица пересчета». Она может быть «таблица целиком» или «строка целиком». Разные типы таблиц имеют разные единицы пересчета. Те типы, у которых единица пересчета «строка целиком», при изменении пересчитывают только те строки, в которых произошли изменения. Действия выполняются только при срабатывании триггера. Форматирование считается только на те поля, которые видны пользователю.
Если в результате расчета или действия в таблице что-то изменилось — то при записи изменений у нее изменяется «транзакционный номер». При начале пересчета этот номер запоминается и сравнивается с номером этой же таблицы по окончании пересчета и перед записью. Если номера не совпали, то это значит, что за время операции таблица была изменена другим пользователем. Тогда расчет можно отменить, продолжить или запустить его еще раз взяв новые исходные данные. Это настраивается для каждой таблицы и позволяет разработчику в два клика управлять требуемым уровнем согласованности данных и обеспечивает многопользовательский режим. Для таблиц, в которые осуществляется непересекающаяся запись, — эту проверку можно отключить. Еще одним преимуществом этой модели является то, что вся цепочка действий и пересчетов, задействующая несколько таблиц будет отменена при наличии ошибки или по срабатыванию специально заложенной отмены без записи каких-либо изменений в базу. Открытая у нескольких пользователей таблица сама не обновляется, но они видят предупреждение, что другой пользователь внес в нее изменение которое текущий пользователь еще не видит. Его тоже можно отключить.
Totum-code
Totum написан на PHP, но внутри программируется собственным языком — Totum-кодом. Он призван упростить задачу разработки для новичков. Упрощали по-максимуму и затачивали под таблицы и поля, которые разработчик видит внутри Totum. Вызов и запись данных тоже осуществляется в Totum-коде, SQL знать не нужно.
Базис выглядит так:
Есть еще немного мелочей, но они уже второстепенные. Все остальное выполняется функциями. Например: