Когда у клиента видел тормоза на базах с управляемым интерфейсом списывал, на то что возможно ещё что крутится. По результатам эксплуатации бухгалтерии 3.0 локально у себя на ноутбуке был вообще огорчён. Ноутбук старенький 2 ядра по 2k и 2k памяти. База демо установка. Тормозит на ровном месте, все задания отключил.  Тормозит рандомно, просто при открытии отчётов, не при формировании, а именно  открытии формы, вообще при кликаньях. При формировании тоже рандомность. Вопрос такой у кого есть опыт эксплуатации не локально, а на хорошем  сервере со скулем.  Управляемый интерфейс и там себя так ведёт? Или всё таки там всё тип топ? Особенно интересно не базы в которые заходят ради сдачи отчётности, а в которых идёт деятельность нонстопом. Например ERP 2.0  полёт нормальный?

(69) тупые одинэснеки не накатывают всё подряд. Хорошая кака(обновление) должно вылежаться. Накатить на тестовой поиграться денёк другой, а уж потом на рабочую. Причины обновления бухии обычно не несёт абстрактного характера. А УТ может и подождать. Люди вообще отказываются от обновлений и живут

(74) Категорически плюсую! В конторах уже от 100  пользователей, БУ и НУ не пустой звук, и позволить себе бардак от глючных обменов и тормозов никто не может. А уж тем более полагаться на криворуких архитекторов типа vde69.

(76) Ты хоть раз сам делал схему обмена между двумя базами?

(74) бедняжка, ты ни разу не автоматизировал холдинги, ни один идиот не держит в одной базе реальный и фискальный учет

(75) У тебя есть сценарии тестирования по всем операциям, которые выполняются на предприятии? Включая закрытие месяца?

(77) Конечно делал, для торгашей в 00-х годах писал кучу обменов УТ->БП, а что?

(78) Я так понимаю ключевое слово "холдинг" прибавляет сразу 7 сантиметров. Не меньше. Даже если это холдинг из трех ларьков.

(78) Бред какой-то. Реальный и есть фискальный. Если не чернушники какие-то.

(81) поржал
от души
пиши ещё

(77) Делал кучу обменов или делал как надо, через стандартные механизмы xml? Да просто не похоже, что ты знаком даже с регистрацией изменений, не то что с конвертацией данных.

(78) Ну куда уж мне до тебя. Видимо последние годы работаю с "идиотами"

(84) вот и говоря - бедняжка

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

(82) да ты сам клоун
(83) "через стандартные механизмы xml" - ЛОЛ, да и через нестандартные тоже, КД юзаю еще с 7-ки, а что сказать-то хотел?

(86) а ты, кроме зачитывание своих бухам ПБУ, чё-то в 1С умеешь ?

(88) Строем еще ходить могу. А Вам слабо?

(86) Обмены вполне допустимы и необходимы по узким участкам, типа  загрузки данных по зарплате или загрузки отчетов по розничным продажам. Там где их можно проверить и пофиксить. Но обмен всего ко всему типа как в УТ - > БП это верный способ иметь секс после каждого обновления и получать звездюлей от бухгалтерии каждый раз после выгрузки.

(90) Согласен.

Чем больше база, тем больше проблем с обменами.
Это закон

(68) Тебе старшие товарищи правильно все говорят.
У больших серьезных контор, с большими нагрузками и оборотами разделение между УУ и БУ по разным кучкам - это правильно, это кавайно.
Сложный обмен  - это не проблема, нужно только руки отрастить из правильного места.

(92) Это закон тобой выдуман?
Опровергаю ваши постулаты.
Яйца в разных корзинах  - это кошерно

(87) Хочу сказать, что где то ты гониш. Или ты не шариш в обменах или не верно твоё утверждении про тормоза с обменами. 1000 пользователей или сколько там у тебя всё летает и всё в одной базе, а обмены мать их за ногу тормозят. Да лажа это. Данные заводим в управленческой базе. В БУ попадают в одно стороннем порядке и все счастливы. Ни каких тормозов. Но тут верно заметили их мало настроить их ещё и мониторить надо, всякое бывает. Можно и в двух стороннем без разницы. На последнем месте центральная база обменивалась с 12-тью филиалами и норм

(95) Еще раз ЛОЛ! Тут недавно MegaKent на опыте Евраза рассказывал про глюки и тормоза с обменами при выгрузке в БП, а также про проблему с распределенкой, в результате они перешли к одной базе. Не веришь мне - почитай его сообщения.

(94) Ты одну большую базу делишь на пицот мелких?

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

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

(99) Так бухгалтера не правят наверно ничего

(100) Бухгалтера не правят??? Это что-то из области фантастики :)))

Карупян, скажи, ты Брегорьян?

(99) У вас вакансий свободных нет? Первой задачей могу вам выделить бух в отдельную базу.

