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

Публикация № 92765

Разработка - Практика программирования

Данная статья описывает механизм получения всех реквизитов для движений партионного учета для всех документов, по всей номенклатуре, в рамках одного запроса. В качестве теоретической базы для данной статьи используется материал двух предыдущих статей автора – «Использование нарастающих итогов в партионном учете и не только» и «Вычисление нарастающего итога для N таблиц в рамках одного запроса».

В статье «Использование нарастающих итогов в партионном учете и не только» рассматривался вопрос получения всех реквизитов движений партионного учета (списания) для всей номенклатуры только одного документа. Зачастую построение движений партионного учета (списание) в организациях выполняется уже после ввода всех документов прихода и расхода товаров, сразу для всех документов расхода. Ниже рассматривается вариант решения данной задачи.

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

SELECT
 ТаблицаНоменклатуры.Номенклатура,
 tab1.Партия,
 CASE
  WHEN
   ( SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) ) > MAX( ТаблицаНоменклатуры.Количество )
  THEN
   MAX( ТаблицаНоменклатуры.Количество ) - SUM( ISNULL( tab2.КоличествоОстаток, 0 ) )
 ELSE
  MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) 
 END AS КоличествоСписания
FROM ТаблицаНоменклатуры
LEFT JOIN РегистрНакопления.ОстаткиНоменклатуры.Остатки AS tab1
ON ТаблицаНоменклатуры.Номенклатура = tab1.Номенклатура
LEFT JOIN РегистрНакопления.ОстаткиНоменклатуры.Остатки AS tab2
ON ( tab1.Номенклатура = tab2.Номенклатура ) AND ( tab1.Партия > tab2.Партия )
GROUP BY ТаблицаНоменклатуры.Номенклатура, tab1.Партия
HAVING SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) < MAX( ТаблицаНоменклатуры.Количество );

Вполне логичным решением для задачи обобщения данного запроса на случай множества документов вроде бы является следующий запрос:

SELECT
 ТаблицаДокументов.Документ,
 ТаблицаДокументов.Номенклатура,
 tab1.Партия,
 CASE
  WHEN
   ( SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) ) > MAX( ТаблицаДокументов.Количество )
  THEN
   MAX( ТаблицаДокументов.Количество ) - SUM( ISNULL( tab2.КоличествоОстаток, 0 ) )
 ELSE
  MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) 
 END AS КоличествоСписания
FROM ТаблицаДокументов 
LEFT JOIN РегистрНакопления.ОстаткиНоменклатуры.Остатки AS tab1
ON ТаблицаДокументов.Номенклатура = tab1.Номенклатура
LEFT JOIN РегистрНакопления.ОстаткиНоменклатуры.Остатки AS tab2
ON ( tab1.Номенклатура = tab2.Номенклатура ) AND ( tab1.Партия > tab2.Партия )
GROUP BY ТаблицаДокументов.Документ, ТаблицаДокументов.Номенклатура, tab1.Партия
HAVING SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) < MAX( ТаблицаДокументов.Количество );

Но на самом деле этот запрос является ошибочным. Основная проблема этого запроса это отсутствие «истории» списания партий по предыдущим строкам запроса. Поясню на следующем примере: допустим, мы имеем два документа и три партии, две из которых полностью списываются на первый документ, а одна - на второй. В приведенном выше запросе для первого документа списание пройдет правильно, а вот для второго документа количество с первой и второй партии будут списаны еще раз, так как нет информации какие именно партии и в каком количестве были списаны для предыдущего документа.

Однако, надо заметить, вопрос хранения «истории» уже решался - для правильного списания партий для одного документа и всего набора номенклатуры тоже необходима «история» предыдущих «списаний». В качестве механизма «сохранения истории» было применено вычисление «нарастающего итога» по таблице партий (в сумме «нарастающего итога» присутствовует информация о цифрах из предыдущих партий, что и позволяет учитывать «историю» по таблице партий). Следовательно, для получения возможности учитывать «историю» для «ТаблицыДокументов» нам необходима возможность получения по ней «нарастающего итога».

Таким образом, для получения запроса, дающего возможность «использовать историю» как для таблицы партий, так и для таблицы документов, необходима возможность получения нарастающих итогов для двух таблиц в рамках одного запроса. Теоретическая часть решения данной проблемы уже была описана ранее мною в статье «Вычисление нарастающего итога для N таблиц в рамках одного запроса». Здесь я приведу только конечный запрос:

SELECT
 tab_doc_1.Документ,
 tab_doc_1.Номенклатура,
 SUM( tab_doc_2.Количество) 
 \
 CASE
  WHEN
   COUNT( DISTINCT tab_part_2.Партия ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_part_2.Партия )
 END AS ДокСуммаПредыдущих,
 tab_part_1.Партия,
 SUM( tab_part_2.КоличествоОстаток ) 
 \
 CASE
  WHEN
   COUNT( DISTINCT tab_doc_2.Документ ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_doc_2.Документ )
 END AS ПартСуммаПредыдущих
FROM ТаблицаДокументов AS tab_doc_1
LEFT JOIN ТаблицаДокументов AS tab_doc_2
ON tab_doc_1.Документ > tab_doc_2.Документ
LEFT JOIN ТаблицаПартий AS tab_part_1
ON tab_doc_1.Номенклатура = tab_part_1.Номенклатура
LEFT JOIN ТаблицаПартий AS tab_part_2
ON ( tab_part_1.Номенклатура = tab_part_2.Номенклатура ) AND ( tab_part_1.Партия > tab_part_2.Партия )
GROUP BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия
ORDER BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия

В данном запросе есть вычисление «нарастающего итога» для двух таблиц, есть соединение «таблицы документов» и «таблицы партий» (каждая строка из «таблицы документов» соединяется со всеми строками из «таблицы партий»). Однако для окончательного решения вопроса нахождения всех реквизитов для движений списания осталось решить несколько вопросов. Во-первых, для каждого отдельного документа из «таблицы документов» важен не весь список партий, а только некоторые из них, партии с которых будет производиться списания по номенклатуре данного конкретного документа. Следовательно, необходимо получить выражение, ограничивающее список партий для каждого конкретного документа. Во-вторых, необходимы формулы, по которым будут рассчитываться значения числовых реквизитов движений списания (количество и сумма списания).

ВНИМАНИЕ!!!
В следующих запросах намеренно опущено деление на соответствующие множители при вычислении нарастающего итога (см. «Вычисление нарастающего итога для N таблиц в рамках одного запроса»). Сделано это для облегчения понимания материала читателем.

Сначала рассмотрим решение вопроса об ограничении списка партий для каждого конкретного документа.

Для дальнейшего правильного понимания всех нюансов проиллюстрируем «взаимоположения» документов и партий следующим рисунком:

ПОЯСНЕНИЕ.

На рисунках изображены все возможные варианты «взаимоположения» документов из таблицы документов и партий из таблицы партий. Для упрощения приняты следующие сокращения:

SUM(Док) - сумма по всем предыдущим документам;
SUM(Док)+MAX(Док) - нарастающий итог по документам;
SUM(Парт) - сумма по всем предыдущим партиям;
SUM(Парт)+MAX(Парт) - нарастающий итог по партиям;

Первично вернемся к запросу для одного документа и рассмотрим его выражение для ограничения списка партий:

HAVING SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) < MAX( ТаблицаНоменклатуры.Количество )

Учитывая то, что для множества документов необходимо учитывать предыдущую «историю» получим следующее выражение для ограничения списка партий «сверху» (отсекаем партии, которые будут участвовать в списаниях для документов, следующих после данного конкретного документа):

SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) < SUM( ISNULL( tab_doc_2.Количество, 0 ) ) + MAX( tab_doc_1.Количество )

Так как одна и та же партия может участвовать в списаниях для нескольких соседних документов, то кроме ограничения для списка партий «сверху» понадобиться также ограничение и «снизу» (ограничение «снизу» отсекает партии, которые были полностью списаны в движениях по документам, предшествующих данному конкретному документу). В запросе для одного документа это ограничение отсутствовало так как «точкой отсчета» для партий всегда являлся 0 (то есть можно было записать «SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) > 0», что не имело бы смысла).

Выражение для ограничения списка партий «снизу» имеет следующий вид:

SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) > SUM( ISNULL( tab_doc_2.Количество, 0 ) ) - MAX( tab_part_1.КоличествоОстаток)

Полное выражение для ограничения списка партий приведено в следующем запросе:

HAVING 
( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) < SUM( ISNULL( tab_doc_2.Количество, 0 ) ) + MAX( tab_doc_1.Количество ) ) 
AND
( SUM( ISNULL( tab_doc_2.Количество, 0 ) ) - MAX( tab_part_1.КоличествоОстаток) < SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) )

<ПРЕДУПРЕЖДЕНИЕ. Так как в выражении для ограничения списка партий применяется ограничение «сверху» и «снизу» для одной и той же величины, то возникает естественное желание оптимизации с помощью оператора BETWEEN. Единственная проблема здесь - данный оператор включает как верхнюю, так и нижнюю границы в область сравнения (фактически оператор сравнения «>» заменяется на «>=»). В результате это приводит к возникновению «пустых» движений - в выходной таблице запроса могут появиться строки с нулевыми значениями для количества и суммы списания.>

Теперь перейдем к выражению для получения количества списания для каждой конкретной партии. Прежде всего, опять запишем аналогичное выражение для случая одного документа:

CASE
 WHEN
  ( SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) ) > MAX( ТаблицаНоменклатуры.Количество )
 THEN
  MAX( ТаблицаНоменклатуры.Количество ) - SUM( ISNULL( tab2.КоличествоОстаток, 0 ) )
ELSE
 MAX( ISNULL( tab1.КоличествоОстаток, 0 ) )
END

Затем перепишем выражение в следующем виде:

CASE
 WHEN
  ( SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab1.КоличествоОстаток, 0 ) ) )
  > 
  MAX( ТаблицаНоменклатуры.Количество )
 THEN
  MAX( ТаблицаНоменклатуры.Количество )
ELSE
 SUM( ISNULL( tab2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab1.КоличествоОстаток, 0 ) )
END
-
SUM( ISNULL( tab2.КоличествоОстаток, 0 ) )

Последний запрос был переписан для иллюстрации того факта, что для вычисления количества списания для данной партии по данной номенклатуре используется разность между «верхней границей» (выражение под CASE) и «нижней границей». Рассмотрим обе эти «границы» более подробно. Для начала еще раз вернемся к рисунку, иллюстрирующему «взаимоположение» документов и партий (см. выше). Для случая одного документа и нескольких партий варианты «взаимодействия» ограничиваются рисунками с номерами 1 и 2. Как видно «нижняя граница» для случая одного документа всегда будет постоянна - одна и та же партия участвует только в списании по одному документу, так что варианты, иллюстрированные на рисунках 3 и 4, для случая одного документа отсутствует (точнее вырождаются в варианты, изображенные на рисунках 1 и 2 соответственно так как «нижняя граница» самой первой партии всегда равна 0). «Верхняя граница» определяется условием превышения нарастающего итога по таблице партий над общим количеством номенклатуры.

