Введение
Хотелось бы поговорить про ERP системы в 2022 году, и можно было бы здесь описать статьи из wiki про то, что такое ERP система общими словами и многое другое, но я не про это, а про то, есть ли вообще место ERP системам в современно микросервисном мире.
Зачем?
Первое что хотелось бы спросить про такой громкий заголовок это "А зачем?" и на мой взгляд это очень правильный вопрос т.к. с нулевых годов витала постоянно мысль, что ERP очень важная штука для более менее приличной компании, у которой есть какие-то операции, склады, учет и тд. НО! На самом деле технологический мир очень сильно изменился с тех пор и если кратко ответить нужна ли ERP, то НЕТ, она действительно не нужна, тк потеряла свою значимость ведь какой раньше был смысл такой системы?
Почему было так
Какие основные причины были раньше:
Все в одном окне;
Все данные связаны в одной системе и потенциал ошибок маленький;
Много кансалтеров SAP, 1c, Axapta и проч.;
Сложно сделать самому, нужно инвестировать большие средства в команду и бизнес аналитиков;
Большое количество модулей из коробки охватывающий много потенциальных бизнес процессов ( учет, склад, логистика, закупки, производство и тд).
На мой взгляд самое большая причина была в том, что бизнесу казалось, что создавать продукт управления бизнесом это что то экстраординарное и трудоемкое, и это было так, тут не поспоришь, и инерция такого умозаключения осталась....
Что такое ERP
Если посидеть, подумать, и разбить все основные модули классической ERP на функциональные блоки то у нас будет такая структура:
Закупки - отвечающие за то, что мы покупаем;
Учет - всем нужен учет :);
Логистика(склад) - учитывать товары многим нужно;
Сбыт - модуль продаж;
HR - модуль учета сотрудников (достаточно опциональный модуль);
В большинстве случаев это и есть картина классической ERP в бизнесе, но пройдемся по каждому из них и попробуем разобраться из чего они состоят
Закупки - это модуль управляющий закупками компании, давайте заглянем внутрь и посмотрим что должно быть внутри такого модуля
Товар и услуга - ну без него не обойтись, мы же что то закупаем,
Поставщик - мы у кого то покупаем,
Прайс-лист(опция)- не всем это нужно, но в целом давайте его добавим,
Склад(опция) - куда мы хотим этот товар закупить,
Контракт - без контракта в РФ ничего нельзя закупать в целом, поэтому его тоже нужно вести,
Менеджер - тот кто закупать,
Заказ - Сам обьект заказа в котором все вышеперечисленные поля заполнены и есть табличная часть с товарами, по сути это основной и наверное единственный динамический обьект модуля закупки, остальное можно считать мастер-данными,
Счет фактура - Invoice те подтверждающий документ о поступлении товаров.
Я не буду разбирать каждый обьект модуля тк это избыточно и может быть наполнен разными атрибутами, типами и свойствами уже зависящих от специфики работы компании.
В целом на этом все, что бы создать модуль закупки нам действительно нужно создать только эти обьекты
Флоу закупки выглядит примерно так:
Менеджер закупки создает поставщика, заводит контракт, создает заказ на закупку и отправляет поставщику его по edi или почтой, это уже средство доставки
Потом приезжает машина и уже от компании зависит кто вводит подтверждение что заказ пришел, вводит количество, в разных компания по разному, у небольших это один и тот же человек, а в других это работник склада получателя в wms системе или так же в заказе созданным менеджером
Далее сотрудник работающий с первичкой вводит Счет фактуру
А теперь самое главное и ВАЖНОЕ в любой ERP системе - создать транзакцию
Транзакция - это сведение о том, что товар или услуга поступила и она несет в себе самую важную для компании информацию - локация, стоимость, товар/услуга.
Любая хозяйственная операция в ERP системе должна и обязана быть учтена как количественно так и финансово, люди которые думают, что важно просто создать удобный интерфейс закупки и работы с ним это главное, но главное на самом деле это транзакционный лог хозяйственных операций, и по факту это и является основной работой ERP системы, которая и должна учитывать любой чих компании в виде финансовой операций, и бывают транзакции в виде:
Тип |
Локация |
Продукт |
Кол-во |
сумма |
Приход товаров |
Склад 1 |
Печенько |
5 |
25 |
Продажа |
Склад 1 |
Печенько |
-2 |
-10 |
Стронирование прихода товаров |
Склад 1 |
Печенько |
-5 |
-25 |
Отражение оплаты |
Склад 1 |
Печенько |
5 |
50 |
Что тут происходит:
Пришел товар Печенько в количестве 5 шт на сумму 25, далее мы продали товар и со склада ушли 2шт товара по стоимости из предыдущей транзакции 10, далее бухгалтер ввел счет фактуру, в которой стоимость печенек стало не 25, а 50, поэтому транзакционность должна быть отсторнированна и скорректирована, и так же на каждом этапе транзакции понятна себестоимость продукция равная сумме сумм поделенное на сумму количеств в каждом моменте времени.
Это примитивный пример, но от отражает основную суть - каждое действие в компании (приход, расход, списание, потери, продажа, инвентаризация, и тд) должно быть выражено с помощью финансово-количественной записью для того, что бы в любой момент времени компания понимала состояние ведение своего бизнеса, в разрезе бизнес юнитов, хозяйственных операций или кагорт товаров и прочими разрезами.
Итак, мы поняли что происходит в закупках, давайте разберемся в следующем модуле
Учет - это модуль бухгатера, помогающий отражать первичные документы, выставлять счета на оплату, управление счетом в банке и прочее, в целом он состоит из таких обьектов как:
Инвойс - это по РФ счет-фактура, или ПТУ или АКТ выполненных работ, те документ отражающий хозяйственную операцию;
Банк - Если система интегрируется с банковскими сервисами;
Платежные поручения - документ отражающий заявки на оплату, например поставщику;
Бухгалтер - пользователь который этим ведует.
И так же как и когда закупщик или склад принимает товар и создается транзакция, так и при вводе инвойса(счет фактуры) происходит транзакция на основе Заказа к поставщику, далее производится оплата с помощью платежного поручения на основе счет фактуры и уходит в банк, а из банка в дальнейшем придет подтверждение, которое с помощью конектора с банком возвращается в систему и процесс закрывается, налоги рассматривать не будем.
Сбыт - модуль сбыта это практически зеркальная копия модуля закупки, только там заказ на продажу, а инвойс не приходит, а выставляется, можно сказать это по сути одинаковые модули, но документы ведут себя наоборот, товар не приходит, а уходит, деньги не уходят а приходят :)
Есть еще более специализированные модули, такие как бюджетирование, производство, маркетинг. Но решение этих задач сложно обобщить, они требуют индивидуальной разработки.
Другие модули я разбирать не буду статья про подход, а не про каждый из них
Промежуточный вывод из примеров
Каждый из модулей ERP в целом содержит несколько уникальных сущностей, но так же имеет общие свойства такие как:
Пользователь - есть у каждого основного документа,
Транзакции - те каждый из модулей генерирует транзакции,
Локации/Склады - почти каждый модуль работает с локациями компании,
И прочие, которые не разбирали.
Какой вывод можно сделать:
Что данный функционал является общим для все и его нужно разрабатывать первостепенно и начиная именно с него, а не с модулей непостредственного ведения бизнеса
Все модули это средства для достижения только 1й цели - создать финансовую транзакцию, И при разработке ERP системы менеджер продукта создающий ее или тим лид команды должен думать только об этом, тк цель всей системы это посчитать все операции и уже предоставить руководству правильные данные, но почему то часто при разработки таких систем об этом забывают.
Что изменилось с 00х
После эпохи классических ERP таких как SAP, 1c, Axapta и проч. изменилось очень многое:
DevOps - стал доступен, те сейчас можно просто купить услуги инфраструктуры у разных компаний и довольно по доступной цене, те не нужно нанимать в штат классических админов и не понимать что же они там делают в своей коморке)).
Развитие web сервисов - сейчас появилось бесчисленное множество платформ для создания веб приложений, на основе которых можно быстро сделать атомарное приложение для бизнеса в тч одно из вышеописанных, где время от ТЗ до MVP будет аля пару месяцев.
Появилось очень много людей, которые знают как правильно создать бизнес приложение.
План действий
Итак мы проговорили, что ERP система это не такая уж умная и недосягаемая штука, которую можно сделать бизнесу самому не привлекая дорогущий консалтинг, ичто нам для этого понадобиться
Самое наверное важное это найти человека который может - это действительно самая важная часть, тк человек, который знает как декомпозировать такую большую задачу как создать ERP на много маленьких и понятных.
Уже нанятому и знающему человеку выбрать платформу, их на самом деле не мало и они отличаются очень кардинально, и тут главное исходить из многих факторов, сроки, функциональности, доступность на рынке разработчиков и проч.
Выбрав платформу декомпозировать на задачи.
Немаловажный пункт второй и тут как раз мы подходим к заголовку статьи - выбор платформы очень важная часть нашей задачи и здесь я упомяну такую платформу как Odoo, она позволяет как говорят - быстро стартануть ввиду уже готовых модулей, что я описал выше, ее можно сравнить с 1с УТ из мира 1с, все в коробке и осталось разобраться как ее варить. Но и упомяну и основные минусы готовых модулей, таких как уже готовые модули из коробки по моему опыту:
Слабо оптимизированны для нагрузки.
Архитектура не самая лучшая для развития и доработок.
Слишком много зависимостей.
Мало разработчиков на рынке знакомые с платформой.
Причем эти минусы относятся почти ко всем коробочным решениям с готовыми модулями
Плюсы
На начальном этапе совсем не нужен фронт, фронт генерируется автоматически, и это позволит существенно сократить бюджет.
Очень много уже платформой заложеных бизнес функций, такие как работа с валютой или логистические операции, или работа в excel и word и многие другие которые являются практически обязательными в Бизнес приложениях.
Много технически батареек нацеленные на бизнес данные.
Много готовых решений (но на них надо очень внимательно смотреть).
В целом Odoo это на мой взгляд очень хорошая платформа для написания почти любого бизнес приложения любой сложности и позволит бизнесу разработать любую функциональность применив наименьшее количество ресурсов
Итог
Данная статья нацелена скорее на бизнес сегмент людей и обьясняет, что любой бизнес продукт можно сделать своими силами и внутренней командой, тк создание даже больших систем не является непостижимой задачей, как и везде главное люди и прежде чем смотреть в сторону покупки "коробки" стоит рассмотреть вариант с созданием собственной системы, в которой можно реализовать практически любой функционал, а не то, что в коробке предлагают.
А хорошо декомпозировав задачу можно сделать приложение на любой современной платформе Django, Odoo, Flask, JavaSpring и другие. и стоимость для бизнеса в среднесрочной и долгосрочной перспективе будет гораздо ниже, при условии конечно качества команды и самого бизнеса.
Комментарии (55)
git-merge
10.02.2022 16:21+2и инерция такого умозаключения осталась....
Проблема убедить бизнес в том, что это именно инерция.
Как показывает практика, бизнес предпочитает платить существенно бОльшие суммы внешним продуктам, нежели своим командам разработчиков.
zambas Автор
10.02.2022 16:23+2Согласен, часто сталкивался, когда и нужные люди есть и талантливые разработчики, но бизнес возможно страхуя последствия своего решения платит внешнему консалтингу
Pantevg
10.02.2022 18:12+2Кому интересно узнать больше про ODOO - https://www.antonpiskun.pro/category/odoo/
timoor
10.02.2022 18:18Шикарный блог, но очень мало технической информации. То есть почитав его - систему под себя не подстроишь, увы.
Pantevg
10.02.2022 18:28+2Я к сожалению (или к счастью) не технарь) и пишу для обычных пользователей. С ODOO работаю больше 5 лет и пока лучше платформы для решения бизнес-задач не нашел. Это по сути конструктор с помощью которого можно достаточно быстро сделать любое решение. Как пример - базовое решение по регламентированному учету для Украины было сделано за 4 месяца с помощью одного аналитика (меня) и двух разработчиков. С описанием решения можно ознакомиться в моем блоге.
И на самом деле в ODOO много готовых решений, правда не адаптированных под потребности наших компаний. И тут вопрос: а кто их должен создавать? индусские разработчики? европейские разработчики? Ну так они под западный рынок это делают
timoor
10.02.2022 18:39Антон, простите, не признал сразу =) Спасибо за кучу полезной информации, которую я почерпнул в Вашем блоге.
Полностью разделяю Ваше мнение про пригодность платформы для решения бизнес-задач самого широкого спектра, но, увы, платформа таки заточена под "западный" рынок. И, как мне показалось, реализовать штатными средствами (мы используем payroll от Odoo mates, пробовали до него модуль от Cybrosys) расчет тех же отпускных и больничных - не представляется возможным.
Соглашусь, что заниматься локализацией системы под локальное законодательство - должны сами "утопающие", ну или те же, условные, индусы, но под чутким руководством локальных аналитиков.
Вопрос - я правильно понимаю, что на Вашем рынке уже есть типовая конфигурация по бухгалтерскому учету? Доступна ли она для свободного скачивания? Почему-то есть ощущение, что законодательство в этих сферах у нас схожее (я из Азербайджана).
И второй вопрос - могли бы Вы порекомендовать ребят из Украины, которые по нашему ТЗ смогут кастомизировать модуль бухгалтерского учета и payroll?
Pantevg
10.02.2022 18:46+1По первому вопросу: к свободному скачиванию еще не доступна. Могу вам показать, что и как реализовано (но перед эти почитайте здесь -https://www.antonpiskun.pro/odoo-reglamentirovannyj-buhgalterskij-uchet-dlya-ukrainy-versiya-14-01/)
По второму вопросу: Да могу) Я как раз в такой компании работаю и у нас есть специалист, который занимается зарплатой - есть большой опыт в этом направлении. Пишите мне на почту antonpiskun@gmail.com или в телеграм Pantevg
CrushBy
10.02.2022 19:59С ODOO работаю больше 5 лет и пока лучше платформы для решения бизнес-задач не нашел.
Как вариант, можете посмотреть платформу lsFusion (и MyCompany - простое решение на ее основе).
qqqoid
10.02.2022 20:33одно время наблюдал за проектом, удачи ребятам. но ява! инструмент ни к месту и не ко времени (при всём Уважении), отправил как-то к ним своего неудавшегося клиента, не знаю дошел или нет.
CrushBy
10.02.2022 21:09Java там используется только при разработке самой платформы. Непосредственно бизнес-логика пишется на собственном высокоуровневом языке.
Не могу сказать, что Java - очень хороший язык программирования, но сложные системные архитектуры все-таки лучше писать на сильнотипизированном языке. Так что выбор был не очень велик при таких вводных.
Высокоуровневые конечные бизнес-приложения же да, на Java писать - не самый лучший выбор, на мой взгляд. Там лучше динамические языки, вроде Python, Ruby, JS и т.д.
qqqoid
10.02.2022 21:36я знакомился, немножко в теме. это религиозный вопрос, стараюсь воздерживаться. ява есть ява, шаг в сторону и вот она со всей свой забавной экосистемой, ценниками и проблемами. ничуть не умаляю, проектик интересный.
MarazmDed
11.02.2022 13:21. И тут вопрос: а кто их должен создавать? индусские разработчики? европейские разработчики? Ну так они под западный рынок это делают
А зачем это делать в РОССИЙСКИХ реалиях? Есть 1С, где все это реализовано. И если в случае с odoo вопрос ставится "что нужно запилить, чтобы просто заработало", то в случае с 1С вопрос ставится "все работает, теперь хочется бизнес-фич". Что как бы делает очевидным перекос в сторону 1С.
zambas Автор
11.02.2022 15:00Ну на моем опыте ( может мне попадались такие компании ), но в первые годы бизнеза действительно 1с незаменимая вещь, но потом, когда компания сильно растет(ну если растет) платформа не может уже дать того, что нужно, примеров очень много и каких только костылей я не видел в 1с, что бы научить ее работать с такими привычными уже вещами как S3, или интеграцией с BI, бедные аналитики в поисках как перевести данные бд в приличный вид. а когда говорят слова типа, ну можно же из 1с выгружать данные как нужно BI в файлики или еще куда, отвечу-нет, это уже костыль
Ta_Da
11.02.2022 18:02Ну на моем опыте ( может мне попадались такие компании ), но в первые годы бизнеза действительно 1с незаменимая вещь, но потом, когда компания сильно растет(ну если растет) платформа не может уже дать того, что нужно
Немного уточню. В первые годы бизнеса, 1С очень дешевая (как с точки зрения лицензий, так и с точки зрения зарплат 1С-ников) и доступная (в плане поиска внедренцев на типовые решения) вещь. Но как только компания сильно растет, доработка/настройка/обслуживание 1С резко вырастает в цене (ох, какая неожиданность - сложные кастомные решения на большое число пользователей - это дорого), а специалистов которые могут (и главное - хотят) решать эти вопросы не всегда удается найти. Т.е. прямо противоположная ситуация с условными ODOO - разработчик, который будет щелкать интеграции с BI, может как от огня сбежать от необходимости поддерживать в актуальном состоянии печатные формы, да и денег попросит, скорее всего, побольше.
zambas Автор
11.02.2022 19:22сбежать от необходимости поддерживать в актуальном состоянии печатные формы
Не вижу проблем с такими задачами))), есть задача - делай, печатная форма это или BI это не важно, это просто задача
MarazmDed
12.02.2022 15:42но потом, когда компания сильно растет(ну если растет)
Ну, за компании, которые сильно растут, можно только порадоваться. Но сильно растут далеко не все. Куча компаний упирается в некоторый потолок, где и болтаются десятилетиями. И для них 1С - то, что доктор прописал.
Ну а в Вашем кейсе, где в платформе 1С тесно, odoo, SAP и что там бывает еще - вполне себе вариант. Для каждой задачи - свой инструмент. Впрочем, для крупных компаний бесплатность инструмента не является ключевым фактором. Так что и здесь у odoo могут быть проблемы.
, что бы научить ее работать с такими привычными уже вещами как S3, или интеграцией с BI,
https://infostart.ru/1c/articles/914689/ - здесь описан вариант интеграции чуть ли не из коробки. S3 - предоставляет API, так что на счет костылей можно спорить.
Разные варианты бывают. Odoo, как и другие решения, имеет право на жизнь. Но малому бизнесу недостаточно бесплатности odoo, еще нужна нормальная поддержка российского, быстро меняющегося, законодательства (это важно и для управленческого учета). И здесь 1с вне конкуренции.
svcoder
12.02.2022 20:10Это вы сами про костыль придумали? Есть механизм регистрации изменений + регламентное задание, которое выгружает данные хоть во внешнюю БД, хоть в шину хоть в веб-сервис. Или по-вашему правильно это дать внешней системе доступ к таблицам?
timoor
10.02.2022 18:25Как же удачно я отвлекся от написания формул зарплаты в Оду и наткнулся на этот пост.
Очень, очень много боли, как только руки до ходят до финансов и пейрола. Когда только установили и стали настраивать моудль кадрового учета - душа пела и радовалась, ровно до того момента, как кадровики прислали нам формулы расчета отпускных и больничных.
Перепробовали несколько модулей (бесплатных), но так и не нашли того, что нам нужно.
Система шикарная, стек - то, что надо. Но без пайтон-разработчика в нее лучше не суваться, во всяком случае в реалиях экс-СССР.
Для себя мы приняли решение и дальше грызть кактус, поэтому ищу сейчас того, кто поможет допилить нужный нам функционал, за адекватное вознаграждение.
В идеале - надо ОДИН раз сделать типовую конфигурацию для нужной страны (по тем модулям, которые этого требуют, тот же пэйрол и бухгалтерия), подогнанную под локальное законодательство, дальше будет существенно легче.
XaBoK
11.02.2022 03:24Вы упустили один важный аспект - само предприятие зачастую не в состоянии построить ERP систему. И дело не в технических аспектах, а в смене парадигмы самого бизнеса. Именно это (взгляд со стороны) дают консалтинги. Business Transformation - это то что нужно, а сама система - лишь инструмент.
zambas Автор
11.02.2022 09:58В статье я как раз и раскрываю мысль, что нужно найти кадры которые могут, поверьте они на рынке есть
XaBoK
11.02.2022 14:56+1В том и загвоздка. Спецов на рынке можно найти, но когда их нанимают, то начальство/владелец требует подчинения своиму пониманию процесса. В то время как крупный бренд со стороны всегда воспренимается не только как исполнитель, но и сертификатор.
Чтобы было более понятно дам пример из личного опыта. Меня вот так наняла компания, как специалиста, чтоб возлавить технический процесс создания системы. В первый рабочий день мне озвучили сроки - всё должно быть готово, через 3 месяца. Вот 2 программиста, вот менеджеры и тестировщики, а вот и тз на 150 страниц, которые мы писали год, но там не хватает деталей. Я изучал требования пару дней и сказал, что нужно человек 10 разработчиков и 2 года. Скандалы, вызовы на ковёр всех VP, торг и все остальные стадии принятия. Так 2 месяца и проходят. Потом из материнской компании нанимают консалтинг. Те говорят тоже что и я, вот только результатом их слов стали не скандалы, а найм команды и увольнения пары VP отвечавших за выбор платформы и задание. Но генеральный то остался. И каждый модуль, каждый раз, проходил через скандалы, попытку начальства продавить свою линию, провал по срокам и качеству, вызову консалтеров и принятию моего мнения через их одобрение.
В общем к своим экспретам в больших компаниях относятся как и ко всем остальным ресурсам - делай как тебе скажут. Это я видел и вижу в разных проектах, не только ERP. Просто сейчас это я прихожу в другие компании как консультант.
zambas Автор
11.02.2022 14:55Ну я кажется это как раз не упустил, а подчеркнул, в моей статье описано, что для того что бы построить ERP систему нужны знающие люди, а на технический аспект я не делал акцента.
А консалтинг это тоже люди)) и они могут работать у вас)
AlexOrgnet
11.02.2022 14:46+2Ну так в чем дело? Набирайте смело команду из примерно 50 человек и в течении примерно 5 лет делайте новую, правильную и молодежную систему ЕРП на микросервисах. Делов то всего
zambas Автор
11.02.2022 14:46так мы набрали, и сделали, и работает, 5 лет не понадобилось, получилось за 6 мес, команда 4 бека 0.5 фронта, продакт
функционал примерно похож на набор из нашей любимой 1с УТ + узкоспециализированные фичи уже относящиеся к внутренним продуктам компании
Закупки, склад, сбыт, логистика, первичка, транзакционность, удивительно, что вам бы понадобилось 5 лет и 50 разрабов :)
Tupolog
12.02.2022 18:12Как же к месту такие посты и обсуждения, спасибо. Мне, как и любому владельцу бизнеса, требуются кастомные решения, смотрел наш totum, odoo, руководитель crm и год сидели на Ragic!. Теперь буду попробовать lsFusion.
Сейчас с успехом применяем планфикс, 1с. Все эти и другие облачные решения хороши, но только до того момента пока вы не решаете использовать принцип одного источника данных. Данные из этих систем необходимо одновременно использовать и на сайте и в конфигураторе продукции и в CAD, и еще много где. И вот с этого момента начинаются костыли и рост затрат в геометрической прогрессии на разработчиков, без надежды на то, что это закочится и не начнется после очередного обновления платформы.
Я не програмист, но с логикой дружу, использовали в свое время, до закрытия проекта XtraBuild disigner, который прекрасно справлялся с задачами построения интерфейса, баз данных, календарей, графиков, канбан досок, гант-диаграм, любых отчетов на встроеном fastreport движке, сводных таблиц, фильтрацией сортировкой и манипуляцией данными, любому человеку знакомому с формулами excel, без единой строчки кода.
Я понимаю, идеального инструмента не существует, но близкие к нему возможно есть или были точно. Еще раз спасибо за обсуждение.
Обобщая выше сказанное от лица бизнеса:
Я хочу просто и понятно владеть, изменять и применять свои данные в единой БД. Ровно так же, как я привык это делать в excel, наполнять фильтровать, делать срезы, считать, сортировать и задавать условное форматирование.
Я не хочу каждый раз окостыливаться, терять время при смене разработчика для изучения нового языка програмирования если проект закрылся, или обновилась платформа, привет 1с, totum и т.д.
Благодаря статье понял что не буду останавливаться на odoo. Спасибо.
CrushBy
А в Odoo уже есть готовые модули для формирования УПД, интеграции с российскими EDI-провайдерами, для взаимодействия с ЧЗ/ЕГАИС/ВетИС ? Или это все нужно писать самому с нуля ?
zambas Автор
про EDI есть
А про ЕГАИС и ЧЗ нет, там есть модуль серийных номеров, думаю там потребовались бы микродоработки для работы с ЧЗ
CrushBy
А можно, пожалуйста, ссылку на уже готовый модуль работы EDI (желательно бесплатный) ?
И УПД все-таки есть какой-то модуль ? А то без УПД (или ТОРГ-а) какого-нибудь вообще как-то не получится начать работать.
Как человек, который реализовывал интеграцию с ЕГАИС и ЧЗ, и знает как там все устроено, "микродоработки" - это явно неправильное слово. Учет по серийным номерам - это маленькая часть (и то, насколько я помню, в Odoo там много чего нет - например, там есть агрегация серийных номеров ?)
zambas Автор
Если ты говоришь про УПД и ТОРГ- как печатные формы то на Odoo с модулем можно начать, но я бы делал свою генерацию, тк покурив все внутренности и возможность open_source python все становится проще
По поводу EDI в Odoo есть из коробки модуль по работе с EDI он называется account_edi* их там несколько, что бы заработало для РФ потребует минимум манипуляций разработчика
arulby
Можно спросить про производство? В erp предполагаются ещё модуль производства продукции, планирование, бюджет, CRM ну и ещё пачка всего
zambas Автор
Модуль производства в odoo есть из коробки, можно на него тут посмотреть
antonsobolev
Вы правда полагаете, что серийные номера и микродоработки решают проблему егаис и чз маркировки?
mgis
Все это разумеется придется писать самому с нуля.
Это пожалуй единственная причина незыблемости решений 1С на рынке автоматизации учета.
При всей моей личной нелюбви к этой компании, они единственные кто подерживает в актуальном состоянии, как взаимодействие и госудаственными информационными системами, так и обновляет печатные формы, документы, отчетность в соответствии с требованиями законодательства.
А вообще сам в последние пару лет активно слежу за Odoo, нравится мне стек, но начать на нем какой нибудь проект автоматизации "рука не поднимается".
zambas Автор
Плюсану про учет и 1с, все так, но мир не ограничивайтся учетом, есть множества других потребностей бизнеса )
CrushBy
К сожалению, не единственная причина и не главная. Незыблемость обусловлена в первую очередь консерватизмом бизнеса (как и на любом другом рынке).
Поддержка ГИС и печатных форм в задачах кроме бухгалтерии и ЗУП не столь трудоемкая, и там нет таких жестких требований в законодательстве. Хотя конечно в Бух и ЗУП действительно 1С практически монополист именно из-за законодательства.
zambas Автор
Ты прав, в статье я как раз в 'инерции' я и подразумевал консерватизм
Про БУХ и ЗУП полностью соглашусь, законодательсво делает такие преграды одним и приемущества другим
qqqoid
почему не поднимается-то? сделать из odoo ERP фантазмагоричная идея, но это ОЧЕНЬ хороший инструмент, да и конкурентов как бы и нет вообще. Получаю удовольствие.
Учет ессно живёт отдельно. Но в наших реалиях он вообще почти всегда "отдельно" живёт, да и вообще не каждой сове надо быть натянутой на глобус ERP.
CrushBy
Проблема Odoo в том, что по нему нет русскоязычного community (я по крайней мере не нашел). Если какие-то проблемы возникают, то придется барахтаться самому. Да и на odoo.com форум, скажем прямо, не очень популярный.
qqqoid
Это да, в России не особо популярная платформа и на русском действительно нет ничего.
Но это open source и python, внутри всё прекрасно документировано и всегда доступно. Особенных проблем в освоении не возникло, фронт конечно специфичный, немного доставлял по-началу.
Кстати есть пара родных отличных книжек, выпущенных пактом (Odoo Development Cookbook и Odoo Development Essentials), в принципе любой из них достаточно для быстрого старта.
CrushBy
Просто не очень понятно, на кого это рассчитано.
Если я - продвинутый пользователь (или средненький/слабенький 1С-разработчик), то я явно не смогу это поддерживать и дорабатывать (там все-таки достаточно высокий порог вхождения).
Если я - сильный python developer, то на Odoo в РФ много не заработаешь (так как придется конкурировать с 1С, который продает все очень дешево). А как сильный python developer можно без проблем найти достаточно жирную вакансию просто в аутсорсе с нормальными условиями работы, а не выносить мозг работая напрямую с бухгалтерами.
Поэтому и не удивительно, что нет комьюнити.
qqqoid
Есть доля истины в ваших словах!
Но я бы не сказал, что уровень вхождения очень высок. Крыжить формы в xml-е много пядей не надо во лбу. С копипастой моделей тоже справится любой. Да вправо-влево нужен и пайтон и js, причем немного специфичный в первом случае и довольно много во втором, но это уже следующий этап. По моему опыту очень многим достаточно и первого. Есть средства быстрой разработки позволяющие крыжить формы и модели из веб интерфейса (никогда не пользовался, но люди пользуются и успешно).
Занимаюсь odoo уже третий проект, повидал и за собой и за многими (и частниками и конторами, в России есть парочка) всякого. Но наклепать на оду какое-то небольшое приложение с формами, правами и коммуникативными возможностями способен любой продвинутый новичок, готового действительно громадное количество.
Но всё надо пилить, просто взять и поставить - мало что получится. Но есть исключения, я писал: есть отличная crm, проекты и многое другое.
Для тех кто на следующем уровне есть OCA - оттуда можно взять просто огромную массу всего, от posgis и рабочих процессов до всевозможных вьюх. Но там конечно всё полуготовое, для более-менее профи.
CrushBy
Первое - это самый простой CRUD ? Очень узкая область.
Опять же встает вопрос позиционирования. Человек, который сможет въехать во все это (xml/html, python и js), разобраться в не такой простой архитектуре и функционале Odoo - это уже человек, который может без проблем стать, как минимум, middle developer'ом, и непонятно зачем ему заниматься этим бедным рынком (малый бизнес в РФ).
qqqoid
мое мнение, что человек который в этом разобрался досконально не "может без проблем стать" - он уже как минимум стал, там местами не для слабых духом.
по остальным вопросам я особо и не спорил, проблем навалом. отечественная мелочь не столько бедна (хотя в среднем по больнице это так), сколько не приучена платить за ит вообще, с ними сложно, но есть исключения.
kuznetsovin
По моему опыту человек без навыков программирования начинает делать модули на оду через неделю...
Архитектура там вполне себе нормальная и позволяет отделить работу верстальщика, от работы фронта и работы бэкендера.
Да специфика, есть но не такая глобальная как кажется, особенно с выходом 14 версии и реактивным фронтом
CrushBy
Речь идет не про CRUD. Для чего-то немного сложнее потребуется уже и Python, и HTML с CSS и JS. А во многих случаях и SQL (не будете же вы считать отчет с выручкой и доходом за месяц через ORM). И вот все это человек без навыков программирования сможет делать через неделю ? Что-то я не верю.
Нам довелось пытаться обучить нашей платформе lsFusion несколько десятков (если не сотен) человек (не программистов). А она гораздо проще для человека с нуля. Даже статью про это писали.
Так вот 90% человек не могут просто создание доменной логики освоить (то есть тупо выделение сущностей для CRUD). Такой бред местами делали в примитивнейшей логике, и не понимали что не так. А Вы говорите про писать модули на Odoo...
Вы понимаете, что сама концепция MVC (используемая в Odoo) у обычного человека вызовет взрыв мозга ? Так как он просто не будет понимать, зачем это все нужно.
kuznetsovin
Вы говорите про пользователей или про разработу модулей? А то все перемешалось...
Разработку модулей можно любом джуну поручить, а пользователи долны просто свои хотелки объяснить
И да, уточните пожалйста, какой у вас опыт работы именно с платформой Odoo чтобы я понимал откуда такие выводы у вас?
CrushBy
Причем здесь пользователи ? Я всегда говорил исключительно про разработчиков.
Поручить можно. Проблема экономической эффективности. Во-первых, Python Developer'ы котируются на международном рынке, а 1С-программисты - нет, то Python программисты значительно дороже. Во-вторых, уровень абстрагирования у 1С - выше, а платформа 1С - более узкоспециализирована. Поэтому на 1С делается быстрее и дешевле (так универсальное всегда хуже, чем специализированное для конкретной задачи).
Разбирался в ней как пользователь, читал исходники, плюс мне знающий Odoo человек рассказывал как там все устроено. Модули сам не писал, но читал.
В целом, ничего плохого про Odoo сказать не могу. Использовать Odoo лучше, чем писать с нуля на python. Но, к сожалению, не увидел что там такого революционного. Классический ORM с небольшой надстройкой + Template engine для формирования форм + по мелочи.
timoor
В Украине, зато, довольно обширное. Там успешно замещают 1С (хотя выбора у них нет) на Odoo.
qqqoid
Когда вот-вот останешся без ноги, конечно станешь срочно искать варианты как заместить её побыстрее хотя бы на костыль, но назвать это успехом сложно.
Обширность оду комьюнити в Украине по сравнению с Россией примерно одинаково нулевого уровня. Но процесс идет и я им немножко завидую.
caballero
Нету там никакого "обширного" замещения. Нужны незилые танцы с бубном чтобы локализовать оду и привести к украинским стандартам учета. Тем более есть та же одноце которую переименовали и выдают за формально отечественную систему.
Какая то контора пытается че то городить на оду но кому оно надо если внедрение обрцдется намного дороже одноце.
kuznetsovin
Поищите в ТГ я знаю как минимум 2 русскоязычных сообщества
slivkarmy
На самом деле есть. https://t.me/odoo_talks
qqqoid
В реалиях РФ оду это исключительно платформа для создания собственного приложения Отличная, прекрасно развитая платформа, очень удачный (хоть уже и немножко подуставший) стек.
Но сделать из нее ERP и тащить потом на себе - форменное безумие, готового нет вообще ничего. Отличный инструмент для консолидации, управленческого учета и любой автоматизации вокруг, выполненной самостоятельно и/или набранной из огромного количества OCA модулей и прочих подарков: CRM, проекты, MRP в каком-то виде, кто-то сможет взять склад.
Это касается как CE так и EE версий, они одинаково неюзабельны по своему задуманному предназначению в реалиях РСБУ, что лично для меня не умаляет ее достоинств как платформы для юыстрой разработки.