Добрый день! Пишу уже третий раз, так никто и не смог помочь, сам к сожалению так и не пришел к решению.
Вопрос, есть тз документа(он единственный) в нем беспорядочные займы, то есть один является должником для второго и в то же время кредитором для третьего, задача в том что нужно провести взаимозачеты и сократить таблицу до минимального кол-ва строк, чтобы при добавлении новых записей алгоритм не ломался и работал правильно, все действия проводить только в запросе, без постобработки и без помощи средств скд, как нужно правильно составить запрос? Делаю так, получил таблицу должников с группировкой по должнику и суммой, и таблицу кредиторов с группировкой по кредитору и суммой. Как теперь получить таблицу расчетов как на 3 скриншоте?
Вопрос, есть тз документа(он единственный) в нем беспорядочные займы, то есть один является должником для второго и в то же время кредитором для третьего, задача в том что нужно провести взаимозачеты и сократить таблицу до минимального кол-ва строк, чтобы при добавлении новых записей алгоритм не ломался и работал правильно, все действия проводить только в запросе, без постобработки и без помощи средств скд, как нужно правильно составить запрос? Делаю так, получил таблицу должников с группировкой по должнику и суммой, и таблицу кредиторов с группировкой по кредитору и суммой. Как теперь получить таблицу расчетов как на 3 скриншоте?
Прикрепленные файлы:
По теме из базы знаний
- Учет расчетов с филиалами и представительствами в 1С (проблемы и решения)
- Отчет по взаимозачетам и актам сверки, автоматическое создание актов сверок БП 3.0
- Автосоздание документов по взаимозачетам
- Проектный челлендж: переход с SAP на 1С:ERP за 1,5 месяца
- Интеграция 1С с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода - для УНФ, УТ, КА, ERP
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) В том и прикол, что не существует решения таким одним запросом, чтобы он был понятен начинающему изучать запросы. Это будет громоздкая и сложная абстракция, поскольку между этими таблицами нет взаимосвязей, нет приоритетов очередности (ну ладно, вместо приоритетов очередности можно от фонаря использовать АВТОНОМЕР()), и так далее... Это первое.
А второе - если бы ко мне пришел подаван с такой задачей, я бы его тряпками погнал бы. Такие задачи решаются без использования запросов (читай - это не дело СУБД).
А второе - если бы ко мне пришел подаван с такой задачей, я бы его тряпками погнал бы. Такие задачи решаются без использования запросов (читай - это не дело СУБД).
(6) ФИФО не прокатит. ФИФО - это когда одна конкретная сумма с ключом размазывается по нескольким остальным сумма с ключом в порядке приоритетности. Я делал запросом, я знаю.
В данной задаче нет взаимосвязанных ключей, как и приоритетности. И сумм несколько. Многие ко многим без единого ключа.
В данной задаче нет взаимосвязанных ключей, как и приоритетности. И сумм несколько. Многие ко многим без единого ключа.
(7) Это задача именно на ФИФО. Разве не очевидно? Расходы распределяются на приходы. Берете сумму из второй таблицы и распределяете ее по строкам первой. Известный рецепт "ФИФО в запросе" тут сработает. Впрочем, можно и не разбираться в таких тонкостях и просто спросить o1. Сразу получите тот же самый запрос, что и в статьях по ФИФО в запросе
(8)
Вторую сумму оплаты уже не размазать в этом же запросе, поскольку ты не поймешь - с какой долговой строки её размазывать после размазывания первой оплаты.
Вторая в поиске
Тут уже реальные ДВЕ таблицы. Но, как я и говорил - между ними есть ключ (Номенклатура), и поле приоритетности для связи на <= (Дата) и подсчета нарастающего итога.
И то же самое: для ключа существует только ОДНА распределяемая сумма во второй таблице. Ибо читай выше - вторую сумму оплаты уже не размазать, поскольку ты не поймешь - с какой долговой строки её размазывать после размазывания первой оплаты.
В задаче же приведенной здесь нет важной составляющей - ключа! Который бы однозначно связывал ОДНУ распределяемую сумму-источник слева с несколькими строками-получателями справа (или наоборот).
ФИФО в запросе
Ну вот, первая в поиске. Все именно так, как я и говорил - ОДНА сумма размазывается на несколько. Единственное, что в данном случае нет ключа связи между таблицами, поскольку сумма всего одна, она приходит единственным параметром, и связывать её ни с чем не надо. Есть параметр ключ приоритетности (Дата) для подсчета нарастающего итога методом связи на <=.
Вторую сумму оплаты уже не размазать в этом же запросе, поскольку ты не поймешь - с какой долговой строки её размазывать после размазывания первой оплаты.
Вторая в поиске
Тут уже реальные ДВЕ таблицы. Но, как я и говорил - между ними есть ключ (Номенклатура), и поле приоритетности для связи на <= (Дата) и подсчета нарастающего итога.
И то же самое: для ключа существует только ОДНА распределяемая сумма во второй таблице. Ибо читай выше - вторую сумму оплаты уже не размазать, поскольку ты не поймешь - с какой долговой строки её размазывать после размазывания первой оплаты.
В задаче же приведенной здесь нет важной составляющей - ключа! Который бы однозначно связывал ОДНУ распределяемую сумму-источник слева с несколькими строками-получателями справа (или наоборот).
(8) Остаётся один вариант - обратиться к твоем всемогущему ИИ. С нетерпением жду решения этой задачи одним запросом от ИИ.
Даже подскажу текст запроса "распределить несколько несвязанных сумм из одной таблицы по нескольким несвязанным сумма из другой таблицы".
Для подсчета нарастающего итога - так уж и быть, разрешу проавтонумеровать строки таблиц в запросе.
Даже подскажу текст запроса "распределить несколько несвязанных сумм из одной таблицы по нескольким несвязанным сумма из другой таблицы".
Для подсчета нарастающего итога - так уж и быть, разрешу проавтонумеровать строки таблиц в запросе.
(11) Да, есть такой вариант, нашел
Была у меня тоже мысль про пересекающиеся нарастающие итоги обеих таблиц. Но так как я не погружался в задачу целиком (своих достаточно) - то не стал раскручивать. Думаю, была бы такая потребность - я бы докрутил без проблем.
А в статье - да, все верно уже докручено. Одна левая сумма может закрываться тремя видами правых строк - хвост предыдущей , полная строка(и) в интервале, и голова следующей. Для этого надо установить три вида связи на вхождение правых строк в левый интервал. Так как интервал определяется двумя границами - до и после, то нам нужны по две нарастающих последовательности с обеих сторон.
Это явно задача не для обучающихся запросам.
Была у меня тоже мысль про пересекающиеся нарастающие итоги обеих таблиц. Но так как я не погружался в задачу целиком (своих достаточно) - то не стал раскручивать. Думаю, была бы такая потребность - я бы докрутил без проблем.
А в статье - да, все верно уже докручено. Одна левая сумма может закрываться тремя видами правых строк - хвост предыдущей , полная строка(и) в интервале, и голова следующей. Для этого надо установить три вида связи на вхождение правых строк в левый интервал. Так как интервал определяется двумя границами - до и после, то нам нужны по две нарастающих последовательности с обеих сторон.
Это явно задача не для обучающихся запросам.
(12) А теперь оцените возможности ИИ. Вы смутно понимаете как, но "докручивать" сейчас нет ресурсов. А тут 10 секунд и готово. Намного быстрее, чем гуглить и разбираться в нагугленном. Вот у автора так вообще не получилось разобраться, хоть ему и сказали, что гуглить
(13) Всё равно придётся разбираться.
1. Как минимум переписывать под свою структуру таблиц. Для это придётся понять.
2. И усиленно тестировать. Ибо алгоритм не твой, а ответственность нести тебе.
Акцептовать применение гуглорезультатов или чаторезультатов все равно должен человек.
1. Как минимум переписывать под свою структуру таблиц. Для это придётся понять.
2. И усиленно тестировать. Ибо алгоритм не твой, а ответственность нести тебе.
Акцептовать применение гуглорезультатов или чаторезультатов все равно должен человек.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот