Добрый день.Мы опубликовали систему управления предприятием Papyrus в исходных кодах под именем OpenPapyrus. Проект так же опубликован на сервере sourceforge.
Технические аспекты я распишу в отдельной статье, а здесь кратко расскажу о том, что такое OpenPapyrus и почему эта система стоит того, чтобы с ней ознакомиться и начать ее использовать.
OpenPapyrus — инфраструктурная система для управления бизнесом, над которой мы работаем более 20 лет (с 1996 года), развив в ней обширный функционал для управления бизнесом в широком наборе сегментов.
До текущего момента мы продавали систему Papyrus только как проприетарный продукт. В дальнейшем мы будем развивать одновременно оба продукта — проприетарный и открытый (тем более, что это — почти одно и то же).
Мы считаем (Open)Papyrus одной из лучших систем такого класса на российском рынке. Утверждение, конечно, сильное и субъективное, но теперь, когда
Вот, возможно не полный, список сегментов бизнеса, в которых OpenPapyrus превосходно работает:
- Розничная торговля
- Аптеки
- Оптовая торговля
- Кафе и рестораны
- Салоны красоты
- Фитнес клубы и спортивные центры
- Небольшое производство
OpenPapyrus умеет очень-очень-очень много всего и почти все, из этого много, делает хорошо. Попытка перечислить функциональные возможности системы лежит там же на github. Мы постарались классифицировать весь функционал и составить перечень, по которому можно было бы сравнивать систему с конкурирующими решениями. Но на мой взгляд, попытка оказалась не очень успешной (хотя этот документ мы, по-возможности, поддерживаем в актуальном состоянии).
Очень тезисная колонка функциональных блоков такова:
- Бухгалтерский учет
- Управление закупками
- Управление продажами
- Управление расчетами с контрагентами
- Управление розничными продажами
- Point-of-sale
- Управление производством
- Управление персональными событиями
- Управление проектами и задачами
- Инфраструктурный функционал
Будет, вероятно, уместным обратить внимание, что у нас есть решение для мобильных торговых агентов (StyloAgent), мобильный официант для ресторанов (StyloWaiter) и модуль для терминалов сбора данных (BHT). Эти продукты мы пока в открытый доступ не выкладываем, но не потому, что жалко, а из-за технических препятствий.
Система разрабатывается и развивается в соответствии с несколькими не сложными принципами, которые, в основном, и определяют ее облик:
- Концептуальная целостность и непротиворечивость. Если по-человечески, то это значит, например, что мы не делаем заплаток для того, чтобы удовлетворить какой-либо запрос клиента, но применяем и(или) расширяем существующие понятия для этого. Если же разработка новой концепции все же необходима, то планируем и прорабатываем ее с расчетом на будущее использование.
- Максимальная унификация. Жаль, что термин «принцип Оккама» измотали применением к месту и не к месту, а то бы он здесь подошел. Но в общем, идея та же: если некая сущность может быть отражена в системе одни раз и затем повторно использоваться, то незачем ее и множить.
Простой пример: персоналии, как субъекты гражданского права, представлены одноименным объектом данных, а не набором «покупатели», «поставщики», «физики», «юрики» и т.д. Вопрос классификации при использовании — техническая проблема.
Аналогично, понятия «склад», «адрес», «складская ячейка» и «подразделение организации» все представляются через единый функциональный объект «локация».
Похожие подходы используются и в разработке кода системы — большинство блоков строятся по шаблонным методам с предельно унифицированными интерфейсами. Результат легко заметен по размеру дистрибутива — он очень скромный.
- Примат снижения себестоимости поддержки. Выражаясь русским языком: если два и более клиента обратились по одному поводу, то дешевле что-то поменять в системе, чем отвечать на такие же обращения в будущем.
- Устранение дефектов имеет максимальный приоритет перед всеми остальными проблемами и выполняется без каких либо условий. С этим все более или менее понятно. Очевидно, этот принцип туго связан с предыдущим.
Учитывая возраст системы и то, что некоторые компании используют ее по 10-20 лет, можно предположить, что эти принципы работают. У них есть и побочный эффект: система в конце концов оказалась весьма не очевидной в настройке, что, однако, перекрывается простотой использования для конечных пользователей.
Функциональных отличий между Papyrus и OpenPapyrus нет. Мы, правда, пока не до конца понимаем как будут уживаться оба этих варианта с маркетинговой точки зрения.
Поддержка остается платной, но мы очень рассчитываем на то, что будет достаточно людей и компаний, которые сами смогут разобраться что и как, и, того паче, смогут продавать свои консультационные услуги другим компаниям.
Инструкции по установке есть и на github'е и на sourceforge. Инсталляция для ознакомления очень простая. Инструкций по сборке из исходных кодов пока нет, но клон исходных кодов точно собирается — мы это тщательно проверили.
Документация (большая, но все равно, не полная) есть там же.
Перед тем, как закруглиться, приведу пару любопытных фактов:
- Papyrus умеет управлять web-контентом. Мы эту feature не позиционируем как тиражируемую, но содержанием сайта компании Петроглиф и сайтом Universe-HTT (там, например, есть один из лучших справочников штрихкодов в сети) управляет сервер Papyrus, накрытый обвязками из Java из т.д.
- Протокол версий Papyrus ведется с самого его рождения. В удобоваримом виде он доступен на сайте компании Петроглиф. Конвертация в html осуществляется автоматически тем же самым Papyrus'ом. В релизах на github мы даем соответствующую ссылку.
Ну и напоследок. Ради чего? Основная причина — экзистенциальная: стоит поделиться тем, что делали 20 с лишним лет, с остальным миром, тем более, что мы сами пользуемся результатами работы open source-сообщества. Остальные причины мелкие и скучные — вы и сами о них знаете.
Комментарии (27)
caballero
27.02.2017 12:49Охотно верю что система хорошая. Но лично я не стал бы сопровождать и развивать такого размера проект на Си, код которого начал писаться 20 лет назад.
Впрочем как авторнаколенной поделкиучетной системы, написанной на PHP, могу быть необъективен.
Emelian
27.02.2017 15:11Я уже закачиваю вашу систему, буду разбираться. В слепую, пока несколько вопросов:
1. Вы ни разу ни упомянули 1С. Как ваша система с ней соотносится, или вообще не пересекается никаким боком?
2. Какой движок БД используется? Думаю, что что-то из sql-серверов только. Это так?
3. Еще не видел вашей системы, но почему-то уверен, что в ее справочниках (в терминах 1С) нет поддержки групп на уровне интерфейса, разве что непосредственный sql отбор / фильтрация и т.п. Это так?
antonsobolev
27.02.2017 15:19Здравствуйте.
1. OpenPapyrus с 1С никак не соотносится. На уровне маркетинга — почти чистая конкуренция с решениями на платформе 1С. Исключение составляют случаи, когда предприятия используют 1с только для бухучета — в этом случае OpenPapyrus обеспечивает хорошие инструменты для экспорта и импорта данных.
2. Движок БД nosql: Pervasive SQL (только низкоуровневый доступ, ранее называвшийся btrieve)
3. Насчет «групп на уровне интерфейса» не понял (я не разбираюсь в 1С).Emelian
27.02.2017 15:361. Народ привык к 1С, хотя часто критикует его. Поэтому какая-то логическая совместимость должна быть. Сильные вещи в 1С – конфигуратор (позволяющий разрабатывать пользовательские бизнес-решения) и поддержка иерархической группировки (грубо говоря, деревья с таблицами вместо листьев) в таблицах (справочниках). Откровенно говоря, если бы вы реализовали «семерку» (1С77) один в один и выложили бы ее код, до она сразу бы обрела популярность и стала бы конкурентом «восьмерки» (1С8х), по словам ее отца-основателя – Бориса Нуралиева.
2. А почему файл-серверные СУБД вам не нравятся?
3. Это похоже на поддержку файловой системы в Total Commander либо Windows-Explorer.antonsobolev
27.02.2017 16:001. У OpenPapyrus идеология иная — это готовый продукт. Мы понимаем, что многим нравится иметь возможность самостоятельно заточить готовое решение по примеру конфигураций в 1С. Собственно, одна из причин публикации opensource-варианта — дать возможность специалистам почувствовать независимость от оригинальных разработчиков. С другой стороны, такие решения очень сложны, и мы отдаем себе отчет в том, что дорога будет долгой.
2. Скорость работы в многопользовательской среде сильно снижается. В зависимости от того, как пойдет с open-вариантом papyrus'а, мы планируем организовать поддержку других СУБД.
3. Понял. Товарные группы, склады и многие иные объекты иерархические.Emelian
27.02.2017 18:281. Да, готовый продукт в исходниках на 400 МБ это очень сложно. Тем более, что судя по позиционированию бизнес решений в области: «Розничная торговля», «Аптеки», «Кафе и рестораны», «Салоны красоты», «Фитнес клубы и спортивные центры», «Небольшое производство», речь идет о, в терминах 1С77, «малых и средних предприятиях». Если, скажем, воспользоваться Qt, то аналогичные исходники будут, наверняка, в несколько десятков раз меньше. Что, теоретически, уже будет под силу наваять одному человеку. Главное правильно выбрать концепцию разработки.
2. А вот с этим можно поспорить. Та же «семерка» в бинарниках весит всего 10-15 МБ. Это позволяет на стареньком сервере с двумя гектарами памяти спокойно держать в терминалке на гигабитной сети 25-30 человек, а с ОЗУ 4Гб – до 50 человек одновременно. В этом смысле распределенные приложения на «семерке» часто выигрывают по производительности и особенно в стоимости с аналогичными решениями на «восьмерке», которая, позволяет одновременно обслуживать до 500 пользователей и выше, вопрос только какой ценой.
«Семерка» реализована на примитивнейшей СУБД на базе DBase-IV и позволяет, благодаря всяким разным пользовательским внешним компонентам, достигать приемлемой производительности. Уверен, что она еще просуществует минимум 20-30 лет, хотя ее поддержка официально прекращена в 2006 году.
Я уверен, что файл-серверные СУБД вполне могут конкурировать с клиент-серверными по соотношению цена – производительность, их просто искусственно принуждают забыть, новое поколение программистов знакомо с файловыми СУБД только на уровне мифов. Вот технология Rushmore в Visual FoxPro, до сих пор никем не превзойдена, но VFP благополучно сливается самим M$, потому, что это слишком дешевая и эффективная система. Не зря в мире широко используются опен-сорсные аналоги вроде xHarbour и др., хотя им до VFP, как Киеву до безвиза.
А «скоростью работы в многопользовательской среде» вполне можно управлять концептуально правильно написанным кодом.
3. Группы в справочниках (по аналогии с каталогами, папками и файлами) это реально круто. Это сильно упрощает бизнес-логику. Также очень удобен в «семерке» быстрый поиск (перемещение по первым символом набора), вполне хорош также отбор в справочниках. И много чего хорошего и удобного по мелочам, а все ляпы фирмы 1С легко лечатся поддержкой внешних компонент, которые способны залезать (недокументированная возможность!) в самое нутро 1С.
В итоге, в 1С можно делать чудеса, при прямых руках, даже при отсутствии их исходников :).Dementor
28.02.2017 21:43С FoxPro все не совсем так было. Технологию Rushmore изобрели еще во времена FoxSoftware и до покупки данной СУБД мелкомягкими, которые переименовали данный продукт в VFP.
Зачем купили, если у них уже был Access для мелочей и MsSQL для крупных проектов? Вероятно исключительно для того, что бы вытянуть все ноу-хау и убить конкурента. В 2007 они заявили, что закрывают этот проект. Но еще в 2005, когда я писал диплом и мне нужно было знать стоимости фокспрошной лицензий для экономического обоснования моей программы, то в микрософтовском офисе мне не смогли дать ответа — сказали, что они ее уже не продают.Emelian
01.03.2017 07:18Да, я знаю, что Rushmore изобрели не в M$, но по факту она актуальна только для VFP. Что самое смешное, никто наверняка не знает, что это за зверь. Некоторые предполагают, что она как-то очень эффективно использует матрицу индексов. Известно, что эта технология демонстрирует очень высокую производительность в запросах VFP. Думаю, что не сильно ошибусь, предположив, что целью мелкософта была именно Rushmore. Выкупив эту технологию, они в итоге убрали ее подальше, как дешевую альтернативу их sql-монстрам. Даже Access не покрывает всех возможностей и удобств VFP. Достаточно сравнить их популярность.
Относительно лицензии на Visual FoxPro, недавно эта тема подымалась на тематическом форуме sql.ru. И вроде удалось найти удовлетворительное решение.
Сейчас актуально использование runtime-библиотек VFP в c++ проектах. Причем можно даже обойтись без OLE и COM, подключившись к его dll-кам напрямую. Далее уже возможны варианты. Либо использовать VFP как DDE-сервер, либо как псевдо-COM контейнер (без регистрации в реестре).
4dmonster
27.02.2017 15:21Я прочитал только то, что по ссылкам из статьи:
1. Вероятно возможен экспорт через XML
2. Pervasive SQL
3. Группы товаров — «иерархические с произвольной вложенностью»antonsobolev
27.02.2017 15:24Да. Все верно. Экспорт/импорт в разных форматах (dbf, text, xml, excel). Для сложных случаев есть COM-интерфейсы.
bormotov
27.02.2017 15:25но почему SourceForge?!
antonsobolev
27.02.2017 15:27+1Популярный ресурс, умеющий автоматом импортировать релизы с github. Почему бы и нет?
bormotov
27.02.2017 15:45+1По крайней мере в моём мире и мире вокруг меня, популярность sf закончилась где-то в начале 2000-ых.
С появлением github так практически совсем завершилась. По после недавних (года два уже или три?) скандалов вокруг неадекватных решений его владельцев, так вообще очень странно его хотя-бы для чего-то использовать. Вторым ресурсом в комплект к github, кажется логичнее использовать bitbucket.
antonsobolev
27.02.2017 15:47Спасибо. Я, к своему стыду, про bitbucket впервые слышу — теперь буду знать.
se80
27.02.2017 15:27хотел-бы я глянуть на консультанта, готового инвестировать свое время в изучение папируса :)
RusMikle
27.02.2017 15:33гдето реально можно посмотреть как это всё работает? (видео может какое итп).
Ещё интересно насколько такая система подходит для реселлера находящегося между поставщиками и оптовыми покупателями. Причём работающего по двум схемам: оптовики напрямую работают с поставщиками а реселлер только менеджит организует и менеджит заказы и рынок и второй когда оптовики полностью завязаны на реселлера т.е. реселлер организует выставки и продажу на них оптовых партий товара далее выставляет счета оптовикам и имеет с этого процент с покупок. Своего склада нет, но поставки со складов производителей управляются и мониторятся через различные логистические фирмы. В редки случаях склад может появиться если товар сначала закупает реселлер а потом продаёт клиентам. Есть отслеживание тована на складах у логистиков. Итп. в настоящий момент всё это крутится на довольно монстериозном софте писанном несколькими поколениями спецов и самоучек со всеми вытекающими. Не срочно но рассматриваются возможности соскочить на что то более менее подходявое с открытым кодом. Спасибо.antonsobolev
27.02.2017 15:45Видео-ролики на сайте есть (правда с некоторыми какие-то проблемы были). Иной вопрос, можно ли там увидеть то, что непосредственно требуется. По прямым запросам мы обычно удаленные презентации устраиваем.
Что касается вопроса про реселлера: на первый взгляд OpenPapyrus здесь хорошо подходит: работа с заказами, платежами, расчетом комиссионных и т.д. хорошо отлажена, но наверняка конкретно у вас есть множество собственных нюансов, потому буду осторожен.
egordeev
27.02.2017 16:28а можете добавить файл лицензии LICENSE в корень github-репозитория? Под какой лицензией распространяете этот проект?
antonsobolev
27.02.2017 16:34Спасибо за напоминание — мы знаем, что не проработали этот вопрос, в ближайшее время решим.
Пока считаем, что лицензия GPL.egordeev
27.02.2017 16:36спасибо, а не планируете переносить этот проект на Qt?
antonsobolev
27.02.2017 16:39На Qt — нет. Такой большой проект очень тяжело перенести на что-то вроде Qt.
Портироваться на linux — да, планируем.
se80
27.02.2017 16:42+1у меня впечатление что вы 20 лет назад начали копировать что-то уже тогда устаревшее. какой смысл писать standalone erp систему под windows!!! на плюсах в 2017 году?
бизнес процессы меняются, входные/выходные формы меняются. честно говоря сложно сказать что не меняется, и это было понятно еще 20 лет назад — вы предлагаете пересобирать систему при каждом апдейте?
я так понимаю ваша ниша — это малый бизнес, но его уводят в облака — ибо денег на свои сервера и своих консультантов/программистов нет, суть малого бизнеса — экономить на всем, даже 1с туда движется, особенно сильна это тенденция в связи с нововведениями в фз-54.
ps это имхо человека, последние 10 лет внедряющего sap.Dementor
28.02.2017 22:00суть малого бизнеса — экономить на всем, даже 1с туда движется
Это вы верно подметили. Не знаю ситуацию в России, но в Украине для ФОПов компания 1С раздает учетную систему «1С: Управление небольшой фирмой для Украины. Микро» абсолютно бесплатно и при этом там есть возможности и интеграции с веб-сайтами (в первую очередь с родным пулом 1C-UMI), с торговым оборудованием, с мобильным приложением, сервисом сдачи бухгалтерской отчетности и так далее.
Продукты 1С — не идеальны, так как иначе не было бы ни этого Папируса, ни Галактики, ни прочих вариантов. Но думаю, что в конце-концов 1С всех задавит демпингом и количеством специалистов. К примеру, в Киеве еще с середины нулевых 1С-Бухгалтерию преподавали в некоторых ВУЗах бухгалтерам и экономистам, а сейчас вероятно это стало обязательным для всех техникумов страны. А в каких ВУЗах СНГ учат работе в Папирусе, Галактике или в том же SAP R/3?
DmitrySokolov
27.02.2017 18:49Название не особо удачное вы выбрали, будут путать с этим — https://eclipse.org/papyrus/.
cry_san
Ребята конечно молодцы!
P.S.
Наймите дизайнера.