Для случая, когда в запросе присутствует множество документов со своими списками номенклатуры, ситуация остается примерно такой же, как и для случая одного документа. Выражение для количества списания также определяется разностью «верхней» и «нижней» границ. Добавляется только несколько отличительных моментов. Во-первых, необходимо учитывать «историю» как для таблицы партий, так и для таблицы документов. Следовательно, в выражении для «верхней границы» должна появиться «история» (сумма по предыдущим документам), а не просто выражение для количества. Во-вторых, в случае множества документов в перечень «взаимоположений» документов и партий полноценно появляются и варианты, проиллюстрированные на рисунках 3 и 4 (необходимо учитывать, что одна партия может участвовать в списании для нескольких документов). Выражение для количества списания в случае множества документов приведено в следующем запросе:

CASE
 WHEN
  ( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab_part_1.КоличествоОстаток, 0 ) ) )
  > 
  ( SUM( tab_doc_2.Количество ) + MAX( tab_doc_1.Количество ) )
 THEN
  ( SUM( tab_doc_2.Количество ) + MAX( tab_doc_1.Количество ) )
ELSE
 ( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab_part_1.КоличествоОстаток, 0 ) ) )
END
-
CASE
 WHEN
  SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) )
  <
  SUM( tab_doc_2.Количество )
 THEN
  SUM( tab_doc_2.Количество )
ELSE
 SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) )
END

Приведем теперь весь запрос для получения реквизитов движений:

SELECT
 tab_doc_1.Документ,
 tab_doc_1.Номенклатура,
 tab_part_1.Партия,
 (
 CASE
  WHEN
   ( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab_part_1.КоличествоОстаток, 0 ) ) )
   >
   ( SUM( tab_doc_2.Количество ) + MAX( tab_doc_1.Количество ) )
  THEN
   ( SUM( tab_doc_2.Количество ) + MAX( tab_doc_1.Количество ) )
 ELSE
  ( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) + MAX( ISNULL( tab_part_1.КоличествоОстаток, 0 ) ) )
 END<>  -
 CASE
  WHEN
   SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) )
   <
   SUM( tab_doc_2.Количество )
  THEN
   SUM( tab_doc_2.Количество )
 ELSE
  SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) )
 END
 ) AS КоличествоСписания
FROM ТаблицаДокументов AS tab_doc_1
LEFT JOIN ТаблицаДокументов AS tab_doc_2
ON tab_doc_1.Документ > tab_doc_2.Документ
LEFT JOIN ТаблицаПартий AS tab_part_1
ON tab_doc_1.Номенклатура = tab_part_1.Номенклатура
LEFT JOIN ТаблицаПартий AS tab_part_2
ON ( tab_part_1.Номенклатура = tab_part_2.Номенклатура ) AND ( tab_part_1.Партия > tab_part_2.Партия )
GROUP BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия
HAVING
( SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) < SUM( ISNULL( tab_doc_2.Количество, 0 ) ) + MAX( tab_doc_1.Количество ) )
AND
( SUM( ISNULL( tab_doc_2.Количество, 0 ) ) - MAX( tab_part_1.КоличествоОстаток) < SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) )
ORDER BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия

Добавляя деление на соответствующие корректирующие множители (см. «Вычисление нарастающего итога для N таблиц в рамках одного запроса») получаем следующий запрос:

SELECT
 tab_doc_1.Документ,
 tab_doc_1.Номенклатура,
 tab_part_1.Партия,
 CASE
  WHEN
  (
   SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
   CASE
    WHEN
     COUNT( DISTINCT tab_doc_2.Документ ) = 0
    THEN
     1
   ELSE
    COUNT( DISTINCT tab_doc_2.Документ )
   END + MAX( tab_part_1.КоличествоОстаток )
  )
  >
  (
   SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
   CASE
    WHEN
     COUNT( DISTINCT tab_part_2.Партия ) = 0
    THEN
     1
   ELSE
    COUNT( DISTINCT tab_part_2.Партия )
   END + MAX( tab_doc_1.Количество )
  )
  THEN
  (
   SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
   CASE
    WHEN
     COUNT( DISTINCT tab_part_2.Партия ) = 0
    THEN
     1
   ELSE
    COUNT( DISTINCT tab_part_2.Партия )
   END + MAX( tab_doc_1.Количество )
  )
 ELSE
  (
   SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
   CASE
    WHEN
     COUNT( DISTINCT tab_doc_2.Документ ) = 0
    THEN
     1
   ELSE
    COUNT( DISTINCT tab_doc_2.Документ )
   END + MAX( tab_part_1.КоличествоОстаток )
  )
 END
 -
 CASE
  WHEN
   (
    SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
    CASE
     WHEN
      COUNT( DISTINCT tab_part_2.Партия ) = 0
     THEN
      1
    ELSE
     COUNT( DISTINCT tab_part_2.Партия )
    END
   )
   >
   (
    SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
    CASE
     WHEN
      COUNT( DISTINCT tab_doc_2.Документ ) = 0
     THEN
      1
    ELSE
     COUNT( DISTINCT tab_doc_2.Документ )
    END
   )
  THEN
   (
    SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
    CASE
     WHEN
      COUNT( DISTINCT tab_part_2.Партия ) = 0
     THEN
      1
    ELSE
     COUNT( DISTINCT tab_part_2.Партия )
    END
   )
 ELSE
   (
    SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
    CASE
     WHEN
      COUNT( DISTINCT tab_doc_2.Документ ) = 0
     THEN
      1
    ELSE
     COUNT( DISTINCT tab_doc_2.Документ )
    END
   )
 END AS КоличествоСписания
FROM ТаблицаДокументов AS tab_doc_1
LEFT JOIN ТаблицаДокументов AS tab_doc_2
ON ( tab_doc_1.Номенклатура = tab_doc_2.Номенклатура ) AND ( tab_doc_1.Документ > tab_doc_2.Документ )
LEFT JOIN ТаблицаПартий AS tab_part_1
ON tab_doc_1.Номенклатура = tab_part_1.Номенклатура
LEFT JOIN ТаблицаПартий AS tab_part_2
ON ( tab_part_1.Номенклатура = tab_part_2.Номенклатура ) AND ( tab_part_1.Партия > tab_part_2.Партия )
GROUP BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия
HAVING
(
 SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
 CASE
  WHEN
   COUNT( DISTINCT tab_part_2.Партия ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_part_2.Партия )
 END + MAX( tab_doc_1.Количество ) 
 >
 SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
 CASE
  WHEN
   COUNT( DISTINCT tab_doc_2.Документ ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_doc_2.Документ )
 END
)
AND
(
 SUM( ISNULL( tab_doc_2.Количество, 0 ) ) /
 CASE
  WHEN
   COUNT( DISTINCT tab_part_2.Партия ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_part_2.Партия )
 END
 <
 SUM( ISNULL( tab_part_2.КоличествоОстаток, 0 ) ) /
 CASE
  WHEN
   COUNT( DISTINCT tab_doc_2.Документ ) = 0
  THEN
   1
 ELSE
  COUNT( DISTINCT tab_doc_2.Документ ) 
 END + MAX( tab_part_1.КоличествоОстаток )
)
ORDER BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия

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

Однако осталась еще одна очень важная деталь - соотношения моментов времени ввода документов и партий. В случае одного документа список партий получался просто - находились все партии, по которым есть остаток на дату документа. Но в случае множества документов необходимо находить подобный «остаток партий» для каждой строки из «таблицы документов», то есть накладывать еще одно ограничение для списка партий для каждого конкретного документа. Казалось бы, что может быть проще - напишем простое ограничение на соотношение моментов времени документа и партии:

SELECT
...
FROM ТаблицаДокументов AS tab_doc_1
LEFT JOIN ТаблицаДокументов AS tab_doc_2
ON ( tab_doc_1.Номенклатура = tab_doc_2.Номенклатура ) AND ( tab_doc_1.Документ > tab_doc_2.Документ )

Данное ограничение будет великолепно работать, но вот только в случае списания по методу FIFO. В случае списания по методу FIFO в «истории» для списка партий учитываются только партии, которые стоят по времени раньше данной текущей партии. Таким образом, накладывая ограничение из предыдущего запроса, мы получаем корректное значение «истории» для партии (если данная партия по времени ввода меньше данного документа, то и все партии из «истории» также заведомо меньше). Однако для случая списания по методу LIFO все несколько иначе: в «истории» партии учитываются значения для партий, которые идут позже. Таким образом, даже накладывая ограничение из предыдущего запроса, мы получим ошибочные значения в «истории» партий (в «истории» могут учитываться партии, которые были введены позднее данного документа). Следовательно, необходимо также накладывать ограничение на «историю» партий. Правильное выражение для учета соотношений моментов времени для документов и партий приведено в следующем запросе:

SELECT
...
FROM ТаблицаДокументов AS tab_doc_1
LEFT JOIN ТаблицаДокументов AS tab_doc_2
ON ( tab_doc_1.Номенклатура = tab_doc_2.Номенклатура ) AND ( tab_doc_1.Документ > tab_doc_2.Документ )
LEFT JOIN ТаблицаПартий AS tab_part_1
ON ( tab_doc_1.Номенклатура = tab_part_1.Номенклатура ) AND ( tab_doc_1.Документ > tab_part_1.Партия )
LEFT JOIN ТаблицаПартий AS tab_part_2
ON ( tab_part_1.Номенклатура = tab_part_2.Номенклатура ) AND ( tab_part_1.Партия > tab_part_2.Партия ) AND ( tab_doc_1.Документ > tab_part_2.Партия )
GROUP BY tab_doc_1.Документ, tab_doc_1.Номенклатура, tab_part_1.Партия

Но и этот вариант запроса имеет свои огрехи для случая списания по методу LIFO (а также в некоторых «спорных» случаях даже для списания по методу FIFO). Устранением этих «огрехов» я постараюсь заняться в следующих своих статьях. Пока же, в качестве разминки, предлагаю читателям самостоятельно найти проблемные места данного запроса.

Окончательный вариант запроса вместе с тестовым примером приведен в присоединенном к данной статье файле выгрузки. Конфигурация реализует управляемое приложение и разработана на релизе 8.2.14.528. 

Скачать файлы

Наименование Файл Версия Размер
Тестовая конфигурация

