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

30.11.12

Разработка - Математика и алгоритмы

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

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

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

 

Таблица 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)      Во втором запросе выбираем движения опять же удовлетворяющие первому условию и где Регистратор имеет тип Документ.Оплата.

 

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

 

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

См. также

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11 / КА 2 / ERP 2. Переносятся документы, справочники и остатки

Обмен между базами 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)

Предлагаем качественное и проверенное временем решение для перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2. Перенос данных находится в продаже с 2015 года, постоянно развивается, им воспользовались уже более 240 компаний. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

50722 45650 руб.

24.04.2015    190284    268    238    

268

"Акты сверки +" Групповая подготовка и рассылка актов сверки для Бухгалтерии 3.0.

Взаиморасчеты Email рассылки Акт сверки Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Платные (руб)

Внешняя обработка для Бухгалтерии 3.0 - позволяет автоматически формировать документы «Акт сверки расчетов» с контрагентами за выбранный период с последующей фоновой отправкой на почту контрагента.

3000 руб.

25.11.2020    21987    157    4    

146

Перенос начальных остатков из Парус 7.71 в БГУ

Внешние источники данных Взаиморасчеты Учет ОС и НМА Логистика, склад и ТМЦ Бюджетный учет Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 2.0 1С:Бухгалтерия государственного учреждения Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Перенос словарей и начальных остатков из ПП Парус-Бухгалтерия Бюджет 7.71 в 1Сv8 БГУ2. Заполнение словарей и документов по вводу начальных остатков. Не требуется установка ПП Парус7. Возможна дозагрузка. Позволит автоматически и наиболее полно ввести данные в программу для начала работы. 

15600 руб.

08.12.2011    81470    128    123    

146

УТ 11, КА 2, ERP 2: Настраиваемые под каждую организацию печать и подпись ответственных лиц в печатных формах (ТОРГ-12, Счёт-фактура, УПД, УКД, Заказ клиента, Акт сверки, М-15 и др.)

Печатные формы Взаиморасчеты Оптовая торговля Производство готовой продукции (работ, услуг) Акт сверки Оперативный учет Управляемые формы 1С:Управление торговлей 11 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Задайте для каждой организации свою печать и для каждого физического лица свою подпись. Выберите в документе печатную форму "... с печатью и подписью" - и автоматически сформируется табличный документ с печатью и подписями той организации и ответственных лиц, которые указаны в документе.

12000 руб.

13.03.2018    56266    176    76    

112

Автоматический зачет авансов в 1С:УНФ по ФИФО

Взаиморасчеты Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

Знаем о взаиморасчетах в Управлении нашей фирмой все, что только можно знать. Самая большая проблема взаиморасчетов в УНФ в том, что зависают непонятные долги и предоплаты, в Пульсе бизнеса показываются неадекватные цифры, отчеты по долгам показывают не пойми что.

12000 руб.

22.07.2021    23470    24    34    

31

Дебиторская задолженность по срокам долга

Взаиморасчеты Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Бухгалтерский учет Управленческий учет Платные (руб)

Один из лучших вариантов отчета по дебиторской задолженности. Отображает сроки возникновения задолженности, просроченной задолженности с точностью до регистратора, а также многое другое, вне зависимости от схемы взаиморасчетов (online / offline) и объекта расчетов (УТ 11.3, 11.4, 11.5, КА 2.4, 2.5, ERP 2.4, 2.5), состояния флажка "по документам расчета" ( УТ 10, КА 1.1, УПП 1.3) в договоре. Группирует задолженность по интервалам. Имеет большое количество настроек. Не требует доработок конфигурации.

13800 руб.

28.09.2012    94391    588    268    

139

Управление автосервисом на платформе 1С 8.3

Управление взаимоотношениями с клиентами (CRM) Взаиморасчеты Производство готовой продукции (работ, услуг) Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Автомобили, автосервисы Управленческий учет Платные (руб)

Профессиональная программа по управлению автосервисом на платформе 1С 8.3 - все что нужно для решения задач учета и контроля в автосервисах. Увеличьте прибыльность автосервиса за счет отлаженных процессов в 1С. Еще никогда контроль и учет в автосервисе не были такими простыми, доступными и наглядными!

18000 руб.

27.11.2015    65067    30    40    

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

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

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