КД: набор записей из отдельных объектов в xml файле #646507

Привет! Вчерась, нужно было прикрутить в БП 2 цены из ТиС 9. А в БП 2 цены - регистр сведений, подчиненный регистратору. Поплевав на руки, нарисовал документ "установка цен", дата - как надо, время ноль, внутренностей нет, а движений - сколько цен в справочнике. Пользуюсь КД 2. Но вот порядок выгрузки этих цен был такой, что записи в регистр сведений разбросаны по файлу, товар 1, потом одна запись скажем на дату 01.01.13, затем товар 2, и вторая запись на ту же дату. Это такое содержимое файла xml. Не получалось у меня отдельные записи в набор записей сформировать. Для этого пришлось бы документ описывать более широко, и у всей номенклатуры, что попадает в выгрузку (это и выборка и по ссылкам) формировать эти цены отдельными документами. А кто знает наперед, какой набор товара будет выгружен... И наткнулся я здесь на тему: Девушка очень хотела объяснить словами все это, но слов подходящих просто не было тогда. Если кто прорубился сквозь описание ситуации, вот решение: В обработчике конвертации записи регистра сведений, помимо задекларированного контекста "объект" (Отказ там, ОбъектМодифицирован  к примеру) доступен также НаборЗаписей Надеюсь эту переменную не переименуют в последующих обновлениях. Так вот, можно по регистратору читать текущий набор записей, анализировать, стоит ли его перезаписывать, и если стоит, то пользоваться этой переменной для загрузки нового набора. Там по ходу алгоритма, стоит присваивание Объект = НаборЗаписей; в то время как Объект во всех обработка - это одна запись.

Ничего не понял, но на всякий случай: вы нифига не знаете КД

Афигеть. Бедный микроскоп...

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

Ну, сделал ты один документ, хорошо. А при чем тут переменная "Объект", которая при этом еще и "НаборЗаписей"?

А зачем создал документ? Типового не хватило чтоль?

Когда в xml файле объект - это одна запись регистра сведений, то набор записей всякий раз из неё и состоит и перезаписывается во время выгрузки. Таким образом по окончании выгрузки цены имеют лишь те товары, регистры записи которых были перезаписаны последними (в разрезе дат регистраторов). В файле: <Нпп = 5> ... описание цены товара1 на дату 01.01.13 ... <Нпп = 7> ... описание цены товара2 на дату 01.01.13 После выгрузки в документе "Установка цен" от 01.01.13 ,будет только последняя запись -  то есть цена будет у товара2 Создал в смысле записал новый типовой документ.

А какая религия мешает сделать один набор записей в XML-файле?

почему отказались от заполнения табличной части дока ? .. это же проще .. и зачем объект=наборзаписей .. жесть какая то напиши правило выгрузки регистра сведений .. и ставь в правиле свой липовый регистратор

---- После выгрузки в документе "Установка цен" от 01.01.13 ,будет только последняя запись -  то есть цена будет у товара2 ---- Галочку "Не запоминать выгруженные объекты" поставил в нужном месте?

Вот и я удивляюсь...

Подозреваю, из-за даты

Потому, что я заранее не знаю, какой товар будет выгружен в xml файл. "объект=наборзаписей .. жесть какая то" - это классика, типовое решение, это не я писал. А для этого нужно знать список товаров которые будут выгружены и цены этих товаров сгруппировать по датам, и на основе этой группировки создавать документ "Установка цен" с заполненными табличными частями. Я не вижу способа определить этот список. А разбивать его цены по датам - ну просто лень.

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

ОбъектИсточник это строка, ОбъектПриемник - это РегистрСведенийЗапись.ЦеныНоменклатуры Обработчик "После загрузки" Вот кстати и код: ВременныйНаборЗаписей = РегистрыСведений["ЦеныНоменклатуры"].СоздатьНаборЗаписей;

"для этого нужно знать список товаров" - а сейчас они как выгружаются в таком случае? "это классика, типовое решение" - Строка кода может и из типовой. А вот "решение" из - это чистейшей воды копрокод.

Хосспади... Как это теперь развидеть?

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

И? Какая религия мешает собрать эти ссылки и выгрузить в один набор?

Собрать из документов? Отследить какие виды документов отмечены галочками в форме в 7.7, какие выставлены отборы, за какой период, сделать серию запросов, выгрузить в ТЗ, свернуть ТЗ по номенклатуре, дополнить ценами, сгруппировать по датам. Так? У нас вообще реквизиты формы можно использовать в обработчике согласно документации КД (я понимаю, что доступны физически и можно без проблем), но так ли это рекомендуют делать Разработчики? не много ли будет работы? Там ведь целые сервисные блоки написаны для отбора объектов в стандартную выгрузку.

"Отследить какие виды документов отмечены галочками в форме в 7.7, какие выставлены отборы, за какой период, сделать серию запросов, выгрузить в ТЗ, свернуть ТЗ по номенклатуре, дополнить ценами, сгруппировать по датам. Так?" - Ну, если нечего делать, то можно и так. А я бы в правиле выгрузки номенклатуры отслеживал, какие позиции выгружены, передавал их в параметр и после выгрузки бы дополнительно вызывал выгрузку цен, которая создала бы один документ с одним набором записей.

"передавал их в параметр" - глобальный объект? Параметр конвертации? "после выгрузки" - всего и вся в конце списка правил выгрузки произвольным алгоритмом из параметра по списку наформировать цены, сгруппировать по датам и правильный документ установки цен на каждую дату и типцены? Да, это будет прямое решение и не надо бояться, что документ установки цен распроведут в БП. У моего решения недостаток - постоянная перезапись набора записей регистра сведений, при чтении из XML очередной цены. тоже нормально.

Или так, да.