1.
Intercititude
22.09.20 16:10 Сейчас в теме+2 $m
Добрый день всем!
ОФ, 8.2.
Есть обработка в которой пользователь выбирает номенклатуру и разные её характеристики. Которая в свою очередь делает записи в РС( ИЗМ - Номенклатура,Свойство(строка),ресурс - (булево,строка,дата,число).
Свойство - это как раз характеристика, к примеру цвет,объём,датаупаковки и т.д.
А ресурс -значение.
Так же после записи идёт запись в другой РС ЗначенияСвойстОбъектов с этой же номенклатурой и ставиться признак(свойство) - Выгружать = истина;
На данный момент сделано так, что я беру Номенклатуру у которой стоит признак Выгружать. И тяну всё её харакетристики из первого РС. Всё ок.
Но! Мне необходимо где то ввести учёт изменившихся характеристик, то есть если пользователь изменил какую-либо хар-ку, то мне необходимо выгружать только номенклатуру и эту хар-ку!
Собственно как это сделать ? И возможно ли есть какой-то проще вариант?
Есть мысли добавить в первый РС реквизит "изменившиисяреквизиты" и с типом хранилище данных и помещать туда массив с изменёнными характеристиками. Далее отслеживать что изменилось. Но это только мысли, если это возможно, то подскажите как это реализовать программно..
Почему не сделано через механизм регистрации изменений в плане обмена для справочника Номенклатура и РС ЗначенияСвойствОбъекта, а с помощью отдельного регистра? Если не требуется в момент выгрузки знать и значение ДО изменения и значение ПОСЛЕ изменения - этого будет достаточно. После регистрации в план обмена можно сделать выгрузку данных через КД 2.1, либо любым другим самописным обменом с сериализацией через JSON/XML.
(2) Ну вот так. Характеристик очень много и решили завести РС а не плодить реквизиты в номенклатуре.
Отслеживать не принципиально - да
Подскажите как сделать корректнее в моём случае, желательно код..
(3)
Создать план обмена или взять один из существующих(например Полный). Включить в план обмена в состав регистр ЗначенияСвойствОбъектов.
Далее выполнить примерный код, самой конфы нет, в названиях могу ошибиться:
//НомерСообщения - тут либо присваивать каждый раз номер и хранить в узле(как в типовых обменах), либо взять число-константу, если не нужна гарантия выгрузки всех записей
//Узел - ссылка на узел регистрации в плане обмена
ВыборкаДанных = ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения, Метаданные.РегистрыСведений.ЗначенияСвойствОбъектов);
Пока ВыборкаДанных.Следующий() Цикл
НаборЗаписейИзмененный = ВыборкаДанных.Получить();
НоменклатураСсылка = НаборЗаписейИзмененный.Отбор.Объект.Значение;
//Далее обработка какая необходима
КонецЦикла;
(25)
Если план обмена новый, то нужно включить в конфигураторе все что вы хотите отслеживать как изменения в состав плана обмена. Далее создать в нем узел в Предприятии и при записи объекта туда произойдёт регистрация в этот узел автоматически, что можно посмотреть через типовую обработку Регистрация изменений для обмена данными.
Если вы не хотите все подряд регистрировать, а по какой-то логике, то вам нужно убирать Авторегистрацию и делать, ручную. В этом случае создаётся подписка на событие и там описывается логика регистрации в узел. Примеры есть в типовой УТ
(26) Добавил план обмена, выбрал спр.номенклатура, добавил узел.
Пытаюсь через обработку посмотреть изменения. Но ничего не происходит. Что я делаю не так ?
(26) Очень странные дела, попробовал вновь добавить план обмена и т.д.
База обновлялась час наверно, но теперь я вижу изменения ! Спасибо.
Осталось далее только:
ВыборкаДанных = ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения, Метаданные.РегистрыСведений.ЗначенияСвойствОбъектов);
Пока ВыборкаДанных.Следующий() Цикл
НаборЗаписейИзмененный = ВыборкаДанных.Получить();
НоменклатураСсылка = НаборЗаписейИзмененный.Отбор.Объект.Значение;
//Далее обработка какая необходима
КонецЦикла;
Этот кусок я использую в своей обработки при выводе характеристик правильно ?
Не совсем понимаю номерсообщения как туда передавать? неважно какой? он же меняется постоянно.
И ещё момент. Я на выходе получаю измененные данные. Как в коде мне их сравнивать с предыдущими?
Так же не нашёл информации для того, чтобы регистрировались только определенные реквизиты через подписку на события.. А именно сам код как это делается, в типовых муторно..
(28)
1) Если у вас односторонний обмен и вам важно передавать только актуальные данные, то можно сделать по упрощенной схеме и использоваться всегда номер сообщения в виде константы, либо через ЗаписьXML сформировать номер сообщения:
Это описано все в том же разделе на ИТС, но в соседней статье: https://its.1c.ru/db/metod8dev#content:2275:hdoc В этом случае в момент выполнения метода ВыбратьИзменения для всех записей в таблице регистрации узла проставляется номер сообщения(число больше 0). В конце выгрузки выполнение кода ПланыОбмена.УдалитьРегистрациюИзменений(Узел, НомерСообщения); удаляет все записи с узла с номером сообщения, который был установлен. Если в процессе выгрузки данные поменяются еще раз, то в узле номер сообщения сбросится на 0 автоматически и поэтому удаление методом УдалитьРегистрациюИзменений вновь измененных данных не затронет. Если какой-то элемент не удалось выгрузить(возникло исключение), то в куске кода обработки вы просто повторно регистрируете его на обмен и таким образом в след. итерации элемент будет выгружен.
2) Для более сложных случае с номерами сообщений и ответным сообщением с подтверждением доставки нужно использовать автоинкрементные номера сообщений, которые при каждом обмене увеличиваются на 1 и сохраняются в качестве реквизитов Плана обмена, а также сериализовать объекты и повторно регистрировать если их не принял получатель. Это логику надо дополнительно кодить (если она вам вообще конечно нужна).
Насчет последнего вопроса не понял. С узла вы получили список измененных данных. А выгружать вы можете все что угодно, я так понял вам нужно взять список номенклатура из изменных характиристик и считать.
(29) Ну вроде описали понятно, но из-за того что не знаю кучу методов плана обмена и вообще не работал с ним написание кода составляет труда.
1)В общем Номерсообщения я выставляю 0. Не совсем понял необходимость программного выставления сообщения правда. Был бы благодарен, если бы предоставили кусок кода установки, а то вожусь уже долго...
2)В итоге все измененные данные получаю поочередно в НаборЗаписейИзмененный - тоесть в этой переменной я получаю уже измененные данные и получается их 100% надо выгружать в моей обработке,так как они явно были измененны?
3) Не совсем правда понятно, как собрать в одну кучу после обхода выборки все эти данные. Поместить в одну тз ? Просто сейчас сделал так, что данные берутся из двух справочников и двух РС.
4) И последний момент, который интересует. Надо ли в модуле объекта описывать какие-либо методы и создавать формы для него ? Или же достаточно того, что есть сейчас. Сам план обмена, узел и состав ПО.
(30)
1) Нужно использовать номер больше 0.
2) Да
3) Смотря в каком формате вы куда выгружаете. Можно использовать файловый поток и туда записать в формате XML/JSON/ручная сериализация, можно использовать таблицу, а потом все разом сериализовать в нужный формат, или записать в базу SQL, или отправить ...вариантов масса. Тут уже надо в специфику вашей задачи глубоко погружаться, смотреть требования системы-приемника данных и т.п., Вряд-ли вам тут дадут готовое решение на ваш самописный обмен.
4) В модуле обмена имеет смысл что-то реализовывать, если у вас логика работы с узлами(проверка заполнения настроек самого узла, если таковы имеются), а также работа с РИБ, Скорее всего ничего такого вам не нужно, поэтому нет - не нужно.
(31) 1) Достаточно при получении указать НомерСообщения 1 ?
2) Я собираю все измененные характеристики из регистров/справочников и формирую файл xml по некому шаблону. Далее этот файл на прямую через http отправляется на сайт. Всё это дело происходит автоматически.
Что посоветуете ?
(32)
1) Достаточно
2) Желательно максимально быстро сделать, чтение изменений с узла, чтобы снялась блокировка с таблиц. Поэтому считанные данные лучше сохранить в некоторый массив структур или таблицу значений, взяв все что надо из самого регистра сведений со свойствами и их самой номенклатуры, а уже непосредственно формирование xml и отправку в rest сервис делать после чтения. И в конце удаление с регистрации.
(34) Отдельные реквизиты в узел не регистрируются. В 1С объектная модель.
.
Для целей регистрации конкретной характеристики номенклатуры их вынесли в отдельный регистр где каждая характеристика номенклатуры - отдельная строка. Для чего регистрировать отдельные реквизиты на обмен вообще не ясно, выгружайте всегда их, либо также выносите из в отдельное хранилище. Но по исходному описанию задачи они и так у вас в отдельный РС сохраняются - его и отслеживайте через план обмена.
(36) Не понял что вызвало сложности в вашем вопросе
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Данные");
Пока ВыборкаДанных.Следующий() Цикл
НоваяСтрока = ТЗ.Добавить();
НоваяСтрока.Данные = ВыборкаДанных.Получить();
КонецЦикла;
Ну, как вариант.
Если на самом деле версионирование не нужно, а нужен только учет изменений, то добавить в РС поле Изменено/ДляОбработки/(свой вариант) с типом булево.
При изменении значений характеристик и записи в РС, записывать с Истина.
При выгрузке делать выборку записей с учетом этого значения.
После выгрузки по записям из выборки изменить значения на Ложь.
Есть обработка в которой пользователь выбирает номенклатуру и разные её характеристики. Которая в свою очередь делает записи в РС...
То изменения характеристик номенклатуры пользователь делает через упомянутую обработку, которая создает или изменяет записи в РС. Вот в ней и нужно добавить установку флага об изменении.
Если это происходит не в обработке или не только в ней, можно добавить подписку на запись при изменении характеристик и регистрировать изменения в ней.
Или вы спрашиваете именно о проверке, когда значение изменено, а не перезаписано со старым значением?
Тогда и сравниваем с текущим (старым) значением при присвоении нового.
(7) Как оказалось, некоторые характеристики хранятся в самой карточке номенклатуры,и так же есть одна хар-ка в карточке Единиц измерении.. Собственно как отслеживать изменения по ним ? Эти данные в первом РС не хранятся..
Так же интересует один момент.
Сейчас я беру некоторые позиции номенклатуры с флагом Выгружать.
Далее я циклом обхожу все эти позиции с харакетристикой,после обхода выгружаю эти данные.
Собственно как сделать универсальный код с проверкой прямо в этом цикле обхода строк, чтобы не прописывать каждую "строкуколлекциизначении" и не проверять,так как харакетристик не мало?
То есть в цикле я обращаюсь к первому регистру, допустим ищу там номенклатура и штрихкод последней записи. И начинаю сравнивать. Так же ? Правда регистр независимый и непереодический..
(10) Если характеристики разбросаны по разным объектам конфигурации, то легкого решения не получится, т.к. нужно отслеживать изменения всех этих объектов.
Я не увидел какая у вас конфигурация используется, но, например, в УПП единицы измерения номенклатуры хранятся в отдельном справочнике так, что придется отслеживать изменения и в нем. Т.е. нужно отслеживать изменения всех объектов, где эти характеристики могут храниться. Если все изменения производятся из одной какой-то формы, то можно отслеживать изменения по всем возможным объектам из нее, если нет нужно делать подписку на событие записи для каждого объекта и эти изменения где-то регистрировать.
В вашем случае, чтобы "не городить огород", наверное, лучшим решением будет все же использовать план обмена, а не добавлять еще один РС, для регистрации изменений, которые могут быть сделаны в каком-то объекте конфигурации из нескольких.
(14) А мне не помешает он для основной задачи ?
Суть такова:
1) Пользователь вбивает данные о позициях
2) Я выгружаю два раза в день по регламентному заданию эти данные в xml и отправляю на прямую на сайт
3) Так же отправляю и отдельные характеристики.
(16) Он, это план обмена?
Если так, то вам должно быть виднее. Если момент выгрузки не будет мешать изменениям пользователя, т.е. накладываться по времени один на другой, то и проблем быть не должно.
Если мешает, добавляйте регистр, в котором будут перечислены все необходимые поля для выгрузки на сайт. Создавайте подписки на события и пишите в этот регистр все, что изменилось. После выгрузки очищайте регистр от уже выгруженных записей.
(17) Вообще конфигурацию нетиповая на основе УТ 10.
Просто к сожалению не работал с планами обменами и подписками на события. Из-за этого сложно определиться, уже изучаю данные моменты.
(19) Уточните, если я ошибаюсь. Выстроил такую схему:
1) Собственный план обмена, включаю спр. Номенклатура и свой РС где хранятся хар-ки. Делаю "авторегистрация". И я так понял просто создания плана обмена недостаточно, необходимо добавить форму и некий код в модуле объекта ?
2) Применяю подписку на событие перед записью спр. Номенклатуры и моего первого РС где хранятся хар-ки.
3) Программно в своей обработке выгружаю данные из своего РС первого. Далее Выгружаю данные о изменениях в плане обмене и сравниваю. Если была изменения то отправляю в xml, нет оставляю как есть.
Правда по поводу третьего пункта код не найти.. А именно как выгрузить данные из плана обмена и сравнить корректно.
(20) Что-то вы все смешали. Использования плана обмена и подписок это два разных метода.
Для плана достаточно:
Собственный план обмена, включаю спр. Номенклатура и свой РС где хранятся хар-ки. Делаю "авторегистрация".
Авторегистрация сама по себе предполагает регистрацию всех измененных значений объектов, которые вы в него добавили. Дальше в процедуре выгрузки использовать то, что предлагали в (5). Этого будет достаточно.
С использованием подписки план не нужен (хотя можно реализовать и через него, но тогда без авторегистрации), а нужен РС, в который нужно вносить регистрацию изменений в требуемых объектах. А потом в выгрузке считывать данные только с этого РС и очищать их после выгрузки.
Собственный план обмена, включаю спр. Номенклатура и свой РС где хранятся хар-ки. Делаю "авторегистрация".
После этих действий при попытке внести изменения в справочник "Номнеклатура" ничего не происходит. Видимо нужны какие-либо типовые процедуры. Где их взять не пойму.. Изменения пытался посмотреть через обработку "Регистрацию изменения для плана обмена"- ничего не происходит. Так же форма с наименованием узла там пустая..
Или же проще использовать план обмена "Полный"? Но там меня смутило, что распределенная база стоит галочка. А она такой не является.
По сути хотелось бы конечно без авторегистрации - выборочные реквизиты только, но к сожалению мало знаний.. И в случае с авторегистрацией необходимо подписки на события я так понимаю ?
(8) Что-то мне подсказывает, что будут претензии к безопасности частных данных на сторонних серверах.
К тому же, автору, как оказалось, не нужен контроль версий, а нужен только контроль изменений, т.е. отследить, что что-то вообще поменялось, а что там было до этого не критично.
Из-за системных особенностей реализации планов обмена не рекомендуется злоупотреблять выгрузкой изменений по планам обмена. Дело в том, что при чтении изменений блокируются все таблицы изменений. Т.е. при выгрузке план обмена не дает записать новые изменений, а следовательно, блокирует и сами элементы — справочники, документы и т.д.
Выгрузку рекомендуется производить в нерабочее время или совсем маленькими партиями данных, чтобы блокировки были на максимально короткий срок.