ERP. Время закрытия месяца. #789696

Прошу пнуть в нужном направлении. Имеется старая европейская система. Месяц закрывается 2.5 часа. Всех устраивает. Перешли на 1С ERP. Новый сервер. База, в которой к настоящему моменту около 10 закрытых месяцев. Проведен полный тюнинг нашим интегратором с нашими системными администраторами. Никаких виртуальных машин, отключенный антивирус и т.п. Windows Server 2012, SQL Server 2014. По тестам Гилева все хорошо. Загрузка сервера не значительная. Сервер-мечта. Сетка гигабит. У всех пользователей i5-ый компьютеры. Пользователей реальных всего не больше 7. Плюс раз в месяц льется информация по выпускам/потреблениям и т.п. Закрытие месяца полное идет 7 часов. Процедура закрытия месяца стандартная. Впринципе все дописки делались сбоку. Я спрашиваю у интегратора - он мне говорит, что на моей объеме документов это нормально. Мы обычное предприятие легкой промышленности. Мы не Мотовилихинские заводы. 7 часов Карл! 7! Куда плыть? Есть такой раздел на сайте 1С - вводишь количество документов, количество товаров, количество операций и т.п. и получаешь за сколько должно считаться? Если считается дольше, то оставляешь заявку и выезжает личный аварийный комиссар из 1С. :) Спасибо!

Дополню. На ERP только бухгалтерский учет. Плюс выпуски/потребления/производственные перемещения/спецификации разумеется льются раз в месяц из старой европейской системы.

42 миллиона долларов, и к Вам будет приезжать полк личных аварийных комиссаров.

Ну да ну да. И волшебник в толерантном вертолете. :)

В болото

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

Ну если хоть скромный бюджет есть, обратитесь к Гилеву. Я бы еще с ехидной улыбкой попросил "интегратора" оценить: какое нужно железо, чтобы закрывалось за 2.5 часа. Если что-то родит, можем посмеяться вместе.

Можно параметры сервера мечты?

>На ERP только бухгалтерский учет >На ERP только бухгалтерский учет >На ERP только бухгалтерский учет >На ERP только бухгалтерский учет >На ERP только бухгалтерский учет

и о каком объёме документообороте идёт речь?

какой релиз ?

Всякое может быть. Может у вас в каком то регистре остатков - есть запись от нулевого года. Позовите специалиста.

Обобщено. Два процессора. В каждом по 8 ядер. Частота не менее 2.2 ГГц. Памяти 128. Жестких дисков более десяти SAS 15K. Точно скажу только завтра. Последние расклады по распределению файлов между дисками скажу только завтра. Там интегратор с админами колдовал. Объем документооборота - трудно сказать. Спросите меня конкретно - количество  того - количество сего Все скажу.

На сервере абсолютно никаких процессов, кроме как одна единственная база данных ERP нет.

в 2.2 переписали методику закрытия месяца -- ускорилии

Хм. Поговорю с интегратором. Они собирались нас переводить. А как этого специалита искать? У меня из вариантов только Гилев. Я списывался с их компанией по другому проекту. Ребята реагируют быстро. Правда потом мне переиграли задачу и поработать не удалось. Просто реально ли это профиль Гилева? Он знает 7 часов или не 7 у меня должно считаться? По тесту Гилева у меня все было впорядке по словам интегратора. Интегратор говорит так и должно быть и быстрее никак не достигнуть. Я говорил, что готов купить железа если надо.

автор, сколько документов в базе за месяц ?

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

запрос к журналу реестр торговых документом

Я зашел в журнал документов регламентированного учета. Отфильтровал декабрь. Скинул в Excel. 8371 документ.

детский

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

В том то и дело. Мы обычная компания средней руки. Продаем изделия легкой промышленности. Они у нас не обладают каждое своим уникальным номером чтобы генерировать безумное количество строк или серий. Да, у нас есть документы производственного учета, распределения затрат и т.п. Но ничего сверхъестественного у нас нет. Конфигурация практически не трогалась. Это было обязательное условие интегратору. Пусть нам будет напряг для пользователей, но обновляться все должно максимально легко. За год 79000 документов. По сути получается в базе впринципе 80 тыс документов.

Первую половину я понял. А что читать-то?

Мда, интегратор интегрировал-интегрировал... Самое время тут появиться спецу по ERP и предложить свои услуги удаленной диагностики.

Я могу потыкать в базу палкой, если вы дадите мне базу с данными. Но вы же не дадите :-)

Да, у нас тут и правда отдел компьютерной безопасности просто так никого не подпустит. Поэтому мне впринципе хотелось понять две вещи. 1. За сколько должно считаться у нас? 2. Есть ли смысл обращаться к Гилеву или это не его профиль? 3. Есть ли смысл в п.1 и п.2? Насколько я понимаю нашего интегратора - все это бестолку. "Это ж ERP. С ним у всех так. На Вашем объеме документов 7 часов - это нормально."

Забавно так интегрировали, что закрываетесь весь рабочий день.

Смысл к Гилеву обращаться есть, я думаю. Сам с ними не сталкивался, но почитывал их требования к кандидатам. Они (требования) - годные. Вопрос в цене :-)

сколько у вас закрывается месяц в ERP?

п.3 - ну, может и получится немного меньше, но это же ERP.

1. Столько, сколько требуется бизнесу. Кому-то годно и за 2 выходных, другим и 30 минут много. Проблемы-то у вас какие? Ну считает 7 часов и что? Закрыли период пользователям. Поставили перед уходом домой закрытие... 2. от 35 до 100к вам аудит. надобность вытекает из п.1. Бизнесу это надо? Как вариант, арендовать у них сервер на пару дней и протестировать эту операцию. Если целевые показатели сильно будут отличаться, то значит или сервер не тянет или "тюнинг" сервераОС1ссубд неудачный

Что именно включается в понятие "закрытие месяца"? Все операции в закрытии месяца? Если да, то отражение документов в регл. учете вполне может занимать озвученное время. В нашем случае отражение занимало 20+ часов, пока не отключили сброс отражения в регл. учете всех документов, которые затронул расчет себестоимости. В последних версиях разработчики вроде бы нас услышали и оптимизировали сброс отражения в регл. учете, но я не проверял. Если речь про формирование движений по партиям и расчет себестоимости, то это очень много. В нашем случае эта операция занимала около 30 минут на в 2-3 раза бОльшем количестве документов. З.Ы. Таки зовите специалиста :)

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

Запускали пересчет сутра. Зам. главного бухгалтера. В течении дня видела если ошибки - исправляла их или организовывала исправление и опять запускала. И т.д. Но обнаружилось, что пока считается закрытие есть проблемы с построением некоторых отчетов и получается, что теперь запуск можно делать только в 2 часа дня. Все ошибки в рабочий день не получится выгребать и надо в вечернее/ночное время поглядывать что там происходит по удаленке. Мы выгребли это полностью в старой системе. И категорически не хотим возвращаться к ночным бдениям. 21-ый век на дворе и мы готовы платить. Если месяц будет закрываться даже за три часа - это будет для нас приемлемым. Всего-то в два раза быстрее чем то, как закрывается сейчас. Дольше всего идет формирование движений по партиям. Будь оно неладным. В прошлой системе не было такого понятия даже. Вот как раз 6 часов из 7-ми уходит.

Вбщем_спам_фильтру_привет я так понимаю действительно нужно звать специалистов. Завтра буду звонить на gilev.ru. Самое главное я уяснил, что надежда есть. Спасибо. Постараюсь отписаться по результату!

Чего все орут, караул!!!... гилев-гилев-гилев? Свет в окошке! "мы готовы платить..." Привыкли тупо смотреть на проблему чисто технически. Эко дело 7 часов. А вы видели закрытие по три дня? Причем, не дай бох, что-то случится за это время, даже под конец 3-го дня. Не всегда дело только в технике. Пересмотрите капитально аналитику и методику учета. Такое может позволить увеличить скорость в десятки раз. И еще, в последних версиях, если мне память не изменяет, регистры движений прилично поменяли. Возможно, это повлияет и на скорость расчета.

для начала смотри журнал регистрации, событие Расчет партий и себестоимости.Протокол расчета

Что мешает сделать распределенную базу и весь расчет проводить в периферийной? А параллельно работать в главной.

в ерп нет распределенки

ты ж программист, сделай полный план обмена))

Честно говоря, 7 часов не так уж много. Вполне можно принять регламент закрытия, выделить на это дело один день. Либо выходной, в который выходят ответственные люди и проводят расчет, либо просто рабочий день, в течение которого не вносят первичку. Конечно, 7 часов можно оптимизировать, как заплатив бабки Гилеву, чтобы они переписали закрытиие, так и купив сервер пошустрее (ну кто вам сказал, что 2,2 ГГц и САС диски - это сервер мечта?) но вот стоит ли игра свеч?

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

Все ошибки в учете нужно исправлять ДО распределения партий и расчета себестоимости, а никак не после. Мы для удобства отключали автоматическое выполнение последующих операций в закрытии месяца. Скинь логи ЖР по закрытию месяца: во сколько началось, сколько каждый этап выполнялся, во сколько закончилось.

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

Смотрите учет. Железо тут не причем. Самая лажа случается со "встречным выпуском". Нам в начале внедрения помогло разделение выпускаемой номенклатуры по характеристикам. Нужно анализировать маршруты выпуска.

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

у нас на УПП крупное производственное предприятие, РАУЗ, ведутся спецификации, расчет себ. около 2 часов.

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

да,  есть такое. поэтому по-любому приходится раза 2-3 пересчитывать. Расчет себестоимости = 7 часов это НЕ нормально!

Новый круг по старым граблям. На УПП ускорил в 4 раза, для этого помог анализ базы старшим опытным товарищем. Но там был РАУЗ.

с УПП без РАУЗ лучше и не связываться.

ну я тоже видал долбодятлов, которые крутили базу на персоналке с 4 ГГц Коркой, потом переходили на серверное железо с дофигаядерными 2 ГГц Ксеонами за сотни нефти и недоумевали, почему же у них медленнее стало всё. Речь не о них.

