В начале года выложили открытый вариант ERP-системы Papyrus (в открытом варианте - OpenPapyrus).

github (для скачки жать ссылку releases)
SourceForge

Инструкции по установке там есть. Установка очень простая: все, что нужно - содержится в дистрибутиве, но сама система - сложная.

Документация толстая, но все равно не полная (ссылки там же).
Сжатое описание функционала, тоже там.

По функционалу от проприетарной версии не отличается, но базы данных не совместимы.

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

Что там есть? Почти все: розница, опт, рестораны, beauty, фитнес, аптеки, производство, бухгалтерия, егаис, фиас, кладр, оборудование самое разнообразное, интеграция со сторонними системами (сет, фронтол, и т.д.), рассылки, и прочий смак.

Если интересно - смотрите. Замечания и обливание помоями приветствуются, однако, отвечать реактивно не смогу - работы много.

LSVХорошая система должна содержать внутренний несложный конструктор.Тогда у нее будет будущее.

А толку с той мегавысокой кучи сорцов ? Кто в нее полезет и с какой целью ???

Если сторонний специалист через 15мин знакомства с системой не сможет создать формочку/справочник/простенький отчет, то грош цена таким проектам. Рынку они не нужны.

Отчет - легко.
Справочник - точно нет. Структура базы данных продумана, выверена и т.д. Расширение данных - за счет тегов.
Насчет формочки (создать/изменить) было бы, наверное, полезно, но сейчас - увы.

LSVsobolevпропущено...


Отчет - легко.
Справочник - точно нет. Структура базы данных продумана, выверена и т.д. Расширение данных - за счет тегов.
Насчет формочки (создать/изменить) было бы, наверное, полезно, но сейчас - увы.Бегло почитал мануал. 800стр. но ни слова про используемую СУБД. Мож пропустил ? :)
Мануал довольно подробный и написан легким языком.

Впечатления о продукте: на 95% хардкод, т.е. практически "коробка"+сорцы (а точнее "черный ящик"). Поэтому в массы не взлетит.
Продуманность структуры это хорошо, но если понадобится даже небольшая модификация, то без помощи "родных разработчиков" сделать малореально. И вникать в С++код ради этого никто не будет. Увы........

СУБД Pervasive SQL
В этой писульке сжато расписаны такие подробности .

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

leonmbsПодобные проги на cpp писаные 20 лет назад- реальная жесть.


sobolev
По поводу хардкода: я так понимаю, этот термин практикуется в форме некоего жупела. Пытаться доказать, что нечто является либо не является хардкодом - развивать флуд на несколько страниц. Потому воздержусь от комментариев.
Ну , логичный вопрос у людей. А как перенастроить бизнес логику если что?
Судя по всему файлов исходников там не одна тысяча.

Бизнес-логика вся настраиваемая. Например (один из самых древних диалогов):


Ну, или вот:


Там очень много настраиваемых параметров. Потому я и сказал, что система сложная.

Кстати, о 20-летней давности: иконки на картинках имеют векторную природу (собственная техника управления такими ресурсами).

Картинки не прицепились

И вторая

irbis_alsobolev,

(Моё мнение тут многие в этом вопросе знают)
:-)
Некроссплатформенная учётная системе,-тупиковая эволюционная ветвь.
Мнение радикальное, но статистически значимое. Потому, во-первых, есть wine, во-вторых, мы все-таки планируем портировать систему на linux.

irbis_alsobolevпропущено...

Мнение радикальное, но статистически значимое. Потому, во-первых, есть wine, во-вторых, мы все-таки планируем портировать систему на linux.

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

[quot irbis_al]sobolevпропущено...


Такой уже прагматический вопрос,...а вот скажите ...я видел у Вас кафешки,магазины в решении...это означает торговое оборудование,этот означает rs-232...Это означает проброс порта rs-232-linux-wine
Вы проволили исследования в этом направлении?...меня вообще не впечатлило(правда это было 10 лет назад)...Уже тогда VirtualBox намного лучше проьрасывал...и я ставил на ещё тогда виндовую версию
:Linux-Виртуальная винда-проброс портов Моя старая ИС с торговыми драйверами.
Что касается переброса портов, то в этой теме я плаваю - ничего не скажу (у нас хардварные инженеры этой темой занимаются). Кстати, недавно сеть бутиков все на linux'е установила. Там местный энтузиаст linux'а - он вопросом рулил. Все там работает, и оборудование в том числе (кассы и принтеры штрихкодов). Но деталей я не знаю.

irbis_alsobolev,

