Автоматический расчет стоимости

Теперь приступим ко второму этапу нашего плана.

До сих пор стоимость расходуемых материалов мы вписывали в документ Оказание услуги вручную, при его создании.

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

Чтобы выполнить такой расчет, нам понадобятся дополнительные данные, которых у нас сейчас нет.

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

• ее стоимость, хранящаяся в регистре СтоимостьМатериалов;
• общее ее количество на всех складах, хранящееся в регистре ОстаткиМатериалов.

Поэтому нам нужно будет доработать наш запрос таким образом, чтобы он получал из базы данных и эти данные тоже.

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

Рис. 14.9. Описание полей запроса

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

• стоимость — из регистра СтоимостьМатериалов;
• остатки на всех складах — из регистра ОстаткиМатериалов (рис. 14.10).

Рис. 14.10. Описание полей и таблиц запроса

Это значит, что наш запрос должен содержать два левых соединения таблицы документа с другими таблицами: одно — с таблицей РегистрНакопления.СтоимостьМатериалов.Остатки, другое — с таблицей РегистрНакопления.ОстаткиМатериалов.Остатки.

Казалось бы, все готово для того, чтобы составить запрос.

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

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

Но представьте реальную базу. В справочнике Номенклатура — 15 000 наименований, например. А в документе — всего 5 наименований. Получится, что сначала виртуальная таблица остатков будет усиленно трудиться и рассчитывать нам стоимость (или остатки) по всем 15 000 наименованиям номенклатуры, а в результате, когда мы левым соединением станем соединять ее с таблицей документа, мы из этих 15 000 строк стоимости (или остатков) возьмем всего лишь 5 строк — для той номенклатуры, которая указана в документе. Остальные 14 995 строк будут просто отброшены — система напрасно их рассчитывала.

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

В результате схема нашего запроса будет выглядеть следующим образом (рис. 14.11).

Рис. 14.11. Схема запроса

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

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

Выполнить эту задачу нам помогут временные таблицы.

Временные таблицы — это программные объекты, которые разработчик может создать и заполнить данными, а запросы могут использовать данные временных таблиц для своих нужд. Например, для наложения некоторого сложного условия, как в нашем случае.

Таким образом, схема нашего запроса приобретает следующий вид (рис. 14.12).

Рис. 14.12. Схема запроса

Итак, приступим.