В карточке 1С одно значение, в выгрузке другое: кто пишет это поле
Иван Недомолков · Dərc edilib:
Где записывается реквизит 1С, поиск по конфигурации покажет только в пределах её собственного кода. Когда значение в карточке расходится с тем, что уходит в выгрузку, этого часто мало: писателей у поля бывает несколько, и часть из них в основной конфигурации не лежит.
Мы разбираем такие расхождения от данных к коду, правка идёт последней. Числа ниже из одного разбора в базе розничной компании. У товара там две карточки: собственная и карточка поставщика, которая приходит обменом. Булево дополнительное сведение решало, какой из двух артикулов уедет на внешнюю площадку, и в карточке галочка стояла в одном положении, а наружу уходил артикул другого вида.
Почему поиск по конфигурации не показывает, кто записал значение
Поиск по коду отвечает, кто мог бы записать поле. Данные отвечают, кто его уже записал. Когда ответы расходятся, верят данным: записи в регистре есть независимо от того, нашли мы их автора или нет.
Писатель выпадает из поиска, если его код лежит вне основной конфигурации или в другой системе:
- внешняя обработка из справочника дополнительных отчётов и обработок;
- расширение, в том числе регламентное задание из него;
- загрузка через служебный интерфейс;
- ручная правка универсальным инструментом;
- обмен из смежной базы: что выгружают его правила и как объект ищется в приёмнике, видно по разбору файла правил.
Поэтому разбор идёт от подсчёта, а код открывают под конкретный вопрос. Схема целиком:
| Что видите | Что посчитать | Что это доказывает |
|---|---|---|
| Поле массово стоит там, где по смыслу не нужно | записи по типу владельца и значению | поле пишут без отбора по владельцу |
| Значение, которого не ставит ни один найденный писатель | что может записать каждый писатель | есть писатель вне списка |
| Интерфейс показывает одно, выгрузка другое | откуда берёт значение каждый читатель | читатели по-разному понимают, где живёт поле |
| Два запроса дают разное число связанных объектов | одно отношение, посчитанное двумя путями | в базе два разных отношения |
Где лежит значение: распределение по владельцам
Первый запрос считает записи поля по типу владельца и значению. Шаблон ниже рассчитан на дополнительное сведение из стандартной подсистемы “Свойства” и проверен на типовой УТ 11.5.22.67 с БСП 3.1.11.189:
ВЫБРАТЬ
ТИПЗНАЧЕНИЯ(ДопСведения.Объект) КАК ТипВладельца,
ДопСведения.Значение КАК Значение,
КОЛИЧЕСТВО(*) КАК Записей
ИЗ
РегистрСведений.ДополнительныеСведения КАК ДопСведения
ГДЕ
ДопСведения.Свойство = &Свойство
СГРУППИРОВАТЬ ПО
ТИПЗНАЧЕНИЯ(ДопСведения.Объект),
ДопСведения.Значение
УПОРЯДОЧИТЬ ПО
ТипВладельца,
ЗначениеВ параметр Свойство передают элемент плана видов характеристик ДополнительныеРеквизитыИСведения. Дополнительный реквизит хранится иначе, в табличной части ДополнительныеРеквизиты самого объекта, и считать его придётся по каждому справочнику отдельно. Если обе стороны связи лежат в одном справочнике, тип владельца их не различит: группируйте по реквизиту, который их разделяет.
В разобранной базе свойство по смыслу относилось к карточке поставщика. Распределение показало другое:
| Чьи карточки | Записей | ”Да" | "Нет” |
|---|---|---|---|
| Собственные | 94 655 | 10 704 | 83 951 |
| Поставщиков | 31 874 | 27 344 | 4 530 |
На собственных карточках записей в 2,97 раза больше, хотя свойство к ним не относится. Почему значение туда вообще попадает, объяснил обработчик входящего обмена: в его цикле по связке карточек соседние свойства отфильтрованы по владельцу, а у этого отбора нет. Весь перекос на него списывать рано: ставит он только “Да”, а на собственных карточках 83 951 запись со значением “Нет”.
Кто пишет поле: какие значения способен записать каждый
Список писателей собирают по коду: обращения к регистру по имени и вызовы общего модуля УправлениеСвойствами. Для каждого места записывают, какие значения его код способен поставить, даже если ветка срабатывает редко.
| Писатель | Где код | Может записать | Отбор по владельцу |
|---|---|---|---|
| Обработчик входящего обмена | основная конфигурация | только “Да” | нет |
| Не найден | неизвестно | ”Нет” | неизвестно |
Вторая строка появилась из арифметики. Записей “Нет” в базе 83 951 + 4 530 = 88 481, и ни одну из них обработчик обмена поставить не мог: такой ветки в его коде нет. Значит, у поля есть второй писатель. Для этого вывода не понадобились ни следы в журнале, ни догадки, хватило вычитания. Самого писателя на момент разбора найти не удалось.
Внешние обработки из справочника и расширения лежат в той же базе, их код можно проверить на запись в регистр свойств: для этого есть чек-лист ревью внешних обработок и анализатор кода для всего справочника разом. Гарантий, что писатель окажется среди них, нет. По журналу регистрации автора записи устанавливают, только если нужные подробности в журнале есть.
Кто читает поле: откуда каждый берёт значение
Список читателей строят с обратной стороны: где поле читается и с какой стороны связи каждое место берёт значение. В разобранном случае мест чтения шесть:
| Читатель | Откуда берёт значение |
|---|---|
| Формы, отчёты, вспомогательная выгрузка, всего пять мест | собственная карточка |
| Боевая выгрузка на площадку | карточка поставщика |
Этой таблицы хватило для исходной жалобы: сотрудник видит галочку на собственной карточке, а выгрузка берёт значение с карточки поставщика. Ошибки нет ни в одном из шести мест, каждое делает то, что задумал автор. Разошлись трактовки: нигде не записано, на какой стороне связи живёт значение, и каждый разработчик решал это сам.
Результат правки проверяют по читателю, который отдаёт значение за пределы базы: ошибка на форме стоит вопроса сотрудника, ошибка в выгрузке стоит чужого товара на витрине. На будущее хватит строки в комментарии к свойству: на какой карточке хранится значение и откуда его читать.
На какую сторону писать исправление
Наше правило: значение записывают на ту сторону связи, где его видят люди, а читателя, который смотрит в другую сторону, правят следом. Обратный порядок чинит выгрузку и ломает экраны: пять мест чтения начнут показывать сотрудникам значения, которых там раньше не было.
Первая версия скрипта исправления так и сделала: писала на карточки поставщиков, под боевую выгрузку, обработала 171 карточку из 196, это 87 %, и отработала без ошибок. Отклонили её после списка читателей, потому что скрипт добавлял ещё одного писателя, несогласованного с пятью читателями из шести.
Процент покрытия говорит, сколько объектов обработано, и молчит о том, туда ли записано значение. Поэтому при приёмке массовой правки мы сначала спрашиваем, на какую сторону писали.
Перед массовой правкой: подписки на запись и настоящий объём
В разобранной базе подписка на событие ставила изменённую карточку в очередь повторной выгрузки во внешнюю таблицу, и правка тысяч объектов дала бы тысячи карточек в очереди. Кто подписан на запись набора регистра, показывает код по метаданным:
ТипНабора = Тип("РегистрСведенийНаборЗаписей.ДополнительныеСведения");
Для Каждого Подписка Из Метаданные.ПодпискиНаСобытия Цикл
Если Подписка.Источник.СодержитТип(ТипНабора) Тогда
Сообщить(Подписка.Имя + ": " + Подписка.Событие + ", " + Подписка.Обработчик);
КонецЕсли;
КонецЦикла;На типовой УТ 11.5.22.67 этот код нашёл 8 подписок из 305, среди них регистрация изменений для обменов. Что эта подписка делает с изменением дальше и на какой из пяти ступеней оно может не встать в очередь, разобрано в статье о регистрации изменений в плане обмена.
В том случае очередь обходили флагом ОбменДанными.Загрузка на наборе записей. Флаг сокращает проверки при записи, но подписки платформа вызывает и с ним, так что обход работает, только если обработчик сам проверяет флаг. Откройте каждый обработчик из списка до запуска.
Второй вопрос: сколько объектов действительно нужно править. Собственных карточек без свойства было 10 208, и задача выглядела большой. Связанная карточка поставщика нашлась у 8 из них, это 0,08 %. Остальным значение ни на что не влияет, а заполнение всех десяти тысяч для порядка усилило бы тот перекос, с которого начался разбор.
Связь двух карточек: посчитайте двумя способами
Связь карточек хранилась в той базе в двух местах: реквизитом в шапке и строками табличной части. Во внутренней документации была описана только шапка, и запросы писали по ней.
Замер дал 313 связанных карточек через табличную часть и 171 через реквизит шапки. Привычный запрос видел 54,6 % связей, ещё 142 карточки в расчёты не попадали. Описание в документации было верным для задачи, под которую его делали, но хранилось как общее правило.
Проверка стоит одного запроса: посчитать отношение двумя путями и сравнить. Совпало, значит, годится любой путь. Разошлось, значит, в базе два разных отношения, и сначала решают, какое из них нужно задаче.
Писатель не найден: правка данных остаётся заплаткой
Пока второй писатель не найден, любая чистка обратима: сразу после правки проверка покажет чистые данные, а при следующем запуске он может вернуть свои значения, и связать возврат с правкой будет трудно. Какие снимки сохранить на такой случай, описано в разборе выгрузки по расписанию с зелёными заданиями.
Данные бизнесу нужны сегодня, а поиск писателя может затянуться. Тогда мы правим данные, называем это заплаткой со сроком и в акте перечисляем, что осталось открытым. По разобранному случаю:
- второй писатель, создавший 88 481 запись со значением “Нет”, не найден;
- боевая выгрузка читает карточку поставщика и увидит исправленное значение только после своей правки;
- сколько товаров ушло наружу с чужим артикулом и во что это обошлось, не измерено;
- соседние свойства, которые пишет тот же обработчик обмена, не проверены.
Заплатку держат на виду и к ней возвращаются, а задачу с пометкой “исправлено” закрывают и забывают. До находки писателя такой пометки быть не должно.
Если расхождение живёт в обмене, который годами дописывали разные люди, разберём его вместе с вами и запишем, кто поле пишет и кто читает.
