Господа, хочется получить убедительные аргументы по поводу максимального количества активных пользователей, поддерживаемые 1С 8.1. Что интересует:
1)Число пользователей от 150, но в перспективе интересует 300-400
2)Хочется всех вкусностей ERP системы, которые есть в УПП. Но есть понимание, что бух.часть этой конфигурации является тормозным звеном и лучше на нее не расчитывать. Есть готовность взять конфигурацию и с нуля переносить все функции УПП, пока не начнуться тормоза. Или сделать наоборот - отрезать в УПП все лишнее.
3)На железо планируется потратить порядка 200т.у.е.: 64 битная архитектура, много памяти, СХД уровня SAN (например EVA 4100).

Взлетит ли УПП?

>>Хочется всех вкусностей ERP системы, которые есть в УПП

смеялсо...

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

опять смеялсо...

(2) хочешь сказать что регистр бухгалтерии - не тормоз ?

Просьба не переводить все на рельсы религиозных войн. Хочется чтобы ветка получилась информативна, содержала объективный взгляд на проблему, причем со всех сторон.
(1)У нас производство, для него нам за глаза хватило бы функциональности ПУБ 7.7.

ставлю 100, кто больше? :-)

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

(5)на что? на то что взлетит?

(4) ну и возьмите ПУБ

(3) Тормоз. Но он же не один такой. Вся система низколетающая...

(9)+1

(4) сбейте смету на все железки, обучение, доработки приглашенного франча...

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

(12) там сама задумка неудачная. все остальное вытекает из нее

(0) наверно надо говорить не о регистре бухгалтерии в отдельности, а более широко:
о том, чтобы организационными мерами достичь приемлемой производительности по принципу "разделяй и властвую"
например можно начать с внедрения оперучёта и если производительность и правда подойдёт к критической - БУ вести уже в другой базе

(11)Внедрение будем проводить сами, направим аналитиков и программистов на курсы УПП. Чтобы поднатореть в прикладной части. У франча только возьмем в аренду программистов, 8-ков (если не будем успевать сами - т.е. собственный опыт в 8-ке, большой, но в УПП опыт равен 0).
Соответственно сумма внешних затрат на внедрение около 100, максимум 200. Но дело не в деньгах. А в самой возможности использовать 8.1 для 400 активных пользователей.
Например можно сделать так, чтобы заказы и некоторые другие документы обрабатывались не в он-лайн, а в фоновом режиме (через специальный объект, который есть в 8.1) - т.е. применить разделение документов на потоки, которые используется например в SAP.

(14)А может тогда внедреить УТ, а уже к ней прикрутить систему производства. Или проще отделить бух учет в УПП (я просто не знаю УПП вообще)?

кстати конкретно в УПП - не факт что проводки по РБ будут тормознее чем по регистрам, ибо в плане счетов аналитики на "тяжелых счетах" поменьше будет чем в регистрах (нет например характеристик)

ну и в конце концов можно сделать доработочку чтобы проводочки делались сводно, а полная аналитика на регистрах накопления

(16) отделить бухучёт на порядок проще

(18)Ваше заключение - будет работать 8.1 с производственным функционалом для 400 активных пользователей?

Есть работающие система на 200-300 человек - правда там приходилось оптимизировать УПП - проблема то не в платформе - а в конфигурации

> проблема то не в платформе
lol

(21)Не LOL - я знаю что УПП работает на 300 пользователях - но это после серьезной переделки УПП

2 раза лол.

При всей курьёзности ветки отвечу всего на один вопрос:
8.0/8.1 может потянуть 300-400 пользователей. Но не на типовых решениях. Более того - после года разработки/поддержки от типового там вообще мало что останется.

(24) а нафига тогда 1С?

(25) При наличии граммотных консультантов-постановщиков, которые знают, что такое автоматизация и знают предметную область (не знают, как это сделано в 1С, а знают, как это должно быть на самом деле и имеют соответствующий опыт - не только внедрения, но работы на соответствующих должностях глав. бухов, аудиторов, управленцев), то на платформе 1с 80-81 можно делать неплохое ПО для автоматизации предприятий. Вот за этим и нужна 1с.

>то на платформе 1с 80-81 можно делать неплохое ПО для автоматизации
предприятий.