(103) А если проводки нужно формировать не так, как их формирует типовая БП? Будешь перегонять документы в ручные операции? Или передавать и движения (и "подкладывать" проводки под регистраторов)?

(102) Мне кажется что Карупян это Гёдза, не?

А что делается в главной базе если надо вручную отредактировать?

Штрилиц как никогда был близок к провалу )))

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

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

ERP2.1, сервер всего один под скуль и сервер приложений, размер базы 30 Гб, пользователей пока 10, притормаживает.
Процессоры AMD Opteron 6284SE 2.70 GHz.

Ребята, я смотрю, в данной ветке у всех по 22 см)))
Подскажите, если не сложно, по такому нубскому вопросу, который касается больше администрирования: можно ли что-то сделать с зависающими процессами пользователей? У нас у клиента ЕРП2.0 крутится на платформе 8.3.6.2363 к обеду обычно начинаются сильные тормоза из-за зависших сеансов. Админы (и наши, и клиента) расписались в собственном бессилии и заказали дополнительно оперативки. Спросил их по поводу обновления платформы - сказали: рекомендуй, мы обновим. Может в более новых платформах исправлен этот баг? Как вы в у себя победили данное зло?
Заранее спасибо!

(110) Что есть "зависающие процессы пользователей"? Висящие сеансы?

(111) Ага.

(112) Они на производительность не влияют. Но действительно часто висят безхозные. Особенно когда на терминале сессия умирает по времени.

Одноэсовцы что-то писали в исправлениях в релизе движка 8.3.7.1993 относительно "висяков". Но не помню об этой ли ситуации. Сам пока не обновлялся. Почитайте.

(0)
Хороший сервер. Сетка, админы. Такси 8.3.7
Формы практически мгновенно стали открываться.
Не настолько быстро как обычные , но и не тормоза управляемых ранних релизов

(110) [к обеду обычно начинаются сильные тормоза из-за зависших сеансов]
кто ж удумал ERP на 32х разрядной 1С запускать ?

С точки зрения тормознутости новые конфы от 1с на УФ это полный провал. Все убого , тормознуто и глючно.

Но так как альтернатив нет, приходиться работать .

(116)[ Все убого , тормознуто и глючно. ]
ты просто не умеешь их готовить (с)

Удивляюсь как у людей нервов хватает работать с УТ11 и Бух 3.0

(118) смелое заявление, с учётом тотального перехода на БП 3.0 и 50% УТ 11

(119) В количестве ноликов путаться не надо, на УТ11 нормально работает максимум 5 процентов купивших, остальные в недоумении.

(117) Типовые конфы не я готовлю, а 1с.

(115) Верно, сервер - 32-ух разрядный. Но там что-то не получилось с 64-ёх ещё до того, как мне достался этот клиент. Кажется, с оперативкой проблемы возникли.
(114) Какие-нибудь критичные ошибки вылезли на 8.3.7? Рекомендуете переходить?

(122) [Верно, сервер - 32-ух разрядный+ Админы (и наши, и клиента) расписались в собственном бессилии и заказали дополнительно оперативки]
так ты на форум зашёл пофлюдить али как ?

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

(124) поищи, форум, вместе с админами и начальством, с удовольствием на тобой потащиться

(124) решение - взять нормальную железку с приличными параметрами и поднять на ней х64 систему и сервер. Печально, но в данном случае кроилово ведет к попадалову. Проверено.

(110) сколько у вас пользователей?

(124) может ЦУП все таки в помощь?

Надо вот мне клиенту сделать "хорошо"
Но мну страшно ему советовать ут11
Что делать не знаю

(129) посоветуй тис

(130)  возможностей маловато.. Надо идти в ногу со временем.. На новую фирму ставить тис есть извращение

(128) Не пользовался никогда... Где его брать и как юзать?

(132) сколько у вас пользователей erp?

(129) УНФ?

во развели холивар :))

резюмирую:
есть два подхода
1. Фискальный учет вести отдельно от реального и гемороится на обменах
2. все вести в одной базе и гемороится на обновлениях

оба подхода имеют и плюсы и минусы, универсального решения нет! Обычно решение зависит от трех параметров
1. трудоемкость поддержки (банально деньги на прогов)
2. трудоемкость тестирования (это ложится на пользователей)
3. замороченной архитектора (его упертостью и не желанием признавать свои ошибки)

лично для меня предпочтительным является подход при котором фискальный учет остается на 100% типовым не смотря на любые хотелки юзеров, все остальное можно обсуждать....

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

Умение идти на компромисс и критически оценивать собственную позицию, это и есть отличие профа от ламера :)

(134)(129) Кстати да, рекомендовать УНФ.
Хороший легкий вариант, прозрачно и вменяемо дорабатывается.
По структуре метаданных очень похож на УПП 1.3 (КА 1.1). Механика проведения сделана новым способом (контроль остатков после проведения и запросы в модулях менеджеров). Состав документов и варианты учета не сильно слабже, чем в УТ11.
Обмены с БП из коробки традиционно с ошибками, но их можно и поправить.

