Мы рассмотрим распространенную проблему в конфигурации 1С:Управление торговлей, редакция 11 (версия 11.5.16.68) на платформе 1С:Предприятие 8.3 (версия 8.3.23.1912), когда после перепроведения документа реализации в регистре накопления «Расчеты с клиентами» формируются некорректные движения. В частности, речь идет о появлении лишних записей по расходу, что приводит к удвоению суммы к оплате клиенту в отчетах.
Представим, что у нас есть документ «Реализация товаров и услуг» (РТУ), который изначально сформировал два движения по приходу в регистре «Расчеты с клиентами». Это может быть ожидаемым по какой-либо причине, например, если расчеты детализируются по нескольким документам или если система учета авансов имеет свои особенности. Однако, ключевая проблема проявляется после обычного перепроведения этого же документа. Вместо того чтобы скорректировать или оставить движения без изменений, система внезапно создает дополнительную запись по расходу в регистре.
Возникает вопрос: почему после перепроведения появляется именно «расход»? Это особенно смущает, поскольку перепроведение, казалось бы, должно просто восстанавливать корректное состояние движений на основе актуальных данных. Но в данном случае мы видим, что эта новая запись расхода не исчезает и не корректируется последующими действиями. Итогом такого поведения становится искажение данных в отчетах. Если мы строим универсальный отчет по регистру накопления «Расчеты с клиентами», мы обнаруживаем, что поля «Сумма» и «К оплате клиенту» отличаются ровно на сумму реализации, как будто в отчет попали две одинаковые записи по приходу или одна запись по расходу не была учтена корректно, что фактически удваивает сумму задолженности клиента. Подозрение, что такое поведение системы могло начаться после обновления конфигурации, указывает на возможные изменения в логике расчетов, внедренные разработчиками.
Дальнейшее тестирование подтверждает эту гипотезу. Если мы отменяем проведение документа РТУ, а затем проводим его снова (даже не перепроводим, а именно через отмену и новое проведение), картина с некорректным расходом сохраняется. Это свидетельствует о том, что проблема не связана с механизмом перепроведения как таковым, а коренится глубже – в логике формирования движений или обработки данных.
Для понимания причин некорректных записей в регистре «Расчеты с клиентами» в 1С:УТ 11.5, мы должны учитывать особенности современных механизмов взаиморасчетов в этой конфигурации.
В конфигурации 1С:Управление торговлей, начиная с версии 11.5, были внесены существенные изменения в алгоритмы взаиморасчетов и формирования движений по регистрам. Регистр «Расчеты с клиентами» является центральным для учета дебиторской и кредиторской задолженности. Одной из ключевых особенностей является использование так называемых «объектных расчетов», где движения формируются не только по основному документу (например, реализации), но и по связанным документам, таким как «Заказы клиентов», «Поступления оплат» или «Авансовые отчеты». Это значительно усложняет сценарии формирования записей, особенно при многократном перепроведении документов или изменении их статусов.
В нашем случае, как выяснилось, документ «Заказ клиента» используется «как счет и не делает никаких движений». Однако, даже если сам заказ не формирует прямых движений по регистру «Расчеты с клиентами», он может быть указан как документ расчетов для связанной с ним реализации. Это означает, что логика взаиморасчетов будет пытаться учитывать состояние заказа при формировании движений реализации. Если у заказа есть определенные статусы (например, «Согласован», «К отгрузке»), то изменение статуса или перепроведение заказа, даже если он сам по себе не генерирует записей, может повлиять на проведение связанных документов реализации. Система может пытаться скорректировать уже сформированные движения реализации, если логика взаиморасчетов находит несоответствия с текущим состоянием или статусом заказа.
Термин «схлопывание» относится к механизму, при котором система стремится объединить или скорректировать несколько движений по регистру, относящихся к одному и тому же расчетному документу (например, «Заказу клиента»), при его изменении или перепроведении. Идеально, если у вас было два «Прихода» по одному заказу, а затем часть заказа отменили, система должна «схлопнуть» эти приходы или сторнировать лишнее, оставив корректное движение. Если логика схлопывания нарушается, это может приводить к тому, что в отчете видны двойные суммы, как будто две записи по приходу сформировались вместо одной корректной или же сторнирующие движения (расходы) формируются ошибочно или неполно. Это часто происходит, когда система пытается компенсировать или сторнировать предыдущие некорректные движения, но делает это с ошибкой, в результате чего остается неверный остаток.
Несмотря на регулярные обновления, иногда могут возникать ошибки в алгоритмах формирования движений, особенно в новых версиях или после внесения значительных изменений. Версия 11.5.16.68 является относительно стабильной, но специфические баги, проявляющиеся в определенных условиях или при сочетании определенных настроек, могут быть обнаружены. Проблема, начавшаяся после обновления, часто указывает именно на эту причину.
При перепроведении документов критически важно соблюдать хронологическую последовательность. Если документы были проведены не по порядку, или если один из связанных документов (например, заказ) был перепроведен без перепроведения зависимых документов (реализации), это может привести к некорректным остаткам. Система может неверно интерпретировать «старые» движения и формировать новые, ошибочные, при попытке восстановить баланс. Специальные обработки по восстановлению последовательности могут помочь, но иногда требуют глубокого анализа причин.
Настройки взаиморасчетов в карточке клиента, договора или соглашения могут существенно влиять на формирование движений. Например, если установлена детализация расчетов «по документам расчетов», то каждое новое проведение или изменение документа будет создавать отдельную запись, и в случае ошибки это может привести к дублированию или некорректной коррекции. Мы должны внимательно изучить эти настройки, чтобы исключить их влияние.
Для того чтобы детально разобраться в том, как именно формируются движения по регистру «Расчеты с клиентами» для нашей проблемной реализации и связанного с ней заказа, мы воспользуемся Консолью запросов 1С. Этот инструмент позволяет выполнить произвольный запрос к базе данных и получить точные сведения о движениях.
В режиме 1С:Предприятие, мы можем найти консоль запросов через меню «Все функции» (если оно включено) или с помощью внешней обработки. Запускаем ее, чтобы получить доступ к механизму выполнения запросов.
Этот запрос позволяет нам получить первые 100 записей из регистра накопления «Расчеты с клиентами» для конкретной реализации и связанного с ней заказа, упорядоченные по периоду и номеру строки для лучшего анализа последовательности:
ВЫБРАТЬ ПЕРВЫЕ 100
таб.*
ИЗ
РегистрНакопления.РасчетыСКлиентами КАК таб
ГДЕ
таб.Регистратор В (&РТУ, &Заказ)
УПОРЯДОЧИТЬ ПО
таб.Период УБЫВ, таб.НомерСтроки
ИТОГИ ПО
Регистратор
Перед выполнением запроса нам необходимо установить значения для его параметров:
&РТУ: Мы устанавливаем в качестве значения проблемный документ «Реализация товаров и услуг», который вызывает некорректные движения. Выбираем его из списка документов.&Заказ: Устанавливаем в качестве значения связанный с этой реализацией документ «Заказ клиента». Несмотря на то что, как мы выяснили, сам заказ не делает прямых движений, он играет роль в механизме взаиморасчетов и может быть указан как ДокументРасчетов.После установки параметров, мы нажимаем кнопку «Выполнить» в консоли запросов.
После выполнения запроса мы получим таблицу с движениями. Внимательно анализируем следующие поля:
ВидДвижения:
Это поле показывает, является ли движение «Приходом» (увеличение задолженности клиента или уменьшение аванса) или «Расходом» (уменьшение задолженности клиента или увеличение аванса). Мы должны искать аномалии: например, если изначально было два прихода, а после перепроведения появился расход, который должен был сторнировать один из приходов, но вместо этого просто добавил лишнюю запись, не устранив предыдущую некорректность.
СуммаВзаиморасчетов:
Это поле отображает сумму движения в валюте взаиморасчетов. Мы внимательно проверяем, нет ли здесь дублирующихся сумм или расхождений. Например, если сумма реализации 808.6, и мы видим два прихода по 808.6, это уже указывает на проблему, а если потом появляется расход 808.6, который не компенсирует один из приходов, это подтверждает некорректность.
ДокументРасчетов:
Это очень важное поле, так как оно показывает, по какому документу система «связывает» это движение. Если для реализации указан «Заказ клиента» как ДокументРасчетов, то даже если сам заказ не генерирует движений, он выступает якорем для логики расчетов. Все движения, связанные с этим заказом (авансы, реализации), будут «привязаны» к нему через это поле.
Период и НомерСтроки:
Эти поля помогают нам понять хронологию и порядок формирования движений. Неправильная последовательность или появление движений в неожиданный момент могут указывать на проблемы с логикой проведения.
Для более глубокого анализа мы можем расширить запрос, добавив в него такие поля как СуммаРегл (сумма в регламентированной валюте), ВалютаДокумента (валюта, в которой оформлен документ), ДоговорКонтрагента, Партнер и другие, чтобы увидеть полную картину.
Результаты запроса помогут нам понять механизм «схлопывания» движений. Если система попыталась сторнировать предыдущие некорректные записи, но сделала это ошибочно (например, создала новый расход, но не удалила лишний приход), мы увидим это в движениях. Этот анализ позволит нам точно определить, где именно возникает логическая ошибка и как она приводит к удвоению сумм в отчетах.
После проведения диагностики с помощью консоли запросов и выявления потенциальных причин некорректных движений, мы можем предпринять следующие шаги для устранения проблемы:
Прежде всего, убедимся, что используемые версии платформы (8.3.23.1912) и конфигурации (11.5.16.68) являются актуальными и соответствуют последним стабильным релизам, рекомендованным 1С. Разработчики постоянно выпускают исправления ошибок, и возможно, данная проблема уже была устранена в более новой версии или патче. Если доступны более новые версии, протестируем их на копии базы.
Критически важно выполнять любые действия по изменению данных или настроек только на копии рабочей базы данных. Это предотвратит потерю или повреждение актуальных данных и позволит безопасно экспериментировать с решениями.
Мы внимательно изучим настройки взаиморасчетов в различных местах конфигурации:
Иногда некорректные движения могут возникать из-за нарушения хронологической последовательности проведения документов. Мы можем использовать специальные обработки для группового перепроведения документов:
В Журнале регистрации 1С могут содержаться записи об ошибках или предупреждениях, которые возникают при проведении проблемных документов. Мы фильтруем журнал по регистратору (документу реализации) и ищем любые сообщения, которые могут пролить свет на причину некорректных движений.
Если в вашей конфигурации присутствуют какие-либо расширения или доработки, особенно те, которые затрагивают проведение документов, работу с регистрами взаиморасчетов или обработку заказов, мы временно их отключаем на копии базы. Затем мы проверяем, воспроизводится ли проблема на чистой типовой конфигурации. Если проблема исчезает, это указывает на то, что ошибка находится в доработках.
На официальном портале 1С:ИТС часто публикуются описания известных ошибок, методики их устранения и рекомендации по работе с регистрами в различных версиях конфигураций. Мы используем поиск по ключевым словам: «Расчеты с клиентами», «УТ 11.5», «некорректные движения», «задвоение сумм», чтобы найти похожие ситуации и готовые решения.
Решение этой проблемы требует системного подхода и поэтапного анализа. Начиная с детальной диагностики с помощью консоли запросов и заканчивая проверкой всех возможных настроек и обновлений, мы сможем выявить первопричину некорректных записей и восстановить корректный учет взаиморасчетов с клиентами.