Итоги в динамическом списке

Как быстро посчитать итоги в динамическом списке

Добрый день, коллеги.

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

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

Его главное достоинство — простота. Дело в том что, с недавних пор в динамических списках появилась возможность использовать временные таблицы в запросах и как следствие пакетные запросы.

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

ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента,
ВложенныйЗапрос.СуммаДокументаИтог КАК СуммаДокументаИтог
ИЗ
Документ.Документ1 КАК Документ1,
(ВЫБРАТЬ
СУММА(Документ1.СуммаДокумента) КАК СуммаДокументаИтог
ИЗ
Документ.Документ1 КАК Документ1) КАК ВложенныйЗапрос

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

1) отборы динамического списка будут установленны на самый первый запрос в пакете

2) выбрать основную таблицу можно будет только из физических таблиц присутствующих в последнем запросе пакета — далее покажу на примере.

Итак, есть некий динамический список с полями числового типа, и требуется по ним рассчитать итоги, в моем примере это некий документ, у которого есть колонка «СуммаДокумента» (см. скриншот):

1-й вариант запроса будет не даст нам возможность указать Документ1 в качестве основной таблицы, как следствие с динамическим списком не будет возможности работать стандартным способом и не будет динамического чтения данных, однако он будет учитывать итоги с учетом отборов. Я покажу его в качестве примера того как делать не нужно:

ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента
ПОМЕСТИТЬ ВТОсновнаяТаблица
ИЗ
Документ.Документ1 КАК Документ1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТОсновнаяТаблица.Ссылка КАК Ссылка,
ВТОсновнаяТаблица.ВерсияДанных КАК ВерсияДанных,
ВТОсновнаяТаблица.ПометкаУдаления КАК ПометкаУдаления,
ВТОсновнаяТаблица.Номер КАК Номер,
ВТОсновнаяТаблица.Дата КАК Дата,
ВТОсновнаяТаблица.Проведен КАК Проведен,
ВТОсновнаяТаблица.СуммаДокумента КАК СуммаДокумента,
ВложенныйЗапрос.СуммаДокументаИтоги КАК СуммаДокументаИтоги
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица
{ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
СУММА(ВТОсновнаяТаблица.СуммаДокумента) КАК СуммаДокументаИтоги
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица) КАК ВложенныйЗапрос
ПО (ИСТИНА)}

2-й вариант запроса — это собственно запрос, который будет работать корректно в наших динамических списках:

ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента
ПОМЕСТИТЬ ВТОсновнаяТаблица
ИЗ
Документ.Документ1 КАК Документ1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента,
ВложенныйЗапрос.СуммаДокументаИтог КАК СуммаДокументаИтог
ИЗ
Документ.Документ1 КАК Документ1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
СУММА(ВТОсновнаяТаблица.СуммаДокумента) КАК СуммаДокументаИтог
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица) КАК ВложенныйЗапрос
ПО (ИСТИНА)
ГДЕ
Документ1.Ссылка В
(ВЫБРАТЬ
ВТОсновнаяТаблица.Ссылка КАК Ссылка
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица)

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

1) мы указываем динамическому списку, какая таблица у нас может быть в качестве основной, и тут же фильтруем её по данным временной таблицы

2) считаем итоги временной таблицы, в которой данные уже отфильтрованны нужным нам образом

3) поля с итогами присоединяем внутреним соединениям к основной таблице

Далее нам остается в свойствах динамического списка у данного поля утановить «использовать всегда» (на форму поля итогов просто не выводим).

И для каждой колонки, в которой нужно рассчитать итоги, указываем ПутьКДаннымПодвала из данных форм со ссылкой на нужное нам поле итога.

Результат работы выглядит так:

Конечно, у данного метода есть свои особенности, но все же на текущий момент это достаточно простой и быстрый способ получить итоги в динамических списках.

Пример расчета итогов в 10 колонках на 50000 документах

Всем спасибо за внимание.

34 Comments

kolya_tlt 03.04.2017 at 15:29

(0) кажется вам не нужно условие в крайнем пакете

Reply ↓
Восьмой 03.04.2017 at 16:50

(1) ошибаетесь коллега — без этого условия у вас перестанет работать фильтр.

Reply ↓
herfis 03.04.2017 at 17:26

Поправьте, если я чего-то недопонял.

Открытие динамического списка документов без отборов и ограничения по периоду приведет к засовыванию всей таблицы документов во временную таблицу?

Reply ↓
Восьмой 03.04.2017 at 19:42

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

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

Я был бы признателен гуру SQL если они на примере данных профайлера объяснили мне что происходит при таком запросе динамического списка и какие здесь могут быть подводные камни.

На моих тестах в 10 колонок итогов в 50000 документах с учетом различных отборов и без, все считаются достаточно быстро.

Reply ↓
Восьмой 03.04.2017 at 19:46

(4) Отображение на форме при скролинге, обновлении данных формы, и.т.д — не вызывает сильных тормозов.

Reply ↓
kolya_tlt 04.04.2017 at 09:05

(4) именно поэтому в платформе и нет нормального механизма по итогам списков документов, потому как без перебора всех документов сумму не подсчитать.

у нас, например, 50к документов создаётся за 5 дней. поставьте эксперимент на 1млн документов

Reply ↓
herfis 04.04.2017 at 09:31

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

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

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

Когда поработаешь с большими потоками информации и посмотришь на возникающие на глазах проблемы — поневоле в первую очередь начинаешь задумываться в том числе и о масштабируемости.

Решение не лишено остроумности, но, к сожалению, плохо масштабируемо.

ИМХО, овчинка не стоит выделки. Если кому-то так уж важны общие итоги, то разумным компромиссом выглядит их получение «по кнопке». А это проще и логичнее делать через СКД.

Reply ↓
sisdrou 04.04.2017 at 10:02

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

Reply ↓
herfis 04.04.2017 at 11:10

(8) Итоги по списку с установленными отборами имеют практический смысл. Это же очевидно.

Другое дело, что

1) если эти данные имеют самостоятельную ценность, то для этого обычно отчеты используются

2) если эти данные часть бизнес-процесса, влияющего на документооборот, то обычно такие бизнес-процессы автоматизируются более полно в рамках какого-нить рабочего стола на это заточенного

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

Reply ↓
starik-2005 04.04.2017 at 11:16

(9)

сформулировать внятное техзадание

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

Reply ↓
herfis 04.04.2017 at 11:25

(10) Ок. Некорректно выразился. Читать как «редко способны самостоятельно сформулировать внятные технические требования».

Reply ↓
Восьмой 04.04.2017 at 11:56

Добрый день коллеги! Большое спасибо за поддержку и за интерес!

Статья предназначается в первую очередь для ТЕХ кому это нужно.

По моему опыту в большинстве случаев это капризы пользователей, не нравится им работать с отчетами и они некоторые вещи хотят видеть сразу в списках, например суммы по отобранным документам ит.д . Тут даже не всегда получается объяснить не рациональность таких требований, а можно и работы лишиться в некоторых случаях. Если мы говорим про базы где производительность критерий номер 1 то да такой подход скорее фишка нежели что-то полезное — если же мы говорим про базы КФИС то тут это будет иметь смысл так как критерий номер 1 уже не производительность а максимально возможное количество аналитики (инталев тому пример) которую хотят видеть сразу на форме и не лезть в 100500 отчетов, и не жать дополнительные кнопки.

Как бы то ни было — у людей возникает потребности в итогах динамических списков , а решения которые находят для этого разработчики весьма изощрённые — собственно им и посвящается.

Reply ↓
Восьмой 04.04.2017 at 12:11

(10) Если мы говорим про разработку тиражных решений то я с Вами полностью согласен. Но реальность такова что практически все тиражные решения всегда затачивались и будут затачиваются под хотелки определенной группы пользователей — проводить аудит, что-то решать, думать «а оно нам надо» — для бизнеса это зачастую дорого и не интересно — бизнесу важен результат в установленных для него рамках — поэтому Бизнес рано или поздно нанимает «отдельно программиста» на которого сыплются все хотелки этого бизнеса.

Reply ↓
herfis 04.04.2017 at 12:42

(12) Хозяин-барин. Только проблема в том, что очень сложно провести границу достаточности масштабируемости.

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

Reply ↓
Vlad_2008 05.04.2017 at 17:32

Тоже считаю, что динамический список должен оставаться динамическим, а итоги можно считать по кнопке. Как вариант, вместо кнопки можно прицепиться к какому-либо событию, хотя их мало: ПриАктивизацииСтроки, ПриАктивизацииЯчейки. Конечно, можно еще и обработку ожидания прикрутить, а к ней, в свою очередь, тоже сделать кнопку Вкл/Выкл, ну чтобы можно было отключать ожидание и не производить постоянные вычисления.

Сами итоги считать через СКД, как написано (уже давно) тут: http://v8.1c.ru/o7/201404list/index.htm

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

Reply ↓
Восьмой 05.04.2017 at 17:43

(15) За наводку на статью спасибо — не знал что так можно. Сразу возникает вопрос — есть возможность быстро отловить момент изменения настроек динамического списка, или тут все-таки танцы с бубнами?

Reply ↓
kolya_tlt 06.04.2017 at 09:02

(16) ПриОбновленииСоставаПользовательскихНастроекНаСервере вам разве не подходит ?

Reply ↓
the1 06.04.2017 at 09:50

(17) ПриОбновленииСоставаПользовательскихНастроекНаСервереИмениНуралиеваБорисаГеоргиевича же! Не вводите людей в заблуждение, коллега!

Reply ↓
kolya_tlt 06.04.2017 at 10:45

(18) Евгений Ваганович, первое апреля прошло, заберите гонорар, увидимся через год

Reply ↓
Vlad_2008 06.04.2017 at 15:25

(16) Увы нету, только танцы.

Я, как правило, делаю кнопку, по которой, после установки фильтров, пользователь делает необходимые расчеты. Иногда, вешаю обработку на событие «ПриАктивизацииСтроки», но обработчик этот глючный и не всегда срабатывает, например, после Ctrl+F в списке остается одна строка — событие есть, меняем условие поиска при котором у нас остается опять одна строка (другая) — события нет. Поэтому, добавляю обработчик и для «ПриАктивизацииЯчейки», т.е. сместились в строке — событие есть, короче, танцы.

Вот, в 8.3.10 пообещали обработчик «ПриПолученииДанныхНаСервере», сначала обрадовался … но, обломали, вызов не контекстный, форму поменять нельзя, можно только строчки оформить, причем искать (сортировка, отбор и т.д.) по таким «данным» (их тама нету) бессмысленно.

Еще жду 8.3.11, там будет общение между сервером (фоновые задания) и клиентскими сеансами, не знаю, может там удастся прорваться, поживем увидим …

Reply ↓
CheBurator 08.04.2017 at 21:12

(20) так уже ж сделали совсем недавно это самое общение сервера с клиентом

Reply ↓
Vlad_2008 09.04.2017 at 15:01

Ну я про пост от 17/03 «Передача информации с сервера», пока написано что «планируется 8.3.11».

Reply ↓
Vlad_2008 10.04.2017 at 14:35

Поковырялся вчера с итогами для документов на 5 000 — летает. Если правильно «КАКать», то верхний запрос отлавливает все: поиск, поиск по полям через ссылку, отбор по любому реквизиту, поиск и отбор по характеристикам, в общем, «загнать в угол» — не вышло.

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

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

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

Reply ↓
nvv1970 17.04.2017 at 01:04

Формировать новую ВТ на 1 млрд записей при каждом скролинге — алескапут.

Может для этих целей вообще отказаться от динамического списка?? ДС в высоконагруженых системах — зло.

Если рассматривать ваши запросы, то поясните для чего нужна ВТ вообще? почему нельзя просто присоединить только готовую сумму из подзапроса?

Если требуется, то для наложения на подзапрос условий прописать в нем {где …}. Кажется должно работать.

Reply ↓