(135) А если некоторые операции БУ не реализованы в типовой?
Просто проводки рисуем операциями?

(137) не мучь котёнка, он в РСБУ полный ноль и всё сказанное в (135) взято из резюме

(137) Я думаю тут надо более пристально взглянуть на эти операции как правило это от невежества буха все идет.

(139) Например Реализация на 46 счет в строительстве

(140) Отраслевые для этого есть.

(140) ну откуда форуму знать про ПБУ 2/2008 или про лизинг, про авизо даже лучше не заикаться

(137) А что смущает ?  Отразить  на основании первичного документа  хоз.операцию .

(143) а если к ней еще ворох регистров нужен? по ндфл например...

а потом отчетность строить по отраслевой нормативке? а данных в хоз. операции просто нет?

(143) смущает легкость, с которой ты убил учет в УПП или ERP и то, сколько потом нам придётся потратить времени на реанимацию учетной системы

(145) :)  Любой аудит  затребует  ваши доходы и расходы с точки зрения отражения оных на плане счетов . А в части НК вообще трактует ведение учета на ... неких регистрах .

(146) Значит вообще конфа не нужна, делаем все ручными операциями и вся любовь.

(147) А что тебя смущает то ?  приход  и расход    на складе и списание себестоимости  рычными операциями не отразишь ?  Гланое основание оных .

(147) много ты таких внедрил?

(148) В общем то можно но тогда 1с вообще по сути не нужна.

(149) Каких?

(150) Видел небольшие конторы где все ведется ручными операциями . Они отrлоняются от требований регулятора в части ПБУ ?

(152) Речь про УПП и ERP, где все завязано на регистрах.

(152) Ну значит там просто зря потратили деньги на 1с.

(154)  Думаете.. ?  Удобная двойная запись , все отчеты  - карточки счетов, осв  и прочее -  удобно  . Все как регулятор и требует :)

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

(155) 7-ка в этом отношении удобней была, бэст еще есть и т.д.

(157) А что ... 8 ка  как то отличается ?

(158) Она тупо дороже по всем параметрам и неудобней для ведения такого учета.

(155) Феликс с ручкой то же хорош

+(158) :)  Т.е. где то в каких то регистах прошли взаиморасчеты  , а на счете взаиморасчетов они не отражены ? :)

(161) ты только что узнал, что учет в УПП или ERP ведётся на регистрах и план счетов там сбоку - поздравляем

(162) Чую придется Феликсу с ручкой  сверять регистры и ... контировки на плане счетов с боку :)

Инструменты разработчика кто-то пробовал туда впихнуть?
Я к тому что режим разработки надо переключить и использование форм. Ну и желательно разрешить модальность.
После этих махинаций всё там будет работать?

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

тот-же регистр с ГТД в 90% компаний имеет минусовые остатки, что является явным нарушение ведения учета, а все ведь из-за "уникальности ведения учета"....

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

Никто не встречался с тем, что ЕРП нет проверки записи в РН в закрытом периоде если пишутся записи хард кодом минуя проведение доков? Я вот встретился с этим. Приходится изобретать велосипед, чтоб закрыть эту дыру.

(166) бедняжка , придётся тебе самому пару строчек кола написать

(167) попридержи свой сарказм

(166) А какой релиз? Не 2.0 случаем?

(167) и там далеко не 2 строчки кода писать, умник, РН + РС + РБ, ключи аналитики парсить для получение объекта раздела закрытия

(169) 2.1.2.106, но есть стойкая уверенность, что не сделали и в 117м этого

(170) Не пиши проводки в закрытом периоде, какие проблемы?

(171) а это не я пишу, приходят доки, подчиенные тем, что в закрытом периоде и меняют их движения в том периоде:

модуль РаспределениеВзаиморасчетов

Процедура ЗаписатьДвиженияДенежныеСредстваКонтрагент(ДанныеДвижений)

ВыборкаПоДокументам = ДанныеДвижений.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаПоДокументам.Следующий() Цикл
  НаборЗаписей = РегистрыНакопления.ДвиженияДенежныеСредстваКонтрагент.СоздатьНаборЗаписей();
  НаборЗаписей.Отбор.Регистратор.Установить(ВыборкаПоДокументам.Регистратор);
  Выборка = ВыборкаПоДокументам.Выбрать();
  Пока Выборка.Следующий() Цикл
   ЗаполнитьЗначенияСвойств(НаборЗаписей.Добавить(), Выборка);
  КонецЦикла;
  НаборЗаписей.Записать();
КонецЦикла;

КонецПроцедуры


где даты у записей уже другие, вне закрытого периода

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

(136) спсб