грустно.. весьма грустно

(24)Вот уже пошла тяжелая артиллерия, пошли знакомые лица... Цифры это хорошо. Статистика знает все. Вопрос к вам: что лучше изначально писать с нуля или все таки начать переделывать УПП (чтобы вы выбрали если бы вам пришлось делать ваш проект заново)?

(24)Кстати, если размышлять логично, то если у вас 8.0 поддерживает 300 пользователей, то используя кластер на 8.1 логично предположить что должно быть 600 (например если использовать кластер из 2-5 мощных серверов приложений).

(29) лучше жевать чем говорить.
чтобы меня не обвинили в голословии. в последний раз, так уж и быть объясню почему:
>кластер на 8.1 логично предположить что должно быть 600 (например если >использовать кластер из 2-5 мощных серверов приложений).
совершенно нелогично. потому что могут не выдержать нагрузки следующие вещи(в порядке вероятности):
1) SQL сервер
2) клиенты (как минимум придется переносить все на сервер)
3) сеть

"и с нуля переносить все функции УПП, пока не начнуться тормоза. "
Садо-мазо какое-то...

Интересно а как же все реализовано в SAP, если он выдерживает несколько десятков тысяч пользователей. Неужто мы на 1С до тысячи не дотянем никогда??

1)Мне кажется в том то и суть серверов приложений - разгрузить сервер SQL - возможно за счет грамотного кэширования, точно не знаю, ни разу не проектировал (а хотелось бы)
2)Это не проблема, особенно если изначально будем писать с нуля. А из УПП брать только идеи предметной области - "как надо".
3)Сеть? Тут ничего не могу сказать, ни согласиться, ни возразить. Не знаю...

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

(32) ппц. если ты нифига не делал и не знаешь - то НАФИГА влазить???

(33)Причины?
-Слабость ИТ-отдела, заложенная в его цель: не разрабатывать новое ПО, а поддерживать существующее
-Проблемы возникающие при внедрении (организационные проблему)

(34)Ты не так меня понял. В том посте я просто как и каждый умный человек сказал - что я все не знаю, ибо это невозможно.

(34) а блин. ты топикстартер. тогда точно невзлетит, потому что  в твоем случае надо ОЧЕНЬ хорошо знать предметную область.

(34)Кстати ты на вопрос (точнее пути решения) в (32) ничего не ответил (не возразил) или ты согласен с ними?

(35) Конечно, п.2. Вероятность вытягивания самого себя из болота за косичку стремиться к бесконечности. Умиляет желание автора переписать в легкую переписать УПП, питаясь только идеями.

>выдерживает несколько десятков тысяч пользователей
незнаю, невидел. предположения конечно есть

Гм, а причем здесь предметная область - ее знаю другие ответственные лица, очень хорошо знают. Но даже этого не достаточно, я отправлю их на курсы, и сам пойду.
P.S.
Мне кажется мы отвлеклись в сторону. Вместо того чтобы доказать что 1С будет работать или не будет работать на большом количестве пользователей, тут хотят доказать что у меня лично ничего не выйдет :)
Меня не интересует ваше мнение выйдет или не выйдет, но мне интересны советы, что в в каком случае нужно делать. Без личностей. Например в (33) корректное замечание, а вот в (37) нет - так как был переход на личности.

знание предметной области - помоему первое необходимое условие

(39)Странно, я как раз думал, что вы будете отстаивать пункт 1. Ну что ж, спасибо. Правильно ли я понял - вы не сомневаетесь, что при грамотной реализации проекта, проблем с производительностью в 1с не будет, а ваше сомнение только в возможности написать нужную функциональность?

(41) Знания предметной области - мало. Надо иметь некий общий подход, а не наблюдать "как там у нас людишки копошаться". Как сегодня писать не надо, надо писать "как будет завтра".
Вопрос к автору ветки: Вы деньги считали???? Скоко обойдется разработка, во что встанет поддержка наваянного??

