gifts2017

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

Опубликовал Александр Терехин (anterehin) в раздел Программирование - Теория программирования

Алгоритм построения дебеторской задолженности с привязкой отгрузки и оплат

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

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

 

Таблица 1

 

 

Обязательства

Расход

Приход

Оплата

Накладная1(на 50000 руб)

30000

30000

Оплата1(на 30000 руб) 

Накладная1(на 50000 руб)

20000

20000

Оплата 2(на 40000 руб) 

Накладная2(на 30000 руб)

20000

20000

Оплата 2(на 40000 руб) 

Накладная2(на 30000 руб)

10000

10000

Оплата 3(на 10000 руб) 

Остаток

 

 

 

 

 

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

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

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

Измерения:

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

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

Ресурсы:

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

Реквизиты:

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

 

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

 

Таблица2

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

Регистратор

Расход

Приход

ДокументСвязи

Накладная1(на 50000 руб)

50000

 

 

Оплата 1(на 30000 руб) 

 

30000

Накладная1(на 50000 руб)

Оплата 2(на 40000 руб) 

 

20000

Накладная1(на 50000 руб)

Оплата 2(на 40000 руб) 

 

20000

 

Накладная2(на 30000 руб)

20000

 

Оплата 2(на 40000 руб) 

Накладная2(на 30000 руб)

10000

 

 

Оплата 3(на 10000 руб) 

 

10000

Накладная2(на 30000 руб)

 

 

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

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

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Максим Зудин (kasper076) 30.11.12 07:20
А что будет в случае если оплата закрывает несколько накладных или накладная закрывает несколько оплат (последнюю частично)??
2. Александр Медведев (anig99) 30.11.12 08:29
Рука тянется к минусу...
mxm2; amiralnar; Hany; +3 Ответить
3. Александр Терехин (anterehin) 30.11.12 13:04
В любом случае может быть ситуация когда есть либо накладная не полностью закрытая оплатами либо оплата частично или полностью образующая переплату... Такие моменты выбирать запросом и они будут образовывать либо задолженность либо переплату
4. Александр Терехин (anterehin) 30.11.12 13:05
После полного описания алгоритма движений документов и написания запроса отчётов выложу в полном формате.
5. Ловыгин Антон (wunderland) 30.11.12 17:16
Идея имеет место. Если добавить регистр и через события писать движения, то потом можно подробную историю ДЗ получить одним запросом.
6. serge_focus (serge_focus) 01.12.12 18:13
Идея имеет место. Но как показывает практика - при записи прихода денег необходиимо пересчитать по истории с актуального момента все расходы товаров и приходы денег, и правильно сформировать записи в учетный регистр.
А если еще и есть возвраты и корректировки... , а еще ошибки ползователей. То обьемчик нужной работы впечетляет... А без такой обработки - только ручное рознесение оплат - как реализовано в типовых конфигурациях.
7. Григорий Бельцев (gregb) 01.12.12 19:01
Рекомендую автору познакомиться с типовыми конфигурациями КА и УПП (движения по регистру "Расчеты по реализации (бухгалтерский учет)"). Похожие механизмы были в типовых еще со времен 7.7.
А вообще идея автоматического погашения долгов по FIFO в разрезе документов расчетов показала свою несостоятельность в реальной практике.
8. Александр Терехин (anterehin) 01.12.12 23:44
(7) gregb, Давайте не будем говорить про реализованные абстрактные идеи где то там... в УПП много реализовано идей... Как и в УТ.НО!!! когда возникает вопрос в реализации какого то механизма в самописной конфе... все посылают в типовые.. типа посмотри там и всё будет пучком. Я на 90% уверен что вы не сможете на базе демо версии реализовать данный механизм. Буду рад увидеть из демо версии конктертный пример на который я смогу опереться. Так как в УТ это выглядит так:
http://forum.infostart.ru/forum26/topic75420/
9. Александр Терехин (anterehin) 01.12.12 23:53
А вообще идея автоматического погашения долгов по FIFO в разрезе документов расчетов показала свою несостоятельность в реальной практике.

А тут никто не говорит про состоятельность!!! Вы вообще о чём? Об общем коммунизме? Так давайте опишем общую концепцую и закроем форум и будем листать толмуты в 20 томов. На то и создан форум чтобы обмениваться опытом. Я и не претендую что моё решение примет глобальный маштам и в следующем релизе 11-ой УТ его внедрят. Просто есть узкопрофильные задачи и народ зачастую не знает как их решить. Я только поделился своим мировоззрение. А если кому то это не надо то может сделать CTRL+C в УПП и CTRL+V в своей конфе.
10. Григорий Бельцев (gregb) 02.12.12 18:38
(8) anterehin,
Ваша аргументация поразительна - "я не разобрался с тем, как это сделано в типовой, поэтому буду собирать шишки пока у заказчика не закончится терпение". В типовых конфигурациях реализованы не абстрактные, а конкретные идеи. И если бы Вы нашли время и желание разобраться в этих механизмах, то не стали бы изобретать велосипед.
Если не хотите решать проблемы, возникающие после исправлений документов задним числом, которые непременно будут при использовании регистра, и не отлавливать все возможные варианты оплаты, могу предложить другой подход к Вашей задаче.
mxm2; anig99; +2 Ответить
11. mxm2 mxm2 (mxm2) 05.12.12 09:08
Посмотрите труды anig99 и/или Дебиторка fifo по долгам контрагентов (УТ 10.3). Регистр в любом случае страдает тем недостатком, что любое изменение "задним числом" будет вынуждать "восстанавливать последовательность".
anterehin; SOLTAN; +2 Ответить 1
12. Александр Терехин (anterehin) 05.12.12 15:26
(11) mxm2, С радостью почитаю.... несогласие просто не в том что не интересно разобраться , а в том что получить вводную информацию... Зачем кому то если он хочет собрать обычный тырчик на двухтактовом двигателе идти и смотреть как этот двигатель работает в мерседесе?
13. mxm2 mxm2 (mxm2) 05.12.12 16:29
(12) anterehin, Красивый пример, смотреть можно, чтобы не изобретать "велосипед" и избежать граблей, на которые дружно наступали до Вас (это, например, про регистры), к тому же двигатель от мерседеса, иногда проще даунгрейдить до 2 тактов, принципы то те же.

Ну, а если цель - прочувствовать эволюционное развитие методики, то - да, ... но времени это займет...
И может быть Вы изобретете, например, какой-нибудь роторно-клиновый ДВС, но пока Ваша метода сильно напоминает классическую модель, именно поэтому Вам указывают на её недостатки.
14. Михаил Ражиков (tango) 10.04.13 16:28
топтанными тропинками в тернии
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа