Отчёт насчитал 703 просрочки, а клиенты заплатили: где в УТ 11.5 и КА 2.5 лежат оплаты по накладным

С чего началось

На бирже Инфостарта заказали отчёт для «Комплексной автоматизации» 2.5. Задача простая на словах: у каждого заказа клиента есть график оплаты из соглашения, например 30 % аванс и остаток через 20 дней после отгрузки. Нужно видеть, какой этап графика оплачен вовремя, какой с опозданием и на сколько дней, а какой не оплачен до сих пор.

Самое трудное, как мне тогда казалось, было в датах. Отгрузка часто уезжает относительно плана, и срок «через 20 дней после отгрузки» надо считать от настоящей реализации. Этим я и занимался больше всего.

С оплатами я поступил просто. Когда клиент платит, типовая закрывает этим платежом план в регистре РасчетыСКлиентамиПланОплат, и в регистре появляется расход с заполненным реквизитом ДокументОплаты. Я брал эти расходы: там уже есть и сумма, и документ, и привязка к заказу.

Проверял на демо-базе заказчика, КА 2.5.27.75. Контрольный заказ на 405 000: семь этапов графика, три реализации, два платежа. Плановые даты, которые посчитал отчёт, совпали с теми, что типовая записала в регистр. Сумма оплат совпала с платёжками. Я сдал отчёт.

Месяц спустя

Готовя отчёт к публикации, я прогнал его на копии рабочей базы оптовой компании. Там «Управление торговлей» 11.5.27.88, 1 057 незакрытых заказов, и у 1 000 из них в заказе стоит порядок расчётов «Аванс по заказам, долг по накладным».

Отчёт показал план оплат 30 650 520,59, найденных оплат 6 558 797,42 и 703 просроченных этапа. Для работающей оптовой компании это выглядело неправдоподобно, и я пошёл смотреть, где отчёт теряет деньги.

Как устроены расчёты с клиентами

В УТ 11.5 и КА 2.5 расчёты с клиентами ведутся в нескольких регистрах. Для этой истории нужны три:

Все три ведутся по объекту расчётов. Объектом может быть заказ, договор или сама накладная, в зависимости от порядка расчётов в заказе.

При порядке «Аванс по заказам, долг по накладным» до отгрузки объектом расчётов служит заказ, и аванс записывается на него. Когда товар отгружен, долг переходит на накладную, и дальше клиент платит уже по накладной.

Где лежали деньги

Я посмотрел регистры по всем 1 057 заказам и их реализациям.

В плановых оплатах по заказам расход такой:

Большую часть плана закрыла реализация: при отгрузке типовая гасит план заказа самой накладной. А по объекту «реализация» в плановых оплатах нет ни одной записи. У накладной своего плана оплат нет, поэтому платёж, пришедший после отгрузки, в этот регистр не попадает. Мой отчёт видел только авансы.

В РасчетыСКлиентами по реализациям тех же заказов картина другая:

Оплаты по накладным, почти 14,5 млн, лежат здесь.

Почему контрольный заказ этого не показал, стало понятно, когда я открыл его платежи: 03.03 и 11.03, а первая отгрузка тоже 11.03. Оба платежа пришли, пока объектом расчётов был заказ. Случай «оплата после отгрузки» я на нём просто не проверял.

Что ещё было в плановых оплатах

Раз уж взялся за этот регистр, я выгрузил весь его расход на демо-базе КА. Кроме поступлений денег там нашлись:

Реализацию отчёт и так отбрасывал, это зачёт аванса. Ввод начальных остатков можно считать оплатой: это аванс, полученный до начала учёта в базе. А возврат товаров на 55 886,72 отчёт засчитал клиенту как оплату этапа графика. Возврат уменьшает долг, но денег клиент при этом не платил.

Выходит, регистр плановых оплат для такого отчёта не годится с двух сторон: часть денег он не содержит, а часть того, что он содержит, не деньги.

Как отличить оплату от остального

Первое, что приходит в голову, это перечислить платёжные документы по именам: поступление на расчётный счёт, приходный кассовый ордер и так далее. Мне этот путь не понравился. Если какой-то вид документа не попадёт в список, часть оплат опять тихо пропадёт, как только что пропала из-за выбора регистра.

В РасчетыСКлиентами есть реквизит СтатьяДвиженияДенежныхСредств. Я посмотрел, у каких движений он заполнен, на обеих базах:

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