igormiro 19.04.2017 at 10:04

Вот рабочий запрос без Вт ВЫБРАТЬ

РаспоряжениеНаОтгрузку.Ссылка КАК Ссылка,
РаспоряжениеНаОтгрузку.ПометкаУдаления КАК ПометкаУдаления,
РаспоряжениеНаОтгрузку.Номер КАК Номер,
РаспоряжениеНаОтгрузку.Проведен КАК Проведен,
РаспоряжениеНаОтгрузку.СуммаДокумента КАК СуммаДокумента,
ВложенныйЗапрос.СуммаДокументаИтог КАК СуммаДокументаИтог,
РаспоряжениеНаОтгрузку.Дата КАК Дата
ИЗ
Документ.РаспоряжениеНаОтгрузку КАК РаспоряжениеНаОтгрузку
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
СУММА(ВТОсновнаяТаблица.СуммаДокумента) КАК СуммаДокументаИтог
ИЗ
Документ.РаспоряжениеНаОтгрузку КАК ВТОсновнаяТаблица
{ГДЕ
ВТОсновнаяТаблица.Ссылка.* как Ссылка}) КАК ВложенныйЗапрос
ПО (ИСТИНА)

{ГДЕ
РаспоряжениеНаОтгрузку.Ссылка.* как Ссылка}

Показать

Reply ↓

zqzq 05.06.2017 at 10:14

(25) Идея интересная, но тогда нужно все поля убрать, краме ссылки и итогов, а на форму вытягивать уже через ссылку, например Ссылка.Дата, Ссылка.Номер и т.д. чтобы отборы корректно работали

ВЫБРАТЬ
Т.Ссылка КАК Ссылка,
ВложенныйЗапрос.СуммаДокументаИтог КАК СуммаДокументаИтог
ИЗ
Документ.Т КАК Т
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
СУММА(П.СуммаДокумента) КАК СуммаДокументаИтог
ИЗ
Документ.Т КАК П
{ГДЕ
П.Ссылка.* как Ссылка}) КАК ВложенныйЗапрос
ПО (ИСТИНА)
{ГДЕ
Т.Ссылка.* как Ссылка}

Показать

Reply ↓

PerlAmutor 06.06.2017 at 06:15

Поправьте ошибку:

1-й вариант запроса будет не даст нам возможность указать Документ1

Reply ↓
Rokky78 11.07.2017 at 16:46

(0) Интересное решение. Попытался применить в своей задаче. Мне нужно при перемещении по списку номенклатуры формировать другой ДС (остатки). Почти все получилось, но для ДС остатков свойства «ТекущаяСтрока», «ТекущиеДанные» = Неопределено. Поэтому итоги в подвале не показывает. Сами поля рассчитываются и присоединяются нормально. Не получается их загнать в подвал.

Может подскажете, как у ДС сделать какую-либо (в моем случае не важно) строку текущей?

Reply ↓
KAV2 08.11.2017 at 03:47

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

Reply ↓
getnight 27.06.2018 at 11:57

Надеюсь автор (или кто нибудь из местных гуру по динамическим спискам) сможет мне помочь.

Проблема описана тут https://forum.infostart.ru/forum9/topic194967

Reply ↓
insurgut 24.01.2019 at 14:05

Только у меня на деле ничего не работает? Нужно на форме заказа разместить список оплат по нему, и в подвале вывести итог. Сделал 1 в 1 — в подвал ничего не выводится.

Reply ↓

insurgut 24.01.2019 at 19:58

В итоге забил на динамический список и сделал таблицу значений на форме, которую заполняю при открытии формы документа…

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