(43) Неправильно. Я думаю, что проблемы производительности вторичны и решаемы. Я сомневаюсь:
1) Что проект (ПП) реально разработать в интересующие фирму сроки даже при наличии команды (аналитики-постановщики, кодеры-разработчики, проектировщики, консультанты и пр)
2) Что даже, если ПП родиться, его нереально внедрить собственными силами, ибо это не учетная система. Решать вопросы с собственными боссами о изменении бизнес-процессов слишком сложно. Учитывая, что вы внутри даже разглядеть ненормальности сложно - вы к ним привыкли и глаз не видит.

>проблемы производительности вторичны и решаемы
весьма смелое заявление

А какие будут предложения? Возможно мы возьмем сторонних разработчиков пока будет вестись разработка: либо фри, либо фра. Но это уже детали. Хотя если есть что предложить - я вас внимательно слушаю. Я пока собираю информацию, решение будет приниматься через месяц.

(40)Видел работает, классно работает

Да кстати про сторонних внедренцев, допустим у нас в городе Орске, нет ни одного нормального франча, который мог бы нормально полностью внедрить хотя бы ЗуП

(49) в Белгороде тоже

(47)Говоришь бы подошла ПУБ, или УТ, внедрение надо начать с причин и нужд, а потом смотреть что Вам необходимо, удовлетворит ли это все восьмерка.
А вообще сетка физически одна будет???
Всегда же можно сделать две базы, и обмен между ними почаще чтобы разгрузить сервера.
Щас работаем на семерке, активных юзеров где то 80, поделили базу на 2 части и все нормал

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

(50)Проблема провинции... Кто головой вырастает выше уезжает в Москву или в областной центр

(52)+1

(52) потом хотелки увеличиваются и все приходит к тому же

Что делать???
Ищем:
1) Команду (это главное), способную решить проблему. В сотрудничестве с вами. В конце концов неважно распределение ролей.
2) ОР, наиболее близкое специфике вашей фирмы
3) Достойный бюджет
4) Желание меняться у ТОпов

(51)У нас 150 активных пользователей, все в одной базе, 1С 7.7. Работает нормал, но - мы задумались о будущем...
Сеток нексколько, практически везде 1Гб, в некоторых местах оптоволокно (видимо между коммутаторами), но точностей не знаю, не сисадмин я. Знаю что сделано максимально хорошо, но если нужно будет - подправим.

>неважно распределение ролей
lol
>наиболее близкое специфике вашей фирмы
я бы сначала просто поискал - где 400 человек работают. потом бы подумал
>Достойный бюджет
ой тяжкое это занятие
>Желание меняться у ТОпов
этого непонял

не надо решать задачу в лоб
надо внимательно смотреть какие пользователи не пересекаются между собой по данным в онлайне

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

(59) Может там у каждого станка по компу.

Бухи сидят отдельно, у станков действительно стоят ПК (но не у всех). В основном рабочие места - это менеджеры по продажам, планируется их увеличить в 3 раза. Отсюда и цифра 400.

(61) менеджеры накладные бьют что ли ?
тогда сделать им небольшую складскую базу с оффлайн-обменом
если менеджеры отчёты смотрют - отвадить их от 1С в конце концов... понаделать им ОЛАП-кубов

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

Интересно другое. А именно как у SAP (48) получается выдерживать десятки тысяч пользователей. Почему в 1С это не получется. Что у них другое (руки)? Вроде такая же трехзвенка. Что нужно сделать чтобы мы у нас получилось?
Попытаюсь начать развивать мысль:
1)Убрать все автоматические блокировки, оставить только управляемые.
2)Придумать потоки обработки информации. Например документы, которые некритичны для загрузки в базу, т.е. если они могут подождать час-другой, обрабатывать в последнюю очередь (так сделано в SAP/R3). Эти обработки реализовывать в фоновых процессах, которые должны крутиться на серверах приложений. Единственная трабла - кто-нить знает как определять степень загружденности? Наверно через счетчики MS SQL? Но тогда непонятно как определять степень загруженности серверов приложений...
3)Что еще?

(62)(63)Этими советами мы сыты, причем находясь еще на 7.7. Именно так все и сделано, а ночью выполняются куча процедур (вплоть до 8 утра).
Хочется сделать нормальную систему.

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

(64) думаю это всё регистры и работа задними числами.

