В разряд свободного ПО переведена система планирования ресурсов предприятия, управление бизнес-процессами и организации взаимодействия с клиентами BGERP. Код написан на Java и распространяется под лицензией GPLv3. Открытие кода призвано упростить распространение решений, а также взаимодействие заказчиков с исполнителями работ. В ближайшем будущем основной разработчик проекта будет работать над ним на полный рабочий день...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51813
> git.pzdc.deДоменное имя на что-то явно намекает. Качество кода?
Намекает, что документация для проекта сгенерирована при помощи PzdcDoc.
>Код написан на JavaNot needed.
Тоже считаю, что промышленные системы должны писаться либо на Electron, либо на асме с синтаксисом Intel под 64-разрядные системы. Java здесь вообще не подходит, она не под промышленные системы заточена.
Node.js? Вы уверены в адекватности идеи?
Абсолютно.
Глупости. Все знают, что ERP должны писаться исключительно на COBOL. Все остальное - происки маркетолухов.
> Тоже считаю, что промышленные системы должны писаться либо на Electron, либо на асме с синтаксисом Intel под 64-разрядные системы. Java здесь вообще не подходит, она не под промышленные системы заточена.Очень тонкий троллинг. Хорош
Ну а вы всё испортили :)
вот-вот. ждём ООМов-зависонов )
А не то что это результат просто хренового кода? Я вот все думаю, а когда уже придет пионер и напишет парсер HTTP для Java или притащет его из какого-нибудь крутого проекта вроде nginx. И вот тогда как минимум уже решили проблему с HTTP сервером
>Стоимость услуг
>Предоставляются следующие виды >услуг: консультации, доработки, >просмотр и принятие сторонних >изменений в исходный код, >конфигурирование, разбор нештатных >ситуаций.Стоимость услуг
… принятие сторонних изменений в исходный код …
Открой для себя путь по которому код платиновых участников Linux Foundation попадает в ядро.
Интересная услуга. Бэкдор почнм будет, интересно
1c намного лучше по всем параметрам.
>1С
>лучшеDoes not compute!
Запомните эти имена: Шамиль Вахитов и Кирилл Сергеев.
Несколько десятков внедрений, а добавления фото до сих пор нет... Ух, говнокодеры!
Мы полностью развязали ваши руки. Можете сделать форк и переделать его даже в фотоальбом.
Насколько мне известно, первый уже давно не работает над системой и эмигрировал в Германию. О втором просто никогда не слышал.
Уж лучше битрикс24
Что угодно лучше чём битрикс.
а г`овоят что за битг`иксом будущее...
Это чистая правда. Я вам больше скажу - будущее далеко за Битриксом, и с каждым новым релизом расстояние увеличивается. Поскольку Битрикс принципиально движется в противоположную сторону.
"
На начало 2018 года сервисом пользовались около 3 миллионов клиентов[14].
22 марта 2019 года «Битрикс24» достиг 5 миллионов зарегистрированных компаний[24]
" (с) вики
плюс два миллиона за полтора года... рост на две трети...
> плюс два миллиона за полтора года...Ну, уж два-то миллиона мух точно не могут ошибаться.
Кажется, потому и открыли, что никому не нужно.P.S. А существующие клиенты как относятся к тому, что их деньгами оплаченная система стала открытой?
Радоваться надо, теперь бесплатно будут доработки прилетать.
это в спам-сетях доработки бесплатно прилетают... а в такого рода системах - любое изменение кода оборачивается нарушением работы. Такие системы дорабатываются только индивидуально.
Индивидуальные доработки никто и не будет пихать в апстрим. Под конкретного индивидуального клиента доработку сделали, у этого конкретного индивидуального клиента развернули - всё. Клиент оплатил - клиент получил.
Вы похоже совсем не знакомы с темой... Речь идет не о пихании индивидуальных доработок в апстрим...
речь идет о том, что индивидуальные доработки в таких системах в 101% случаев таковы, что даже незначительное изменение в апстрим коде - может привести к необходимости переписывать код индивидуальных доработок. И это- нафиг никому не сдалось (кроме конечно самих разработчиков которые за то денюжку получают :)
>индивидуальные доработки в таких системах в 101% случаев таковы, что даже незначительное изменение в апстрим коде - может привести к необходимости переписывать код индивидуальных доработокА зачем вам переносить изменения из апстрима в работающую систему? В энтерпрайзе так не делают. Либо если прямо очень хотят новых фишек - повторно оплачивают перенос доработок.
Индивидуальные доработки выходят слишком дорогими. Особенно когда индивидуалка уходит.
Существующие не против. Спрашивали.
ШГp.s. зачем старались замазывать "Уфанет", если один раз не замазали?
Можно ли сделать из этого выводы, что ERP заточена под деятельность провайдера?
И как оно против сахара/тигра?
Очень давно, когда искали систему для интеграции с биллингом - изучали в т.ч. и эти варианты.
Что не понравилось в Sugar:
- язык разработки, нам было удобнее писать на Java, не потому что он суперхороший, просто раз уж начали на нём;
- насколько я помню, там структура БД изменяется при настройке кастомных объектов, это путь не особо удобный, тоже пробовали - но выбрали нормализацию в итоге.
Интересно. Пощупаем. Спасибо.
Советую людям кто обожает хардкор. Погрузитесь в пучину безумия и отчаянья. Окутайте себя тайнами работы системы, фейлами и могущественными багами.
Ну, это вообще о любой сложной системе
>Blow-график=З
> СУБД MySQLРеляционка для BPM-решений - не лучший выбор (Mongo лучше гораздо). Нормальная ERP вообще подразумевает комплекс из реляционки + NoSQL.
Одна реляционка в списке говорит о том, что она прибита там гвоздями...
Ну а по скринам красивенько так.
Да, и про хранилище файлов ничего непонятно. Если файлы также хранятся в MySQL, - это печально.
Файлы хранятся на диске, в базе метаданные. Как обычно.
DMS (систему управления документами) при обращении с контрагентами и внутренний документооборот реализованы в BGERP? Или BGERP по сути является CRM с задатками ERP?
В данный момент готового проверенного решения нет.Документооборот планировалось делать на базе процессов. То есть привязывать документ к процессу, далее обычная схема с изменением статусов. Была давно одна попытка реализации, не доделали до конца.
Обычно (я видил массу таких решений) пихают файлы прямо в реляционку (в блобы).
Прибита, так точно. Не получается полноценно СУБД использовать без прибивания. Различные оптимизации вроде LIMIT, полнотекстового поиска - вне стандартов. Даже особенности репликации приходится учитывать.
Плюсану, ибо считаю, что возможность использовать полностью все фичи одной выбранной СУБД важнее, чем возможность пользоваться любой СУБД за счёт ограничения используемых фич неким общим подмножеством.
В 1С же вроде неплохо реализовали работу с mssql,db2, oracle и postgres. Хотя конечно основные там mssql и postgres.
И почему mysql а не postgres?
1) Исторически начали работать с MySQL, ещё очень давно. Так как находили там решения для всех задач - то так и оставались на ней.
2) Мы не используем хранимых процедур и обращаемся с БД как с тупым быстрым хранилищем. Вся логика в Java.
3) Репликация в Постгре появилась встроенная значительно позже и она там специфичная, на основании сравнения бинарного файлов была. Не знаю, как сейчас. На эту тему хороший пост был от Mail.ru или типа того, как они переходили на Постгре. Репликация нам нужна, поскольку на слейв базы перекидывали тяжёлые запросы, не требующие суперактуальных данных.
4) Хранение таблиц в отдельных файлах. Сейчас это стандартная настройка, но мы когда-то пришли к этому сами. При такой схеме гораздо удобнее холодный бакап с использованием снапшотов ФС. Не знаю, есть ли это в Постгре.
5) Когда-то мы смотрели Оракл, но тогда не нашли специфичных плюшек вроде LIMIT. Там совсем другой подход, с курсорами.
6) А недавно уже в Германии я делал поддержку в Постгрес для изначально Оракл программы. Не знаю, насколько там красивый код, но вот поведение в некоторых местах было совсем непредсказуемое. Вроде как ставишь приведение типа в запросе и начинает работать индекс. Причём купленная поддержка удивляется вместе с тобой вместе, как это так получается.В общем, БД - это почти как жена, выбираешь надолго и изучаешь основательно. Ну или у меня такой подход однолюба :)
>гораздо удобнее холодный бакапдля этого надо выключать базу и как следствие - остановка системы?
>специфичных плюшек вроде LIMIT
>А недавно уже в Германии я делал поддержку в Постгрес для изначально Оракл программы. Не знаю, насколько там красивый код, но вот поведение в некоторых местах было совсем непредсказуемое. Вроде как ставишь приведение типа в запросе и начинает работать индекс. Причём купленная поддержка удивляется вместе с тобой вместе, как это так получается.И тут надо делать большие глаза и таинственно понижать голос.... План запроса оракл может показать прямо по пунктам, со всеми "приседаниями и ужимками" которые он при этом совершает. И то что вы пишите - обусловлено какой-то рациональной логикой. используется в запросе индекс или нет- определяется стоимостью этой операции относительно прямого чтения последовательно и часто бывают такие случаи когда просто линейно прочитать файл дешевле того же самого через индекс... причем план запроса может поменяться в зависимости от объема данных в таблице... Ну вы же написали я так понимаю целую ERP.. должны сами это знать и понимать...
>Исторически начали работать с MySQL,
То есть выбор обусловлен критериями 20-летнего давности...
> для этого надо выключать базу и как следствие - остановка системы?Надо её перезапускать, чтобы сбросились файловые кэши. Но задержка минимальна и практически незаметна. Ещё со времён биллинга нашли решение.
>Надо её перезапускать, чтобы сбросились файловые кэши.перезапустить базу чтобы сбросить файловые кэши... надо этот прикол рассказать народу :)
https://stackoverflow.com/questions/5231678/clear-mysql-quer...
там и про сброс кэша запросов базы и про сброс файловых кэшей...
>Ещё со времён биллинга нашли решение.Извиняюсь, но вы просто остались на том самом 20-летнем технологическом стэке..во всех смыслах...
Я так понимаю это в первую очередь именно CRM/BPM а потом уже ERP. Просто из описания получается что это навороченный календарь планировщик. В ней вообще предусмотрен функционал учета по основной деятельности фирмы? Например торговля, оказание услуг, собственное производства, учет и анализ взаиморасчетов ну и т.д.
> Не получается полноценно СУБД использовать без прибивания.Получается, посмотрите Nuxeo.
>> Не получается полноценно СУБД использовать без прибивания.
> Получается, посмотрите Nuxeo.Таки глянул. Там используется свой язык NXQL, который транслируется в конкретные диалекты. Ну это не то. Так можно сказать, что PHP не прибито гвоздями потому что есть doctrine или как там его.
>Одна реляционка в списке говорит о том, что она прибита там гвоздями...Неприбитые к СУБД решения могут быть только очень простые.
Неправильно. Посмотрите Nuxeo.
Прибитость от привычки работы в одной СУБД и недостатка опыта работы в других. Серьёзные решения пишутся в комбинации noSQL, RDB (включая DWH), Redis, Elastic...
Серьезные решения - это мозаика из разных продуктов, которые компанией были куплены у разных фирм и стартапов и теперь продаются под одной вывеской... И там действительно на каждом кусочке мозаики- могут быть разные СУБД и языки, и технологии...
Но на каждом из этих кусочков- выбранная СУБД "прибита гвоздями"... По многим причинам.
> Серьезные решения - это мозаика из разных продуктов, которые компанией были куплены
> у разных фирм и стартапов и теперь продаются под одной вывеской...
> И там действительно на каждом кусочке мозаики- могут быть разные СУБД
> и языки, и технологии...
> Но на каждом из этих кусочков- выбранная СУБД "прибита гвоздями"... По многим
> причинам.Вот именно. Особенно весело, когда в одном из сторонних решений по неведомым причинам в качестве места хранения используется ЛДАП.
> Неправильно. Посмотрите Nuxeo.
> Прибитость от привычки работы в одной СУБД и недостатка опыта работы в
> других. Серьёзные решения пишутся в комбинации noSQL, RDB (включая DWH), Redis,
> Elastic...Что мне смотреть. Приходится и в Oracle и в MySQL жить. Разница в синтаксисе вполне конкретная даже в мелочах. А это означает, что написаное под одну СУБД может незаработать в другой, хотя внешне это может оказаться неочевидно.
> Неправильно. Посмотрите Nuxeo.Простой пример непереносимости. В Oracle пустая строка трактуется как NULL, а в Mysql пустая строка и NULL разные штуки.
>>Одна реляционка в списке говорит о том, что она прибита там гвоздями...
> Неприбитые к СУБД решения могут быть только очень простые.1C вполне себе серьезное решение и может работать с 4 СУБД
Ну, если вы в теме - то знаете наверное что работает оно с ними очень по разному...
Для этого у них есть специальный сервер, который транслирует исходные запросы в запросы для каждой СУБД. Более того сейчас даже в режиме файловой базы у них эмулируется полная трехзвенка, поэтому сейчас 1С в файловом режиме жутко тупит особенно на офисных компах без ссд, а если ещё и по сети несколько пользователей то вообще амбец.
В демку не пускает онлайн. У всех так?
Чёрт, шутники зашли и юзера удалили. Надо будет что-то придумать против этого. В 0 часов сбросится база.
ох тут и специалисты пишут комменты. огонь! прекратите вот это вот, езжайте в деревню, занимайтесь тем для чего вас природа породила. растите поросенка, картоху или еще чего там ростят.
Глянул демку, а ведь неплохо задумано! Сам концепт приложения после 1C:УПП/ERP2 кажется удобным и понятным.Демка сама ужасна, отчетов 0 (первое что смотрят), контент демки не раскрывает не то что ERP/MRP, даже CRM-фнукционала. Антидемо, в общем.
Если сравнивать со свободными (Odoo, vTiger, SugarCRM) и брошенными free-аналогами (Naudoc) то пока 2,5/5. В общем рано. Но будем следить за проектом.
Это не задумка, а примерно десятая передумка. Значительная часть функционала осталась в кастомизациях клиентов, гвоздями прибито к конкретной организации. Так когда-то Nau делал, под каждого - свой продукт. Постепенно будем выносить в апстрим.
Технологии 20 летней давности: Struts, JSP, JQuery.Неприятно выглядят SQL запросы в коде (отсюда и крепкая привязка к базе), собираемые конкатенацией.
Из хорошего - код лаконичный и его не много.
Ещё Java, MySQL, 386 архитектура с монолитным Linux на нём. HTML так вообще незнамо откуда привет в светлое будущее ;)Пробуем периодически новые. Был кусок на Angular, например. Потом я с ним работал на другом проекте. Убрали, не понравилось. Мы остались на server side rendering, к которому сейчас приходят обратно с фронтенда. Гораздо удобнее доставать данные из памяти, чем каждый чих запрашивать. Не оправдала себя идея, что "рендерить на клиенте эффективнее". Накладные расходы на пересылку данных по сети убивают преимущество от распределения.
От Struts там вообще распределение по классам и методам осталось только. Вообще по моим наблюдениям любой крупный проект неминуемо начинает что-то от себя добавлять.
>Ещё Java, MySQL, 386 архитектура с монолитным Linux на нём. HTML так вообще незнамо откуда привет в светлое будущее ;)- юмор это хорошо, но в данном случае он не к месту. На Java можно писать по разному. У Вас написано на технологическом стеке 20 летней давности. Это всего лишь констатация факта. И HTML за 20 лет поменялся, и работа с БД, и web-фреймворки существенно изменились.
Важно то, насколько хорошо обеспечивает задуманное.В Боинге тоже на Фортране пишут. Не самый модный язык. Но толковые самолёты.
>Накладные расходы на пересылку данных по сети убивают преимущество от распределенияа можно про вот это поподробнее?
Вы же пересылаете только необходимые данные? не базу же целиком и не таблицу целиком...
То есть объем данных передаваемых по сети в случае рендеринга на клиенте должен быть даже меньше чем при рендеринге на сервере... А у вас наоборот получается. как так?
Или вы какие-то другие накладные расходы имеете в виду?или... у вас рендеринг неотемлим от выборки данных? sql код прямо в html-темплейтах ?
> Вы же пересылаете только необходимые данные? не базу же целиком и не таблицу целиком...Например, быстрое обращение к справочнику пользователей. Для этого удобно в хипе держать кэш. То же с группами, правами. То есть можно и джойны всегда делать, но иногда это неудобно, так как приходится и классы-бины менять, в которых данные пересылаются.
Вы когда нибудь слышали про AJAX?
> Вы когда нибудь слышали про AJAX?Нет, а что это? ))
Обращение по сети за этими данными будет в 1000 и более раз медленнее, чем внутри памяти одного приложения.
Вообще интересную вы тему подняли. Я лично пришёл к тому, что новые технологии лучше всего пробовать в отдельных проектах. Где хозяин-барин платит за распитие самого свежего смузи. Можно бесплатно потренироваться, так ещё и заплатят за время учёбы. Посмотреть - иногда что-то и перенять. Большая часть нового - шлак или перепродажа старого. Пошумят и умирают, потому что неудобно оказалось. Web сервисы, Ангуляр, много их было уже. Невозможно физически делать большой проект на самых новых технологиях, мода слишком переменчива. Ещё есть эффект изолированного развития стеков по сути одного продукта. Например на фронте до сих пор логируют с помощью console.log() и вообще не понимают, когда пытаешься им объяснить про что-то подобное log4j.
>пришёл к тому, что новые технологии лучше всего пробовать в отдельных проектах- может и так, но проект, о котором идет речь, выглядит откровенно запылившимся и перевод его в opensource скорее всего мало что даст, так как сейчас так уже не пишут. Черезчур олдскульно.
>что-то подобное log4j- даже тут не айс. Энтерпрайз давно слез с Log4J и переполз на SLF4J, что дает продукту большую гибкость в использовании логера и в использовании сторонних библиотек.
>Невозможно физически делать большой проект на самых новых технологиях, мода слишком переменчива
- как правило новые фреймворки и технологии призваны упростить и ускорить разработку
Пытались использовать эту систему когда она еще была платной. Ад. Боль и слёзы. Видимо, после BGBilling разработчиков окончательно покинул разум.
Вы нам тоже не понравились. Чуть что - кричать и в слёзы.
Чтобы разум покинул, он должен сначала быть :)Вы бы кратко отписали, что было не так. Мы бы учли на будущее.
А мы из opensource успешно внедрили и используем https://erpnext.com/
Выглядит современно, есть мобильный клиент, написана на питоне, часто обновляется. Потихоньку вытесняет 1с и jira.
2064 Issues из них часть помечена как баг. Для провайдинга может и сойдет, но для для другой деятельности переделывать всяческие Bank Invoice - вторая разработка.
Хотел поблагодарить команду OpenNet, пока не промоталось.
1)Новость хорошо оформили, лучше, чем я сам прислал. С картинками ещё.
2)Пример перехода этого сайта на коллективное финансиорование заставил меня поверить, что опенсурс в России возможен.
3)Аудитория молчунов здесь отличная. Которые молча читают, а потом выходят на связь с интересными предложениями.
А в чем "промышленность" данного продукта? Или так, для сурьезности и важности прикрутили словцо? Промышленная принадлежность как бы подразумевает использование принятых в отрасли стандартов,возможности масштабирования, показатели надежности. И? "Мы программируем на Java, потому что мы выучили Java". "Мы используем MySQL, потому что мы привыкли к MySQL". Так и напрашивается - "Я тебя слепила, из того что было..." Не, я не против,только за, но при чем здесь "промышленная".
Вот такая у них "промышленность" - СУБД бэкапится по холодному, через шотдаун, и это считается "найденным еще со времен..." (с) типа хорошим решением...
бекапится уже давно xtrabackup'ом. шамиль писал про древние времена, когда для консистентности снапшотов (с которых уже и снимался бакап) необходимо было выполнятьFLUSH TABLES WITH READ LOCK;
system /bin/sh $snapscript
UNLOCK TABLES;это довольно быстро. и ничего там не шатдаунилось, конечно. хотя не вижу проблем зашатдаунить реплику на время снятия снапшота или даже тупо бекапа, если реплика только для этого и предназначена =)
что касается bgerp/bgcrm то боль наступает из-за:
1) хранения файлов в одном плоском каталоге фс, без хеширования по какому-либо признаку. за несколько лет использования накопилось 5+ млн файлов в каталоге (по 130 тыщ в месяц). после этого оно встало колом.
2) все процессы в одной таблице, без партиций. десятки миллионов строк. как только таблица перестала влезать в память - все встало колом.со структурой бд надо что-то делать. вечно наращивать память невозможно. с файлами мы уже порешали, правда кривовато (я бы предпочел структуру типа кеша сквида). не знаю, есть ли этот костыль в опенсорсе =)
Дальнейшие планы:Выставление счетов;
Это точно crm? А упд завезут ?
Бухам можно уже вешаться ?
примеры гибкой настраиваемой системы с скриптами и свистоплясками где??? в целом норм проект по сравнению с платным шлаком норм решение