В начале года выложили открытый вариант 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 штук списаны как потери)? Какими датами будут учтены фин проводки?
По инвойсу, выставленному какого-то дня себестоимость может быть пересчитана только на остаток того самого дня. На то, что продано себестоимость не пересчитается.
Если очень хочется, то можно изменить полную себестоимость всего лота задним числом, но это - ручная операция и не рекомендуемая.

jabiksobolev, добрый день!
посмотрел я на функционал в рознице и не нашел там модуля "управления цепочками поставок", можете мне подсказать, где он находится, чтобы посмотреть его, если он реализован.
SCM - широкое понятие. Большая часть функционала, реализующего эту концепцию в системе есть. Перечислю по пунктам из вики (с целью снижения заморочек с терминологией).

-- прогноз продаж (прогнозирование недельных и дневных продаж товара)
Модуль прогнозирования спроса

-- управление запасами (оптимизационное планирование гарантийного запаса, текущего запаса, резервов с учётом выбранной модели управления запасами для каждой товарной категории)
Модуль прогнозирования спроса

-- управление пополнениями (оптимизационное планирование поставок внутри логистической сети компании с учётом планируемых продаж, поставок от производителя, наличия остатков, транспортных мощностей, различных ограничений и бизнес-правил)
Модуль прогнозирования спроса. Для сетей существует специализированный механизм взаимных заказов и поставок.

-- построение краткосрочного (до 4-х недель) и долгосрочного (до 6-и месяцев) прогноза
Все туда же: модуль прогнозирования спроса (он очень большой и развитый).

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

-- проведение ABC-XYZ-анализа по произвольным критериям (количество, прибыль, стоимость закупки);
ABC - в классическом виде. XYZ - не в классическом варианте, но по дисперсии спроса есть.

-- проведение кросс-ABC анализа по произвольным критериям;
Пользователю приходится делать несколько лишних движений, но, тем не менее, и это работает.

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

-- учёт произвольных факторов, влияющих на продажи в автоматическом режиме;
Нет. Причем принципиально. В документации кратко определены концепции, лежащие в основе подхода к прогнозированию спроса.

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

-- расчёт оптимального запаса для каждой позиции с учетом прогноза спроса и страхового запаса.
Да. Все там же - в прогнозировании спроса.

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

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

Мораль - без переписывания с нуля модуля расчета себестоимости для многих задач вашу систему использовать нельзя.
Гм. Я правильно понял, что вы настаиваете на том, что документ должен мочь влиять на предшествующее состояние баланса предприятия?

LSVsobolevГм. Я правильно понял, что вы настаиваете на том, что документ должен мочь влиять на предшествующее состояние баланса предприятия?Если учет чисто УУ, нет какой-то особой проблемы в правках "баланса предприятия" задним числом.
Главное про это помнить.

Все равно в наших реалиях БУ/НУ несовместимо с УУ. :)

Лучше исправить ошибку задним числом, чем оставить ее там навсегда, ИМХО.
Имеет место некоторая путаница в понятиях. Модифицировать или вводить новые документы задним числом это - одно, а документ, влияющий на состояние предприятия задним числом это - нечто иное и больше похожее на оксюморон (или машину времени).

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

Гм. Я правильно понял, что вы настаиваете на том, что документ должен мочь влиять на предшествующее состояние баланса предприятия?
Нет.
Никакие проводки в закрытом периоде не допускаются - на то он и закрытый.

В моем примере речь идет об "Изменения в бухгалтерских оценках"
Понял. Да, реализуется настройками.

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

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

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

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