Запрос = Новый Запрос(«ВЫБРАТЬ
| ПоступлениеНаСчет.Ссылка КАК ДокументОплаты,
| ПоступлениеНаСчет.СуммаДокумента КАК СуммаДокумента
|ИЗ
| Документ.ПоступлениеНаСчет КАК ПоступлениеНаСчет
|ГДЕ
| ПоступлениеНаСчет.ДокументОснование = &ДокументОснование
| И ПоступлениеНаСчет.Проведен
|
|УПОРЯДОЧИТЬ ПО
| ПоступлениеНаСчет.Дата,
| ПоступлениеНаСчет.Ссылка»);
Запрос.УстановитьПараметр(«ДокументОснование», Объект.Ссылка);
ТаблицаОплат.Загрузить(Запрос.Выполнить().Выгрузить());
Элементы.ТаблицаОплатСуммаДокумента.ТекстПодвала = ТаблицаОплат.Итог(«СуммаДокумента»);

КонецПроцедуры

Показать

Reply ↓

robomicky 21.02.2019 at 02:50

Чисто для проверки работы ПолучитьИсполняемуюСхемуКомпоновкиДанных()

Сделал расширение для формы списка документа Комплектация номенклатуры и

добавил в расширение Форму списка Комплектации, далее:

1. реквизит КоличествоИтог (Тип Число)

2. Использование Подвал — Да

3. Для колонки Количество — Текст подвала «Итого:» и Путь к данным новый реквизит КоличествоИтог

4. В модуль формы добавил код:

&НаСервере

Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)

ОпределитьКоличествоКоличествоИтог();

КонецПроцедуры

&НаСервере

Процедура ОпределитьКоличествоКоличествоИтог()

Схема = Элементы.Список.ПолучитьИсполняемуюСхемуКомпоновкиДанных();

Настройки = Элементы.Список.ПолучитьИсполняемыеНастройкиКомпоновкиДанных();

КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных();

МакетКомпоновки = КомпоновщикМакета.Выполнить(Схема,Настройки,,, Тип(«ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений»));

ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;

ПроцессорКомпоновки.Инициализировать(МакетКомпоновки);

ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений;

Результат = ПроцессорВывода.Вывести(ПроцессорКомпоновки);

КоличествоИтог = Результат.Итог(«Количество»);

КонецПроцедуры

&НаКлиенте

Процедура Расш1_СписокПриАктивизацииЯчейкиПосле(Элемент)

ОпределитьКоличествоКоличествоИтог();

КонецПроцедуры

&НаКлиенте

Процедура Расш1_ИзменитьВыделенныеПосле(Команда)

ОпределитьКоличествоКоличествоИтог();

КонецПроцедуры

Итоги в подвале показываются.

P.S. Есть некоторая особенность.

Если устанавливать/снимать Чекбоксы на форме (Вид операции и Организация), то обновление итогов произойдёт только после щелчка мышью в любой ячейке списка.

Reply ↓

user1012691 05.04.2019 at 14:12

Можно уточнить, если нужно добавить условие для расчета итога по колонке

ГДЕ Документ1.ПометкаУдаления = ЛОЖЬ

, то помеченные на удаление документы не показываются в списке. Есть возможность исправить это? Пример:

ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента
ПОМЕСТИТЬ ВТОсновнаяТаблица
ИЗ
Документ.Документ1 КАК Документ1
ГДЕ Документ1.ПометкаУдаления = ЛОЖЬ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Документ1.Ссылка КАК Ссылка,
Документ1.ВерсияДанных КАК ВерсияДанных,
Документ1.ПометкаУдаления КАК ПометкаУдаления,
Документ1.Номер КАК Номер,
Документ1.Дата КАК Дата,
Документ1.Проведен КАК Проведен,
Документ1.СуммаДокумента КАК СуммаДокумента,
ВложенныйЗапрос.СуммаДокументаИтог КАК СуммаДокументаИтог
ИЗ
Документ.Документ1 КАК Документ1
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
СУММА(ВТОсновнаяТаблица.СуммаДокумента) КАК СуммаДокументаИтог
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица) КАК ВложенныйЗапрос
ПО (ИСТИНА)
ГДЕ
Документ1.Ссылка В
(ВЫБРАТЬ
ВТОсновнаяТаблица.Ссылка КАК Ссылка
ИЗ
ВТОсновнаяТаблица КАК ВТОсновнаяТаблица)

Показать

Reply ↓

Итоги в динамическом списке

Related Posts

34 Comments

Leave a Comment Отменить ответ