Данное творчество появилось на основании поставленной задачи, которая заключается в следующем.
Задача: Сделать для коммерческого отдела отчёт по дебиторской задолженности в следующем виде.
Таблица 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) Во втором запросе выбираем движения опять же удовлетворяющие первому условию и где Регистратор имеет тип Документ.Оплата.
Дальнейшая логика сводится просто к объединению запросов.
Теперь осталось подумать об алгоритме движений документов.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
А что будет в случае если оплата закрывает несколько накладных или накладная закрывает несколько оплат (последнюю частично)??
Рука тянется к минусу…
В любом случае может быть ситуация когда есть либо накладная не полностью закрытая оплатами либо оплата частично или полностью образующая переплату… Такие моменты выбирать запросом и они будут образовывать либо задолженность либо переплату
После полного описания алгоритма движений документов и написания запроса отчётов выложу в полном формате.
Идея имеет место. Если добавить регистр и через события писать движения, то потом можно подробную историю ДЗ получить одним запросом.
Идея имеет место. Но как показывает практика — при записи прихода денег необходиимо пересчитать по истории с актуального момента все расходы товаров и приходы денег, и правильно сформировать записи в учетный регистр.
А если еще и есть возвраты и корректировки… , а еще ошибки ползователей. То обьемчик нужной работы впечетляет… А без такой обработки — только ручное рознесение оплат — как реализовано в типовых конфигурациях.
Рекомендую автору познакомиться с типовыми конфигурациями КА и УПП (движения по регистру «Расчеты по реализации (бухгалтерский учет)»). Похожие механизмы были в типовых еще со времен 7.7.
А вообще идея автоматического погашения долгов по FIFO в разрезе документов расчетов показала свою несостоятельность в реальной практике.
(7) gregb, Давайте не будем говорить про реализованные абстрактные идеи где то там… в УПП много реализовано идей… Как и в УТ.НО!!! когда возникает вопрос в реализации какого то механизма в самописной конфе… все посылают в типовые.. типа посмотри там и всё будет пучком. Я на 90% уверен что вы не сможете на базе демо версии реализовать данный механизм. Буду рад увидеть из демо версии конктертный пример на который я смогу опереться. Так как в УТ это выглядит так:
А тут никто не говорит про состоятельность!!! Вы вообще о чём? Об общем коммунизме? Так давайте опишем общую концепцую и закроем форум и будем листать толмуты в 20 томов. На то и создан форум чтобы обмениваться опытом. Я и не претендую что моё решение примет глобальный маштам и в следующем релизе 11-ой УТ его внедрят. Просто есть узкопрофильные задачи и народ зачастую не знает как их решить. Я только поделился своим мировоззрение. А если кому то это не надо то может сделать CTRL+C в УПП и CTRL+V в своей конфе.
(8)
Ваша аргументация поразительна — «я не разобрался с тем, как это сделано в типовой, поэтому буду собирать шишки пока у заказчика не закончится терпение». В типовых конфигурациях реализованы не абстрактные, а конкретные идеи. И если бы Вы нашли время и желание разобраться в этих механизмах, то не стали бы изобретать велосипед.
Если не хотите решать проблемы, возникающие после исправлений документов задним числом, которые непременно будут при использовании регистра, и не отлавливать все возможные варианты оплаты, могу предложить другой подход к Вашей задаче.
Посмотрите труды и/или Регистр в любом случае страдает тем недостатком, что любое изменение «задним числом» будет вынуждать «восстанавливать последовательность».
(11) mxm2, С радостью почитаю…. несогласие просто не в том что не интересно разобраться , а в том что получить вводную информацию… Зачем кому то если он хочет собрать обычный тырчик на двухтактовом двигателе идти и смотреть как этот двигатель работает в мерседесе?
(12) Красивый пример, смотреть можно, чтобы не изобретать «велосипед» и избежать граблей, на которые дружно наступали до Вас (это, например, про регистры), к тому же двигатель от мерседеса, иногда проще даунгрейдить до 2 тактов, принципы то те же.
Ну, а если цель — прочувствовать эволюционное развитие методики, то — да, … но времени это займет…
И может быть Вы изобретете, например, какой-нибудь роторно-клиновый ДВС, но пока Ваша метода сильно напоминает классическую модель, именно поэтому Вам указывают на её недостатки.
топтанными тропинками в тернии