The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Открыт код промышленной CRM/BPM/ERP системы BGERP

05.11.2019 00:50

В разряд свободного ПО переведена система планирования ресурсов предприятия, управление бизнес-процессами и организации взаимодействия с клиентами BGERP. Код написан на Java и распространяется под лицензией GPLv3. Открытие кода призвано упростить распространение решений, а также взаимодействие заказчиков с исполнителями работ. В ближайшем будущем основной разработчик проекта будет работать над ним на полный рабочий день.

Проект изначально разрабатывался для крупных предприятий, с фокусом на высокую производительность, гибкость и расширяемость. BGERP имеет несколько десятков внедрений, крупнейшие из которых обрабатывают базы в миллионы процессов и сотни тысяч контрагентов. Приложение построено по трёхзвенной схеме: Web интерфейс (HTML + CSS + JS), сервер (Java + JSP) и СУБД MySQL. Языки конфигураций: Java + JEXL.

Схема разработки основана на ветках GIT, переносимых по окончанию цикла реализации, документирования и тестирования в виде патчей в основную ветку. Релизы с основной ветки публикуются непрерывно по мере поступления патчей. Для обсуждений и вопросов открыта группа Telegram.

Текущая функциональность:

  • Разграничение прав доступа: группы, наборы, индивидуальные разрешения, опции в некоторых разрешениях;
  • Процессы с настраиваемыми статусами, матрицами переходов между ними, параметрами, зависимостями;
  • Механизм обмена различными типами сообщений: E-Mail, звонки, Slack, Telegram;
  • Учёт контрагентов;
  • График работ, табель учёта рабочего времени; - планирование проектов с использованием оригинальной методологии Blow;
  • Интеграция с биллинговой системой BGBilling;
  • Мобильный Android-клиент (бесплатный, но его код пока не открыт).