Действительно ли частота работы процессора оказывает такой эффект? 1С хреново распределяет?

Частота ядер оказывает большой эффект. SQL сервер нормально процы использует, а вот 1с сервер хреново паралелит. Поэтому лучше было бы в 2 раза меньше ядер но по 4 ГГц.

Это не проблема 1С. Ну на сколько нитей можно распараллелить выполнение типичного запроса? Ну 2-3. Да и то, они ж не будут одинаковые, то есть фактическое ускорение будет в лучшем случае в 1,5 раза. Но дело то не в этом, а в том что в корке тоже не одно ядро, и для 7 пользователей больше 4 ядер задействовать вряд ли удастся. А ведь помимо линейной скорости одного процессорного ядра, на такую числодробилку как закрытие месяца, большое влияние окажет скорость обмена памяти с кешем процессора и скорость загрузки данных с дисковой подсистемы в эту самую память. И что-то мне подсказывает, что у сервера-мечты с САС дисками это все тоже на уровне 2000х годов находится. Впрочем это все не отменяет того простого факта, что если заменой железа можно сократить время с 7 часов до 5, то заменой кода можно время сократить и до часа а то и дальше.

...Два процессора. В каждом по 8 ядер. Частота не менее 2.2 ГГц... сам на свой вопрос ответил

плюсую У нас по УТ 11 два по 3.20GHz 4 шт SSD Intel SATA 2.5" 400Gb S3710 8 шт DDR4-2133MHz 16Gb

просьба к автору в финале отписаться, к чему пришли. Если своих специалистов нет, то перед тем, как менять что-то в сервере, лучше привлечь эксперта, который АРГУМЕНТИРОВАННО скажет, что именно нужно поменять. И оплату в договоре прописывать от результата, чтобы итогом аудита не была фраза "производительность типичная для ЕРП, ничего не поделаешь" :). Фанатам гигагерцев  - MS SQL замечательно распараллеливает громоздкие запросы. По этой причине у нас стоит максимальная степень параллелизма = 6, т.к. есть отчеты , которые успешно утилизируют все доступные ядра сервера на 100%. Фанатам РАУЗ - вот наш расклад: УПП 1.3, в части распределения затрат полностью типовая, партионный учет. База около 300Гб. ведется с 2008г. Около 100 тыс. документов в месяц, из них отчетов производства за смену около 40 тыс. Переходящей незавершенки из месяца в месяц почти нет. уникальных номенклатур выпуска несколько тысяч в месяц. количество переделов от 1 до 8. Расчет с/ст по БУ занимает 5-6 часов. информация приведена, чтобы у автора было понимание, что при грамотном подходе все реально. Начинать нужно с поиска узкого места.

Узким местом является ERP ;)

УПП с РАУЗом основательно вылизана, я запускал на 1000 документов в сутки на отгрузку на скромненьком сервере и с небольшими настройками скуля, с/с считалась около часа.

Текущее поколение конф можно сливать в унитаз, потому что это франкенштейн из тормозных УФ, монструозной БСП, глючных фоновых заданий и платформы (привет всем #tt). Зато стильно модно молодежно, бгг.

А не боишься группы К?

а что там с группой К?

Ты же из франча

Уже нет

Кстати даже если бы и был, то что? Я кого-то наипал щас?

Ну, если уже нет-живи спокойно

да и здесь на форуме критика запрещена, так что сдержаннее нужно быть... Хотя дедушка был прав в свое время "Узок круг этих революционеров. Страшно далеки они от народа". Хотя... Может он и не про отдел разработки это говорил :).

Не Фанатам гигагерцев, как я уже писал в   MS SQL замечательно распараллеливает громоздкие запросы, а вот rphost нет. А при закрытии месяца rphost  очень активно участвует.

Практика показывает, что какой-нибудь i7 с повышенной герцовочкой, уделывает целый шкаф с ксеонами )))

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

Не я про другое. При работе с 1с. Четырех ядерный i7 4GHz, уделает Xeon 8 ядер по 2GHz, там чуть ли не в 2 раза. Лично тестировал. А мощность вроде одинаковая.

Какое месть в ЕРП узкое? :)

+ *место

Фся )))

Спасибо за развернутые советы и информацию. По результатам отпишусь в ветке. А насчет гигагерцев почему я так заинтересовался, потому, что сейчас мы планируем перевод сервера в кластер, либо на другой отдельный более мощный или как минимум такой же мощности сервер и есть еще вариант скорректировать конфигурацию.

перевод сервера куда нибудь - это ответ на вопрос "что делать". Не получив ответ на вопрос "Кто виноват", можно получить вот это:

Кластер вам не поможет. Узкие места в сервере 1С (он же rphost), в дисковой системе, в сети (если сиквел разнесен). Можно попробовать на мощный сервер поставить 1С вместе с сиквелом и настроить шаред мемори.

но вы мало выиграете от железа, курите учет!

да, действительно. Как можно ответить, хреново она распределяет или нет, если она ничего не распределяет