1Ссовские регистры уникальны тем, что позволяют получить остатки на любой момент времени за счёт того что хранят много срезов, из за этого таблицы итогов пухнут
А во всех нормальных системах только один срез - текущий. Ну и заднее число под запретом.

Ну и ещё одна причина - чисто технологическая - это плохо строящиеся индексы по полям GUID

(67)А разве в 8.х не один набор остатков? Честно говоря у меня к вам вопрос, вы здесь даете советы, а вы на 8.0 работали?

(64) а ещё десятки тысяч пользователей - это брехня по большей части
больше 500 пользователей - это уже не "легко и не принуждённо" - а на уникальном оборудовании да и не без тормозов (ну тормоза там на любом количестве пользователей, почти как у нас) :))

(68) не пойму, обидеть меня что ли тут хотят
ну прямо скажу на УПП я не работал, не подошла мне она. Но очень хотелось, по производительности не получилось. Поэтому для меня вопрос больной, потому и учавствую в обсуждении.
Сам работаю с БП и ЗуП

Не хотите советов - не надо

(68) принцип хранения промежуточных итогов со времён 7.7 не именился - итоги хранятся на начало каждого месяца. Это вообще краеугольный камень 1С всех поколений

(70)Обидеть не хочу. Меня самого постоянно пытались обидеть, еле отбился :)
Хочу понять истину. Так как если я выберу 1С 8.1, то буду нести офигенную ответственность. Поэтому хочу все понять, а так как я не работал на 8.1 (только 8.0) хочу получить дельные советы.

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

Из басни:
"А мишенькин совет лишь попусту пропал..."
Из классики юмора:
"Пилите, Шура, пилите.."
От себя:
Творческих успехов

(68) Нет, не один. Промежуточные и актуальные итоги точно также как и в 7.7 еще было. Но в 8.1 все это можно поотключать нах. Можно даже актуальные итоги отключить по выборочным регистрам и вообще одни таблицы движений останутся. Но с ними есть проблема - штатными средствами они плохо индексируются (нет возможности создать составной индекс). Это сказывается не только на производительности, но и очень сильно сказывается на блокировках в автоматическом режиме, поскольку в нем используется уровень изоляции SERIALIZABLE.

>Хочу понять истину
вот только наша истина тебе судя по всеему неподходит

почитал ...

прикольный у вас бюджет 100 - 200 тысяч на прогеров и так далее ...

причем с тем что в голове нету целей вООбще .. цель поиграться в ответственность, а это плохо. плохо для бизнеса собственников.

вам аналитики нужны, которые скажут что то типа: делите учет на в УПП(1С) и на оперативку (писать самим, тысяч за 20 можно найти гения, котрый за полгода напишет на дельфях или в дот.нет).

(71)Ты не прав. Если выбрать дату границы итогов равной например 1980 год, то в итоге будет всего один набор записей - Актуальных итогов.

(72) Брать на себя ответственность за внедрение системы учета в России нельзя никогда... При любом раскладе будешь виновным.

ЗЫ Брать можно только так - взял откат и уволился...

(75) Есть способ создать составные и вообще любые индесы - просто создавайте их (прямыми запросами к SQL). 1С 8.1 вполне лояльно относиться к чужим индексам. Удаляет их только если меняется структура таблицы.

(75)Я же написал в (64) - используем только управляемые блокировки.

Продолжаем развивать идеи, новый пункт:
3)Использовать собственные индексы (особеннно составные - так как в 1С нет инструмента их создания)
4)Что еще?

(76)Истина она одна, от вас я хочу собрать информацию, чтобы вместе с вами ее найти.

(81) Еще отключение актуальных итогов в подавляющем большинстве регистров. Или вообще во всех - при нормальных индексах, имхо, должно летать и без них

(83)А как это делается? я что то не нашел...

(84) Флажка в конфигураторе нет, к сожалению)) Есть метод у менеджера регистров, не помню точно - глянь в СП

(83)Кстати вы тут ошибаетесь, представьте 10 млн записей движений. В то время как в таблице актуальных итогов их порядка 10 тысяч. Таким образом в вашем случае в среднем нужно в 1000 раз больше времени чтобы получить остаток

(0) Попытаюсь объяснить, почему ветка курьёзная:
Автор сабжа хочет понять, брать ли ему ответственность за проект, при этом разговаривая о вещах, которые к проекту автоматизации на 400 пользователей отношения НА ЕГО УРОВНЕ (как руководителя проекта) не имеют. Какие-то автоматические блокировки, принципы хранения итогов, потоки...
РП такого проекта будет 80% времени проводить на бесконечных заседаниях, работать с проектной документацией, бюджетами, отчётностью, будет решать проблемы с кадрами, выстаривать политически правильные отношения с топами и т.д. и т.п.
Вы за ЭТО берёте ответственность. Вы ЭТО готовы/хотите делать? Хватает ли политического веса? Достаточно ли ресурсов? Достаточно ли дома запасов вазелина?
А вы - про технические нюансы..

(87) Абсолютно точно. Я слежу за веткой и вообще не понимаю, пробьет ли автора на здравый смысл.

(86) Ты говоришь о ситуации, когда для получения итога необходимо выполнить полный перебор движений, при использовании индекса это будет совсем не так. Кроме того, я, конечно, не силен в вопросах касающихся работы SQL Server, пусть меня поправят более знающие люди, например masky, но сильно подозреваю, что при увеличении количества чтений, общее время выполнение запроса вовсе не обязательно вырастет пропорционально.
Не говоря уже о том, что для целого ряда регистров актуальные итоги в принципе не нужны, потому как запросы к ним на актуальный момент времени ну очень редки. Регистры бухгалтерии в УПП это типичный пример.

>пусть меня поправят более знающие люди
Дима, лучше жевать, чем говорить

(87) ну а с другой стороны - стоит ли вообще начинать дело если заранее будет известно, что при такой нагрузке вообще ничего работать не будет

он всё правильно делает - сначала надо разведать техническую возможность

(87)Может быть вы правы, а может и нет. Но я привык держать все под контролем, каждый винтик в системе. Пока мне хочется понять какую систему выбрать 1с,SAP или еще что-то.
Цель данной ветки - обменятся мнениями взлетит ли 1С 8.1 (в частности УПП) вообще, т.е. теретически, при выполнении всех технических нюансов пунктов 64,81.

(91)>сначала надо разведать техническую возможность
на этом форуме он этого не узнает

(89)Ты видимо путаешь со временем доступа к одной записи (в случае если она проиндексирована). Да действительно, если записей миллион или миллиард скорость доступа особенно не изменяется (если у мы осуществляем бинарный поиск, то в первом случае доступ будет осуществлен за 20 циклов, а во втором за 30 - т.е. замедление только в 1,5). Но это применительно именно к одной записи, к 10 записям нужно 10 раз обращаться. К 1000 - 1000 раз. В то время как таблица движения растет, таблица актуальных итогов практически нет...

(93) а на каком узнает ?

(93)Не согласен, здесь есть и технически подкованные люди.

(93) а ни на каком. помоему таких внедрений вообще нету.
http://www.sql.ru/forum/actualthread.aspx?tid=456428&pg=1&hl=&#4448173

Рассудим логически. Предположим, есть сомнения в возможности комфортной работы под УПП на таком количестве активных юзеров. Тогда вперед под САП и решаем вопросы по (87). Ищем отраслевое решение и партнера.
Мне непонятно стремление изобретать велосипед, т.е. писать средствами платформы управленческое решение. Я подчеркиваю - управленческое. Неважно средствами какой платформы- САПом, 8.1 или Билли Гейтсом.
А автор обсуждает индексы, итоги и пр. Вспомнилась опять одна басня. Стесняюсь процитировать, чтобы не обидеть.

(97)Очень интересная ссылка, буду изучать

Очень интересная ссылка, буду изучать

(100)http://atlantgroup.ru/protucts/8/texnoplat/7.php

(98) т.е. только из-за наличия СОМНЕНИЙ в возможности Вы предлагаете выбрать решение в 10 раз дороже, и даже отказываете в праве исследовать вопрос ?

Кроме того зачем писать решение - автор наоборот склонен использовать типовую. И зачем здесь подчёркивать "управленческое". Фишка как раз в том, что автор хочет окучить и фискальную бухгалтерию в той же базе

(101) Несмотря на заявления, что "смоделированная нагрузка на систему значительно превышает нагрузку, которая наблюдается в реальных условиях" позволю себе усомнится в этом.
Во-первых, там есть интересная строчка:
"Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам"
Во-вторых, там всего-то проводится документ Реализация товаров и услуг в оперативном режиме.
Что станет с производительностью при наличии существенного количества перепроведений уже существующих документов в том же тесте? Я вам скажу что - в типовой реализации УПП все просто загнется. Проверено на гораздо меньшем количестве пользователей.
Что станет с производительностью когда будут выполняться регламентные действия по закрытию месяца?
Короче, это тест для базы оперативной работы менеджеров по продажам и не более того.

+103 причем когда КАЖДЫЙ менеджер торгует СВОИМ товаром и товары не пересекаются

Вывод - тест является полной наё.кой лохов - типа смотрите как круто у нас...
В реалиях все абсолютно другое....

УППырище в том виде, в каком оно есть - не взлетит...
Для этого оно должно быть за ХХХХ человеко-лет переписано.
По цене выйдет - тоже самое дорогое решение, которое будет СРАЗУ.

(103) Смотри (61). Это именно то что нужно.
(104) Ну если с разных складов торгуют, то блокировок не будет, даже если номенклатура одна и та же.

(100) вначале провести нагрузочное тестирование в одной конфигурации - сравнить время выполнения каждой операции (есть конфигурация 1С:ТестЦентр 1.0 ), затем разрезать конфигурацию  при помощи периферийных узлов РБД на 2, потом на 3 и т.д части - настроить автообмен через оптимально выверенный промежуток времени( или/и COM(ADO,OLE),WEB-сервисы если нужно что-нить в онлайн режиме получать)  и в итоге в каждой базе сидит не 400 активных  пользователей, а по 400/количество разрезов при помощи РБД

LOL

(107) автоматизировал таким подобным образом крупную компанию в России

+ ко всему если удаленные офисы имеются можно настроить репликацию

(1)
Система взлетит. Конечно при грамотном устранении узких мест. Мощности железа достаточно.

Главное, что придется сделать, программно оптимизировать множество модулей.
Но, раз вы запускаетесь на 140 пользователей то проблему сможете решать постепенно.
У вас будет расти профессионализм и знание системы, вы будете последовательно выявлять и устранять узкие места. За 1 год можно подняться со 140 до 400, и не слушайте всяких умников. Если есть желание, все у вас получится. Вы же не собираетесь сидеть сложа руки и ныть про "тормоза".

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

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

Все будет зависеть от уровня ваших специалистов.

(1)
В качестве примера, берем стандартную процедуру переноса данных из УТ в БП.
переносим товарное движение, приход расход + все сопутствующие данные, номенклатуру, контрагентов и т.д.

скорость работы при выборе периода в 1 месяц -- 6 часов выгрузки + 6 часов загрузки.

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

результат  -- выгрузка 30 минут + загрузка 40 минут.

Настройка стандартной процедуры заняла 2 дня. Написание собственной 3 дня.

Короче, наш девиз: "Каждому менеджеру по своему складу и каждому пользователю по своей базе!"

>Пишем свою процедуру
и так со всем остальным?

(110) - верно. НО
- временные и финансовые затраты приведут к тому же результату, что и "хорошая дорогая мощная" система. ГДЕ ЭКОНОМИЯ?
- потери при таком внедрении рассчитать просто невозможно...


(106) делить базу на мелкие и трахаться, трахаться, трахаться...
Держать штат объединителей-админов, копировщиков, эникейщиков и т.д.

(114) +
Еще подносчики вазелина понадобятся. И менеджеры по его оптовым закупкам))

У него всего одно узкое место - это интенсивная отгрузка
только и делов-то что взять, копированием сделать свой док "реализация", который будет не универсален, но быстр
Распределение по партиям, выделение авансов - ночью. (ну и что что как в 7.7 - весь мир так работает)

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

Если уж упоминать всуе западные альтернативы - то почему сразу САП.
Наверно Аксапту надо смотреть...

+(111)выгрузка изменений 30 000 документов проводится средствами РБД 2 минуты с небольшим , загрузка небольше 7 минут - это грамотно настроенный РБД и автообмен )))

+(117) стандартный чуть модифицированный документ "Поступление товаров и услуг " в УТ(в УПП пораздутей чуть документ)

+(117) - это количество документов филиала за полмесяца(дней за 10 иногда)

(104)В нашей текущей базе 7.7, где сидят 150 пользователей мы полностью удалили все блокировки 1С и сиквела, т.е. перевели на уровень изоляции READ UNCOMMITTED. Естетственно чтобы итоги правильно считались ввели собственные - логические. Поставили счетчики для контроля времени ожидания блокировок. Ну так вот все 150 пользователей за день находятся в режиме ожидания 30-40 сек, при максимальном времени одной блокировки 0,5 сек. А мертвых блокировок нет вообще - результат правильно составленного алгоритма.

(120) жесть.  а ведь менеджер блокировок в сиквеле 10 лет разрабатывала мощнейшая корпорация. а тут на тебе.

отложил ссылку в закладки, надо будет почитать

(121) ну при чём тут это. В 7.7 это единственный выход, т.к. иначе одновременно документы проводиться вообще не могут

единственное - раз у них всё уже так здорово, то психологически перейти на УПП будет очень сложно

(121)>ну при чём тут это
а при том, что от 1С там остался интерфейс да хреновая структура таблиц.

(121)Требование о наличии собственного интеллекта еще никто не отменял - пусть они хоть 100 лет что-то пишут :)

(125) т.е, 1С и Микрософт должны убить себя "апстену"?... им уже сообщили?

(126)Кто вам сказал такую глупость?

Кину полторы копейки тоже.
В общем, работал в 7.7. Вернее, писал там участок для коммерческой службы(складской учет, заявки, их отслеживание и все прочее...). Естественно, все это сразу, без всяких там перегрузок, ложялось проводками в бухию. Там было 360 пользователей в 6 городах России. От Москвы до восточной сибири. Техники, конечно, немеряно. Но, главное, работало. Была снесена полностью стандартная конфа.
На 8.1, думаю, возможности такой реализации гораздо выше. Мне кажется, технические вопросы можно отодвинуть не на первый план. То есть их, конечно, стоит исследовать. Но они решаемы, очень даже неплохо, при правильной идеологии. Тем более, чем-то таким, на 7.7 пришлось заниматься, судя по некоторым ответам автора.
Дальше. По поводу УПП, очень сильно сомневаюсь. Верно было подмечено, что разработчики не очень то сильно на оптимизацией работают. Их девиз - Работает на трех записях и ладно.
Поначалу меня удивляло желание автора с уровня руководителя проекта вникать в какие то там нюансы, типа, индексов и прочего. Но, если заряжаться на серьезную работу, то, возможно, так и стоит. Чтобы потом быть в курсе идей, возможно, влияющих на производительность системы. Я, как правило, придерживаюсь такой стратегии. Конечно, чтобы поднимать такой проект, нужно очень хорошо разбираться в учете. Или иметь сильного постановщика-интегратора, который на ТЫ с бухгалтерией и с программистами. А это не очень частое явление. И, боже упаси, это отдавать на откуп франчам.
Дальше. SAP - это, на мой взгляд, по соотношению цена-качество не идет ни в какие ворота. Делали, знаем. За те бабки которые уйдут на внедрение "счастливого будущего" на SAP, можно приличную, грамотную команду содержать для нормального проекта.
И еще. Все же, думаю, для начала взять БП. Там для бухии, практически, есть все.  И дописывать, пока идет внедрение этого модуля. По крайней мере, я бы так поступил, на месте автора.

Изучение ссылок дало больше оптимистичности. Посему продолжу выкладывание идей, что нужно будет сделать с УПП, чтобы она быстро заработала:
4)Написать свои правила RLS, нежели те которые стоят в УПП. Основная идея - не должно быть обращения к таблицам. Нужно понимать что запросы которые пишутся в RLS услвовиях добавляются во все запросы к базе данным по этому объекту. И поэтому лучше сделать не так как в УПП, а сделать проверку по фиксированному списку, который находится в параметрах сеанса пользователя (он в свою очередь заполняется при запуске системы). Метод мною проверен в свое время на 8.0 - торомзов не дает вообще.