В процессе разработки в современных конфигурациях на базе 1С:Предприятие 8.3 (таких как 1С:ERP, 1С:Комплексная автоматизация 2 или 1С:Управление торговлей 11) программисты часто сталкиваются с необходимостью упростить сложные складские операции. Типовые бизнес-процессы, такие как переупаковка товара с одновременной сменой серии на адресном складе, могут требовать оформления целой цепочки документов: отборок, размещений, приходных и расходных ордеров, а также документов сборки. Логичным кажется желание создать один «свой» документ, который будет делать прямые движения по регистрам Товары на складах и Товары в ячейках. Разберем подробно, почему это решение может стать «миной замедленного действия» для системы.
Рассмотрим ситуацию, когда на ордерном адресном складе необходимо изменить упаковку и серию товара. В типовой логике 1С:ERP это требует взаимодействия нескольких подсистем:
Сборка (разборка) товаров — для отражения факта изменения номенклатуры/серии в финансовом учете.Расходный ордер на товары — для инициации складского списания.Отбор (размещение) товаров — для фиксации изъятия из конкретной ячейки.Приходный ордер на товары — для отражения поступления новой упаковки/серии.Отбор (размещение) — для размещения в ячейку.Проанализируем этот процесс: для выполнения одной операции требуется 5 документов. Это создает высокую нагрузку на пользователя и базу данных. Однако попытка заменить эту цепочку одним движением в регистры таит в себе скрытые угрозы, которые мы разберем далее.
Выясним причину, по которой простое добавление записей в Товары на складах недостаточно. В современных конфигурациях складской учет (количественный) и финансовый учет (стоимостный) разделены, но жестко связаны. Данные регистра Товары на складах должны строго соответствовать данным регистра Себестоимость товаров.
Если наш самописный документ сделает движение только по складским регистрам, мы получим ситуацию, когда товар в штуках на складе числится (или списан), а в финансовом контуре он все еще висит на старой серии или упаковке. Результат: процедура Закрытие месяца и документ Расчет себестоимости выдадут критические ошибки, а отчеты Ведомость по товарам на складах и Ведомость по себестоимости никогда не сойдутся. Это сделает невозможным получение корректной управленческой и финансовой отчетности.
Посмотрим, как устроена запись в регистры изнутри. Современные решения 1С используют систему ключей аналитики. Вместо прямого указания склада, номенклатуры и серии в каждой записи регистра, система ссылается на справочник КлючиАналитикиУчетаНоменклатуры.
При проведении типового документа система сначала ищет существующий ключ или программно создает новый. Если ваш самописный документ проигнорирует этот механизм или заполнит аналитику некорректно, типовые отчеты на СКД просто «не зацепят» эти движения, и остатки в отчетах будут отображаться неверно, несмотря на наличие физических записей в таблицах базы данных.
Проанализируем работу регистра Товары в ячейках. В типовой логике 1С это не просто «остатки», это отражение состояния складских задач. Движение по этому регистру часто сопровождается:
Задания к распределению запасов.Прямая запись в эти регистры в обход логики складских ордеров приведет к тому, что система будет считать ячейки занятыми или товар «находящимся в процессе перемещения» вечно, блокируя работу штатных складских механизмов.
Рассмотрим несколько путей реализации, от наиболее опасных к наиболее правильным:
Если вы все же решили идти по этому пути, вам необходимо:
Себестоимость товаров).Регистратор будет отображаться как «Объект не найден», а итоги могут рассчитываться некорректно.Важное замечание: При каждом обновлении конфигурации вам придется вручную проверять структуру типовых регистров, так как 1С может изменить состав измерений или логику заполнения ресурсов.
Некоторые разработчики предпочитают программно создавать документ Корректировка регистров при проведении своего документа. Рассмотрим плюсы и минусы:
Плюсы: Не нужно менять метаданные типовых регистров (добавлять свой документ в регистраторы).
Минусы: Это крайне неудобно для поддержки. Как выразились участники обсуждения: «Корректировка регистров — это как ручные проводки в бухгалтерии». Теряется прозрачность учета, сложно отследить связь между вашим документом-первоисточником и итоговыми движениями. При отмене проведения основного документа придется вручную (программно) искать и удалять созданную корректировку.
Наиболее безопасный и правильный с точки зрения архитектуры способ — создать ваш «удобный» документ, который в фоновом режиме или при проведении будет автоматически создавать и проводить всю необходимую цепочку типовых документов (Сборка + Ордера).
Разберем по шагам, почему это лучше:
Подводя итог, можно сказать: технически сделать свой документ регистратором для типовых регистров можно, но практически это неоправданно дорого в долгосрочной перспективе. Основная опасность заключается не в «слетающих отчетах», а в разрушении сложной цепочки финансового учета. Если ваша задача требует изменения характеристик товара (упаковки, серии), это движение обязано пройти через регистр Себестоимость товаров с соблюдением всех правил формирования ключей аналитики. Самым надежным решением остается автоматизация создания типовых документов под капотом вашего собственного интерфейса.