ВЫБРАТЬ
	Д.ОбъектРасчетов.Объект КАК ОбъектРасчетов,
	Д.Регистратор КАК Документ,
	МИНИМУМ(Д.Период) КАК ДатаДокумента,
	СУММА(Д.Сумма) КАК Сумма
ИЗ
	РегистрНакопления.РасчетыСКлиентами КАК Д
ГДЕ
	Д.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход)
	И Д.ОбъектРасчетов.Объект В (&ОбъектыРасчетов)
	И (Д.СтатьяДвиженияДенежныхСредств <> ЗНАЧЕНИЕ(Справочник.СтатьиДвиженияДенежныхСредств.ПустаяСсылка)
		ИЛИ Д.ХозяйственнаяОперация = ЗНАЧЕНИЕ(Перечисление.ХозяйственныеОперации.ВводОстатковАвансовКлиентов))
СГРУППИРОВАТЬ ПО
	Д.ОбъектРасчетов.Объект,
	Д.Регистратор
ИМЕЮЩИЕ
	СУММА(Д.Сумма) > 0

В &ОбъектыРасчетов передаю заказ, все его реализации и его договор. Договор нужен для порядка расчётов «по договорам»: там платёж привязан к договору, и без него клиент, который заплатил, числился бы должником.

Названий платёжных документов в запросе нет. Поля СтатьяДвиженияДенежныхСредств, ХозяйственнаяОперация и значение ВводОстатковАвансовКлиентов я сверил по выгрузкам УТ 11.5.22.182 и 11.5.27.79, они есть в обоих релизах.

Что получилось

Для сверки я отдельным запросом сложил поступления в регистре: 8 463 399,30 на заказы и 14 479 826,62 на накладные, всего 22 943 225,92. Сумма в отчёте совпала до копейки.

Как платежи раскладываются по этапам

Платежи по заказу идут по порядку дат и закрывают этапы графика по порядку их плановых дат. Один платёж может закрыть несколько этапов, один этап может закрываться несколькими платежами. На том же контрольном заказе, 50 000 от 03.03 и 70 500 от 11.03, начало отчёта выглядит так:

Второй платёж закрыл остаток первого этапа и часть второго, а 10 500 остались неоплаченными.

Если платёж пришёл на договор, а не на заказ или накладную, заказы этого договора разбирают его по очереди своих дат. На демо-базе так оплачен заказ с порядком «аванс по договорам, долг по накладным»: 47 200 и 50 000 пришли на договор и закрыли два этапа «до отгрузки». Распределять платёж по договору между заказами приходится по допущению, поэтому у таких строк в отчёте указан источник «договор», чтобы это было видно.

Вторая половина картины: отгрузки

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

Когда оплаты и отгрузки лежат в одном отчёте, видно, кто на самом деле держит деньги. На демо-базе КА после всех исправлений просрочка оплат составила 11 495 840,10, а просрочка отгрузок 8 144 708,95. Из всей просрочки по сумме 41 % приходится на отгрузки, то есть на опоздания продавца, а не клиентов.

Хороший пример этой связки на демо-базе, заказ ДС00-000003. Отгрузку планировали на 17.11, а реализация прошла 02.12, на 15 дней позже. Этап оплаты «через 1 день после отгрузки» в самом заказе остался с датой 18.11. Если считать от неё, клиент заплатил 18.12 с опозданием на месяц. Отчёт считает срок от фактической отгрузки, 03.12, и показывает две разные просрочки: 15 дней по отгрузке за нами и 15 дней по оплате за клиентом. Разговор с таким клиентом получается совсем другим, чем по одной цифре «месяц просрочки».

Если отгрузки по этапу ещё не было, строка помечается «Ожидается (отгрузки не было)» и в просрочку не попадает: срок оплаты, который отсчитывается от отгрузки, ещё не наступил.

Ещё три исправления

НДС в плане отгрузок. План отгрузок я брал из строк заказа, поле Сумма, а факт из реализации, СуммаДокумента. На демо-базе у 27 заказов из 63 цена указана без НДС. У них сумма строки заказа налога не содержит, а сумма реализации содержит, и отчёт показывал 12 строк «Сверх графика», которых на самом деле нет. Теперь с обеих сторон берётся СуммаСНДС. Отгрузки считаются по строкам реализации, по реквизиту Товары.ЗаказКлиента: одна реализация бывает по нескольким заказам, на демо-базе такая есть, по двум заказам на 20 160 и 877 800.

