1С *

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

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

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

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

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

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

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

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

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

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

https://t.me/another1C

Попалась на глаза статья (https://infostart.ru/1c/articles/2636935/#5. В чем плюсы использования интервальных регистров) на Инфостарте, про интервальные регистры сведений в ЗУПе.
Вспомнил, что недавно использовал эту ЗУПовскую идею для совершенно другой задачи - интервального хранения цен.
Но цель использования интервальных РС - та же, оптимизация скорости выполнения запросов и удобства их написания.

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

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

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

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

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

https://t.me/ywhite

Обновлю статистику по недорогим переходам. Это формат проектов такой, специальный - перейти с одной конфигурации 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

Весенние вакансии в SSP SOFT: Ждем резюме

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошедший 2025 год мы наняли 179 новых сотрудников. По размеру компании — мы «средний бизнес» с проектами федерального уровня.

Рабочие места у нас в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в департамент разработчики в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Горячие вакансии марта (переадресация, дождитесь загрузки вакансии):
1️⃣ Разработчик DWH
2️⃣ Data Аналитик
3️⃣ Технический писатель
4️⃣ Разработчик 1С
(на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

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

В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 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

Правило второго раза

Привет, Хабр!

Когда-то давно мастерил я СложнуюФункцию. Делал сам - в модулях не нашёл ничего похожего. А как доделал – подумал: можно ведь её универсальной сделать, чтоб потом удобно применять.

И сразу сомнения приходят: а вдруг больше никогда в жизни эта Сложная не потребуется – ни мне, ни коллегам. Как это понять? Стоит ли делать инструмент?

Тогда я не знал ответа. А позже у меня в ЗапасникеПравил появилось одно на эту тему. Назвал я его Правилом второго раза.

Если сомневаешься, надо ли превращать разработку в Инструмент или Продукт – просто сохрани её, но не трать время на доработку. Жди второго раза.
А вот если она второй раз попалась – потрать время и сделай.

Конечно, бывают исключения. Иногда по причине «если нельзя, но очень хочется – то можно» - делаю сразу. А иногда интуитивное «потребуется» перевесит. Бывает и наоборот: нет времени, и не делаю после второго раза.

Но в большинстве случаев работает это правило.

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

В сезоне INFOSTART AWARDS 2025 мы обновили механику выбора победителей - добавили этап экспертного голосования. Цель простая: объединить оценку сообщества Инфостарта с независимым взглядом со стороны рынка, чтобы отмечать не только популярные материалы, но и решения, которые реально работают в бизнесе.

Процесс идёт в два этапа.

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

Затем в дело вступает экспертное жюри INFOSTART AWARDS 2025 - ИТ-директора, технические руководители и лидеры цифровых трансформаций из крупных компаний разных отраслей. Они голосуют за номинантов из шорт-листа, и победителями становятся авторы и решения с наибольшей поддержкой экспертов.

Почему это важно? В жюри - люди, которые ежедневно отвечают за внедрения, масштабирование и устойчивую работу ИТ-систем. Они оценивают подходы не по описанию, а с точки зрения того, что реально работает: с учётом рисков, практического эффекта и жизнеспособности.

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

Полный список экспертов жюри и представление каждого — в статье на сайте.

Церемония награждения пройдёт офлайн на INFOSTART TEAM EVENT 2026 в Москве.

Налоговая отчётность в 1С: почему не стоит менять?

Привет, Хабр!

Стали мне часто попадаться доработки налоговой отчётности.

Я всегда категорически против таких доработок. Мне отвечают: уже всё согласовано. Не отстаю, назойливо предлагаю отказаться от таких доработок. К сожалению, не всегда выходит.
Почему же нельзя дорабатывать отчётность?

1. Отчётность - это часть конфигурации, которая обновляется чаще всего. Каждое ваше исправление - это потеря денег при каждом обновлении (адаптация).

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

3. Ваша «точечная» правка может незаметно сломать смежные расчёты в других разделах или за другие периоды.

Что же делать?

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

2. Внимательно изучите типовое решение. Скорее всего, там есть настройки или правила игры, учитывающие ваш случай. Например, меня неоднократно просили добавить справочник «Филиалы» для заполнения декларации по прибыли. Решение: во всех типовых конфигурациях для учёта филиалов используется справочник «Организации».

3. Если правок в декларацию немного, и их можно без существенных трудозатрат сделать руками – следует оставить типовой вариант.

4. .Если есть такая возможность - внесите правки после заполнения декларации отдельным апгоритмом.

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

ВАЖНО: типовые возможности должны быть сохранены и для пользователя.

Например, если добавляем кнопку заполнения книги покупок, должна быть добавлена кнопка «Заполнить книгу (ООО «Ромашка»)», а типовая кнопка должна остаться в первозданном и рабочем состоянии.

Это позволит:

• быстро вернуться к типовому варианту

• проверить работоспособность типового варианта

• сравнить доработанный вариант с типовым

• и ещё это спасительная возможность заполнить декларацию, если доработанный вариант перестал работать после обновления.

Всем удачи и лёгких обновлений!

1С:Документооборот = ВРМ? Как получить максимум от 1С:Документооборот

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

19 февраля в 11:00 (МСК) мы проводим открытый вебинар, на котором разберем практический подход к использованию 1С:Документооборот не только как системы электронного документооборота, но и как инструмента управления процессами согласования и исполнения.

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

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

Кому будет полезно? Вебинар ориентирован на ИТ-директоров, руководителей по 1С, операционных и финансовых руководителей, а также специалистов, участвующих в автоматизации и сопровождении корпоративных процессов.

Участие бесплатное, требуется предварительная регистрация.
Регистрация по ссылке!

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

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

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

А пока вот:

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

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

Привет, Хабр!

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

Сначала главные причины:

• Критичные изменения (смена руководства и т.д.)

• Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени

• Неконтролируемая волна хотелок (НВХ)

• Неготовность к изменениям - внутренним и внешним

• Неправильный выбор подрядчика, чрезмерное доверие или недоверие.

Ещё причины, вытекающие из основных

• Непредоставление информации Заказчиком.

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

• Отсутствие технического планирования (железо)

• Чрезмерно сжатые сроки

• Не хватает денег

• Неотлаженные бизнес-процессы

• Проблемы с данными

Также нашёл и такие "причины", о них в статье планирую специальный комментарий:
Внедрение без обследования
Отсутствие или изменение целей
Неправильно выбранная проектная методология
Незаинтересованность руководства Заказчика

Буду благодарен всем, пополнившим коллекцию.

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

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

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

Кейс, в котором облако получается в 3 раза выгоднее железа

💼 Что за компания

Девелоперская компания «Люди» строит жилые комплексы в Тюменской и Свердловской областях.

🕵️ Задача

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

У компании было три варианта: строить свой ЦОД, арендовать выделенный сервер у провайдера или размещать все в публичном облаке. По расчетам самым эффективным оказался третий вариант, поэтому начался поиск подходящего облачного провайдера, которым в итоге стал Cloud.ru.

👨‍💻 Решение

Знакомство ДК «Люди» с нами началось с теста, во время которого стало понятно, что сервисы и поддержка, которые мы предлагаем, закрывают все задачи и ожидания клиента.

В итоге девелопер разместил виртуальные машины и настроил резервное копирование на платформе Облако VMware, а объектное хранилище подключил на платформе Cloud.ru Advanced. Потом связал две эти облачные платформы, чтобы весь трафик находился внутри защищенного облачного периметра.

📈 Результаты и планы

Базы данных 1С, CRM-система на базе Битрикс24, почтовые сервисы, системы ВКС и видеонаблюдения, СКУД — все переместилось в облако за два месяца. При этом после миграции производительность 1С выросла в 1,5 раза. Этому способствовали три фактора:

1. Перенос баз из Windows и MS SQL на Linux и PostgreSQL.

2. Подключение высокочастотных процессоров (CPU).

3. Рост скорости выполнения параллельных операций в облаке.

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

Все подробности по кейсу здесь

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

Тут две ветки получается - обновление внутри одной редакции и переход между редакциями.
Если говорить про семейство ЕРП - т.е. ЕРП, ЕРПУХ, КА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

Новогодний дайджест с подарками 1С.

Вашему вниманию предлагается 1С - подборка для ваших баз - для новогоднего настроения и проведения праздников.

С наступающим праздником новогодними поздравлениями и открытками поздравляет Инфостарт.

Чем можете отблагодарить? Пройдите новогодний опрос для сообщества и посмотрите ответы.

Для любителей 1С и классики игр будет интересен и такой сюрприз.

Кому надо просто отвлечься - есть и небольшие игры для 1С:

• Идём на обгон - для пользователей ERP

• Змейка

• Для тех, кто не отступает

• Матрёшка для квестеров

• Экстремальное развлечение

Для практического применения в офисе и не только - тайный Санта

И не забудьте поздравить детей по списку

Надеюсь, вы найдете полезный подарок.

Всех с наступающим! Счастливого праздника!

Инфостарт перезапустил «Большой опрос 1С-сообщества» — ежегодное исследование, которое помогает понять, как за несколько лет меняются роли, инструменты и реальные практики вокруг 1С.

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

Проект стартовал в 2022 году, тогда в исследовании поучаствовали 10 672 специалиста. В 2023 — 7 887. Опрос 2024 года сознательно не проводили: команда пересобрала методологию и формат, чтобы результаты разных лет можно было сравнивать корректно, без эффекта «вроде похоже, но непонятно, что именно изменилось».

В версии 2025 года обновили саму анкету: уточнили формулировки, расширили варианты ответов и добавили блок про использование ИИ-инструментов в разработке и работе с 1С — от повседневных задач до более сложных сценариев. А главное — после заполнения участник сразу получает доступ к интерактивной аналитике и может сравнивать данные за 2022, 2023 и 2025 годы.

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

Заполнение занимает примерно 5–10 минут, после отправки анкеты система автоматически перенаправит на страницу с результатами. Сбор ответов идёт до конца января 2026 года, возможно продление до конца февраля, после чего исследование за этот цикл будет закрыто.

Как закрывать месяц в 1С не за час, а за 20 минут — история производителя тахографов

💼 Что за компания

«Новые решения драйва» (НРД) работает на рынке транспортной автоматизации. Компания производит и продает тахографы — устройства, которые регистрируют скорость, пробег, режим труда и отдыха водителя.

В каждом грузовом автомобиле массой выше 3,5 тонн и автобусе должен быть тахограф — так требует закон. Например, если водитель попадет в спорную ситуацию, данные с тахографа помогут доказать, что он работал не дольше, чем положено, и ехал не быстрее, чем разрешено.

🕵️ Задача

Раньше IT-инфраструктура НРД была построена по модели SaaS на базе ресурсов облачного провайдера. Но компания решила развивать собственную инфраструктуру, чтобы предложить новый вид сервиса для клиентов, партнеров и внутренних заказчиков. 

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

Так решение строить собственную IT-инфраструктуру стало проектом года. Отдельно обсуждали вопрос о том, где эта инфраструктура будет размещена: локально на своих серверах или в дата-центре провайдера, которого тоже решили сменить.

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

Первый тендер выиграли мы: клиент развернул тестовые контуры у нескольких провайдеров, но только у нас коэффициент производительности 1С:ERP и других продуктов вырос с 0,475 до 0,725 — спасибо процессорам с частотой 3,0 и 3,5 Ггц. Второй тендер выиграл IT-интегратор «Протон» — он умеет проводить аудит инфраструктуры, строить новую и мигрировать программные решения в облако.

👨‍💻 Решение

Миграция в облако длилась три месяца и, грубо говоря, в четыре этапа:

Команда «Протона» проанализировала текущую инфраструктуру НРД и начала строить новую на платформе Облако VMware от Cloud.ru. Тестирование, уточнение деталей и настройка заняли месяц.

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

Перенесли в облако боевые базы данных, внедрили в новую инфраструктуру учетную систему 1C:ERP, 1С:ЗУП и 1С:Бухгалтерия.

Настроили два корпоративных VPN-сервера для удаленного доступа к новой инфраструктуре. Сотрудники НРД сказали, что работать дома после этого стало гораздо комфортнее.

Когда закончилась активная фаза переноса, специалисты «Протон» продолжили заниматься технической поддержкой инфраструктуры, а команда НРД перешла к планомерной работе, доработке и донастройке всех систем.

📈 Результаты

Системы мониторинга, контроллер доменов, приложения 1С, сервер удаленных рабочих мест и другие технические серверы перенесены в виртуальный ЦОД в облаке Cloud.ru. Что ощутимо изменилось, это то, что ускорилось формирование отчетности в 1C:ERP и документооборот:

• список регламентных операций открывается за 7 секунд вместо 30;

• отчеты из раздела «Функции для технического специалиста» составляются за 7–8 секунд вместо 20;

• месяц теперь закрывается за 20 минут, а не за час, как раньше.

Если тоже раздумываете о переносе 1С в облако, обращайтесь, у нас большой опыт такой миграции.