Использование функции ЗАДЕРЖКИ для создания записей для клиента

#oracle #lag

#Oracle #задержка

Вопрос:

У меня есть приведенная ниже настройка, которая используется только для объяснения проблемы

Здесь автомобиль является приобретенным транспортным средством по умолчанию, если никакое другое транспортное средство не куплено

Логика заключается в том, что если есть массовый платеж, то он должен быть разделен по транспортным средствам в разделе «Дебетовый клиент»

Фактическая транзакция происходит следующим образом

 bought date              Bought   Credit_Acc  Debit Customer  paid_date
-----------              ------   ----------  --------------  ----------
 1-jan-2019              Bike      10k         0             03-Jan-2019
 2-jan-2019              cycle     20k         0             03-Jan-2019
 3-jan-2019              Car       30k        60k            03-Jan-2019
  

Но Клиент хочет, чтобы финансовый отчет был таким, как показано ниже

  bought date             Bought   Credit_Acc  Debit Customer  paid_date
-----------              ------   ----------  --------------  ----------
 1-jan-2019              Bike      10k         10k             03-Jan-2019
 2-jan-2019              cycle     20k         20k             03-Jan-2019
 3-jan-2019              Car       30k         30k             03-Jan-2019
  

Также иногда, если он платит только 15 тыс., которые записываются в разделе «Дебетовый клиент»
для даты покупки 03 января 2019 года отчет должен быть

  bought date             Bought   Credit_Acc  Debit Customer      paid_date
-----------              ------   ----------  --------------  ----------
 1-jan-2019              Bike      10k         10k                 03-Jan-2019        
 2-jan-2019              cycle     20k         5k                  03-Jan-2019    
 3-jan-2019              Car       30k         0(15k actual data)  03-Jan-2019            
  

Итак, после этого платежа в размере 15 тыс., 04 января 2019 года выполняется еще один платеж в размере 15 тыс., затем в таблице базы дебетовых клиентов записывается 30 тыс., но в отчете должно быть показано следующее

  bought date             Bought   Credit_Acc  Debit Customer      paid_date
-----------              ------   ----------  --------------  ----------
 1-jan-2019              Bike      10k         10k                04-Jan-2019        
 2-jan-2019              cycle     20k         20k                04-Jan-2019
 3-jan-2019              Car       30k         0(30k actual data) 04-Jan-2019            
  

Затем после этого платежа 05 января 2019 года производится еще 30 тыс., затем 60 тыс. записывается в таблицу базы дебетовых клиентов, но в отчете должно быть показано следующее

  bought date             Bought   Credit_Acc  Debit Customer        paid_date
-----------              ------   ----------  --------------  ----------     
 1-jan-2019              Bike      10k         10k                 05-Jan-2019        
 2-jan-2019              cycle     20k         20k                 05-Jan-2019
 3-jan-2019              Car       30k         30k(60k actual data)05-Jan-2019            
  

СТРУКТУРА ТАБЛИЦЫ

 VALUE DATE (bought date/paid date)  
ITEM (Bought)  
Debit_Entry (Debit Customer) 
Credit_Entry (Credit_Acc)
  

Комментарии:

1. На данный момент это не очень понятно. Какие данные на самом деле находятся в вашей таблице (ах)? Где записано 15 КБ? Какова логика вывода? И какой порядок вы применяете здесь — есть ли дата, которую вы не указали, например?

2. @AlexPoole я обновил информацию, 15 тысяч записаны в разделе «Дебетовый клиент»

3. логика заключается в том, что если я произвожу массовый платеж, то он должен быть разделен на разные учетные записи в разделе «дебетовый клиент»

4. Итак, есть ли (по крайней мере) две таблицы, одна с покупками, а другая с платежами? И то, что вы показали, должно быть запросом текущего баланса на момент времени, с платежами, применяемыми к покупкам в порядке даты? Опять же, покажите ваши фактические данные таблицы (и структуры) и покажите, как эти базовые данные изменяются по мере покупки товаров и осуществления платежей, и что ваш запрос (если это то, что вам нужно) должен показывать на каждом этапе.

5. На самом деле есть только одна дата, которая является датой стоимости с тегами, используемыми для определения того, является ли это датой покупки или датой оплаты, с которой я могу справиться, моя проблема заключается в обработке разделенной суммы в дебетовом клиенте

Ответ №1:

По вашему вопросу трудно сказать, поскольку данные базовой таблицы по-прежнему не отображаются, но, похоже, вы хотите что-то вроде:

 select value_date, item, credit_entry, item_paid
from (
  select value_date, item, credit_entry, debit_entry,
    greatest(0, least(credit_entry, nvl(sum(debit_entry) over (), 0)
      - nvl(sum(credit_entry) over (order by value_date
          rows between unbounded preceding and 1 preceding), 0))) as item_paid
  from your_table
)
where item is not null;
  

db<>скрипка

Для каждой строки в таблице суммируется общая сумма дебета и вычитается общая сумма кредита до (но не включая) этой строки. Если этот общий платеж больше, чем кредит текущей строки, то значение кредита используется как есть; если оно отрицательное (поскольку текущий товар вообще не был оплачен), то вместо этого используется ноль; в противном случае используется вычисленное значение, которое представляет собой сумму кредита этого товара, которая была выплачена — после рассмотрения всех предыдущих позиций.