То же от ПарусаИ еще Парус 8 был изначально написан по Oracle и только под него (то есть не многоплатформенная ). Вся база и язык запросов все это Оракловое изначально.
Но самое важное не это. Самое важное, что Парус 8 это достаточно новая функциональная ERP архитектура, которая является единым интегрированными информационным пространством. Все подсистемы тесно связаны с собой посредством единых разделов и таблиц (выгрузки из модуля в модуль нет – все едино).

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

Отсутствие возможности выбирать - выгрузки или их отсутствие - почти всегда минус.

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

Отсутствие возможности выбирать - выгрузки или их отсутствие - почти всегда минус.

Возможность выгрузки есть в каждом разделе и справочниках (интерфейс), возможность репликации и интеграции с другой системой полностью поддерживается интеграционной платформой Oracle.
Выгрузка из модуля в модуль наследие начала 90-х г когда архитектура ERP создавалась год за годом по мере возникновения задач бизнеса. Многие системы собраны из продуктов разных производителей и пожаты Workflow инструментами. Это болезнь тех систем, которые ранее были написаны, но позже интегрированы между собой.
Единой интегрированной платформе ERP не нужна модульная выгрузка, так как целостность и правильность введенной информации проверяется на вводе (ибо разделы едины). А проверка и обработка данных на разных этапах производиться с помощью системы поэтапного утверждения объектов ERP. Поэтому проблемы несовместимости данных выгрузки данных из модуля в модуль в Парусе просто нет.
Он создан позже, когда бонусы от автоматизации и ошибки, прошлых ERP были видны. Подход возможности внедрения одного модуля без другого присутствует. Так же как репликации его модулей с производителями других систем. С учетом того, что база и приложение выполнены в едином ключе, у Паруса 8 отсутствует задвоенность аналогичных по функциям разделов и справочников в разных модулях и различия в терминологии (точнее аналогичных по функциям регистров системы просто нет). Взаимосвязи между данными в системе со стороны клиента достаточно прозрачны и есть возможность их графического отображения по команде пользователя.

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

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


1. При росте числа пользователей идет регулировка настраиваемой очереди обработки транзакций, но только средствами СУБД а не апликейшина (аналог регулировки частоты выгрузки из модулей).
Но! Но если при большом количестве пользователей помодульная выгрузка будет производиться медленно – смысл КИС тереться.
2. Если говорим о стандартном продукте –то разговор не о разработке (если не стороннее решение) а костомизации. В этом случае все так же как в модульных ERP.

Но что мы спорим? Тут уже 1С никаким боком. Да и новые ERP системы сейчас стараются писать интегрированными (едиными).

О росте числа пользователей я говорил не в контексте скорости СУБД, а скорее со стороны эксплуатации пользователями. Например, если некий отдел работает в своем модуле и накосячил там, то устранить ошибки будет намного проще если выгрузка еще не произошла, в противном случае это расползется по всей системе.

Theon mainstreamО росте числа пользователей я говорил не в контексте скорости СУБД, а скорее со стороны эксплуатации пользователями. Например, если некий отдел работает в своем модуле и накосячил там, то устранить ошибки будет намного проще если выгрузка еще не произошла, в противном случае это расползется по всей системе.

А чем проще то? В том же Парусе сделана например приходная накладная и ее можно исправить пока не сделали Счет фактуру.
А если сделали можно откатить счет фактуру назад и исправит накладную.
А если из СЧФ сделали проводку, то можно откатит назад проводку, а потом СЧФ. А если период закрыт, то сторнировать проводку, после чего можно откатывать СЧФ.
Очень удобно!

ЗЫ Предрекаю возможное замечание, что лучше вводить сторнирующие запаси а не откатывать (что бы история сохранялась). На что есть ответ. В Парус 8 можете запретить откатывать и делайте как в других ERP обратные операции.Но вряд ли вы это сделаете, имея такой функционал-). Тем боле, что есть история действий с объектом -)

Все понятно, еще одну 1Ску сделали.
С таким подоходом про МСФО и внутренний контроль можно забыть.
Надо определятся в каком направлении двигаться - ERP по международным стандартам или
что "хочу то ворочу" с учетом российской специфики. И не называть одно другим.