Каталог решений - Алгоритм ведения дебиторской задолженности(Часть 1)

Данное творчество появилось на основании поставленной задачи, которая заключается в следующем.

Задача: Сделать для коммерческого отдела отчёт по дебиторской задолженности в следующем виде.

Таблица 1

Первоочередной возникла мысль связывать платёжный поручения с накладными оных при проведении. Всё вроде бы логично. Оплата при проведении находит неоплаченные Накладные и привязывается к ним посредством указания накладной в неком реквизите регистра и фиксировать в регистре сумму, на которую она её закрывает (сумма движения). Но возникает вопрос с образованием аванса (переплаты). Т.е. в какой-то момент оплата сделает движение без указания документа отгрузки. Получается нужен алгоритм, при котором накладная, проводимая после поступления аванса, должна неким образом привязаться к той сумме переплаты, которая образовалась и непосредственно к тем документам, которые образовали данную переплату (их может быть несколько).

Мысли двинули к построению регистра следующим образом (хотя в неком плане структура практически аналогичная с регистром УТ).

                                                              Структура регистра(оборотный)

Измерения:

Регистратор   (Тип: Документ.Накладная,Документ.Оплата)

Договор         (Тип: Справочник.Договор)

Ресурсы:

               Сумма (Тип: Число(14,2))

Реквизиты:

               ДокументСвязи (Тип: Документ.Накладная,Документ.Оплата)

В соответствие со структурой регистра и предполагаемого алгоритма движений документов Таблица1 в движениях регистра примет следующий вид(при отображении движений будет исключён договор так как он очевиден и Вид движения разбит на Расход, Приход):

Таблица2

Движения выстроены в хронологическом порядке!!!

По факту  результирующий инструмент для получения у нас в конечном варианте у нас готов… О том как получили данные движения по регистрам чуть позже, над алгоритмом ещё не думал.

Теперь возникает вопрос о получение данных из данного регистра в виде Таблицы1.

Построение отчёта

Тут пока напрашивается следующий вариант. Вариант объединения двух запросов. Сразу оговорюсь , каковы условия запросов. Нас абсолютно не интересуют те записи в которых нет ДокументаСвязи.

Структура полей первого запроса следующая:

Обязательства,Расход,Приход,Оплата, где у нас:

Обязательства – это регистратор имеющий тип Документ.Накладная

Расход    — при условии того что мы исключили записи регистра где нет Документа Связи , то данная сумма будет соответствовать, сумме на которую данная накладная закрывается конкретной выпиской (пример: пятое движение в Таблице2).

Приход – опять же при условии что когда мы выбираем данные только со связанными документами , сумма прихода у нас равняется сумме расхода(пример: пятое движение в Таблице2, трансформируется в третью строчку Таблицы1)

Оплата – это у нас соответственно будут документы в реквизите ДокументСвязи  и будут однозначно иметь тип Документ.Оплаты

Структура полей второго запроса будет прямо обратной первому запросу:

Обязательства – это будут документы из реквизита ДокументСвязи имеющие тип Документ.Накладная

Расход    — в расход у нас попадёт та сумма которая указана в приходе по движению(пример: вторая и третья запись в Таблице 2).

Приход – это будет сумма прихода по движению (пример: вторая и третья запись в Таблице2 соответственно трансформируется в первую и вторую запись в Таблице1 соответственно)

Оплата – это у нас соответственно будет регистратор имеющий тип Документ.Оплата

В итоге логика выборки данных:

1)      Нужно в обоих запросах выбрать движения не с пустым реквизитом ДокументСвязи

2)      В первом запросе выбираем движения соответствующие первому условию и где Регистратор имеет тип Документ.Накладная

3)      Во втором запросе выбираем движения опять же удовлетворяющие первому условию и где Регистратор имеет тип Документ.Оплата.

Дальнейшая логика сводится просто к объединению запросов.

Теперь осталось подумать об алгоритме движений документов.