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