В процессе эксплуатации конфигураций на базе 1С:Предприятие (особенно часто это встречается в «Управлении торговлей» версии 10.3) пользователи сталкиваются с ситуацией, когда в регистре накопления ЗаказыПокупателя (остатки) появляются отрицательные значения. Это приводит к тому, что заказ зависает в системе как невыполненный, хотя фактически товар отгружен. В этой статье мы подробно разберем причины этой проблемы, проанализируем взаимосвязь регистров и выработаем системный подход к лечению «минусов».
Для начала проанализируем структуру регистра ЗаказыПокупателя. Он является регистром остатков и работает по классической схеме: документ Заказ покупателя делает движение «Приход», увеличивая остаток по заказу, а документ Реализация товаров и услуг делает «Расход», закрывая потребность.
Рассмотрим основные сценарии, при которых возникают отрицательные остатки:
Заказе покупателя указан один договор, а в Реализации товаров и услуг — другой, то программа при проведении реализации сделает «Расход» по новому договору. В итоге по первому договору остаток так и останется висеть в плюсе, а по второму — уйдет в минус.Возврат товаров от покупателя без указания заказа или с некорректной привязкой к нему может приводить к хаосу в движениях регистра.Чтобы локализовать проблему, нам необходимо сформировать отчет по движениям регистра (например, «Ведомость по заказам покупателей») с максимальной детализацией до регистратора. Проанализируем строки отчета: если мы видим одинаковые позиции номенклатуры, где одна строка в плюсе, а другая в минусе — проблема в разной аналитике (чаще всего в договорах).
Казалось бы, решение очевидно: нужно привести договоры в документах к «общему знаменателю». Однако здесь нас подстерегает опасная ловушка, о которой упоминают опытные специалисты. При простом изменении договора в реализации может «поплыть» валовая прибыль.
Проанализируем ситуацию: в типовых решениях (УТ 10.3, КА 1.1) себестоимость товаров часто учитывается в разрезе договоров (партионный учет). Когда мы меняем договор в реализации, документ перестает видеть партию поступления, которая числилась за старым договором. В результате:
Рассмотрим по шагам, как можно исправить ситуацию в зависимости от глубины проблемы и возможности редактирования документов прошлого периода.
Если период еще не закрыт для редактирования, наиболее правильным будет исправление первичных документов. Разберем алгоритм:
Для автоматизации этого процесса программист может написать небольшую обработку. Посмотрим на пример логики поиска несоответствий:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Реализация.Ссылка КАК ДокументСсылка,
| Реализация.ДоговорКонтрагента КАК ДоговорРеализации,
| Реализация.Сделка.ДоговорКонтрагента КАК ДоговорЗаказа
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Реализация
|ГДЕ
| Реализация.Сделка ССЫЛКА Документ.ЗаказПокупателя
| И Реализация.ДоговорКонтрагента <> Реализация.Сделка.ДоговорКонтрагента";
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
// Логика исправления документа
КонецЦикла;
Если документы находятся в закрытом периоде и менять их нельзя (налоговая отчетность сдана), используем механизм корректировки. Нам нужно вручную «схлопнуть» остатки в регистре ЗаказыПокупателя, не затрагивая при этом бухгалтерские итоги и регистры продаж.
Разберем, какие записи нужно сделать в документе Корректировка записей регистров:
Такой подход исправит только управленческий учет по заказам, не ломая себестоимость и валовую прибыль в прошлых периодах.
Чтобы ситуация не повторилась, проанализируем возможность внедрения автоматического контроля. Рассмотрим пример кода, который можно добавить в модуль объекта документа РеализацияТоваровУслуг перед записью или при проведении:
Если ЗначениеЗаполнено(Сделка) И Ссылка.Сделка.ДоговорКонтрагента <> ДоговорКонтрагента Тогда
Сообщить("Внимание! Договор в реализации не совпадает с договором в заказе!");
// В сильно дописанных конфигурациях здесь можно поставить отказ в проведении
// Отказ = Истина;
КонецЕсли;
Отрицательные остатки в заказах — это лишь вершина айсберга. Основная сложность заключается в целостности партионного учета. При исправлении ошибок всегда проверяйте, как ваши действия отразились на регистре Продажи и ПартииТоваровНаСкладах. Помните, что «волшебной кнопки» не существует, но системный анализ движений регистратора позволяет быстро найти и устранить корень проблемы.