Дальнейшие планы:

  • Функциональность корпоративного сайта: база сотрудников, организационная структура;
  • Выставление счетов;
  • Личный кабинет контрагента;
  • Интеграция с GitLab;
  • Учёт ТМЦ;
  • Полный Blow-график разработки программы.


  1. Главная ссылка к новости (https://bgerp.ru...)
  2. OpenNews: Новая версия SalesPlatform Vtiger CRM 7.1 интегрирована с тринадцатью облачными АТС
  3. OpenNews: Выпуск CRM-системы SuiteCRM 7.10
  4. OpenNews: SugarCRM становится проприетарным продуктом
  5. OpenNews: Обновление системы автоматизации для малого бизнеса NORD POS 3.0.3CE
  6. OpenNews: Релиз открытой системы управления ресурсами предприятия OpenERP 6.1
Автор новости: Pingvin235
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51813-bgerp
Ключевые слова: bgerp, crm, erp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (91) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, KonstantinB (ok), 07:24, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    > git.pzdc.de

    Доменное имя на что-то явно намекает. Качество кода?

     
     
  • 2.4, Аноним (4), 07:44, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Намекает, что документация для проекта сгенерирована при помощи PzdcDoc.
     

  • 1.2, Аноним (2), 07:27, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    >Код написан на Java

    Not needed.

     
     
  • 2.5, Аноним (4), 07:46, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +54 +/
    Тоже считаю, что промышленные системы должны писаться либо на Electron, либо на асме с синтаксисом Intel под 64-разрядные системы. Java здесь вообще не подходит, она не под промышленные системы заточена.
     
     
  • 3.10, Anonymou (?), 08:17, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Node.js? Вы уверены в адекватности идеи?
     
     
  • 4.21, Аноним (2), 09:28, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Абсолютно.
     
  • 3.16, Онаним (?), 08:53, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Глупости. Все знают, что ERP должны писаться исключительно на COBOL. Все остальное - происки маркетолухов.
     
  • 3.27, Аноним (27), 10:20, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Тоже считаю, что промышленные системы должны писаться либо на Electron, либо на асме с синтаксисом Intel под 64-разрядные системы. Java здесь вообще не подходит, она не под промышленные системы заточена.

    Очень тонкий троллинг. Хорош

     
     
  • 4.35, Pingvin235 (?), 12:49, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а вы всё испортили :)
     
  • 2.30, InuYasha (?), 11:20, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот-вот. ждём ООМов-зависонов )
     
     
  • 3.74, Аноним (74), 18:18, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А не то что это результат просто хренового кода? Я вот все думаю, а когда уже придет пионер и напишет парсер HTTP для Java или притащет его из какого-нибудь крутого проекта вроде nginx. И вот тогда как минимум уже решили проблему с HTTP сервером
     

  • 1.3, Аноним (3), 07:36, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Стоимость услуг
    >Предоставляются следующие виды >услуг: консультации, доработки, >просмотр и принятие сторонних >изменений в исходный код, >конфигурирование, разбор нештатных >ситуаций.

    Стоимость услуг
    … принятие сторонних изменений в исходный код …

     
     
  • 2.7, Аноним (7), 08:01, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Открой для себя путь по которому код платиновых участников Linux Foundation попадает в ядро.
     
  • 2.42, Аноним (42), 18:10, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Интересная услуга. Бэкдор почнм будет, интересно
     

  • 1.6, Аноним (6), 07:59, 05/11/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

  • 1.9, Аноним (9), 08:07, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Запомните эти имена: Шамиль Вахитов и Кирилл Сергеев.
    Несколько десятков внедрений, а добавления фото до сих пор нет... Ух, говнокодеры!
     
     
  • 2.23, Pingvin235 (?), 09:38, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Мы полностью развязали ваши руки. Можете сделать форк и переделать его даже в фотоальбом.
     
  • 2.87, www2 (??), 17:43, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько мне известно, первый уже давно не работает над системой и эмигрировал в Германию. О втором просто никогда не слышал.
     

  • 1.11, Аноним (11), 08:21, 05/11/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –2 +/
     

     ....ответы скрыты (5)

  • 1.12, В (?), 08:37, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кажется, потому и открыли, что никому не нужно.

    P.S. А существующие клиенты как относятся к тому, что их деньгами оплаченная система стала открытой?

     
     
  • 2.15, Аноним (15), 08:52, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Радоваться надо, теперь бесплатно будут доработки прилетать.
     
     
  • 3.18, ыы (?), 08:57, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это в спам-сетях доработки бесплатно прилетают... а в такого рода системах - любое изменение кода оборачивается нарушением работы. Такие системы дорабатываются только индивидуально.
     
     
  • 4.24, Аноним (24), 09:38, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Индивидуальные доработки никто и не будет пихать в апстрим. Под конкретного индивидуального клиента доработку сделали, у этого конкретного индивидуального клиента развернули - всё. Клиент оплатил - клиент получил.
     
     
  • 5.28, ыы (?), 10:54, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы похоже совсем не знакомы с темой... Речь идет не о пихании индивидуальных доработок в апстрим...
    речь идет о том, что индивидуальные доработки в таких системах в 101% случаев таковы, что даже незначительное изменение в апстрим коде - может привести к необходимости переписывать код индивидуальных доработок. И это- нафиг никому не сдалось (кроме конечно самих разработчиков которые за то денюжку получают :)
     
     
  • 6.38, жека воробьев (?), 15:52, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >индивидуальные доработки в таких системах в 101% случаев таковы, что даже незначительное изменение в апстрим коде - может привести к необходимости переписывать код индивидуальных доработок

    А зачем вам переносить изменения из апстрима в работающую систему? В энтерпрайзе так не делают. Либо если прямо очень хотят новых фишек - повторно оплачивают перенос доработок.

     
  • 4.29, Pingvin235 (?), 11:15, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Индивидуальные доработки выходят слишком дорогими. Особенно когда индивидуалка уходит.
     
  • 2.22, Pingvin235 (?), 09:34, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Существующие не против. Спрашивали.
     

  • 1.13, Аноним (13), 08:45, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ШГ

    p.s. зачем старались замазывать "Уфанет", если один раз не замазали?

     
     
  • 2.75, Аноним (75), 19:45, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно ли сделать из этого выводы, что ERP заточена под деятельность провайдера?
     

  • 1.25, Аноним (24), 09:41, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И как оно против сахара/тигра?
     
     
  • 2.34, Pingvin235 (?), 12:41, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очень давно, когда искали систему для интеграции с биллингом - изучали в т.ч. и эти варианты.
    Что не понравилось в Sugar:
    - язык разработки, нам было удобнее писать на Java, не потому что он суперхороший, просто раз уж начали на нём;
    - насколько я помню, там структура БД изменяется при настройке кастомных объектов, это путь не особо удобный, тоже пробовали - но выбрали нормализацию в итоге.
     

  • 1.31, Константавр (ok), 11:28, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно. Пощупаем. Спасибо.
     
  • 1.32, Аноним (32), 11:56, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Советую людям кто обожает хардкор. Погрузитесь в пучину безумия и отчаянья. Окутайте себя тайнами работы системы, фейлами и могущественными багами.  
     
     
  • 2.36, CrazyAlex (?), 14:19, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну, это вообще о любой сложной системе
     

  • 1.33, Аноним (33), 12:03, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Blow-график


     
  • 1.37, VladSh (?), 15:35, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > СУБД MySQL

    Реляционка для BPM-решений - не лучший выбор (Mongo лучше гораздо). Нормальная ERP вообще подразумевает комплекс из реляционки + NoSQL.
    Одна реляционка в списке говорит о том, что она прибита там гвоздями...
    Ну а по скринам красивенько так.

     
     
  • 2.39, VladSh (?), 15:53, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да, и про хранилище файлов ничего непонятно. Если файлы также хранятся в MySQL, - это печально.
     
     
  • 3.40, Pingvin235 (?), 17:56, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Файлы хранятся на диске, в базе метаданные. Как обычно.
     
     
  • 4.45, Pret78 (?), 18:44, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    DMS (систему управления документами) при обращении с контрагентами и внутренний документооборот реализованы в BGERP? Или BGERP по сути является CRM с задатками ERP?
     
     
  • 5.47, Pingvin235 (?), 20:48, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В данный момент готового проверенного решения нет.

    Документооборот планировалось делать на базе процессов. То есть привязывать документ к процессу, далее обычная схема с изменением статусов. Была давно одна попытка реализации, не доделали до конца.

     
  • 4.70, VladSh (?), 14:03, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обычно (я видил массу таких решений) пихают файлы прямо в реляционку (в блобы).
     
  • 2.41, Pingvin235 (?), 18:02, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прибита, так точно. Не получается полноценно СУБД использовать без прибивания. Различные оптимизации вроде LIMIT, полнотекстового поиска - вне стандартов. Даже особенности репликации приходится учитывать.
     
     
  • 3.48, Аноним (24), 22:27, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Плюсану, ибо считаю, что возможность использовать полностью все фичи одной выбранной СУБД важнее, чем возможность пользоваться любой СУБД за счёт ограничения используемых фич неким общим подмножеством.
     
  • 3.50, AleksK (ok), 07:23, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В 1С же вроде неплохо реализовали работу с mssql,db2, oracle и postgres. Хотя конечно основные там mssql и postgres.
    И почему mysql а не postgres?
     
     
  • 4.53, Pingvin235 (?), 10:31, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1) Исторически начали работать с MySQL, ещё очень давно. Так как находили там решения для всех задач - то так и оставались на ней.
    2) Мы не используем хранимых процедур и обращаемся с БД как с тупым быстрым хранилищем. Вся логика в Java.
    3) Репликация в Постгре появилась встроенная значительно позже и она там специфичная, на основании сравнения бинарного файлов была. Не знаю, как сейчас. На эту тему хороший пост был от Mail.ru или типа того, как они переходили на Постгре. Репликация нам нужна, поскольку на слейв базы перекидывали тяжёлые запросы, не требующие суперактуальных данных.
    4) Хранение таблиц в отдельных файлах. Сейчас это стандартная настройка, но мы когда-то пришли к этому сами. При такой схеме гораздо удобнее холодный бакап с использованием снапшотов ФС. Не знаю, есть ли это в Постгре.
    5) Когда-то мы смотрели Оракл, но тогда не нашли специфичных плюшек вроде LIMIT. Там совсем другой подход, с курсорами.
    6) А недавно уже в Германии я делал поддержку в Постгрес для изначально Оракл программы. Не знаю, насколько там красивый код, но вот поведение в некоторых местах было совсем непредсказуемое. Вроде как ставишь приведение типа в запросе и начинает работать индекс. Причём купленная поддержка удивляется вместе с тобой вместе, как это так получается.

    В общем, БД - это почти как жена, выбираешь надолго и изучаешь основательно. Ну или у меня такой подход однолюба :)

     
     
  • 5.59, ыы (?), 12:41, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >гораздо удобнее холодный бакап

    для этого надо выключать базу и как следствие - остановка системы?

    >специфичных плюшек вроде LIMIT
    >А недавно уже в Германии я делал поддержку в Постгрес для изначально Оракл программы. Не знаю, насколько там красивый код, но вот поведение в некоторых местах было совсем непредсказуемое. Вроде как ставишь приведение типа в запросе и начинает работать индекс. Причём купленная поддержка удивляется вместе с тобой вместе, как это так получается.

    И тут надо делать большие глаза и таинственно понижать голос....  План запроса оракл может показать прямо по пунктам, со всеми "приседаниями и ужимками" которые он при этом совершает. И то что вы пишите - обусловлено какой-то рациональной логикой. используется в запросе индекс или нет- определяется стоимостью этой операции относительно прямого чтения последовательно и часто бывают такие случаи когда просто линейно прочитать файл дешевле того же самого через индекс... причем план запроса может поменяться в зависимости от объема данных в таблице... Ну вы же написали я так понимаю целую ERP.. должны сами это знать и понимать...

    >Исторически начали работать с MySQL,

    То есть выбор обусловлен критериями 20-летнего  давности...

     
     
  • 6.61, Pingvin235 (?), 13:14, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > для этого надо выключать базу и как следствие - остановка системы?

    Надо её перезапускать, чтобы сбросились файловые кэши. Но задержка минимальна и практически незаметна. Ещё со времён биллинга нашли решение.

     
     
  • 7.68, ыы (?), 13:33, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Надо её перезапускать, чтобы сбросились файловые кэши.

    перезапустить базу чтобы сбросить файловые кэши... надо этот прикол рассказать народу :)

    https://stackoverflow.com/questions/5231678/clear-mysql-query-cache-without-re
    там и про сброс кэша запросов базы и про сброс файловых кэшей...


    >Ещё со времён биллинга нашли решение.

    Извиняюсь, но вы просто остались на том самом 20-летнем технологическом стэке..во всех смыслах...

     
  • 5.76, AleksK (ok), 22:58, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я так понимаю это в первую очередь именно CRM/BPM  а потом уже ERP. Просто из описания получается что это навороченный календарь планировщик. В ней вообще предусмотрен функционал учета по основной деятельности фирмы? Например торговля, оказание услуг, собственное производства, учет и анализ взаиморасчетов ну и т.д.
     
  • 3.71, VladSh (?), 14:05, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не получается полноценно СУБД использовать без прибивания.

    Получается, посмотрите Nuxeo.

     
     
  • 4.91, непомнюкто (?), 14:19, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не получается полноценно СУБД использовать без прибивания.
    > Получается, посмотрите Nuxeo.

    Таки глянул. Там используется свой язык NXQL, который транслируется в конкретные диалекты. Ну это не то. Так можно сказать, что PHP не прибито гвоздями потому что есть doctrine или как там его.

     
  • 2.49, непомнюкто (?), 06:33, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Одна реляционка в списке говорит о том, что она прибита там гвоздями...

    Неприбитые к СУБД решения могут быть только очень простые.

     
     
  • 3.72, VladSh (?), 14:07, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Неправильно. Посмотрите Nuxeo.
    Прибитость от привычки работы в одной СУБД и недостатка опыта работы в других. Серьёзные решения пишутся в комбинации noSQL, RDB (включая DWH), Redis, Elastic...
     
     
  • 4.79, ыы (?), 07:08, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Серьезные решения - это мозаика из разных продуктов, которые компанией были куплены у разных фирм и стартапов и теперь продаются под одной вывеской... И там действительно на каждом кусочке мозаики- могут быть разные СУБД и языки, и технологии...
    Но на каждом из этих кусочков- выбранная СУБД "прибита гвоздями"... По многим причинам.
     
     
  • 5.90, непомнюкто (?), 14:12, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Серьезные решения - это мозаика из разных продуктов, которые компанией были куплены
    > у разных фирм и стартапов и теперь продаются под одной вывеской...
    > И там действительно на каждом кусочке мозаики- могут быть разные СУБД
    > и языки, и технологии...
    > Но на каждом из этих кусочков- выбранная СУБД "прибита гвоздями"... По многим
    > причинам.

    Вот именно. Особенно весело, когда в одном из сторонних решений по неведомым причинам в качестве места хранения используется ЛДАП.

     
  • 4.89, непомнюкто (?), 14:10, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Неправильно. Посмотрите Nuxeo.
    > Прибитость от привычки работы в одной СУБД и недостатка опыта работы в
    > других. Серьёзные решения пишутся в комбинации noSQL, RDB (включая DWH), Redis,
    > Elastic...

    Что мне смотреть. Приходится и в Oracle и в MySQL жить. Разница в синтаксисе вполне конкретная даже в мелочах. А это означает, что написаное под одну СУБД может незаработать в другой, хотя внешне это может оказаться неочевидно.

     
  • 4.92, непомнюкто (?), 14:27, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Неправильно. Посмотрите Nuxeo.

    Простой пример непереносимости. В Oracle пустая строка трактуется как  NULL, а в Mysql пустая строка и NULL разные штуки.

     
  • 3.81, AleksK (ok), 08:18, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>Одна реляционка в списке говорит о том, что она прибита там гвоздями...
    > Неприбитые к СУБД решения могут быть только очень простые.

    1C вполне себе серьезное решение и может работать с 4 СУБД

     
     
  • 4.82, ыы (?), 10:05, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если вы в теме - то знаете наверное что работает оно с ними очень по разному...
     
     
  • 5.83, AleksK (ok), 11:06, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого у них есть специальный сервер, который транслирует исходные запросы в запросы для каждой СУБД. Более того сейчас даже в режиме файловой базы у них эмулируется полная трехзвенка, поэтому сейчас 1С в файловом режиме жутко тупит особенно на офисных компах без ссд, а если ещё и по сети несколько пользователей то вообще амбец.
     

  • 1.43, Andre (??), 18:23, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В демку не пускает онлайн. У всех так?
     
     
  • 2.44, Pingvin235 (?), 18:42, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чёрт, шутники зашли и юзера удалили. Надо будет что-то придумать против этого. В 0 часов сбросится база.
     

  • 1.51, Alex (??), 09:46, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ох тут и специалисты пишут комменты. огонь! прекратите вот это вот, езжайте в деревню, занимайтесь тем для чего вас природа породила. растите поросенка, картоху или еще чего там ростят.
     
  • 1.52, economist (?), 10:18, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Глянул демку, а ведь неплохо задумано! Сам концепт приложения после 1C:УПП/ERP2 кажется удобным и понятным.

    Демка сама ужасна, отчетов 0 (первое что смотрят), контент демки не раскрывает не то что ERP/MRP, даже CRM-фнукционала. Антидемо, в общем.

    Если сравнивать со свободными (Odoo, vTiger, SugarCRM) и брошенными free-аналогами (Naudoc) то пока 2,5/5. В общем рано. Но будем следить за проектом.  

     
     
  • 2.67, Pingvin235 (?), 13:32, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это не задумка, а примерно десятая передумка. Значительная часть функционала осталась в кастомизациях клиентов, гвоздями прибито к конкретной организации. Так когда-то Nau делал, под каждого - свой продукт. Постепенно будем выносить в апстрим.
     

  • 1.54, MVK (??), 10:59, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Технологии 20 летней давности: Struts, JSP, JQuery.

    Неприятно выглядят SQL запросы в коде (отсюда и крепкая привязка к базе), собираемые конкатенацией.

    Из хорошего - код лаконичный и его не много.

     
     
  • 2.56, Pingvin235 (?), 11:24, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё Java, MySQL, 386 архитектура с монолитным Linux на нём. HTML так вообще незнамо откуда привет в светлое будущее ;)

    Пробуем периодически новые. Был кусок на Angular, например. Потом я с ним работал на другом проекте. Убрали, не понравилось. Мы остались на server side rendering, к которому сейчас приходят обратно с фронтенда. Гораздо удобнее доставать данные из памяти, чем каждый чих запрашивать. Не оправдала себя идея, что "рендерить на клиенте эффективнее". Накладные расходы на пересылку данных по сети убивают преимущество от распределения.

    От Struts там вообще распределение по классам и методам осталось только. Вообще по моим наблюдениям любой крупный проект неминуемо начинает что-то от себя добавлять.

     
     
  • 3.58, MVK (??), 11:44, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ещё Java, MySQL, 386 архитектура с монолитным Linux на нём. HTML так вообще незнамо откуда привет в светлое будущее ;)

    - юмор это хорошо, но в данном случае он не к месту. На Java можно писать по разному. У Вас написано на технологическом стеке 20 летней давности. Это всего лишь констатация факта. И HTML за 20 лет поменялся, и работа с БД, и web-фреймворки существенно изменились.

     
     
  • 4.93, Оно Ним (?), 20:21, 07/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Важно то, насколько хорошо обеспечивает задуманное.

    В Боинге тоже на Фортране пишут. Не самый модный язык. Но толковые самолёты.

     
  • 3.60, ыы (?), 12:51, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Накладные расходы на пересылку данных по сети убивают преимущество от распределения

    а можно про вот это поподробнее?
    Вы же пересылаете только необходимые данные? не базу же целиком и не таблицу целиком...
    То есть объем данных передаваемых по сети  в случае рендеринга на клиенте должен быть даже меньше чем при рендеринге на сервере... А у вас наоборот получается. как так?
    Или вы какие-то другие накладные расходы имеете в виду?

    или... у вас рендеринг неотемлим от выборки данных? sql код прямо в html-темплейтах ?

     
     
  • 4.62, Pingvin235 (?), 13:17, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы же пересылаете только необходимые данные? не базу же целиком и не таблицу целиком...

    Например, быстрое обращение к справочнику пользователей. Для этого удобно в хипе держать кэш. То же с группами, правами. То есть можно и джойны всегда делать, но иногда это неудобно, так как приходится и классы-бины менять, в которых данные пересылаются.

     
     
  • 5.64, ыы (?), 13:26, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы когда нибудь слышали про AJAX?
     
     
  • 6.66, Pingvin235 (?), 13:30, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы когда нибудь слышали про AJAX?

    Нет, а что это? ))

    Обращение по сети за этими данными будет в 1000 и более раз медленнее, чем внутри памяти одного приложения.

     
  • 2.65, Pingvin235 (?), 13:28, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще интересную вы тему подняли. Я лично пришёл к тому, что новые технологии лучше всего пробовать в отдельных проектах. Где хозяин-барин платит за распитие самого свежего смузи. Можно бесплатно потренироваться, так ещё и заплатят за время учёбы. Посмотреть - иногда что-то и перенять. Большая часть нового - шлак или перепродажа старого. Пошумят и умирают, потому что неудобно оказалось. Web сервисы, Ангуляр, много их было уже. Невозможно физически делать большой проект на самых новых технологиях, мода слишком переменчива. Ещё есть эффект изолированного развития стеков по сути одного продукта. Например на фронте до сих пор логируют с помощью console.log() и вообще не понимают, когда пытаешься им объяснить про что-то подобное log4j.
     
     
  • 3.73, MVK (??), 14:11, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >пришёл к тому, что новые технологии лучше всего пробовать в отдельных проектах

    - может и так, но проект, о котором идет речь, выглядит откровенно запылившимся и перевод его в opensource скорее всего мало что даст, так как сейчас так уже не пишут. Черезчур олдскульно.


    >что-то подобное log4j

    - даже тут не айс. Энтерпрайз давно слез с Log4J и переполз на SLF4J, что дает продукту большую гибкость в использовании логера и в использовании сторонних библиотек.

    >Невозможно физически делать большой проект на самых новых технологиях, мода слишком переменчива

    - как правило новые фреймворки и технологии призваны упростить и ускорить разработку

     

  • 1.55, ugygi76865e54 (?), 11:19, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пытались использовать эту систему когда она еще была платной. Ад. Боль и слёзы. Видимо, после BGBilling разработчиков окончательно покинул разум.
     
     
  • 2.69, Pingvin235 (?), 13:35, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы нам тоже не понравились. Чуть что - кричать и в слёзы.
    Чтобы разум покинул, он должен сначала быть :)

    Вы бы кратко отписали, что было не так. Мы бы учли на будущее.

     

  • 1.57, Кирилл (??), 11:42, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А мы из opensource успешно внедрили и используем https://erpnext.com/
    Выглядит современно, есть мобильный клиент, написана на питоне, часто обновляется. Потихоньку вытесняет 1с и jira.
     
     
  • 2.77, Аноним (77), 23:42, 06/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    2064 Issues из них часть помечена как баг. Для провайдинга может и сойдет, но для для другой деятельности переделывать всяческие Bank Invoice - вторая разработка.
     

  • 1.63, Pingvin235 (?), 13:21, 06/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Хотел поблагодарить команду OpenNet, пока не промоталось.
    1)Новость хорошо оформили, лучше, чем я сам прислал. С картинками ещё.
    2)Пример перехода этого сайта на коллективное финансиорование заставил меня поверить, что опенсурс в России возможен.  
    3)Аудитория молчунов здесь отличная. Которые молча читают, а потом выходят на связь с интересными предложениями.
     
  • 1.78, Anonimus (??), 00:04, 07/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А в чем "промышленность" данного продукта? Или так, для сурьезности и важности прикрутили словцо? Промышленная принадлежность как бы подразумевает использование принятых в отрасли стандартов,возможности масштабирования, показатели надежности. И? "Мы программируем на Java, потому что мы выучили Java". "Мы используем MySQL, потому что мы привыкли к MySQL". Так и напрашивается - "Я тебя слепила, из того что было..." Не, я не против,только за, но при чем здесь "промышленная".
     
     
  • 2.80, ыы (?), 07:14, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот такая у них "промышленность" - СУБД бэкапится по холодному, через шотдаун, и это считается "найденным еще со времен..." (с) типа хорошим решением...
     
     
  • 3.84, боцман (?), 20:24, 07/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    бекапится уже давно xtrabackup'ом. шамиль писал про древние времена, когда для консистентности снапшотов (с которых уже и снимался бакап) необходимо было выполнять

    FLUSH TABLES WITH READ LOCK;
    system /bin/sh $snapscript
    UNLOCK TABLES;

    это довольно быстро. и ничего там не шатдаунилось, конечно. хотя не вижу проблем зашатдаунить реплику на время снятия снапшота или даже тупо бекапа, если реплика только для этого и предназначена =)

    что касается bgerp/bgcrm то боль наступает из-за:
    1) хранения файлов в одном плоском каталоге фс, без хеширования по какому-либо признаку. за несколько лет использования накопилось 5+ млн файлов в каталоге (по 130 тыщ в месяц). после этого оно встало колом.
    2) все процессы в одной таблице, без партиций. десятки миллионов строк. как только таблица перестала влезать в память - все встало колом.

    со структурой бд надо что-то делать. вечно наращивать память невозможно. с файлами мы уже порешали, правда кривовато (я бы предпочел структуру типа кеша сквида). не знаю, есть ли этот костыль в опенсорсе =)

     

  • 1.85, Аноним (85), 20:37, 08/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дальнейшие планы:

    Выставление счетов;

    Это точно crm? А упд завезут ?

    Бухам можно уже вешаться ?

     
  • 1.88, чевам (?), 16:53, 14/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    примеры гибкой настраиваемой системы с скриптами и свистоплясками где??? в целом норм проект по сравнению с платным шлаком норм решение
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру