Прусаков Никита | Про 1С

🚀 Как провести документ и не «повесить» интерфейс Серфил тут по одной конфигурации и наткнулся на интересный подход, которого раньше не встречал: проведение документа из формы запускается как длительная операция. ⏱️ В чём проблема? Полагаю, все знают, что документ, который проводится 20 секунд и дольше, — не самый удачный сценарий. Особенно в веб-клиенте, где требования к времени отклика выше, чем в тонком клиенте. Если серверный вызов выполняется слишком долго, соединение клиента с информационной базой может быть разорвано. В рекомендациях 1С приводятся примерно такие значения: • около 20 секунд — для большинства браузеров и веб-серверов; • около 8 секунд — для некоторых браузеров. Поэтому серверные вызовы, которые могут выполняться дольше 8 секунд, рекомендуется запускать асинхронно — через фоновое задание. А для конфигураций, работающих в модели сервиса через веб-клиент, требования ещё строже: отклик должен укладываться примерно в 2–3 секунды. ⚙️ И вот как это решили в конфигурации В форме документа стандартное проведение заменили запуском длительной операции. Документ проводится в фоне, а после завершения операции форма получает результат и обновляется. 🛠 Получается примерно такая схема: 1️⃣ Переопределяем стандартные команды формы: Записать, Провести и Провести и закрыть. 2️⃣ При выполнении команд Провести или Провести и закрыть сериализуем объект документа в двоичные данные и помещаем их во временное хранилище. 3️⃣ Передаём адрес временного хранилища в фоновое задание. Там восстанавливаем объект из двоичных данных и проводим его. 4️⃣ После завершения фонового задания возвращаем результат на клиент и при необходимости обновляем или закрываем форму. ✅ Что получаем в итоге? Пользователь не смотрит на зависший экран и может заняться чем-то ещё, пока документ проводится. ⚠️ Конечно, есть нюансы: нужно обработать ошибки проведения, защититься от повторного нажатия команды и правильно обновить состояние формы после завершения операции. Сам документ от этого быстрее проводиться не станет. Но для пользователя, особенно в веб-клиенте, работа будет выглядеть гораздо приятнее. До этого фоновые операции я обычно встречал в обработках и отчётах, при заполнении табличных частей, а вот проведение документа в фоне из формы увидел впервые. А вы встречали такой подход?

Несколько часов на поиски проблемы, или почему нужно знать базу Потребовалось реализовать задачу связанную с редактированием одного объекта справочника внутри карточки другого справочника. Предыстория для понимания, в конфигурации есть справочник «Внутренние документы», в котором хранятся разные виды документов: служебные записки, приказы, заявки, договоры и так далее. Для договоров понадобилось добавить большой набор реквизитов пояснительной записки. Добавлять все эти поля непосредственно во «Внутренние документы» не хотелось: для большинства видов документов они никогда не используются. Поэтому пояснительную записку решил хранить в отдельном справочнике, а во внутреннем документе — только ссылку на неё. При этом для пользователя всё должно выглядеть максимально прозрачно: открывается карточка внутреннего документа и реквизиты пояснительной записки заполняются прямо в этой карточке. У пользователя должно складываться ощущение, что работа происходит только с карточкой внутреннего документа. В справочник ВнутренниеДокументы добавляем реквизит: ПояснительнаяЗаписка, тип СправочникСсылка.ПояснительныеЗаписки На форму внутреннего документа добавляем реквизит формы: ПояснительнаяЗапискаОбъект, тип СправочникОбъект.ПояснительныеЗаписки После этого на форме внутреннего документа можно размещать его поля: ПояснительнаяЗапискаОбъект.Обоснование и т д. При создании нового элемента внутреннего документа создаём объект пояснительной записки и заранее формируем для него ссылку: ПояснительнаяЗапискаОбъект = Справочники.ПояснительныеЗаписки.СоздатьЭлемент(); ПояснительнаяЗапискаСсылка = Справочники.ПояснительныеЗаписки.ПолучитьСсылку( Новый УникальныйИдентификатор()); ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового( ПояснительнаяЗапискаСсылка); Объект.ПояснительнаяЗаписка = ПояснительнаяЗапискаСсылка; ЗначениеВРеквизитФормы( ПояснительнаяЗапискаОбъект, "ПояснительнаяЗапискаОбъект"); Таким образом, во внутреннем документе будет хранится ссылка на будущий элемент справочника, хотя сама пояснительная записка ещё не записана. Перед записью внутреннего документа преобразуем реквизит формы обратно в прикладной объект: ПояснительнаяЗапискаОбъект = РеквизитФормыВЗначение( "ПояснительнаяЗапискаОбъект", Тип("СправочникОбъект.ПояснительныеЗаписки")); Затем передаём полученный объект в ПриЗаписиНаСервере через параметры записи: ПараметрыЗаписи.Вставить( "ПояснительнаяЗапискаОбъект", ПояснительнаяЗапискаОбъект); А в ПриЗаписиНаСервере записываем пояснительную записку: ПояснительнаяЗапискаОбъект.Записать(); ЗначениеВРеквизитФормы( ПояснительнаяЗапискаОбъект, "ПояснительнаяЗапискаОбъект"); Обратное преобразование после записи нужно, чтобы пользователь мог продолжить редактирование и повторно записать карточку. Далее как раз возникает проблема. После записи оказывается, что в реквизите "Пояснительная записка" внутреннего документа лежит битая ссылка. При этом элемент справочника успешно записан, но ссылка у него почему-то оказалась другая, а не та которую указали в методе: ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового(ПояснительнаяЗапискаСсылка); Почему же так произошло ? Все дело в одной особенности работы платформы, а именно: При переносе объекта в данные формы платформой, или при вызове методов ЗначениеВДанныеФормы(), ЗначениеВРеквизитФормы(), переносятся только данные объекта. Внутренние состояние объекта в данные формы не переносится. Например, значение ссылки нового, которая установлена в объект методом УстановитьСсылкуНового(), будет утеряна в процессе преобразования объекта в данные формы и обратно. Упрощённо ПередЗаписьюНаСервере должен выглядеть так: &НаСервере Процедура ПередЗаписьюНаСервере( Отказ, ТекущийОбъект, ПараметрыЗаписи) ПояснительнаяЗапискаОбъект = РеквизитФормыВЗначение( "ПояснительнаяЗапискаОбъект", Тип("СправочникОбъект.ПояснительныеЗаписки")); Если ПояснительнаяЗапискаОбъект.ЭтоНовый() Тогда ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового( ТекущийОбъект.ПояснительнаяЗаписка); КонецЕсли; ПараметрыЗаписи.Вставить( "ПояснительнаяЗапискаОбъект", ПояснительнаяЗапискаОбъект); КонецПроцедуры Такие особенности платформы нередко встречаются в процессе разработки. А с какими особенностями при разработке сталкивались вы? Поделитесь своими примерами в комментариях.

Новое видео на канале. В этом видео проверяем, насколько далеко продвинулись нейросети в разработке на 1С. ИИ написал обработку 1С за 25 минут: Cursor Composer 2.5 Fast без MCP. 📱 - YouTube 🌐 - Rutube 📱 - VK Видео Я специально усложнил задачу: без GPT, без Opus, без топовых моделей, без MCP-серверов по метаданным, синтаксису и документации. Только Cursor Composer 2.5 Fast, простые Project Rules и подробная спецификация. Задача — с нуля разработать внешнюю обработку для 1С:Бухгалтерии, которая загружает данные из Excel и создает документы «Поступление товаров и услуг». Что получилось в итоге: — модель сама создала внешнюю обработку; — корректно собрала XML; — сделала форму; — вынесла бизнес-логику в модуль объекта; — прочитала Excel; — создала и провела документы; — исправляла ошибки по ходу работы; — даже нашла и использовала типовые механизмы конфигурации. Отдельно покажу, почему качественная спецификация решает очень многое, и почему «просто напиши мне обработку» — это почти всегда плохой выбор. Видео записано практически в live-режиме: без ручной правки кода, только постановка задачи, ошибки и доработки через нейросеть.

📣 Новая серия вебинаров «Разбор задач с экзамена 1С:Эксперт»! ➡️ На developer.1c.ru в разделе «Обучение» мы начали публиковать серию вебинаров «Разбор практических задач с экзамена 1С:Эксперт по технологическим вопросам». Всего выйдет 6 обучающих видео. Разбираем решение задач из практической части экзамена: 🔸 Проблема потребления оперативной памяти 🔸 Взаимоблокировка на управляемых блокировках 🔸 Таймаут на управляемых блокировках 🔸 Длительный запрос 🔸 Типичные ошибки сдающих 💡 Короткие, но насыщенные уроки — максимум практики для будущих 1С:Экспертов! ✅ Сейчас на developer.1c.ru доступно первое видео из этой серии! Его тема «Проблема потребления оперативной памяти».

Статистика может устаревать. Когда происходит массовая вставка данных, при загрузках, массовом вводе документов. Статистику нужно регулярно обновлять. Это может происходить несколькими способами: - Вручную, когда выполняем команду UPDATE STATISTICS. Может быть как FULLSCAN, так и SAMPLE (частично) - Второй вариант – делаем перестроение индекса (REBUILD). Вместе с этим соответствующая статистика помечается как устаревшая, и затем обновляется. - Чтобы сделать жизнь проще, в MS SQL добавили настройку под названием AUTO_UPDATE_STATISTICS. А чтобы жизнь стала совсем сладкой, также добавили параметр AUTO_UPDATE_STATISTICS_ASYNC, т.е обновление статистики асинхронно. SQL Server отслеживает количество изменений строк (вставок, удалений, обновлений) с момента последнего обновления статистики и сравнивает его с порогом. Когда порог превышен, статистика помечается как устаревшая. Далее запускается процесс асинхронного пересчета статистики. На практике это выглядит так: запустили запрос - система увидела, что статистика устарела, запустила процесс обновления статистики по таблице, при этом запрос продолжает выполняться. И как раз тут мы попадаем в ловушку ожидания на таком типе блокировки как LCK_M_SCH_M / LCK_M_SCH_S, связанные с попыткой получить блокировки модификации схемы Sch-M / Sch-S. LCK_M_SCH_M - Будет возникать у служебной сессии ms sql, которая запустила пересчет статистики. Запрос компилируется и выполняется с существующей, возможно устаревшей статистикой, а обновление статистики уходит в фоновую сессию. Эта сессия будет пересчитывать статистику, и затем обновлять сам объект статистики, чтобы другие запросы могли пользоваться обновленной статистикой. Но, блокировка на этот объект статистики будет держаться до тех пор, пока не закончится выполняться наш основной запрос (тот самый неоптимальный и долгий). И только после того как долгий и неоптимальный запрос выполнится, объект статистики подменится на новый, и блокировка будет снята. Только вот есть еще один ключевой нюанс, пока выполнение долгого запроса не завершится, статистика обновлена быть не может. И все другие сессии, которые заходят воспользоваться этим объектом статистики, буду ждать в очереди с типом ожидания LCK_M_SCH_S. Они как бы хотят прочитать, что там в этой статистике, а сервер им говорит подождите в данный момент статистика обновляется. Таким образом может скопиться очень длинный паровоз из других сессий, которые ожидают возможности прочитать эту статистику. Весьма непрозрачная история. Отчет, который выполняется без транзакции с NOLOCK, все равно может вызвать ожидания. Этот сценарий характерен именно для включенного AUTO_UPDATE_STATISTICS_ASYNC. При синхронном обновлении статистики проблема проявляется иначе: запрос ждёт обновления статистики перед компиляцией и выполнением, компиляция запроса не начнется, пока не завершится обновление статистики. Только после этого запустится компиляция запроса. А вы ловили такие ожидания у себя в практике ?

Можно ли словить блокировки при формировании отчета на MS SQL в 8.3 в режиме управляемых блокировках ? Как думаете? Напомню, что в 8.3 в режиме управляемых блокировок режим изоляции транзакций - Read Committed Snapshot Isolation (RCSI), а значит при чтении в транзакции S-блокировки на чтение не накладываются, а используется версионность строк, оператор чтения видит подтвержденные данные на момент начала выполнения этого оператора. При этом отчеты выполняющиеся вне транзакции (ни разу не видел, чтобы отчеты в транзакции формировали), в режиме NOLOCK, т.е. с грязным чтением. Они по определению сами игнорируют наложенные блокировки и никого не ждут – одновременно не накладывают собственных S-блокировок и никого не могут подвесить. Так, вот представим, что у вас есть большой отчет который формируется достаточно долго и читает много данных из-за неоптимального запроса без использования индексов. Одновременно с этим, пользователи формируют другие отчеты, и ожидают их выполнения одну, две, три минуты. Хотя раньше отчеты формировались за секунды. В чем же может быть проблема? Для дальнейшего понимания, необходимо развернуть и пояснить такое понятие как "Статистика". Наверное, многие знают, что запросы в MS/PG формируются декларативно. Мы пишем инструкции, что нам нужно, а сервер СУБД сам строит план запроса, выбирает физические операторы для выполнения. Этим процессом напрямую мы управлять не можем, но можем исправлять запросы так, чтобы запросы использовали индексы и в итоге читали только то, что нужно. Когда СУБД строит план запроса, ей нужно сделать какие-то решения. Например, каким образом проводить соединение таблиц. Есть три способа: -  Nested loops – вложенные циклы; -  Hash Match - соединение хэшированием; -  Merge Join - соединение слиянием; У каждого из этих способов есть сильные и слабые стороны. Одни операторы лучше подходят для обработки больших объемов данных, когда значительное количество строк участвует и с левой, и с правой стороны соединения. Но за это приходится платить повышенным потреблением ресурсов, особенно оперативной памяти. Другие, наоборот, эффективны на небольших выборках: они работают быстро и экономно, но при росте объема данных могут резко терять производительность. Поэтому выбор подходящего оператора соединения — нетривиальная задача. От этого выбора напрямую зависит, насколько эффективно будет выполняться запрос. Какую же проблему решает статистика? Чтобы планировщик смог выбрать правильный план, планировщику необходимо понимать сколько строк есть в таблицах. Именно для этой цели нужна статистика. Статистика - это специальный объект в базе данных, который можно найти в дереве таблицы базы данных. Статистика хранит не сами данные таблицы, а сведения для оценки кардинальности: заголовок, гистограмму распределения значений. Гистограмма строится по первому ключевому столбцу статистики и состоит максимум из 200 шагов, и показывает, сколько строк попадает в каждый интервал. Без статистики планировщик не смог бы понимать сколько строк есть в таблицах и не выбирал бы оптимальный план запроса. Всё бы хорошо, но, как говорится, есть нюанс. Продолжение в следующем посте.