Базовый курс. 2-ой блок.
19.11.2010
комментариев 49
Представляем 2-ой блок базового курса.
15 глав 294 видео-урока.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
Я смотрю, мои комментарии-вопросы сейчас будут занимать значительное место на этой странице. По этому поводу надеюсь лишь, что эти вопросы могут быть интересны не только для меня.
В этом случае – ещё вопрос про таблицы итогов.
Хотелось бы уточнить, что означает дата периода, на который устанавливаются итоги.
Сейчас текущий месяц – декабрь. Когда я захожу в “Управление итогами”, по умолчанию предлагается установить для регистров накопления – 30.11.2010, для регистров бухгалтерии – 31.12.2010.
Далее, в синтакс-помощнике для метода УстановитьПериодРассчитанныхИтогов() читаем: “Если указана дата 31.01.2000 то это значит что будут рассчитаны итоги на 01.02.2000. Для получения итогов после этой даты будут использоваться актуальные итоги”.
Кроме того, для случая, когда требуется рассчитать остатки на промежуточную дату месяца, из книги “Профессиональная разработка в 1С:Предприятие 8” мне удалось почерпнуть следующее (как я это понял).
В случае регистров накопления:
Берутся рассчитанные итоги на дату следующую за требуемой, а если их нет, то актуальные итоги. Затем от них к требуемой дате производится обратный расчет, т.е. вычитаются движения, выполненные от требуемой даты до даты итогов. То есть, если мне нужны остатки на 15.12.2010, система из актуальных итогов вычтет все движения после 15.12.2010 (границу не уточняю, сейчас не о том речь).
В случае регистров бухгалтерии:
Берутся рассчитанные итоги (остатки) на дату следующую за требуемой, если их нет и требуемая дата лежит в месяце следующем, за который рассчитаны последние остатки, то система возьмёт эти остатки и добавит к ним рассчитанные обороты текущего месяца (они ведь в той же строке таблицы итогов); если же требуемая дата лежит ещё дальше в будущем, то актуальные итоги. Затем от них полученных таким образом итогов также производится обратный расчет к требуемой дате, т.е. вычитаются движения, выполненные от требуемой даты до даты, на которую получены итоги. То есть, если мне нужны остатки на 15.12.2010, система возьмет остатки на 01.12.2010, прибавит к ним обороты за декабрь и затем вычтет все движения с 15.12.2010 по 31.12.2010. Если мне нужны остатки на 15.01.2011, система из актуальных итогов вычтет все движения после 15.01.2011 (как я понимаю, эта схема универсальная и рассчитана в том числе и на тот случай, когда в базе присутствуют движения будущими датами).
Вот теперь вопрос следующий: правильно ли я понимаю, что если установить итоги так, как рекомендуется, то и для регистров накопления, и для регистров бухгалтерии остатки будут рассчитаны на 01.12.2010. Однако использование актуальных итогов будет различным: в случае регистров накопления они будут использоваться для текущей даты начиная с декабря, в случае регистров бухгалтерии – для текущей даты начиная с января. При этом в случае регистров бухгалтерии для декабрьских текущих дат будут использованы рассчитанные остатки на 01.12.2010 и рассчитанные обороты за декабрь – и в этом смысл формулировки, что итоги бухгалтерии установлены по 31.12.2010.
Ещё один вопрос насчет обратного расчета: в видеоуроках я про него информации не обнаружил, а упомянутая книга была про 8.0. Здравый смысл подсказывает, что в 8.2 должно быть так же, но хотелось бы уточнить.
>Хотелось бы уточнить, что означает дата периода, на который устанавливаются итоги.
Вы указываете месяц, за который хотите рассчитать итоги.
Например, указываете 31.03.2011. Это будет означать, что итоги будут рассчитаны по этот период. И как мы знаем, рассчитанные остатки за некоторый месяц будут храниться на дату начала следующего месяца.
То есть в нашем случае в физической таблице итогов будут записи на дату 01.04.2011, что и означает остатки на 31.03.2011.
Что касается схемы расчета остатка в зависимости от даты на которую он получается, то она должна быть одинаковой для регистров накопления. Однако это нужно проверить, проанализировав запросы к СУБД.
>правильно ли я понимаю, что если установить итоги так, как рекомендуется, то и для регистров накопления, и для регистров бухгалтерии остатки будут рассчитаны на 01.12.2010
Да, правильно.
>Однако использование актуальных итогов будет различным
Сейчас однозначно ответить не могу. Нужно провести эксперименты.
Несколько позже постараюсь сообщить информацию.
>Здравый смысл подсказывает, что в 8.2 должно быть так же, но хотелось бы уточнить.
Да, в 8.2 данные алгоритмы не поменялись..
Я дополнительно посмотрел, что устроено в типовых конфигурациях. И в Бухгалтерии, и в УПП в регламентных заданиях выполняется метод УстановитьПериодРассчитанныхИтогов() на одну и ту же дату для регистров накопления и для регистров бухгалтерии – дату конца предыдущего месяца, т.е. в моем примере это будет 30.11.2010.
Если же зайти в диалог “Управление итогами” в режиме пользователя, то там рекомендуется для регистров бухгалтерии установить конец текущего месяца, т.е. 31.12.2010. (Мне кажется, смысл этой рекомендации в том, что нам часто нужны оборотки за текущий месяц, а актуальные итоги не вполне подходят для остатков на конец месяца, т.к. в общем случае нельзя исключить существование проводок в будущих периодах).
Так что, стало быть, здесь имеется расхождение между рекомендациями платформы и кодом типовых конфигураций.
Мои же предположения о способах расчета остатков на промежуточную дату, таким образом, становятся довольно зыбкими (только ссылка на книгу), и проверить их возможно будет только выходя за рамки 1С (т.е. анализировать запросы к СУБД – это ведь уже не в 1С?).
Вопрос достаточно интересный.
Я его направил в мастер-группу, там и разберем..
Вот есть два вопроса по СКД. Не знаю, может быть об этом речь пойдёт в последующих курсах – я не так давно лишь закончил просмотр 2-го блока.
1. Хотелось бы выяснить возможности манипуляции параметрами виртуальных таблиц в СКД.
Когда мы делали отчет по ценам остатков номенклатуры, то у двух соединяемых таблиц система сама подставила один параметр Период – и для таблицы остатков, и для таблицы среза последних. В данном случае это хорошо, но вообще-то мы об этом систему не просили.
А если потребуется сделать аналогичный отчет, но с остатками и на начало месяца, и на начало следующего? При этом цены надо будет поставить на соответствующие даты, а может быть вообще на другую дату, например на текущую.
Есть ли доступ к параметрам требуемой виртуальной таблицы? Можно ли это сделать в диалоге СКД или только в программном коде?
2. В диалоге СКД на закладке “Связи наборов данных” мы настраиваем аналог левого соединения. А если нужно полное соединение? Если речь идет о двух запросах, то их можно, в принципе, заменить на один запос (хотя есть какая-то разница, пока что мне неясная, между тем, чтобы настраивать связи в запросе и тем, чтобы настраивать связи между наборами данных). Но если один из наборов – объект?
Итак, можно ли настроить аналог полного соединения наборов данных?
>А если потребуется сделать аналогичный отчет, но с остатками и на начало месяца, и на начало следующего?
Тогда нужно вручную настраивать параметры в отчетах СКД.
И делать это на закладке “Компановка данных” конструктора запроса. Тогда параметры будут необязательными.
>Итак, можно ли настроить аналог полного соединения наборов данных?
Соединить 2 источника данных полным соединением нельзя. Нужно стоить алгоритмы из модели левого соединения.
Если нужно полное соединение – то можно попытаться использовать объединение двух источников.
Понятно. Спасибо.
Евгений, а далее будет объясняться, как работать с Хранилищем настроек, о котором Вы упоминаете в главе 15 Обработки? Методом “тыка” создал хранилище, указал его в обработке. Пробую сохранить значения – выскакивает форма хранилища и все, ничего не сохраняется.
Хранилище настроек мы рассматриваем в 0-вом блоке продвинутого курса.
Но для того чтобы реквизиты обработок сохранялись вовсе не обязательно создавать свое хранилище. Можно использовать стандартное. Достаточно в свойствах формы поставить признак сохранения и для реквизитов формы отметить необходимость сохранения.
Со стандартным разобрался, в уроках все доступно показано и рассказано. Спасибо.
Евгений, раз уж хранилище настроек – тема продвинутого курса, пытать не буду. Узнаю на продвинутом курсе :) Но если можно приоткройте завесу тайны, для чего оно используется? Я вот предположил, что для разделения хранилищ по сущности хранимых данных. Например, если делать электронный документооборот, можно разделить хранилища по каким то смысловым критериям. Я правильно думаю или нет? :)
>Я правильно думаю или нет?
Направление мысли правильное.
Ряд решаемых задач с помощью собственных хранилищ:
– возможность администрирования настроек (права, etc).
– копирование настроек между пользователями
– установка настроек по-умолчанию новым пользователям.
Спасибо
Вот ещё вопрос. (Может ответ есть где-то в видеоуроках, но я либо не дошёл до него, либо пропустил). Предположим, нам надо программным образом установить какой-либо реквизит. Мы вызываем серверную процедуру, в ней запросом извлекаем из базы ссылку, которую возвращаем на клиента. Но в форме-то мы видим её представление – наименование или код. Происходит ли это так, что платформа сама, передавая ссылку, одновременно передаёт и её представление? Или сначала приходит ссылка, а когда надо её отобразить, происходит ещё один вызов сервера.
Попробовал поэкспериментировать – например, при изменении номенклатуры должна измениться единица измерения – такое впечатление, что вызов всё-таки один.
Хороший вопрос.
На клиента вместе со ссылкой сразу же передается и ее представление.
Поэтому повторного обращения к серверу не будет.
Понятно
Рассматриваем реализацию записи в регистр в модуле документа вне обработки проведения (в видеоуроках – по кнопке “Ордер”). После выполнения команды “Ордер” запись в регистр выполнена, но оказывается, что форма документа об этом не знает. Можно в форме перейти на “Остатки товаров” и если они до команды были пустыми, то пустыми и останутся. Кроме того, можно видеть в “Показателях производительности”, что при переходе на “Остатки товаров” серверного вызова не происходит.
Далее, если мы программно установили модифицированность формы, то создаётся впечатление, что можно отказаться от выполненного действия. Закрываем форму, отказываясь от сохранения, открываем снова – конечно же обнаруживаем, что появилась запись об остатках.
(Впрочем, надо отметить, что если выполнить запись в форме, то при переходе на “Остатки товаров” происходит серверный вызов и мы видим заполненные остатки).
Предположим, что запись в регистр должна быть неразрывно связана с изменением какого-либо реквизита – по видимому, в этом случае надо и запись самого документа проводить в одной транзакции с записью в регистр. Понятно, что пользователь уже не сможет отказаться от выполненного действия. Кроме того, теперь данные документа, вернувшиеся на клиентскую форму, соответствуют записанным данным документа – стало быть модифицированность формы устанавливать не надо. Однако остаётся проблема – опять же форма не знает о том, что произошла запись в регистр.
Переходим на “Остатки товаров” – они пустые, серверного вызова не происходит. Выполняем команду “Перечитать” – 1 серверный вызов, но остатки все равно пустые. Закрываем форму, открываем снова – конечно же, появились.
Есть ли возможность управлять обновлением этой информации?
Отличное наблюдение.
Для того, чтобы остатки отображались необходимо действительно связать набор записей регистра с данными формы.
Попробуйте сделать так (в серверном вызове):
ДокОбъект = РеквизитФормыВЗначение(“Объект”);
Набор = ДокОбъект.Движения.ОстаткиТоваров;
//Далее добавление записей в набор и его запись в БД
Остатки должны быть сразу видны.
Получилось?
Нет, не получилось!
Фактически, это и было уже сделано. Т.е. после преобразования структуры данных форм в объект вызывалась процедура частичного проведения в модуде документа, в которой в набор добавлялись записи и далее он записывался в БД (это просто повторение того, что было в видеоуроке).
Сейчас я попробовал перенести этот код в модуль формы (хотя сразу были сомнения в том, что это поможет) – результат тот же самый.
Кроме того, не мог найти, как вообще обратиться к движениям документа из клиентской формы (в тех случаях, когда мы их видим). В свойствах объекта “Объект” движений документа нет – там только реквизиты, стандартные реквизиты и табличные части.
Странно, что не получилось.
Вот такой код в серверной процедуре модуля формы отрабатывает (новое движение сразу же видно в списке движений документа).
Набор = ДокОбъект.Движения.ОстаткиТоваров;
Набор.Прочитать();
Запись = Набор.ДобавитьРасход();
Запись.Период = Объект.Дата;
Запись.Номенклатура = Справочники.Номенклатура.Паллета;
Запись.Количество = 777;
Набор.Записать();
Аналогичным образом отрабатывает обращение к экспортному методу модуля объекта:
Процедура ОрдерНаСервере()
ДокОбъект = РеквизитФормыВЗначение("Объект");
ДокОбъект.ДобавитьДвижение();
КонецПроцедуры // ОрдерНаСервере()
Процедура ДобавитьДвижение() Экспорт
Набор = Движения.ОстаткиТоваров;
Набор.Прочитать();
Запись = Набор.ДобавитьРасход();
Запись.Период = Дата;
Запись.Номенклатура = Справочники.Номенклатура.Паллета;
Запись.Количество = 777;
Набор.Записать();
КонецПроцедуры
К движениям нужно обращаться через “настоящий” объект, то есть ДокументОбъект.
Реквизиты формы Объект имеет тип данных ДанныеФормыСтруктура. Именно поэтому от Объекта нельзя обратится к движениям.
А вызывает метод управляемой формы РеквизитФормыВЗначение(“…”) мы получаем ДокументОбъект.
Будете смеяться…
… не получилось.
На этот раз я скопировал представленный код один-в-один, вставил в серверную процедуру.
Документ сначала провёл, затем отменил проведение – убедился что записей в регистре нет.
Выполнил команду “Ордер”. Перехожу на “Остатки товаров” – пусто. Коменда “Перечитать” тоже не помогает.
Захожу под толстым клиентом, обращаюсь запросом к базе – запись есть.
Могу увидеть запись только если: 1) закрыть документ, открыть снова или 2) выполнить команду “Записать”.
Но, между прочим, на этот раз не было строки ЗначениеВРеквизитФормы(). Хотя это не важно – с ней всё равно не работает, а ведь в этом случае мы должны были бы видеть движения независимо от выполнения команды “Записать”.
Может быть, это глюк платформы? У меня 8.2.12.80. Если есть основания считать это ошибкой платформы, то, наверное, стоит оставить эту проблему до лучших времен.
Про обращение “к движениям” из клиентской формы: я неправильно выразился, конечно же не к движениям, а к тому объекту, который отображается на форме. когда я перехожу по команде “Остатки товаров”. Ведь, я полагаю, так же как в форме документа я вижу не настоящие реквизиты документа, а элементы переданной на форму структуры, в форме “набора записей” регистра я тоже вижу что-то другое?
Все-таки нашёл! Не пойму только, почему раньше я этого не видел.
Во-первых, у свойства формы “Объект” обнаружил свойство “Движения”, тип ДанныеФормыСтруктура, а далее – свойство ОстаткиТоваров, тип ДанныеФормыСтруктураСКоллекцией.
Кроме того, когда я вывел движения ОстаткиТоваров именно на форму документа, то при выполнении команды “Ордер” в этой таблице стали появляться движения. Более того, при переходе по команде “Остатки товаров” в командном интерфейсе документа можно видеть движения и там.
Однако же если на форме документа движения не выведены, то – ещё раз проверил – при переходе по команде “Остатки товаров” в командном интерфейсе документа все-таки движения не видны (а также можно видеть, что серверного вызова не поисходит). Так что, я думаю, что, скорее всего, это недостаток платформы.
Проблема у меня воспроизвелась.
Пока ситуацию расследуем.
Решить удалось пока только очень плохим способом – вызывать изменение формы. Тем самым заставить клиентскую часть закачать данные с сервера.
Вот такой код:
Процедура ДобавитьЗапись(Команда)
ДобавитьЗаписьНаСервере();
КонецПроцедуры
&НаСервере
Процедура ДобавитьЗаписьНаСервере()
ДокОбъект = РеквизитФормыВЗначение("Объект");
Набор = ДокОбъект.Движения.РегистрНакопления1;
Набор.Прочитать();
Запись = Набор.ДобавитьРасход();
Запись.Период = Объект.Дата;
Запись.Реквизит1 = Объект.Реквизит1;
Набор.Записать();
ЗначениеВРеквизитФормы(ДокОбъект, "Объект");
Элементы.Дата.Заголовок = Элементы.Дата.Заголовок+" ";
КонецПроцедуры // ДобавитьЗаписьНаСервере()
Еще одно добавление. Как теперь мне кажется, поведение зависит от того, переходил ли я по команде “Остатки товаров” в командном интерфейсе формы документа перед выполнением команды Ордер. Стоит туда один раз заглянуть, как после этого серверного вызова не происходит.
Т.е. когда я туда первый раз захожу, чтобы убедиться, что движения очищены, происходит серверный вызов, а после этого форма, видимо, считает, что больше к серверу можно не обращаться.
Да, в этом то вся и проблема.
В релизе 13.202 исправляли похожую ошибку.
Но, к сожалению, наш случай пока не исправился..
Продолжаем расследование..
Наконец-то найдено приемлемое решение.
Разработчики помогли.
Все дело в том, что изначальные движения “затревали” в кэше. Его нужно почистить.
Для этого используйте метод ОповеститьОбИзменении(Объект.Ссылка).
Вызывайте его на стороне клиента, после добавления движения.
Про ОповеститьОбИзменении() – Это здорово!
(Кнопка “Ответить” уже не показывается, поэтому отвечаю как бы на свой комментарий).
Проверил – работает! С этой процедурой действия платфромы приобрели должную стройность (точнее, мои представления о них).
Спасибо! Спасибо также и разработчикам!
1. Для чего понадобилось в 8.2 вводить свойство документа “Запись документов пи проведении”, да еще по умолчанию устанавливать его в значение “Записывать выбранные”, почему не использовать тот режим записи как в 8.1 автоматическая запись модифицированных регистров.
2. в уроке 254 Как это было в 8.1. “Очистка наборов записей перед выполнением запроса” я попытался модифицировать передаваемый параметр используя следующий код вместо УстановитьПараметр(“Момент”, МоментВремени()), установил УстановитьПараметр(“Момент”, Новый Граница(МоментВремени(), ВидГраницы.Исключая) очистку регистров не использовал при этом ожидал, что при повторном проведении документ будет проводится правильно, на самом деле также получил сообщение о нехватке товара. Почему ведь вроде все логично?
Думаю, что вопросы связанные с особенностями проведения документов и получением остатков в зависимости от значения этих свойств имеет смысл рассмотреть более подробно в Мастер группе.
1. В 8.2 реализован более гибкий алгоритм.
Записью набора может управлять сам разработчик.
В 8.1, например, нельзя было записать пустой набор без дополнительных телодвижений.
Также использование “Записывать модифицированные” предполагает очистку движений перед проведением.
В 8.2 в управляемом интерфейсе не так..
2. В уроке есть неточность.
Вид границы включая действительно не поможет.
Дело здесь в том, что при оперативном проведении документа меняется его время.
И получается, что время документа, например 18:45:34, а время движений (которые еще не очищены) 18:03:19.
И выходит, что движения самого документа попадают в запрос.
А очистка движений перед запросом как раз приводит к желаемому эффекту.
Можете посмотреть одну из 13 ошибок (бонусный материал), там это поведение ярко демонстрируется..
Евгений, добрый день!
Возник вопрос по правильному проектированию и использованию регистра сведений с точки зрения производительности.
Есть задача хранения и получения значения параметра, который может меняться со временем, например, статус сотрудника – работает или нет. Предположим, сотрудник может одновременно работать в нескольких подразделениях.
Первый вариант решения (назовем его «правильный») :
создаем периодический регистр сведений с ведущими измерениями Сотрудник, Подразделение и ресурсом Работает (тип булево). Данные из регистра получаем с помощью запроса к виртульной таблице СрезПоследних. В параметрах виртуальной таблицы указываем дату получения среза ДатаАктуальности и накладываем условия по измерениям Сотрудник и Подразделение.
Второй вариант (назовем его «неправильный»): создаем непериодический регистр сведений с измерениями Сотрудник, Подразделение, ДатаНачалаРаботы, ДатаОкончанияРаботы (в этом случае вместо регистра можно использовать и справочник с реквизитами Сотрудник, Подразделение, ДатаНачалаРаботы, ДатаОкончанияРаботы). Все измерения проиндексированы. Данные из регистра(справочника) получаем с помощью запроса к соответствующей физической таблице с условием
“…
| Где
| Табл. Сотрудник = & Сотрудник
| И Табл. Подразделение = & Подразделение
| И Табл.ДатаНачалаРаботы <= & ДатаАктуальности
| И Табл.ДатаОкончанияРаботы >= &ДатаАктуальности
…”
Вопрос – насколько эффективнее использовать первый вариант по сравнению со вторым и почему?
Хороший вопрос.
На самом деле регистр сведений чудес не совершает.
“На глазок” правильный вариант эффективнее неправильного на 0-30%. Цифры условные и показывают именно незначительную разницу.
А вот эффективность использования регистров накопления (против их неиспользования) может достигать десятков и сотен раз.
Но, тем не менее, почему же правильный вариант быстрее неправильного?
Дело лишь в индексе.
В случае регистра сведений создается кластерный индекс из полей: Период, Сотрудник, Подразделение.
Таким образом, обращение в запросе к регистру будет использовать один индекс.
В случае неправильного варианта создается несколько индексов.
1. Ссылка + Код (создается системой)
2. Ссылка + Наименование (создается системой)
3. Ссылка + Сотрудник
4. Ссылка + Подразделение
5. Ссылка + ДатаНачалаРаботы
6. Ссылка + ДатаОкончанияРаботы
Поэтому запрос непонятно какой индекс будет использовать. Может быть все, может быть ни одного.
При использовании регистра сведений следует не забывать о контроле уникальности. Это очень важное свойство, и именно оно используется во многих задачах.
Спасибо за ответ.
Большое спасибо за то что вы в каждом уроке не жалеете время и повторяете важные моменты несколько раз. Отдельное спасибо за то что показали как в запросе использовать характеристики, постоянно изобретал велосипед. Жаль что времени мало и приходится смотреть видео в ускоренном режиме. Хорошо то что 80 процентов уже знакомо. но те 20 я бы долго познавал сам. Так же спасибо за бонусы, обязательно посмотрю их в праздники.
Вопрос по 1-му блоку:
В модуле объекта справочника переменные модуля инициализируются каждый раз при считывании и записи в базу.
В моей базе, переведенной с 8.1 поведение другое: при открытии формы – инициализируются 2раза, при копировании формы – 3 раза, при интерактивной записи – ни разу, при программной – 1 раз. Режим совместимости снял – тоже самое.
В чем дело?
Есть предположение, что вы говорите о модуле формы, а не модуле объекта. Я ошибаюсь?
Ну и на всякий случай – как вы проверяете инициализацию переменных модуля объекта?
именно о модуле объекта.
проверяю: поставил точку останова на присвоение значения переменной в операторах основной программы.
Интересное поведение. Давайте разбираться.
Какое приложение используется для запуска?
Проведите эксперимент: создайте новый справочник, для него воспроизводится поведение?
Также, например, в конфигурации с домашними заданиями воспроизводится поведение?
На новой конфе вроде все работает.
На старой (была 8.1, обычное приложение, режим совместимости снят).
При открытии – 1раз. При вводе нового – 2р, При копировании – 3р. При программной записи (установка/снятие пометки удаления) – 1 раз. При интерактивной записи – ни разу.
На новой конфе (дом.задание на упр.приложении) все ОК.
Хороший вопрос.
Такое поведение характерно только для обычных форм.
То что при интерактивной записи модуль объекта не инициализируется это нормально. Дело в том, что в обычной форме объект существует все время, пока форма открыта. То есть инициализация происходит раз при открытии.
По поводу двойной инициализации при открытии. Предполагаю, что это связано: 1. С открытием формы. 2. С инициализацией основного реквизита.
Хотя поведение действительно загадочное. Как было в 8.1:
1. При открытии нового – 1 раз.
2. При открытии существующего и копировании – 2 раза.
А то что в 8.2 трижды обрабатывается модуль объекта, то это уже явная ошибка.
Но все-таки ошибка незначительная, поскольку использование переменных модуля объекта не является хорошей практикой..
это я писал о модуле документа.
Узнал что можно не создавая свою форму, наложить отбор на открываемую форму, а также с позиционировать нужную строку. Очень полезно. Спасибо.
Аналогичным образом, можно не изменяя отчет передать в него отбор и автоматические сформировать при открытии.
Шикарная возможность :)
В п .176 “Запись в независимый регистр сведений. Использование набора записей, установка отбора.” Есть на мой взгляд неточность. В регистре сведений ЦеныНоменклатупы необходимо кроме отбора по Номенклатуре также устанавливать отбор по Периоду, потому, что без этого при записи набора мы потеряем всю историю изменения цен данной номенклатуры.
Спасибо за внимательность, урок перепишем.
В архиве лишний файл: “Block1-299-part0-main.avi”. Правильно я понимаю?
Его нужно переименовать в Block2-299-part0-main.avi
Там уже есть такой
Значит его нужно заменить.