Почему в отчете Валовая прибыль при отборе по договору искажаются данные по возвратам и как это исправить?

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

В чем заключается суть проблемы и как она проявляется

Рассмотрим типовую цепочку документооборота: оформляется реализация товаров, затем клиент возвращает часть продукции документом Возврат товаров от клиента. При оперативном проведении возврата формируются сторнирующие записи по выручке в регистре накопления ВыручкаИСебестоимостьПродаж. На этом этапе измерения Договор, Соглашение и Склад заполняются корректно из документа.

Однако в конце месяца выполняется регламентная процедура Расчет себестоимости товаров (партионный учет 2.1). Этот документ производит окончательный расчет и дописывает стоимостные потоки (себестоимость) в движения документа возврата по регистру ВыручкаИСебестоимостьПродаж.

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

1. В регистре формируются две записи по одной хозяйственной операции: выручка со знаком «минус» с заполненным договором и себестоимость со знаком «минус» с пустым договором.
2. Пользователь открывает отчет «Валовая прибыль» и накладывает жесткий отбор по договору контрагента.
3. Схема компоновки данных (СКД) выбирает только те записи, где договор строго равен указанному. Строка с выручкой попадает в выборку, а дозаписанная регламентным расчетом строка с фактической себестоимостью отсекается (так как поле не заполнено).
4. В результате математика отчета ломается: валовая прибыль по операции возврата уходит в минус на величину рассчитанной себестоимости либо отображает некорректный финансовый результат.

Анализ программного кода типовой конфигурации

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

КопируемыеПоля = "
    |Период, Подразделение, АналитикаУчетаПоПартнерам, ЗаказКлиента, ТипЗапасов, ВидЗапасов,
    |ХозяйственнаяОперация, Менеджер, ДокументДвижения";

В этом списке и в текстах соответствующих запросов закрытия себестоимости отсутствуют критически важные измерения регистра ВыручкаИСебестоимостьПродаж: Договор, Соглашение, а также складские аналитики и АналитикаУчетаНаборов. Таким образом, это является дефектом типового алгоритма конфигурации, приводящим к расхождению аналитик между выручкой и себестоимостью одной операции.

Способ 1. Корректировка алгоритма через расширение конфигурации

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

1. Подключим расширение конфигурации для переопределения процедур формирования движений регистра ВыручкаИСебестоимостьПродаж в общем модуле расчета себестоимости и партионного учета.
2. Дополним список копируемых полей и выборку запроса недостающими измерениями: Договор, Соглашение, Склад (или складская аналитика) и АналитикаУчетаНаборов.
3. Сохраним изменения и заново выполним регламентную операцию закрытия месяца Расчет себестоимости за проблемные периоды. В результате движения по себестоимости перезапишутся с полным набором измерений.

Способ 2. Обновление конфигурации и переход на новую версию партионного учета

Фирма «1С» устранила данное поведение в последующих версиях конфигураций линейки 11.3 (начиная с релизов 11.3.2+) и 11.4. Кроме того, в более современных версиях реализован «Партионный учет 2.2», в котором архитектура распределения стоимостных потоков возвратов была кардинально модернизирована.

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

Способ 3. Доработка схемы компоновки данных (СКД) в отчете

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

1. Откроем схему компоновки данных отчета (в пользовательском режиме через изменение варианта отчета либо в конфигураторе).
2. Настроим вычисляемое поле для договора или соглашения. Если в текущей строке регистра измерение Договор не заполнено, определим его из связанных реквизитов: через ЗаказКлиента.Договор, документ партии ДокументДвижения.Договор либо через ключ аналитики расчетов АналитикаУчетаПоПартнерам.
3. Перенесем пользовательский отбор по договору на созданное вычисляемое поле, благодаря чему СКД склеит движения выручки и себестоимости в единую строку отчета.

Методические нюансы и ограничения

Обратим внимание на важные особенности ведения учета:

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