Comments 57
В целом Odoo это на мой взгляд очень хорошая платформа для написания почти любого бизнес приложения любой сложности
А в Odoo уже есть готовые модули для формирования УПД, интеграции с российскими EDI-провайдерами, для взаимодействия с ЧЗ/ЕГАИС/ВетИС ? Или это все нужно писать самому с нуля ?
про EDI есть
А про ЕГАИС и ЧЗ нет, там есть модуль серийных номеров, думаю там потребовались бы микродоработки для работы с ЧЗ
А можно, пожалуйста, ссылку на уже готовый модуль работы EDI (желательно бесплатный) ?
И УПД все-таки есть какой-то модуль ? А то без УПД (или ТОРГ-а) какого-нибудь вообще как-то не получится начать работать.
А про ЕГАИС и ЧЗ нет, там есть модуль серийных номеров, думаю там потребовались бы микродоработки для работы с ЧЗ
Как человек, который реализовывал интеграцию с ЕГАИС и ЧЗ, и знает как там все устроено, "микродоработки" - это явно неправильное слово. Учет по серийным номерам - это маленькая часть (и то, насколько я помню, в Odoo там много чего нет - например, там есть агрегация серийных номеров ?)
Если ты говоришь про УПД и ТОРГ- как печатные формы то на Odoo с модулем можно начать, но я бы делал свою генерацию, тк покурив все внутренности и возможность open_source python все становится проще
По поводу EDI в Odoo есть из коробки модуль по работе с EDI он называется account_edi* их там несколько, что бы заработало для РФ потребует минимум манипуляций разработчика
Можно спросить про производство? В erp предполагаются ещё модуль производства продукции, планирование, бюджет, CRM ну и ещё пачка всего
Модуль производства в odoo есть из коробки, можно на него тут посмотреть
Вы правда полагаете, что серийные номера и микродоработки решают проблему егаис и чз маркировки?
Все это разумеется придется писать самому с нуля.
Это пожалуй единственная причина незыблемости решений 1С на рынке автоматизации учета.
При всей моей личной нелюбви к этой компании, они единственные кто подерживает в актуальном состоянии, как взаимодействие и госудаственными информационными системами, так и обновляет печатные формы, документы, отчетность в соответствии с требованиями законодательства.
А вообще сам в последние пару лет активно слежу за Odoo, нравится мне стек, но начать на нем какой нибудь проект автоматизации "рука не поднимается".
Плюсану про учет и 1с, все так, но мир не ограничивайтся учетом, есть множества других потребностей бизнеса )
Это пожалуй единственная причина незыблемости решений 1С на рынке автоматизации учета.
К сожалению, не единственная причина и не главная. Незыблемость обусловлена в первую очередь консерватизмом бизнеса (как и на любом другом рынке).
Поддержка ГИС и печатных форм в задачах кроме бухгалтерии и ЗУП не столь трудоемкая, и там нет таких жестких требований в законодательстве. Хотя конечно в Бух и ЗУП действительно 1С практически монополист именно из-за законодательства.
почему не поднимается-то? сделать из odoo ERP фантазмагоричная идея, но это ОЧЕНЬ хороший инструмент, да и конкурентов как бы и нет вообще. Получаю удовольствие.
Учет ессно живёт отдельно. Но в наших реалиях он вообще почти всегда "отдельно" живёт, да и вообще не каждой сове надо быть натянутой на глобус ERP.
Проблема Odoo в том, что по нему нет русскоязычного community (я по крайней мере не нашел). Если какие-то проблемы возникают, то придется барахтаться самому. Да и на odoo.com форум, скажем прямо, не очень популярный.
Это да, в России не особо популярная платформа и на русском действительно нет ничего.
Но это open source и python, внутри всё прекрасно документировано и всегда доступно. Особенных проблем в освоении не возникло, фронт конечно специфичный, немного доставлял по-началу.
Кстати есть пара родных отличных книжек, выпущенных пактом (Odoo Development Cookbook и Odoo Development Essentials), в принципе любой из них достаточно для быстрого старта.
Просто не очень понятно, на кого это рассчитано.
Если я - продвинутый пользователь (или средненький/слабенький 1С-разработчик), то я явно не смогу это поддерживать и дорабатывать (там все-таки достаточно высокий порог вхождения).
Если я - сильный python developer, то на Odoo в РФ много не заработаешь (так как придется конкурировать с 1С, который продает все очень дешево). А как сильный python developer можно без проблем найти достаточно жирную вакансию просто в аутсорсе с нормальными условиями работы, а не выносить мозг работая напрямую с бухгалтерами.
Поэтому и не удивительно, что нет комьюнити.
Есть доля истины в ваших словах!
Но я бы не сказал, что уровень вхождения очень высок. Крыжить формы в xml-е много пядей не надо во лбу. С копипастой моделей тоже справится любой. Да вправо-влево нужен и пайтон и js, причем немного специфичный в первом случае и довольно много во втором, но это уже следующий этап. По моему опыту очень многим достаточно и первого. Есть средства быстрой разработки позволяющие крыжить формы и модели из веб интерфейса (никогда не пользовался, но люди пользуются и успешно).
Занимаюсь odoo уже третий проект, повидал и за собой и за многими (и частниками и конторами, в России есть парочка) всякого. Но наклепать на оду какое-то небольшое приложение с формами, правами и коммуникативными возможностями способен любой продвинутый новичок, готового действительно громадное количество.
Но всё надо пилить, просто взять и поставить - мало что получится. Но есть исключения, я писал: есть отличная crm, проекты и многое другое.
Для тех кто на следующем уровне есть OCA - оттуда можно взять просто огромную массу всего, от posgis и рабочих процессов до всевозможных вьюх. Но там конечно всё полуготовое, для более-менее профи.
По моему опыту очень многим достаточно и первого.
Первое - это самый простой CRUD ? Очень узкая область.
Да вправо-влево нужен и пайтон и js
Опять же встает вопрос позиционирования. Человек, который сможет въехать во все это (xml/html, python и js), разобраться в не такой простой архитектуре и функционале Odoo - это уже человек, который может без проблем стать, как минимум, middle developer'ом, и непонятно зачем ему заниматься этим бедным рынком (малый бизнес в РФ).
мое мнение, что человек который в этом разобрался досконально не "может без проблем стать" - он уже как минимум стал, там местами не для слабых духом.
по остальным вопросам я особо и не спорил, проблем навалом. отечественная мелочь не столько бедна (хотя в среднем по больнице это так), сколько не приучена платить за ит вообще, с ними сложно, но есть исключения.
По моему опыту человек без навыков программирования начинает делать модули на оду через неделю...
Архитектура там вполне себе нормальная и позволяет отделить работу верстальщика, от работы фронта и работы бэкендера.
Да специфика, есть но не такая глобальная как кажется, особенно с выходом 14 версии и реактивным фронтом
По моему опыту человек без навыков программирования начинает делать модули на оду через неделю...
Речь идет не про CRUD. Для чего-то немного сложнее потребуется уже и Python, и HTML с CSS и JS. А во многих случаях и SQL (не будете же вы считать отчет с выручкой и доходом за месяц через ORM). И вот все это человек без навыков программирования сможет делать через неделю ? Что-то я не верю.
Нам довелось пытаться обучить нашей платформе lsFusion несколько десятков (если не сотен) человек (не программистов). А она гораздо проще для человека с нуля. Даже статью про это писали.
Так вот 90% человек не могут просто создание доменной логики освоить (то есть тупо выделение сущностей для CRUD). Такой бред местами делали в примитивнейшей логике, и не понимали что не так. А Вы говорите про писать модули на Odoo...
Вы понимаете, что сама концепция MVC (используемая в Odoo) у обычного человека вызовет взрыв мозга ? Так как он просто не будет понимать, зачем это все нужно.
Вы говорите про пользователей или про разработу модулей? А то все перемешалось...
Разработку модулей можно любом джуну поручить, а пользователи долны просто свои хотелки объяснить
И да, уточните пожалйста, какой у вас опыт работы именно с платформой Odoo чтобы я понимал откуда такие выводы у вас?
Вы говорите про пользователей или про разработу модулей? А то все перемешалось...
Причем здесь пользователи ? Я всегда говорил исключительно про разработчиков.
Разработку модулей можно любом джуну поручить, а пользователи долны просто свои хотелки объяснить
Поручить можно. Проблема экономической эффективности. Во-первых, Python Developer'ы котируются на международном рынке, а 1С-программисты - нет, то Python программисты значительно дороже. Во-вторых, уровень абстрагирования у 1С - выше, а платформа 1С - более узкоспециализирована. Поэтому на 1С делается быстрее и дешевле (так универсальное всегда хуже, чем специализированное для конкретной задачи).
И да, уточните пожалйста, какой у вас опыт работы именно с платформой Odoo чтобы я понимал откуда такие выводы у вас?
Разбирался в ней как пользователь, читал исходники, плюс мне знающий Odoo человек рассказывал как там все устроено. Модули сам не писал, но читал.
В целом, ничего плохого про Odoo сказать не могу. Использовать Odoo лучше, чем писать с нуля на python. Но, к сожалению, не увидел что там такого революционного. Классический ORM с небольшой надстройкой + Template engine для формирования форм + по мелочи.
В Украине, зато, довольно обширное. Там успешно замещают 1С (хотя выбора у них нет) на Odoo.
Когда вот-вот останешся без ноги, конечно станешь срочно искать варианты как заместить её побыстрее хотя бы на костыль, но назвать это успехом сложно.
Обширность оду комьюнити в Украине по сравнению с Россией примерно одинаково нулевого уровня. Но процесс идет и я им немножко завидую.
Нету там никакого "обширного" замещения. Нужны незилые танцы с бубном чтобы локализовать оду и привести к украинским стандартам учета. Тем более есть та же одноце которую переименовали и выдают за формально отечественную систему.
Какая то контора пытается че то городить на оду но кому оно надо если внедрение обрцдется намного дороже одноце.
Поищите в ТГ я знаю как минимум 2 русскоязычных сообщества
по нему нет русскоязычного community (я по крайней мере не нашел).
На самом деле есть. https://t.me/odoo_talks
В реалиях РФ оду это исключительно платформа для создания собственного приложения Отличная, прекрасно развитая платформа, очень удачный (хоть уже и немножко подуставший) стек.
Но сделать из нее ERP и тащить потом на себе - форменное безумие, готового нет вообще ничего. Отличный инструмент для консолидации, управленческого учета и любой автоматизации вокруг, выполненной самостоятельно и/или набранной из огромного количества OCA модулей и прочих подарков: CRM, проекты, MRP в каком-то виде, кто-то сможет взять склад.
Это касается как CE так и EE версий, они одинаково неюзабельны по своему задуманному предназначению в реалиях РСБУ, что лично для меня не умаляет ее достоинств как платформы для юыстрой разработки.
Кому интересно узнать больше про ODOO - https://www.antonpiskun.pro/category/odoo/
Шикарный блог, но очень мало технической информации. То есть почитав его - систему под себя не подстроишь, увы.
Я к сожалению (или к счастью) не технарь) и пишу для обычных пользователей. С ODOO работаю больше 5 лет и пока лучше платформы для решения бизнес-задач не нашел. Это по сути конструктор с помощью которого можно достаточно быстро сделать любое решение. Как пример - базовое решение по регламентированному учету для Украины было сделано за 4 месяца с помощью одного аналитика (меня) и двух разработчиков. С описанием решения можно ознакомиться в моем блоге.
И на самом деле в ODOO много готовых решений, правда не адаптированных под потребности наших компаний. И тут вопрос: а кто их должен создавать? индусские разработчики? европейские разработчики? Ну так они под западный рынок это делают
Антон, простите, не признал сразу =) Спасибо за кучу полезной информации, которую я почерпнул в Вашем блоге.
Полностью разделяю Ваше мнение про пригодность платформы для решения бизнес-задач самого широкого спектра, но, увы, платформа таки заточена под "западный" рынок. И, как мне показалось, реализовать штатными средствами (мы используем payroll от Odoo mates, пробовали до него модуль от Cybrosys) расчет тех же отпускных и больничных - не представляется возможным.
Соглашусь, что заниматься локализацией системы под локальное законодательство - должны сами "утопающие", ну или те же, условные, индусы, но под чутким руководством локальных аналитиков.
Вопрос - я правильно понимаю, что на Вашем рынке уже есть типовая конфигурация по бухгалтерскому учету? Доступна ли она для свободного скачивания? Почему-то есть ощущение, что законодательство в этих сферах у нас схожее (я из Азербайджана).
И второй вопрос - могли бы Вы порекомендовать ребят из Украины, которые по нашему ТЗ смогут кастомизировать модуль бухгалтерского учета и payroll?
По первому вопросу: к свободному скачиванию еще не доступна. Могу вам показать, что и как реализовано (но перед эти почитайте здесь -https://www.antonpiskun.pro/odoo-reglamentirovannyj-buhgalterskij-uchet-dlya-ukrainy-versiya-14-01/)
По второму вопросу: Да могу) Я как раз в такой компании работаю и у нас есть специалист, который занимается зарплатой - есть большой опыт в этом направлении. Пишите мне на почту antonpiskun@gmail.com или в телеграм Pantevg
одно время наблюдал за проектом, удачи ребятам. но ява! инструмент ни к месту и не ко времени (при всём Уважении), отправил как-то к ним своего неудавшегося клиента, не знаю дошел или нет.
Java там используется только при разработке самой платформы. Непосредственно бизнес-логика пишется на собственном высокоуровневом языке.
Не могу сказать, что Java - очень хороший язык программирования, но сложные системные архитектуры все-таки лучше писать на сильнотипизированном языке. Так что выбор был не очень велик при таких вводных.
Высокоуровневые конечные бизнес-приложения же да, на Java писать - не самый лучший выбор, на мой взгляд. Там лучше динамические языки, вроде Python, Ruby, JS и т.д.
. И тут вопрос: а кто их должен создавать? индусские разработчики? европейские разработчики? Ну так они под западный рынок это делают
А зачем это делать в РОССИЙСКИХ реалиях? Есть 1С, где все это реализовано. И если в случае с odoo вопрос ставится "что нужно запилить, чтобы просто заработало", то в случае с 1С вопрос ставится "все работает, теперь хочется бизнес-фич". Что как бы делает очевидным перекос в сторону 1С.
Ну на моем опыте ( может мне попадались такие компании ), но в первые годы бизнеза действительно 1с незаменимая вещь, но потом, когда компания сильно растет(ну если растет) платформа не может уже дать того, что нужно, примеров очень много и каких только костылей я не видел в 1с, что бы научить ее работать с такими привычными уже вещами как S3, или интеграцией с BI, бедные аналитики в поисках как перевести данные бд в приличный вид. а когда говорят слова типа, ну можно же из 1с выгружать данные как нужно BI в файлики или еще куда, отвечу-нет, это уже костыль
Ну на моем опыте ( может мне попадались такие компании ), но в первые годы бизнеза действительно 1с незаменимая вещь, но потом, когда компания сильно растет(ну если растет) платформа не может уже дать того, что нужно
Немного уточню. В первые годы бизнеса, 1С очень дешевая (как с точки зрения лицензий, так и с точки зрения зарплат 1С-ников) и доступная (в плане поиска внедренцев на типовые решения) вещь. Но как только компания сильно растет, доработка/настройка/обслуживание 1С резко вырастает в цене (ох, какая неожиданность - сложные кастомные решения на большое число пользователей - это дорого), а специалистов которые могут (и главное - хотят) решать эти вопросы не всегда удается найти. Т.е. прямо противоположная ситуация с условными ODOO - разработчик, который будет щелкать интеграции с BI, может как от огня сбежать от необходимости поддерживать в актуальном состоянии печатные формы, да и денег попросит, скорее всего, побольше.
сбежать от необходимости поддерживать в актуальном состоянии печатные формы
Не вижу проблем с такими задачами))), есть задача - делай, печатная форма это или BI это не важно, это просто задача
Не вижу проблем с такими задачами))), есть задача - делай, печатная форма это или BI это не важно, это просто задача
Проблема-то есть. Только, скорее всего, не у специалиста, а у его руководителя. Нагружать сеньора джуновскими задачами - слишком дорого. Но тут именно руководитель должен разрулить, по опыту сотрудников, кому какая задача достанется.
Да и для самого сеньора обилие правок в печатных формах вредно - он в этот момент не развивается.
но потом, когда компания сильно растет(ну если растет)
Ну, за компании, которые сильно растут, можно только порадоваться. Но сильно растут далеко не все. Куча компаний упирается в некоторый потолок, где и болтаются десятилетиями. И для них 1С - то, что доктор прописал.
Ну а в Вашем кейсе, где в платформе 1С тесно, odoo, SAP и что там бывает еще - вполне себе вариант. Для каждой задачи - свой инструмент. Впрочем, для крупных компаний бесплатность инструмента не является ключевым фактором. Так что и здесь у odoo могут быть проблемы.
, что бы научить ее работать с такими привычными уже вещами как S3, или интеграцией с BI,
https://infostart.ru/1c/articles/914689/ - здесь описан вариант интеграции чуть ли не из коробки. S3 - предоставляет API, так что на счет костылей можно спорить.
Разные варианты бывают. Odoo, как и другие решения, имеет право на жизнь. Но малому бизнесу недостаточно бесплатности odoo, еще нужна нормальная поддержка российского, быстро меняющегося, законодательства (это важно и для управленческого учета). И здесь 1с вне конкуренции.
Это вы сами про костыль придумали? Есть механизм регистрации изменений + регламентное задание, которое выгружает данные хоть во внешнюю БД, хоть в шину хоть в веб-сервис. Или по-вашему правильно это дать внешней системе доступ к таблицам?
Посмотрите на swe-notes.ru там есть норм контент по odoo
Как же удачно я отвлекся от написания формул зарплаты в Оду и наткнулся на этот пост.
Очень, очень много боли, как только руки до ходят до финансов и пейрола. Когда только установили и стали настраивать моудль кадрового учета - душа пела и радовалась, ровно до того момента, как кадровики прислали нам формулы расчета отпускных и больничных.
Перепробовали несколько модулей (бесплатных), но так и не нашли того, что нам нужно.
Система шикарная, стек - то, что надо. Но без пайтон-разработчика в нее лучше не суваться, во всяком случае в реалиях экс-СССР.
Для себя мы приняли решение и дальше грызть кактус, поэтому ищу сейчас того, кто поможет допилить нужный нам функционал, за адекватное вознаграждение.
В идеале - надо ОДИН раз сделать типовую конфигурацию для нужной страны (по тем модулям, которые этого требуют, тот же пэйрол и бухгалтерия), подогнанную под локальное законодательство, дальше будет существенно легче.
Вы упустили один важный аспект - само предприятие зачастую не в состоянии построить ERP систему. И дело не в технических аспектах, а в смене парадигмы самого бизнеса. Именно это (взгляд со стороны) дают консалтинги. Business Transformation - это то что нужно, а сама система - лишь инструмент.
В статье я как раз и раскрываю мысль, что нужно найти кадры которые могут, поверьте они на рынке есть
В том и загвоздка. Спецов на рынке можно найти, но когда их нанимают, то начальство/владелец требует подчинения своиму пониманию процесса. В то время как крупный бренд со стороны всегда воспренимается не только как исполнитель, но и сертификатор.
Чтобы было более понятно дам пример из личного опыта. Меня вот так наняла компания, как специалиста, чтоб возлавить технический процесс создания системы. В первый рабочий день мне озвучили сроки - всё должно быть готово, через 3 месяца. Вот 2 программиста, вот менеджеры и тестировщики, а вот и тз на 150 страниц, которые мы писали год, но там не хватает деталей. Я изучал требования пару дней и сказал, что нужно человек 10 разработчиков и 2 года. Скандалы, вызовы на ковёр всех VP, торг и все остальные стадии принятия. Так 2 месяца и проходят. Потом из материнской компании нанимают консалтинг. Те говорят тоже что и я, вот только результатом их слов стали не скандалы, а найм команды и увольнения пары VP отвечавших за выбор платформы и задание. Но генеральный то остался. И каждый модуль, каждый раз, проходил через скандалы, попытку начальства продавить свою линию, провал по срокам и качеству, вызову консалтеров и принятию моего мнения через их одобрение.
В общем к своим экспретам в больших компаниях относятся как и ко всем остальным ресурсам - делай как тебе скажут. Это я видел и вижу в разных проектах, не только ERP. Просто сейчас это я прихожу в другие компании как консультант.
Ну я кажется это как раз не упустил, а подчеркнул, в моей статье описано, что для того что бы построить ERP систему нужны знающие люди, а на технический аспект я не делал акцента.
А консалтинг это тоже люди)) и они могут работать у вас)
Ну так в чем дело? Набирайте смело команду из примерно 50 человек и в течении примерно 5 лет делайте новую, правильную и молодежную систему ЕРП на микросервисах. Делов то всего
так мы набрали, и сделали, и работает, 5 лет не понадобилось, получилось за 6 мес, команда 4 бека 0.5 фронта, продакт
функционал примерно похож на набор из нашей любимой 1с УТ + узкоспециализированные фичи уже относящиеся к внутренним продуктам компании
Закупки, склад, сбыт, логистика, первичка, транзакционность, удивительно, что вам бы понадобилось 5 лет и 50 разрабов :)
Как же к месту такие посты и обсуждения, спасибо. Мне, как и любому владельцу бизнеса, требуются кастомные решения, смотрел наш totum, odoo, руководитель crm и год сидели на Ragic!. Теперь буду попробовать lsFusion.
Сейчас с успехом применяем планфикс, 1с. Все эти и другие облачные решения хороши, но только до того момента пока вы не решаете использовать принцип одного источника данных. Данные из этих систем необходимо одновременно использовать и на сайте и в конфигураторе продукции и в CAD, и еще много где. И вот с этого момента начинаются костыли и рост затрат в геометрической прогрессии на разработчиков, без надежды на то, что это закочится и не начнется после очередного обновления платформы.
Я не програмист, но с логикой дружу, использовали в свое время, до закрытия проекта XtraBuild disigner, который прекрасно справлялся с задачами построения интерфейса, баз данных, календарей, графиков, канбан досок, гант-диаграм, любых отчетов на встроеном fastreport движке, сводных таблиц, фильтрацией сортировкой и манипуляцией данными, любому человеку знакомому с формулами excel, без единой строчки кода.
Я понимаю, идеального инструмента не существует, но близкие к нему возможно есть или были точно. Еще раз спасибо за обсуждение.
Обобщая выше сказанное от лица бизнеса:
Я хочу просто и понятно владеть, изменять и применять свои данные в единой БД. Ровно так же, как я привык это делать в excel, наполнять фильтровать, делать срезы, считать, сортировать и задавать условное форматирование.
Я не хочу каждый раз окостыливаться, терять время при смене разработчика для изучения нового языка програмирования если проект закрылся, или обновилась платформа, привет 1с, totum и т.д.
Благодаря статье понял что не буду останавливаться на odoo. Спасибо.
Странно оперировать термином ERP и рассматривать пример "купи-продай". Это как из пушки по воробьям.
Сама расшифровка термина ERP как бы намекает на сферу применения. И одна из главные её задач - на основе взаимоувязанных учетных данных о закупках, производстве, контрактах и т.д. планировать ресурсы предприятия (когда и что закупить, запустить в производство, в отгрузку, откуда деньги брать на всё это) и оперативный контроль над себестоимостью.
Как сделать ERP и причем здесь Odoo