|
Вопрос по программированию плана обмена для своих нужд | ☑ | ||
---|---|---|---|---|
0
WDUM
24.01.12
✎
16:25
|
Нужды в общем то простые - нужно на веб-сайт выгружать информацию о товарах, свойствах и ценах из 1С УТ 11 (Платформа 8.2).
Вообще механизм планов обмена мне очень понравился по своему смыслу. Проведя пару дней в его тестированиях я практически всем доволен. Итак, насколько я понял, для основных объектов (товаров, видов свойств и т.п.), которым в конфигурации соответствуют справочники всё довольно радужно - нужно только зацепится за UUID как уникального идентификатора синхронизации - и дело в кармане. 1С-ка сама будет отмечать для плана обмена какие объекты были изменены с последней удачной выгрузки - мы просто получаем их список и даже если объект был целиком удален из базы мы всё равно из объекта вида "УдалениеОбъекта" получим его UUID и успешно дадим команду сайту объект с таким UUID удалить - отлично, просто отлично. Я использую свой механизм собственно обмена с сайтом, поэтому XML-объекты мне собственно не нужны да и при вышеописанных вещах и незачем. Но есть однако объекты конфигурации у которых UUID отсутствует - это записи регистров сведений (далее сокращаю до "РС"). Для измененных с момента последней выгрузки РС механизм планов обмена возвращает НаборЗаписейРегистраСведений с установленным отбором. Для тех РС у которых нет документа-регистратора всё в общем то так же замечательно. У меня таковой РС - это РС.ДополнительныеСведения, где хранятся свойства товара нужные для сайта. Так вот в отсутсвие регистратора в НаборЗаписейРегистраСведений просто установлен Отбор по ключевым записям регистра (измерениям) - и если запись была изменена - она присутствует в наборе и её можно считать. Если запись была удалена - она просто отсутствует в наборе и тогда можно взять ключи из установленного отбора и всё равно успешно дать сайту команду удаления записи из соответствующей таблицы - никаких проблем и это радует. Но всё равно тучки сгустились и сгустились над РС у которого есть регистратор. В моём случае это РС.ЦеныНоменклатуры. Ествественно цены позарез как надо грузить на сайт. Но вот тут вскрывается существенный подвох - НаборЗаписейРегистраСведений в этом случае возвращается с установленным отбором - по регистратору. И всё. Т.е. по документу. И в УТ 11 это единственный документ - УстановкаЦенНоменклатуры. Да, далее в этом НабореЗаписей идут записи регистра - всё казалось бы ок, но это не так - теряется синхронизирующая нить. Допустим кто-то создал УстановкуЦенНоменклатуры, ввёл в неё товары и провел. При этом механизм плана обмена вернет мне НаборЗаписейРС с отбором по этой установке цен и в нём будет набор записей с конкретными измерениями - тут мне остаётся только взять из этих измерений учавствующую в ней Номенклатуру, извлечь её последнюю цену (регистр, как мы помним, не только с регистратором, но и периодический - на сайт нам надо грузить только последние цены товаров, поэтому если кто проведет документ задним числом - не ведемся на значения цен в наборе записей, но лишь из актуальных данных регистра) и грузим на сайт в виде таблички (UUID_товара, UUID_типа_цены, значение_цены). Но вот незадача - если кто-то возьмет и отменит проведение документа - нам вернется НаборЗаписей просто пустой! А как мне теперь определить какие именно товары подверглись изменению? Возникает мысль пройтись по товарам перечисленным в документе, раз уж мы можем выйти на него через Отбор НабораЗаписей, но ведь из этого документа могут еще после отмены проведения взять и удалить строки! Так же возникает еще ряд осложнений ровно в связи с тем же что и вышеописанное. И зацепок как то не остаётся... Проверил как работает стандартный план обмена с сайтом (в УТ11 подразумевается что сайт - это 1С Bitrix) и был заинтригован - он после махинаций с проведением/отменой проведения УстановкиЦенНоменклатуры безошибочно определяет какие товары надо выгружать - возникает подозрение что где-то в процедуре проведения УстановкиЦенНоменклатуры происходит пометка признака измененности учавствующих в документе товаров для этого плана обмена. Это в общем то интересный ход и я покопаю в этом направлении, хотя честно говоря наскоком найти нужный код не удалось (поиском по имени плана обмена). Но попробую еще. Хотя решение для меня не очень хорошее, т.к. видно что метится на изменение именно товар, а не запись регистра цен, а значит выгрузка должна тупо грузить товар, включая его цены, независимо от того менялся ли сам товар или только его цена. А дело в том что у меня строка выгрузки товара - самая "жирная" - в нём есть такое поле как "описание", и оно размером килобайты может быть. Поэтому, например, какой нибудь глобальный пересчет цен повлечет за собой сотнемегабайтную выгрузку товаров - это огорчает, т.к. теоретически можно было бы выгрузить действительно только цены.... А вопрос после всего вышенаписанного - есть какие нибудь идеи у кого нибудь поопытнее меня в планах обмена? Заранее спасибо. |
|||
1
DmitryPavlik
24.01.12
✎
16:38
|
Офигеть!
Даже на юридических форумах вопросы меньше по длине )) Что мешает тупо брать срез цен? Честно, терял мысль по ходу твои рассуждений :D |
|||
2
rbcvg
24.01.12
✎
16:41
|
(1) сумел до конца дочитать?
я не осилил. |
|||
3
WDUM
24.01.12
✎
17:03
|
(1) (2) Да, сам понимаю что много вышло писанины, но чтобы понять вопрос, имхо, нужно понять в чём подвох, писанина его и описывает.
Могу спросить короче: Можно ли как то для регистра сведений с регистратором учавствующем в плане обмена сделать так чтобы метод ПланыОбмена.ВыбратьИзменений исчерпывающим образом давал сведения о ключах (измерениях) УДАЛЕННОЙ записи? Скорее всего невозможно - тогда какой подход можно применить чтобы минимизировать объём выгрузки, учитывая что нежелательно помечать как полностью измененный объект в ключе удаляемой записи. Так понятнее стало? |
|||
4
WDUM
31.01.12
✎
13:41
|
Ну что же, решил проблему следующим образом (подсмотрел части решения в стандартной конфигурации, часть додумал сам).
Завёл дополнительный регистр сведений с единственным измерением Номенклатура и даже без ресурсов. Ввёл Подписку на события (! вот что мне реально помогло из стандартной конфы когда исследовал как стандартный обмен с сайтом умудряется метить товары как измененные из УстановкиЦенНоменклатуры!) которая срабатывает когда изменяется регистр ЦеныНоменклатуры. Всё что делает в этой подписке - определяется перечень товаров учавствующий в изменении регистра и пишутся записи "Номенклатура" в вышезаведенный регистр. При выгрузке просто достаю все цены товара объединением с этим регистром и гружу в файл. При успешной выгрузке этот регистр тупо очищается. Такой своеобразный хак над несовершенством планов обмена... Однако вроде работает. |
|||
5
Colleg
29.02.12
✎
19:20
|
(4)Сделал точно так же когда допиливал обмен с магазином под Битрикс.
|
|||
6
Сияющий Асинхраль
29.02.12
✎
19:47
|
Не осилил... Слов много...
|
|||
7
Kashemir
29.02.12
✎
19:53
|
(4) Почему же сразу несовершенством. Платформа не виновата что организация данных конфигурации отличается от организации данных для сайта.
Если бы была таблица номенклатуры и таблица цен отдельно - проблем бы не было. А так у тебя получается что 2 таблицы 1С пытаешся синхронизировать с 1 таблицей сайта. |
|||
8
MaxS
29.02.12
✎
20:11
|
(6) аналогично ))
(4) а что мешает завести план обмена, который так же как и для регистра регистрирует у себя номенклатуру для обмена. При успешном обмене регистрация сбрасывается. |
|||
9
KarpovDeniska
29.02.12
✎
20:43
|
(0) до конца дочитать не смог, но присоединюсь к 1,что мешает брать срез последних?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |