← На главную

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

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

Почему не стоит добавлять ресурс в типовой регистр партий

Типовой регистр ПартииТоваровНаСкладах является одним из ключевых и самых сложных узлов во многих конфигурациях (например, в УТП). Посмотрим на основные проблемы, с которыми вы столкнетесь при попытке «в лоб» добавить туда новый ресурс:

1. Сложность алгоритмов пропорционального списания: Типовые механизмы списания себестоимости по методам ФИФО и ЛИФО жестко запрограммированы в общих модулях. Платформа не будет автоматически списывать ваш новый нестандартный ресурс пропорционально количеству отгружаемого товара. Если не переписать ядро партионного учета, при частичных отгрузках будут возникать математические искажения, а при нулевом остатке товара в регистре "зависнут" копейки или суммы дополнительных расходов.
2. Сложности с возвратами: При возврате товара от покупателя программа должна восстановить себестоимость именно той партии, по которой ранее была зафиксирована продажа. Новый ресурс потребует значительной доработки алгоритмов расчета возвращаемой доли дополнительных затрат.
3. Риски при восстановлении последовательности: Вмешательство в структуру и движения партионного регистра резко повышает вероятность возникновения ошибок при ручном или автоматическом запуске обработки проведения по партиям (восстановление партионной последовательности). Это может полностью заблокировать корректное закрытие месяца.
4. Проблемы с поддержкой: Регистр партий затрагивается десятками видов документов-регистраторов. Изменение его структуры напрямую в основной конфигурации сделает процесс обновления базы крайне трудоемким и болезненным.

Решение 1: Создание параллельного регистра для дополнительных расходов

Рассмотрим наиболее технически грамотный подход, если транзакционный учет в разрезе партий все-таки необходим. Правильно будет не трогать типовой объект, а вынести ресурс в отдельный регистр.

Разберем по шагам, как это реализовать:

1. Создайте свой собственный регистр накопления, например, ДополнительныеРасходыПоПартиям. Скопируйте в него основные измерения из типового регистра (Номенклатура, Склад, ДокументОприходования/Партия) и добавьте необходимые вам ресурсы (например, СуммаДопЗатрат).
2. Используйте механизм «Подписок на события». Чтобы не менять модули объектов каждого типового документа, подпишитесь на событие ОбработкаПроведения документов-регистраторов, либо на событие ПриЗаписи набора записей самого типового регистра партий.
3. Настройте синхронное чтение движений. В обработчике подписки на событие ваш алгоритм должен анализировать уже сформированные типовые движения (какая именно партия списалась и в каком объеме). На основе этой пропорции формируйте расходные движения по новому регистру. Это гарантирует, что ваши дополнительные затраты спишутся в ноль одновременно с основной партией.
4. Если позволяет версия платформы 1С:Предприятие 8.3 и режим совместимости, создавайте новый регистр и подписки через механизм расширений. Это позволит полностью сохранить типовую конфигурацию на замке (на поддержке).

Решение 2: Решение задачи на уровне методологии и отчетов

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

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

Использование плановых типов цен: Если задача состоит исключительно в анализе плановой рентабельности менеджерами, можно обойтись без изменения партионного учета. Создайте два типа цен: «Базовая закупочная» и «Закупочная с учетом средних доп. расходов». Анализ валовой прибыли в таком случае легко настраивается через типовые отчеты путем сравнения фактической выручки с этими расчетными типами цен.

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

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