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