.dt 194,63Kb
12
.dt 194,63Kb 12 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. y-str 59 03.10.11 07:18 Сейчас в теме
Частично обсуждение данной статьи велось также в комментариях к другой моей публикации: Использование запросов с нарастающим итогом
2. alexk-is 6489 03.10.11 15:10 Сейчас в теме
(0) С нетерпением жду результатов нагрузочных испытаний.

Вот параметры реальной базы небольшой торговой организации:
Документов поступления товаров 5000, среднее количество строк в документе 10
Документов реализации товаров 30000, среднее количество строк в документе 5
3. y-str 59 03.10.11 15:30 Сейчас в теме
(2) Пока могу сказать, что простой запрос получения нарастающего итога для таблицы в 1 миллион записей вычислил значения для 50 000 записей примерно за час на достаточно слабой системе. То есть порядка 1000 строк за минуту. То есть для всего миллиона потребуется порядка 1000 минут. Учитывая, что в запросе применяется вычисление сразу двух нарастающих итогов получаем, что вычисление подобного запроса будет занимать порядка двух дней (на миллионе записей как по таблице документов, так и по таблице партий + на той системе, что доступна мне). Учитывая то, что на тестовой системе уровень загрузки процессоров (двух) был постоянно около отметки в 100% (использование памяти для вычисления было практически нулевым) считаю, что результат может быть существенно улучшен на профессиональных системах.

P.S.: тест проходил при тестировании native SQL-запроса, прямо на SQL Server 2008R2.
4. Ёпрст 1046 03.10.11 15:52 Сейчас в теме
Да уж.. Вот что значит кастрированный запрос в снеговике.
Изврат да и только.
Сутки ждать выполнения для мульта записей - это п..ц.
Светлый ум; +1 Ответить
5. y-str 59 03.10.11 17:13 Сейчас в теме
(4) Данная статья представляет собой основу для произвольной оптимизации. Возможно позже я возьмусь и за эту тему. На сегодняшний момент я считаю, что для любой оптимизации необходимо иметь (и четко понимать) саму "базу", которую в дальнейшем предстоит оптимизировать.
6. ildarovich 7195 03.10.11 18:47 Сейчас в теме
(4) Пусть автор меня поправит, но 1С не причем
P.S.: тест проходил при тестировании native SQL-запроса, прямо на SQL Server 2008R2.

(3) Неправда то, что
То есть для всего миллиона потребуется порядка 1000 минут.
- так как рост квадратичный. Для последних 50000 записей потребуется в 20х20=400 раз больше времени, то есть 400 часов.
Сомневаюсь, что
Учитывая, что в запросе применяется вычисление сразу двух нарастающих итогов получаем, что вычисление подобного запроса будет занимать порядка двух дней
Вроде бы там используется декартово соединение таблиц? 1000000х1000000?
7. y-str 59 03.10.11 19:04 Сейчас в теме
(6) ildarovich, соединение "все со всеми", совершенно верно. Но учитывая, что в результат попадают только выборочные "партии" я уменьшил их количество до "линейного" значения.
Про реальное "полное" время исполнения запрос - тест был прерван, результаты которые я получил, я описал здесь.
8. Ёпрст 1046 03.10.11 19:25 Сейчас в теме
(6) еще как причем!
на обычном t-sql используя все методы скуля этот запрос пишется совсем по-другому без таких извратов. И работает, ну никак не 2-е суток.

А дело как раз в недоделанности 8-ого запроса.
9. y-str 59 03.10.11 19:32 Сейчас в теме
(8) Я же писал что запускал "простой запрос получения нарастающего итога". Написан он был на Transact SQL. Этот запрос используется в моем запросе просто как основа, ничего более.
10. Ёпрст 1046 03.10.11 19:37 Сейчас в теме
(9) ну и ? Есть же over и т.д
+хранимку для реализации фифо.
11. y-str 59 03.10.11 19:40 Сейчас в теме
(10) Целью моего тестирования на SQL Server 2008R2 было проверить принципиальное время выполнения простейшего запроса с нарастающими итогами. Я его проверил. Оптимизация данного запроса например с использованием CTE выходит за рамки моей статьи, и тем более выходит за рамки моего теста.
12. Ёпрст 1046 03.10.11 19:51 Сейчас в теме
ну ясно, практический смысл отсутствует.
13. y-str 59 03.10.11 19:54 Сейчас в теме
(12) Хорошо, пусть для Вас "практический смысл" моей статьи будет нулевым, я удовлетворюсь этим фактом.
14. dkprim 5 11.10.11 18:35 Сейчас в теме
публикация полезная. автору спасибо. побольше бы таких, осмысленных статей.
15. y-str 59 11.10.11 18:40 Сейчас в теме
Оставьте свое сообщение

См. также

FormCodeGenerator Программная доработка форм. Часть 2 (Режим работы "Режим сравнения форм") на примере ERP 2.5 Промо

Практика программирования Адаптация типовых решений Прочие инструменты разработчика v8 1cv8.cf Абонемент ($m)

Данная публикация является продолжением описания функционирования обработки "FormCodeGenerator " в режиме сравнения форм и генерирования кода на основании сравнения. Подходит для перевода уже доработанных форм с интерактивной доработки на программную. Данный режим работы обработки снизит издержки при дальнейших обновлениях конфигураций.

5 стартмани

21.12.2020    2817    14    huxuxuya    11    

Интерактивная справка по объектам 1С (подключаемое расширение)

Практика программирования Работа с интерфейсом v8 ERP2 Абонемент ($m)

База знаний, подключаемая к объектам основной базы. Пополняется интерактивно, формируется в виде статей прямо в 1С (текст, картинки, таблицы, ссылки). Есть возможность прикрепления файлов, привязки к объектам 1С, возможности рейтинга и комментирования пользователями.

3 стартмани

29.09.2020    8722    50    sapervodichka    42    

Конвейер проверки качества кода

Инструментарий разработчика Практика программирования Математика и алгоритмы v8 1cv8.cf Абонемент ($m)

Jenkinsfile для выполнения проверки качества кода. Собирает информацию с АПК, EDT и BSL-LS. Сопоставляет ошибки с гит-репозиторием, выгруженным ГитКонвертором. Отправляет в Сонар.

3 стартмани

04.09.2019    28458    23    Stepa86    46    

Алгоритмы поиска пути в графе

Практика программирования Разработка v8 1cv8.cf Абонемент ($m)

Реализуем алгоритмы поиска пути в графе на платформе 1С 8.3, такие как алгоритм А*, поиск в ширину, жадный поиск, алгоритм Дейкстры и вконце волновой.

1 стартмани

09.07.2019    19163    12    RonX01    10    

Вам нравятся запросы в 1С? Промо

Практика программирования Разработка v8 v8::Запросы 1cv8.cf Абонемент ($m)

Речь не только о том, что простейший запрос с "легальным" оформлением растянется на пол-экрана, речь еще обо всем, что нужно написать "в нагрузку" к тексту запроса. Все эти "Новый Запрос", "УстановитьПараметр" и последующие пляски с обработкой результата... Пора с этим заканчивать!

1 стартмани

03.07.2019    22706    6    m-rv    88    

Работа с публикациями "Инфостарт"

Практика программирования О сообществе WEB v8 УУ Абонемент ($m)

Работа с рублевыми публикациями на сайте "Инфостарт": ведение клиентов, заказов, обновление файлов публикации, рассылка обновлений.

1 стартмани

13.09.2018    23410    13    RocKeR_13    16    

HTTP Сервисы: Путь к своему сервису. Часть 3

Инструментарий разработчика Практика программирования v8 1cv8.cf Абонемент ($m)

Продолжение статьи «HTTP Сервисы: Путь к своему сервису. Часть 2». В предыдущих частях мы использовали только Get, в этой части поговорим о других методах и длительных операциях.

1 стартмани

27.08.2018    42343    63    dsdred    17    

Позиционирование в помещении с помощью нейросети по сигналу Wi-Fi. Интерактивная карта склада в 1С с показом позиции

Инструментарий разработчика Практика программирования v8 Абонемент ($m)

Данная публикация содержит в себе редактор и интерактивную карту склада или иного помещения, на которой в реальном времени отображается позиция устройства, координаты которого вычисляются по уровням сигнала нескольких роутеров Wi-Fi. В статье и приложенным к ней разработкам предлагаются инструменты и методика для реализации вычисления точной геопозиции внутри помещений с помощью нейронной сети. Конфигурация написана на релизе 1С:Предприятие 8.3.12.1412, клиентское приложение имеет минимальный уровень совместимости SDK -16.

5 стартмани

09.08.2018    30232    26    informa1555    26    

ВСТАВИТЬ В Справочник.Номенклатура (Код, Наименование) ЗНАЧЕНИЯ ("001", "Новый товар") Промо

Практика программирования v8 v8::Запросы 1cv8.cf Абонемент ($m)

Вас не обманывают ваши глаза, это запрос на изменение данных! И это работает без прямого доступа к БД, регистрации и смс.

1 стартмани

01.06.2018    32004    88    m-rv    57    

Работа с данными выбора

Практика программирования Работа с интерфейсом v8 Россия Абонемент ($m)

В управляемом интерфейсе заложена мощная возможность описывать связи реквизитов формы через параметры. Установка параметров связей позволяет ограничить выбор данных так, чтобы целостность данных была обеспечена на этапе ввода. Однако без дополнительного программирования задать можно только самые простые связи. Такие условия связи, как зависимость от реквизита через точку или зависимость через дополнительное отношение, заданное в регистре сведений - уже задать без программирования не получится.

1 стартмани

17.07.2018    54032    20    kalyaka    16    

Полезные примеры составления схемы компоновки данных #2

Практика программирования v8 v8::СКД 1cv8.cf Абонемент ($m)

Еще один набор примеров как решить частные задачи в СКД

1 стартмани

22.05.2018    33759    11    SITR-utyos    13    

Печатная форма, сделанная как расширение конфигурации для БП 3.0. Новые возможности БСП

Практика программирования Универсальные печатные формы v8 БП3.0 Абонемент ($m)

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

1 стартмани

06.12.2017    28442    54    kwazi    6    

Заполняем по шаблону (по умолчанию) Промо

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

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

1 стартмани

08.02.2018    29999    20    mvxyz    17    

Паузы при исполнении кода (Sleep для 1С)

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

Решил проверить все найденные варианты паузы для 1С. В результате получилась обработка для тестирования и небольшая статья с итогом.

1 стартмани

28.11.2017    52741    13    swimdog    44    

Макет в СКД - пример всех возможных типовых вариантов

Практика программирования Инструментарий разработчика v8 v8::СКД 1cv8.cf Абонемент ($m)

Макет СКД: наглядное представление того, что, как и куда выводится при типовых настройках.

1 стартмани

09.11.2017    23368    77    freelancer    4    

Telegram-боты

Практика программирования v8 Абонемент ($m)

Описание теории, разбор архитектуры и пример реализации telegram-ботов. Сразу скажу, со структурированием изложения мало что могу поделать. :) редакция от 18.07.2018 Правки последней редакции выделены жирным.

1 стартмани

01.09.2017    35657    136    PLAstic    59    

Нечеткий поиск одним запросом Промо

Практика программирования v8 1cv8.cf Абонемент ($m)

Использование механизма полнотекстового поиска в 1С не всегда оправдано, т.к. построение индекса и поддержание его в актуальном состоянии может значительно нагружать систему. Предлагаемая реализация нечеткого поиска методом N-грамм выполняется одним запросом, что позволяет производить поиск в любой таблице и не требует предварительного построения индекса.

1 стартмани

28.12.2015    29540    71    vasvl123    9    

Умный дом на 1С + ардуино

Практика программирования v8 Абонемент ($m)

Конфигурация для автоматизации быта программиста 1C и не только. В данной статье будет рассказано, как можно использовать 1С для задач, не входящих в стандартные рамки этой платформы. Например, управление домом. В качестве периферии для подключения будет использован микроконтроллер (МК) Ардуино, но на нём не будет никакой логической нагрузки, весь процесс будет проходить на сервере 1С. Работа с пинами ввода/вывода происходит напрямую из 1С.

1 стартмани

07.08.2017    24411    21    sasha777666    64    

Расширения конфигураций 1С: учимся перехватывать методы

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

В этой статье я на примерах разберу некоторые механизмы расширений конфигураций 1С. А именно «перехваты» методов модуля объекта и «перехваты» событий формы и элементов формы. Данная статья написана с учебными целями, чтобы показать, как при помощи расширений конфигурации можно делать такие доработки, ради которых раньше приходилось снимать конфигурацию с поддержки.

1 стартмани

30.05.2017    142487    13    signum2009    48    

Регулярные выражения – это просто. Построитель и отладчик регулярных выражений

Инструментарий разработчика Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

13.03.2017    33421    117    romasna    49    

1С: Предприятие + корпоративный чат, как наладить оперативные уведомления за 10 минут Промо

Практика программирования v8 Абонемент ($m)

Как сделать автоматические уведомления о разных событиях из 1С в корпоративный чат MyChat для сотрудников компании

1 стартмани

14.08.2016    49963    36    Demanoidos    60    

Распознавание текста с помощью нейросетей Google Cloud Vision и 1С

Практика программирования v8 1cv8.cf Абонемент ($m)

Возможности Google Cloud Vision в распознавании текста.

1 стартмани

08.02.2017    32208    134    kiv1c    18    

Графическая схема. Управление при помощи XDTO.

Практика программирования v8 Абонемент ($m)

В статье описывается методика программного управления элементами графической схемы при помощи механизма XDTO. Приложена готовая к использованию библиотека функций для создания и удаления графических объектов, а также для связи элементов схемы соединительными линиями.

2 стартмани

16.01.2017    24458    109    Alxby    23    

Простой редактор плана помещения JavaScript

Практика программирования Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

На ресурсе сейчас очень много решений, которые позволяют редактировать карты, используя географические схемы. Так же много решений, которые позволяют редактировать объекты онлайн веб-карт. Мне же нужно было простое решение, для того чтобы расставить квадратные объекты на плане, показать их пользователю. Ну и распечатать, опять же. Я решил написать простенький редактор на JavaScript с использованием библиотеки Raphael.

1 стартмани

23.11.2016    22694    99    igel9780    22    

Быстрое определение интервалов в запросе Промо

Практика программирования v8 Абонемент ($m)

В статье описывается новый метод определения интервалов между данными различных записей в запросе. В отличие от общеизвестного метода, время работы предлагаемого метода зависит от объема данных ЛИНЕЙНО. Это обеспечивает ему значительный выигрыш по быстродействию на больших объемах данных. В качестве иллюстрации возможностей метода приведен отчет, показывающий гистограмму распределения времени между продажами.

1 стартмани

01.10.2015    54359    35    ildarovich    41    

Работа с двоичными данными на примере чтения файлов изображений. Новые возможности 8.3.9

Практика программирования WEB v8 1cv8.cf Россия Абонемент ($m)

В статье приводятся новые функции по работе с двоичными данными, появившимися в версии платформы 8.3.9 , на примере анализа формата и размера изображений. А также пример отправки изображения через API ВКонтакте с помощью новых объектов (без использования ОбъединитьФайлы())

1 стартмани

14.11.2016    28800    16    Anton64    22    

Загрузка файлов на сервер с прогрессом и докачкой

Практика программирования v8 1cv8.cf Россия Абонемент ($m)

Пример использования новых возможностей платформы 8.3.9 по низкоуровневой работе с двоичными данными для инкрементальной передачи файлов на сервер.

1 стартмани

04.10.2016    14467    53    mrstomak    21    

Несколько шаблонов для доработки типовых конфигураций

Практика программирования Инструментарий разработчика v8 v8::УФ Абонемент ($m)

Предлагаю несколько каркасов для создания новых объектов в типовых конфигурациях. Это выжимка из кода нескольких конфигураций, которая позволит быстро и красиво создавать и дорабатывать объекты метаданных с соблюдением идеологии исходной системы

1 стартмани

03.10.2016    38270    96    json    25    

HTTP-сервис: отчеты [Расширение]

Практика программирования Работа с интерфейсом v8 1cv8.cf Абонемент ($m)

Это HTTP-сервис, который возвращает почти любой отчет в HTML, XLSX или в JSON. Сохраните вариант отчета, получите на него ссылку и можно получить данные без захода в 1С. Работает в конфигурациях на основе БСП 2.3.3+, для отчетов на СКД и в 1С 8.3.8+

2 стартмани

30.08.2016    28726    143    Stepa86    15    

Недокументированное использование стандартных форм Upd.

Практика программирования v8 v8::УФ 1cv8.cf Абонемент ($m)

Вам не хватает возможностей в платформе 1С или у Вас нет времени на углубленное изучение платформы 1С? Рассмотрены возможности использования стандартных форм, вызываемых из платформы.

1 стартмани

26.07.2016    30017    86    ZhokhovM    60    

Хранение файлов в томах на диске (для УПП 1.3)

Практика программирования v8 УПП1 Абонемент ($m)

Доработка типовой УПП 1.3 в плане хранения присоединенных файлов вне базы данных

2 стартмани

05.06.2016    60494    11    wowik    32    

БСП 2.3 и БСП 3.0: Просто про выполнение внешней обработки в фоне (c индикацией прогресса выполнения)

Инструментарий разработчика Практика программирования БСП (Библиотека стандартных подсистем) v8 1cv8.cf Абонемент ($m)

Простое пояснение о том, как сделать внешнюю обработку с фоновым выполнением и индикацией процесса для любой конфигурации на основе БСП 2.3.2. UPDATE 20/09/19: добавлен вариант обработки с индикацией процента выполнения и статусом выполнения для БСП 3.0.

1 стартмани

18.05.2016    65606    194    rozer    66    

Остатки на каждый день в запросе

Практика программирования Учет ТМЦ Учет ТМЦ v8 1cv8.cf УУ Абонемент ($m)

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

1 стартмани

26.04.2016    64421    19    arakelyan    20    

Еще один способ расчета остатков на каждый день в запросе

Математика и алгоритмы Практика программирования v8 Абонемент ($m)

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

1 стартмани

24.04.2016    36354    51    ildarovich    23    

Вывод печатных форм с запросом данных в форму "Печать документов" из подсистемы БСП "Печать".

Практика программирования БСП (Библиотека стандартных подсистем) v8 1cv8.cf Абонемент ($m)

Все не раз видели, как в типовых конфигурациях, построенных на основе БСП (Библиотека стандартных подсистем), печатные формы, построенные на основе Табличного документа, выводятся в специальную форму "ПечатьДокументов". Эта форма входит в состав подсистемы "Печать" из БСП. При разработке своих печатных форм, иногда необходимо запросить у пользователя дополнительные данные необходимые для печати. Тут встает вопрос, как в этом случае вывести печатную форму в форму "Печать документа". В этой статье я рассмотрю, как реализовать вывод печатной формы в упомянутую форму из подсистемы "Печать", в случае если мы хотим перед выводом печатной формы запросить у пользователя дополнительные данные. Здесь будут рассмотрены два случая: когда реализуется печатная форма с использованием подсистемы "Дополнительные отчеты и обработки" и когда печатная форма добавляется в конфигурацию в режиме конфигуратора, т.е. вносятся изменения в типовую конфигурацию.

1 стартмани

29.03.2016    98155    190    lopatin    14    

Выполнение JavaScript кода из 1С в объекте Поле HTML Документа (HTML 5) и вызов события в 1С ПриНажатии

Практика программирования v8 1cv8.cf Россия Абонемент ($m)

Пример выполнения JS кода из 1С в Поле HTML Документа под управляемыми формами, с удобным получением результата в 1С(С помощью вызова привязанного события ПриНажатии к элементу ПолеHTMLДокумента)

1 стартмани

22.03.2016    85607    163    igo1    54    

Количество дней недели (понедельников/вторников/...) в заданном диапазоне одним запросом

Практика программирования v8 Абонемент ($m)

При реализации периодического авто-заполнения маршрутных листов по графику (недельному) необходимо было просчитать стоимость всего периода, с условием выездов только по определенным дням. Заморачиваться с обходом результата не хотелось. Пришлось написать "Небольшой" запрос.

1 стартмани

03.03.2016    19517    1    Alexander.Shvets    5    

Простые радости жизни программиста 1С: выбор типа значения

Работа с интерфейсом Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

17.02.2016    52692    54    yuraos    18    

Отображение прогресса выполнения длительных операций в БСП и их отладка в текущем сеансе.

Практика программирования БСП (Библиотека стандартных подсистем) v8 1cv8.cf Абонемент ($m)

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

1 стартмани

17.02.2016    59299    194    balanton    23    

Яндекс.Деньги "Благотворительность"

Инструментарий разработчика Практика программирования v8 1cv8.cf Абонемент ($m)

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

1 стартмани

16.02.2016    24628    8    Tatitutu    5    

Мастер рассылки e-mail 2.2 для управляемых форм

Практика программирования Email v8 v8::УФ ERP2 БП3.0 УТ11 Абонемент ($m)

Для пользователей: переделанный из старый разработки под 8.2 с использованием библиотеки Мастер рассылки e-mail 2.2 (ERP, УТ, БП) (Только управляемые формы), который теперь может запускаться под любой версией платформы с разрешенными или запрещенными модальными/синхронными вызовами в конфигурации. Также удобный выбор e-mail и их владельцев с помощью отбора динамического списка по любым критериям и галочки исключения.

1 стартмани

29.12.2015    40799    20    milkers    4