Реквизит, которого нет в УТ 11.5.22. Этапы «до отгрузки» и «от даты отгрузки» отчёт пересчитывает от фактической реализации. Для этого нужно знать, от какой плановой отгрузки типовая считала этап. У табличной части ЭтапыГрафикаОплаты в КА 2.5.27 и УТ 11.5.27 есть реквизит ДатаОтгрузки, но на демо-базе он пустой во всех строках, так что плановую отгрузку я восстанавливаю из ДатаПлатежа и Сдвиг. А в УТ 11.5.22.182 этого реквизита нет совсем, и запрос с ним в этом релизе не выполняется. Поле теперь подставляется в текст запроса после проверки по метаданным:

Если ЕстьРеквизитТабличнойЧасти("ЗаказКлиента", "ЭтапыГрафикаОплаты", "ДатаОтгрузки") Тогда
	ПолеДатаОтгрузки = "Э.ДатаОтгрузки";
Иначе
	ПолеДатаОтгрузки = "ДАТАВРЕМЯ(1, 1, 1)";
КонецЕсли;
Запрос.Текст = СтрЗаменить(Запрос.Текст, "&ПолеДатаОтгрузкиЭтапа", ПолеДатаОтгрузки);

Этап «от даты перехода права собственности». Восстанавливая плановую отгрузку для такого этапа, я вычитал из даты платежа ещё и срок перехода права из соглашения. Типовая этот срок в дату этапа не включает, это видно на трёх заказах демо-базы: 17.03 = 15.02 + 30, 28.11 = 18.11 + 10, 03.07 = 13.06 + 20. Из-за лишнего вычитания этап сопоставлялся не с той реализацией: 10-дневный этап одного заказа считался от второй отгрузки вместо первой. Итоговые суммы от этого не менялись, только даты отдельных этапов, поэтому сверка итогов ошибку не показывала. Её видно, только если разобрать заказ по строкам.

Чего я не проверил

• деление оплаты, пришедшей на реализацию по нескольким заказам: такая реализация на демо-базе есть, но оплат на неё нет;
• вывод остатка платежа по договору, который не понадобился ни одному заказу: такого остатка в данных не было;
• варианты отсчёта «фиксированная дата», «от даты поступления» и «формула» из УТ 11.5.27: в проверенных базах их нет;
• порядок расчётов «по расчётным документам»: на демо-базе два таких заказа, но графика оплаты у них нет;
• «1С:ERP».

Как проверить свою базу

Если у вас есть свой отчёт по оплатам заказов и он берёт деньги из РасчетыСКлиентамиПланОплат, посмотрите, сколько оплат лежит на накладных. Эту сумму такой отчёт не видит:

ВЫБРАТЬ
	КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Д.Регистратор) КАК Документов,
	СУММА(Д.Сумма) КАК Сумма
ИЗ
	РегистрНакопления.РасчетыСКлиентами КАК Д
ГДЕ
	Д.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход)
	И Д.СтатьяДвиженияДенежныхСредств <> ЗНАЧЕНИЕ(Справочник.СтатьиДвиженияДенежныхСредств.ПустаяСсылка)
	И Д.ОбъектРасчетов.Объект В
		(ВЫБРАТЬ РАЗЛИЧНЫЕ
			Т.Ссылка
		ИЗ
			Документ.РеализацияТоваровУслуг.Товары КАК Т
		ГДЕ
			Т.Ссылка.Проведен
			И Т.ЗаказКлиента ССЫЛКА Документ.ЗаказКлиента
			И Т.ЗаказКлиента <> ЗНАЧЕНИЕ(Документ.ЗаказКлиента.ПустаяСсылка))

На копии УТ запрос вернул 364 документа на 14 479 826,62, на демо-базе КА два документа на 4 069 600,00. Он считает за все периоды; для отчётного периода добавьте условие на Д.Период.

И контрольный пример для такого отчёта стоит подбирать под каждый путь денег: аванс до отгрузки, оплата после отгрузки, оплата на договор. Мой контрольный заказ покрывал только первый.

Отчёт со всеми исправлениями лежит в Базе знаний: «Анализ плановой оплаты и просрочки по заказам клиентов для 1С:КА 2.5 и 1С:УТ 11.5», //infostart.ru/1c/reports/2804095/. Проверен на КА 2.5.27.75, УТ 11.5.27.88 и УТ 11.5.22.182, код открыт.