А Вот ещё прагматический вопрос...Фискальные регистраторы...Вы скорее всего пользуетесь заводскими драйверами (Мы сами пишем по низкоуровневому протоколу)...И например мне удалось абстрагироваться от модели фискального регистратора. ...ИС всегда в порт (либо socket либо websocket(чтоб из браузера можно было фискальный чек печатать) посылает xml заданного образца.
Прослушивает этот порт драйвер piritа ...Пирит печатает...Прослушивает Мария(Это украинский) мария печатает,прослушивает штрих,штрих печатает...
(Я кстати от тех ,кто изменил протокол низкоуровневый в связи с онлайн кассами,от тех отказался..Пирит респект тебе Кристалл Сервис...сохранил и не перекладывал с больной головы на здоровую )

Так вот вопрос...у Вас как-то решено абстрагирование от ФР-аппарата или просто хардкод ветвлением?
Частично хард, частично абстрактными драйверами (конкретно, пирит - через драйвер, атол-драйвер - хард). Система большая и с историей - унифицируем постепенно.

LSVБизнес-логика вся настраиваемая.Я бы уточнил: Стандартная Бизнес-логика. бух.проводки - это стандарт.
И то не уверен, что там можно параметрически настроить абсолютно все. Например расчет себестоимости, сложные накладные расходы и подобное сложно настроить, т.к. сначала нетривиально нужно подготовить для отправки в главную книгу (например куда нить в забаланс). Или доработать журнал товарных движений для учета сложных управленческих процессов.
Многое из этого можно сделать в SQL. Но.... Почти неизбежно может понадобится доработка на клиенте, н-р передать дополнительные параметры.

Поэтому говорить про "настраиваемую систему" нужно с оговорками. Иногда с очень критичными.

А первасив это конеш тупиково-лютый фейспалм. :) К тому же небесплатно.
Какого-то непонятного чорта был немного популярен в конце 90-х. Был использован в ряде СНГ-шных проектов: Галактика, ИС-Про и пр.
По настройке проводок: "абсолютно все" - слишком сильное выражение, потому не поручусь. Но вот, "практически любой" случай - настраиваемый. Накладные расходы, перенос активов между складами с разной схемой учета, забалансы, регистровые проводки и т.д. Если приведете конкретный кейс, то попробую ответить конкретнее.

По pervasive: он живой и очень быстрый. Вот его небесплатность - проблема. Мы в пилотном варианте сделали поддержку sql-серверов, но потом выяснилось, что статистическим потребителям плевать на то, какая субд используется в приложении. Их функционал беспокоит, потому до поры-времени оставили как есть. (Боюсь, что пора-время уже наступили).

LSVsobolevЕсли приведете конкретный кейс, то попробую ответить конкретнее.Главную Книгу пока не будем обсуждать. Там все действительно довольно стандартно.

А вот с Упр.Учетом все намного сложнее.
У вас есть журнал товарного движения (Item Ledger) ? Самое интересное там - себестоимость и разного рода накладные расходы.
Например при доставке надо распределить транспортные затраты пропорционально к-л факторам. Причем при наличии разных схем доставки может быть много профилей расчета. Целая шахматка вариант/тип товара.
Экономисты захотят увидеть много подробных цифр, чтобы оперативно управлять стоимостью/сроками доставки, которая непосредственно влияет на продажную цену товара и его запасы.

В простом производстве (кондитерский цех, пекарня, сборка мебели) - те же проблемы.

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

Подобное можно перечислять до бесконечности.
Поэтому все сводится к острой необходимости возможности полноценной доработки как таковой.
Не тюнинга и бантиков, а именно доработки.
Не должно быть риска на вопрос "А можно сделать вот так ?" получить ответ "Нет, это настроить невозможно".
По распределению себестоимости как-то так (на картинке). Итоговая себестоимость раскидывается по строкам, а результирующая сумма валится по счетам при проведении документа.

s_ustinovLSVпропущено...
Главную Книгу пока не будем обсуждать. Там все действительно довольно стандартно.

А вот с Упр.Учетом все намного сложнее.
У вас есть журнал товарного движения (Item Ledger) ? Самое интересное там - себестоимость и разного рода накладные расходы.
Например при доставке надо распределить транспортные затраты пропорционально к-л факторам. Причем при наличии разных схем доставки может быть много профилей расчета. Целая шахматка вариант/тип товара.
Экономисты захотят увидеть много подробных цифр, чтобы оперативно управлять стоимостью/сроками доставки, которая непосредственно влияет на продажную цену товара и его запасы.

В простом производстве (кондитерский цех, пекарня, сборка мебели) - те же проблемы.

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

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

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

Конкретный кейс:
На склад в марте прошлого года пришло 100 штук товара.
В июне 50 штук отгрузили на другой склад. В октябре также переместили оставшиеся 50 штук.
В мае текущего года (после закрытия периода и аудита отчетности) пришел инвойс от склада за хранение товара - 750 долларов за первые 50 штук и 1650 долларов за вторые 50 штук (дольше хранились - больше стоимость хранения).

Как в вашей системе учтется этот счет? Пересчитает ли система себестоимость остатков (10 штук еще хранятся на одном из складов), продаж (80 штук проданы разным клиентам) и списаний (10 штук списаны как потери)? Какими датами будут учтены фин проводки?
По инвойсу, выставленному какого-то дня себестоимость может быть пересчитана только на остаток того самого дня. На то, что продано себестоимость не пересчитается.
Если очень хочется, то можно изменить полную себестоимость всего лота задним числом, но это - ручная операция и не рекомендуемая.