Про типичный паттерн, который помогает решать задачи по производительности в 1С.

Оптимизировали как-то мы обмен (как начало сказки звучит 😁). Вообще, началось не с обмена, а с “иногда 1С внезапно начинает тормозить”. Посмотрели журнал регистрации, выполнение регламентных и фоновых - увидели, что обмен идёт.

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

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

Второй подозреваемый - количество выгружаемых данных. Здесь важно понимать паттерн - он часто помогает при оптимизации даже типовых 1Сных решений. Паттерн такой: разработчик почти всегда тестирует на ограниченных данных и в идеальной среде (если не было задачи именно оптимизированный алгоритм написать). Если он пишет обмен, то проверяет на 1-2-10 объектах. И на идеальной среде - в которой нет никого, кроме него. Если разрабатывает планирование, то для 2-3 заказов. И там, где он один. И т.д.

Вообще, это всё ежу понятно. Но когда дело доходит до проблем с производительностью, то почему-то паттерн этот часто забывается. Забывание выражается в том, что все исходят из предпосылки “там всё правильно сделано”. А это не всегда так. Оно сделано правильно, но для небольшого объёма данных и для среды, где нет пользователей и другой нагрузки.

Вот и в нашем случае, первые мысли были - переписать весь обмен. Вообще уйти от XML и правил, написать сервис. Потом немного одумались, вспомнили паттерн, и пошли проверять файл с сообщением обмена.

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

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

https://t.me/another1C

Конечность силы воли (из серии «математика воли»)

Главное, фундаментальное, что я узнал о силе воли — она конечна, то есть умеет убывать, заканчиваться. Как деньги в кошельке, физические силы, заряд в батарее смартфона.

В любой момент времени — сейчас, например — у вас есть определённый запас силы воли. Которого лично вам хватит на выполнение каких‑то действий — дочитать этот текст, сходить почистить зубы, не съесть на ночь тортика, почитать книгу, сделать уроки. А на какие‑то действия этого запаса не хватит — тогда вы не дочитаете текст, не почистите зубы, съедите тортик (а то и два), отложите книгу, оставите уроки на завтра (или на «вдруг не спросят») и пойдёте в интернет.

Из всех аналогий наиболее близкой мне всегда казалась мана — запас магической энергии в компьютерных играх. Помните? Обычно есть красная колбочка — это здоровье, оно убывает, когда от кого‑то получаешь. И синяя — мана, запас энергии. Он убывает, если колдовать. Потом восстанавливается — или сам (если не тратить), или если зелья восстановления пить.

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

Наверное, вы уже поняли мою мысль. Теперь осталось принять.

Телеграм

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

Всё, что пишу — рациональный взгляд со стороны старого докладчика. Я ездил на конференции Инфостарта с 2015 года.

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

Соответственно, у выступлений на конференциях Инфостарта была высокая конверсия.
Выступить тогда на Инфостарте — всё равно, что попасть на Первый канал в 90-е. Тебя увидят и услышат все. И на выступлении всё не закончится — оно продолжится на сайте Инфостарта, так как сообщество и конференции синергично связаны.

Сейчас Инфостарт перестал быть главной тусовкой, а стал одной из. Возможно, на данный момент — самой крупной. Но точно не единственной. Дальше — простая неумолимая математика. Твой доклад увидит столько же людей, что и 10 лет назад — столько, сколько придёт в зал. Даже при битком набитом зале будет несколько сотен человек.
Если выложить своё выступление в блог или видеоканал — получишь больше просмотров, при несопоставимо более низких затратах.

Инфостарт тоже выкладывает видео выступлений, и раньше это было существенным преимуществом — во времена, когда у 1Сников не было блогов. Но сейчас это преимущество растаяло.

Ну и третья часть конверсии — в узнаваемость в сообществе, то есть на сайте Инфостарта.
Она нивелировалась вслед за развитием других тусовок 1Сников — блогов, сообществ, конференций.

Вот такая математика. Из‑за неё каждый раз и собираюсь больше не ехать.

Но всё равно еду :)

Если смотреть с точки зрения участника, а не докладчика — конференции Инфостарта действительно с каждым годом становятся лучше, удобнее, организованнее, интереснее.
Команда Инфостарта растёт в профессиональном плане, это очевидно. С учётом их опыта, частоты и количества проведённых конференций — они точно лучшие по части их организации (в среде 1С).

Для тех, кто не выступает — конференции Инфостарта очень хороши. Это действительно так.

Для начинающих же докладчиков конференции Инфостарта — по‑прежнему лучшая точка старта, на мой взгляд.

Главным образом — из‑за масштаба конференции, который позволяет набирать в программу довольно много новичков.
Другие конференции вмещают в себя в разы, а то и в десятки раз меньше докладов/активностей, поэтому новичкам туда не пробиться — организаторы стараются пригласить каких‑нибудь мэтров, иначе никто на их конференцию просто не приедет.

А у Инфостарта продуктовая линейка докладчиков сейчас хорошо разделена. Есть хэдлайнеры и конкурсный отбор, через который прогоняют и новичков, и докладчиков с опытом (это некое «среднее звено»). Через конкурсный отбор точно можно пройти. И точно можно не пройти, даже будучи докладчиком с опытом (я однажды не прошёл 😂).

Короче, кто хочет попробовать себя в роли докладчика — вам точно на Инфостарт.
Кто хочет посмотреть/послушать/поучаствовать — вам точно на Инфостарт.
Кто старый прагматик, как я — тому дома на диване сидеть 😊.

Телеграм

Один хороший человек, зовут Руслан, в своём тг‑канале написал небольшой текст про мой «Универсальный механизм планирования» (УМП). Руслану можно верить — он несколько раз внедрял УМП. На практике знает, насколько сложно решать реальные задачи планирования в 1С.

Думаю, опубликовать его текст будет уместным. Тем более, что УМП я распространяю бесплатно (прям здесь). Кстати, Руслан когда‑то тоже скачал УМП бесплатно, внедрил, и только через несколько лет я об этом узнал:)

Итак, текст Руслана.

«Как же долго я тебя искал…»

Знакомьтесь — УМП, универсальный механизм планирования. Когда я впервые про него узнал, радости было ещё больше, чем от автозадач.

Почему? Потому что он умеет делать главное, что должно уметь любое планирование — распределять ограниченные ресурсы (деньги, товары, время работы оборудования и так далее) на потребности (планы оплат, заказы клиентов, планы производства…). И, что важнее всего, делать это гибко, по любым условиям.

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

Пример из практики
Производственное предприятие, которое работает в основном под заказ. Главный вопрос от менеджеров:

«Сможем ли сделать и отгрузить к нужной дате?»

В 90% случаев ответ упирается в одно — наличие сырья. А тут всё сложно:

• ассортимент продукции большой

• сырьё может лежать на складе

• а может быть «в пути» от поставщика

Посчитать это в типовой ERP — задачка не из простых. И тут на сцену выходит УМП.

Что мы сделали

1. Разузловали спецификации готовой продукции до конечных материалов и храним их в специальном регистре — это ускоряет расчёт.

2. В УМП распределили материалы на складе и «материалы в пути» (с учётом даты поступления и времени, необходимом на изготовление продукции) на заказы покупателей.

3. Каждый заказ получил статус:

• обеспечен

• обеспечен частично

• не обеспечен

4. В отчёте видно какого именно сырья не хватает и под какие изделия.

5. В журнале заказов добавили светофор, чтобы статус был виден сразу.

6. В АРМ «Формирование заказов по потребностям» диспетчер видит этот же статус и понимает — включать заказ в производство или нет.

В итоге

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

В следующей части расскажу про автоматизацию планирования в производстве.

Про отличия обучения зумеров. Ещё раз акцентирую внимание — текст не содержит оценочных суждений, не ищите тут скрытого смысла «зумеры плохие» или «с зумерами что‑то не так». Каждое поколение отличается от предыдущих. Бэби‑бумеры тоже много написали бы про особенности обучения миллениалов, но у них не было интернета.

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

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

Надо нарезать помельче весь контент и все шаги, которые надо в обучении делать.
Видео — короткие. Обучающие задачи — тоже. Предметная или техническая область, которую надо изучить при решении задачи — одна, максимум две.
Тогда норм будет.

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

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

Телеграм

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

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

Это немного непривычно для руководителя, который раньше с зумерами не работал. Они очень неконфликтные. Настолько неконфликтные, что с ними сложно разговаривать, если тема или тон разговора хоть немного попахивают агрессией, критикой и так далее
Зумер не защищается, не оправдывается, не спорит — он просто замолкает («замри»). И думает лишь о том, чтобы неприятный для него разговор побыстрее закончился («беги»).

С этим надо научиться жить. Если использовать старые методы, давление, критику и так далее — любую агрессию — зумеры будут уходить. Причём, молча, ничего не объясняя ни в процессе, ни после.

Так что, если не можете получить от зумера какой‑то прямой понятный ответ о его работе — это нормально. Ну, для него, по крайней мере.

Телеграм

На одном из проектов перехода с УПП на ЕРП возник неожиданный субподрядчик, который добавил приключений и нам, и заказчику.

Заказчик работает с сетями, а где сети — там какой‑нибудь хитровыдуманный электронный документооборот.

В основе — просто модуль/обработка, написанная какой‑нибудь известной компанией, но обязательно — доработанная на месте под требования сети.

И вроде бы — что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля — открыт, доработки под сеть — известны. Что может пойти не так?

Первое, что пошло не так — разработчики модуля сказали, что ни нам, ни заказчику нельзя его дорабатывать. А кто там его доработал несколько лет назад для УПП — уже никто и не помнит. Ну, ладно, хозяин‑барин — нельзя так нельзя. Спрашиваем — так, а можете нашему заказчику‑то доработать? Хотя, чего нашему — он и ваш заказчик.

Можем, говорят, только в очередь вставайте. Дело было в ноябре, месяца за полтора до запуска. Ладно, очередь так очередь. Встали, где‑то на декабрь.

В декабре ребята честно что‑то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать. В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают. Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.

Пишем ребятам, и оказывается... Тех.поддержка не работает (в первые дни каникул).
А заказчику уже отгружать надо — сети, они такие. Там нельзя не отгрузить.
Что делать? Или самим‑таки доработать (но разработчики ЭДО грозили штрафами), или из УПП отгрузки делать. Выбрали второе — сели несчастные люди и вбили реализации в УПП, просто чтобы выгрузить в ЭДО.

Через пару дней начала работать тех.поддержка, но вот незадача... Они ничем не могли помочь с нашим доработанным модулем. Потому что помочь может только разработчик, который с их стороны модули допиливал. А он — на законных каникулах до 12 января. И связаться с ним нельзя никак и ни за какие деньги. А документации он никакой не передал, тех.поддержке ничего не объяснил, поэтому помочь они ничем не могут.

Тут у заказчика вторая волна отгрузок в сеть — ну, что поделать... Пришлось опять из УПП выгружать.

По окончании каникул подрядчик, конечно, всё быстренько починил.
Претензий нет, если что. Просто не знал, что так бывает :)
Теперь знаю. Придётся учитывать этот риск в следующих проектах.

Телеграм

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

Проблема была такая. Есть КА1, в ней — дофигищща чеков. В чеке есть цена продажи, но нет себестоимости. Можно получать какую‑то себестоимость, если включить оценку стоимости списания при проведении документа (фифо, средняя), но это замедлит проведение документов (а их очень много).

К тому же, себестоимость не будет актуальной — документы поступления, как положено, вводятся с опозданием. Соответственно, чтобы актуализировать с/с по чекам, надо или документы перепроводить (а их, напомню, слишком много), или расчёт себестоимости ежедневно или ежечасно делать (не вариант).

У клиента уже было своё технико‑методическое решение — считать себестоимостью цену последнего закупа номенклатуры.

Но тут две проблемы. Если определять цену при проведении чека, то получаем обозначенную выше проблему — поступления вводят с опозданием, поэтому с/с при проведении чека не будет актуальной. Если же брать с/с не при проведении чека, а на лету, отчётом, то тормозит и запрос неприятный получается — кто писал запросы получения среза последних на дату документа, знает, о чём речь.

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

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

Хорошая штука эти интервальные регистры. Рекомендую.

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

В основном такие переходы - вынужденные, вроде отказа от УПП.
Заказчику всё нравится в его УПП, но так уж вышло, что её больше не поддерживают, и придётся переходить.
Поэтому хочется всё сделать с минимальными затратами. Это один из ключевых критериев.

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

На данный момент мы сделали 6 таких проектов:

1. Два перехода УПП - ЕРП;

2. Два перехода УПП - КА2;

3. Один переход УНФ - КА2;

4. Один переход УПП - Аренда (там БП внутри).

Ещё два проекта в процессе, их рано включать в статистику.

Средний чек проекта - 1274 часа.

https://t.me/another1C

P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.

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

Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.

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

Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.

А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/

Расширение можно скачать в тг-канале: t.me/another1C

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

В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 1С для обновления, без существенных потерь для бизнеса.
В нашем случае окно было размером в 40 часов.

Вообще, это не так уж и мало, но... Надо было обновить на 4 редакции - с УТ 11.4.14 до 11.5.22.
Кто помнит обновление на 11.5.8, в котором появились распределение запасов и объекты расчетов, понимают - там время обновления измерялось, скорее сутками.
Обращаю внимание - надо было обновить все 4 редакции в одно окно 40 часов.
Так сильно дешевле, чем накатывать по одному релизу и запускать пользователей. Причём, дешевле в разных всех смыслах - не надо адаптировать конфигурацию под каждый релиз (можно это сделать один раз в конце), не надо мучить людей (заставляя переживать 4 обновления, 4 смены некоторых интерфейсов и механизмов).

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

Короче, надо было сжать 300 часов времени обновления в 40, т.е. в 7-8 раз.

Ну и чё... Получилось 😁

Применили нестандартные методы предварительной подготовки конфигурации и данных, оптимизацию обработчиков, обрезку данных - и оно зашуршало сильно быстрее.
Модных режимов, вроде обновления через копию, не применяли. Никакого вмешательства в СУБД не было. ИИ не использовали :)

Как-нибудь соберусь, напишу статью - там есть, что рассказать.

https://t.me/another1C

Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.

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

Правда, дашборды типа "отчёт" (о которых речь в видео) - не самое эффектное представление данных, есть ещё диаграммы. Но про них я отдельное видео сниму.

А пока вот:

https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc

Расширение можно скачать тут - https://t.me/another1C/48

Выложил новую версию расширения "Рабочий стол" - подрихтовал интерфейс. Он был старый, т.к. создавался под толстого клиента - см. картинку. Теперь выглядит почти как типовой 1Сный интерфейс.

Также снял видео-знакомство с простейшими функциями рабочего стола (для тех, кто раньше не видел это расширение)
https://youtu.be/-SMc-Q2EOiw
https://vkvideo.ru/video-208482299_456239487

Скачать решение можно в тг-канале https://t.me/another1C

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

Тут две ветки получается - обновление внутри одной редакции и переход между редакциями.
Если говорить про семейство ЕРП - т.е. ЕРП, ЕРПУХ, КА2 и УТ11 - то переход между редакциями там случается раз в год.

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

Сам технический процесс обновления с расширениями проходит быстрее, т.к. в этом процессе сравниваются конфигурации (основная, старая и новая от поставщика), а не расширения.
Возня с расширениями начинается, собственно, после привычного процесса обновления. Как в шутку коверкали в нулевые название технологии Plug and Play ("подключи и играй") от Windows - Plug and Pray ("подключи и молись"). Так же и с расширениями.
Если повезёт - всё будет работать без вмешательства. Если чуть меньше, но всё-таки повезёт - вывалятся красные ошибки в расширениях, и их нужно будет исправить. Если не повезёт, красных ошибок не будет, но в процессе эксплуатации выяснится, что доработки расширения молча творят какую-то дичь.

Ну а обновления с переходом между редакциями обходятся в 5-10 раз дороже, если основная часть доработок выполнена через расширения.
Разумеется, речь о большом количестве доработок. А то вдруг в системе 5 доработок, из которых 3 - в расширениях :)

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

Ну а все типовые процедуры, изменённые в расширении с инструкциями Вместо и ИзменениеИКонтроль, приходится почти вручную адаптировать под новый релиз. Буквально пересобирать заново - брать новый текст типовой процедуры и вручную помещать туда старые изменения.

Собственно, поэтому и дороже.

https://t.me/another1C

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

Обработка подсчитывает:

1. Количество модулей и строк в них;

2. Количество модулей с изменениями;

3. Количество процедур и функций, разбитое по категориям - новые, изменённые с инструкциями ИзменениеИКонтроль, Вместо, Перед/После;

4. Количество строк в процедурах каждой категории;

5. Для ИзменениеИКонтроль подсчитывает количество изменений и количество строк в этих изменениях.

Как пользоваться:

1. Выгружаем расширение в файлы (можно несколько расширений выгрузить и скопировать в одну папку);

2. Запускаем обработку, указываем папку с выгруженным расширением;

3. Жмём "Посчитать".

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

Но понять, сколько изменений содержится в расширении, крайне затруднительно. В платформе 1С инструменты оценки изменённости есть только для конфигураций.

Обработка тут - https://t.me/another1C/148

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

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

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.

Так вот, попробовал я взять этот обработчик обновления, вынести код в обработку/расширение, самостоятельно распараллелить и запустить. Код там простой, изолированный, никаких зависимостей ни до ни после его выполнения я не нашёл.

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

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

В современных, вроде ЕРП, УМП вполне себе работает. У одного клиента с 2021 г. всё обеспечение продаж и многопередельного производства на УМП держится.

Скачать расширение можно в тг-канале - https://t.me/another1C/130

Описание решения - vk.com/@ivan.belokamentsev-universalnyi-mehanizm-planirovaniya-ump

Снял пару видео по своим разработкам "Автозадачи" и "Структура затрат". Они без видео не очень понятны, обычно. Особенно Автозадачи - чтобы получать от них пользу, надо понять логику и принципы применения.

А пользы от автозадач можно получить очень много, особенно если народу в 1С работает много, процессы сложные и запутанные, и свободы выбора у людей - чересчур.

Итак, видео по автозадачам:

https://vk.com/video-208482299_456239480, оно же https://youtu.be/4Z6Z3tZTVKM

Видео по структуре затрат:

https://vk.com/video-208482299_456239481, оно же https://youtu.be/4Z6Z3tZTVKM

Сами решения (эти и остальные) можно скачать в тг-канале: https://t.me/another1C

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

Само решение можно скачать в моём тг-канале https://t.me/another1C

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

Итак, видео.

Первое - совсем простые примеры: https://vk.com/video-208482299_456239478

Второе - чутка посложнее, но всё равно просто: https://vk.com/video-208482299_456239479

В обоих видео показаны примеры использования без навыков программирования.

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

Вообще, выложенное решение - для старых конфигураций, вроде УПП, УТ 10.3 и т.д. Но если не лень - можете и в ЕРП вставлять. У меня есть расширение, причешу и тоже выложу.

Детальное описание решения есть тут - https://infostart.ru/marketplace/690271/
Там же можете стоимость заценить :)

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

Внимание! Внедрить эту штуку можно только с участием программиста! Там надо запросы писать и отчёты делать.
Это несложно, просто предупреждаю, чтобы у вас ожиданий неоправданных не было.

Берите и пользуйтесь. Файл лежит в тг-канале - https://t.me/another1C/92