К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

К знатокам конвертации данных

0 - 15.10.2016 - 07:02
Конвертацией данных пользуюсь редчайше, когда уже нет под рукой других инструментов. Возникла потребность в обмены ACC_ACC8 и USN_ACC8 (из клюшек в БП3.0) добавить GUID элементов справочников. GUID в 7.7 я сгенерирую и сохраню. Буду выгружать в 3.0 начальные остатки и мне очень надо, чтобы новые элементы нескольких видов справочников создались именно с этими GUID. Облазил правила обмена УТ10.3-БП2.0 в которых этот функционал вроде как присутствует, но не нашел как выгружается уникальный идентификатор. Еще раз - мне надо для нескольких видов справочников сделать обмен между 7.7 и БП3.0 с синхронизацией по уникальным идентификаторам. Они у меня есть )


Гость
1 - 15.10.2016 - 13:33
Начни применять правильную терминологию, и полегчает.
Начнем с того, что в v77 никаких GUID нет. А в v8 нет ID. И, несмотря на очевидную наследственность, смешивать эти термины все-таки не стоит.
ИМХО, не следует тащить GUID в v77. Лучше наоборот: ID держать как дополнительный реквизит. Тогда при обмене v8 -> v77 "клюшкам" не надо будет никаких дополнительных обвесов: ID достаточно для позиционирования объекта.
А еще у V8 есть предопределенные элементы. Воспользуйся этим.
Еще плюс "ID как дополнительный реквизит": доп.реквизит в БП3 может быть общим.

А формируется ID совсем даже не просто. А очень просто ;)
2 - 15.10.2016 - 14:28
(1) Я прекрасно знаю, что есть в 7.7, что оно называется Id, знаю как оно формируется и хранится. Также знаю, что такое GIID, как оно формируется и хранится. Знаю, что Id и GUID не имеют ничего общего. Мне не нужны предопределенные элементы. Мне надо при переносе остатков записать элементы ряда справочников с теми GUID (!!! не Id, а именно GUID), с которыми я хочу. Неважно где я их взял, хотя в заголовке темя по моему про это написано. Вот именно это мне надо. И я ничего не смешиваю.
3 - 15.10.2016 - 14:42
Если подробнее, то есть база торговли 7.7, которая будет передавать документ в БП3.0. Синхронизация по GIID (36-разрядному), который генерируется внешней компонентой для каждого элемента и документа обмена. И с этими GUID элементы и документы пишутся в БП3.0. И это все работает и нет никаких проблем. Но начальные остатки на начало года и документы первого квартала будут закачаны не из торговли, а из бух 7.7, в которую ранее качались документы из торговли. Поэтому стоит задача связать в БП 3.0 что закачалось их бух 7.7 с торговлей. Поскольку баз несколько, а торговля одна, то хотелось бы создавать в БП 3.0 элементы с теми GUID (не ID), что будут у меня в регистраторе торговли.Может несколько путано изложено, но как то так. (только не говорите мне что в одной базе 3.0 можно вести все организации и не надо несколько баз, я в курсе). В противном случае мне придется в торговле регистратор разрезать по фирмам, что не хочется. Хотя может именно так и сделаю
Гость
4 - 15.10.2016 - 17:55
Ты не можешь записать элемент с заданным ID - движек v77 запрещает, и не дает никакого метода для этого. Но позволяет узнать результат.
Ты можешь изощренным "колдунством" преодолеть этот запрет, но тогда на тебя ляжет обязанность обеспечивать уникальность ID в пределах базы. И всего, что с этим связано. Например, с автоуборкой мусора (удаленные объекты. Не путать с "помеченными на удаление"). Ты же не сталкивался с этой проблемой, так? А механизм-то существует.
Или удаление объекта. Или поместить ссылку на объект - движок использует только ID, и наплевать, к какой ветви метаданных этот объект привязан, какой у него код, наименование, и значение реквизита Примечания "Спросить разрешение у Светы!").
Т.е., влезая со своей хотелкой самостоятельно рулить ID, ты делаешь неустойчивым функционирование ИБ. И плевать, что ты хочешь. Или не хочешь.
С "восьмеркой" дело обстоит так же. Если не хуже. Когда ты встречался с требованием конвертации ИБ? Полной конвертации, с поиском всех связей, переписыванием всех объектов?
Вот именно. Не лезут разработчики на этот уровень. И ты не лезь.
Хватит с тебя реквизитов. И пары функций:
ПредставлениеОБъектаПоУИД(объект) и ОпределитьОбъектПоПредставлениюУИД(ПредставлениеПо УИД).
Вот и храни эти УИДы в реквизитах. И передавай их через файлы обмена.
Гость
5 - 15.10.2016 - 18:19
И если у тебя есть две базы, изначально не синхронизированные, то не беспокойся: тебе не удастся создать третью, одновременно синхронизированную с первыми двумя.
Миссия не выполнима.
6 - 15.10.2016 - 18:26
(4)Ты совсем не понял, вообще не про это пишешь.
1 - я не присваиваю Id в 7.7. Это делает платформа
2 - с 8-кой все обстоит иначе. При записи объекта можно без проблем сунуть ему свой GIID и все будет отлично.
И не надо горячиться )
Еще раз, я хочу прислать в БП 3.0 с новым элементом свой GUID (самый настояший, самый уникальный) и записать с ним этот элемент. Записать нет проблем )) Как прислать с помощью КД не знаю.
Про хранение в реквизитах - в них ранее и хранил для своих обработок. Именно в общих реквизитах, Но 8-ка дает новые возможности. В чем страх вычислить GUID по всем правилам и именно его подсунуть объекту ? Это документированная (штатная) возможность. В 7.7. тоже можно, но там совсем другой принцип и другие риски и можно только прямым запросом (то есть нештатными средствами)
7 - 15.10.2016 - 18:35
(5)миссия выполнима
Есть ТИС -> БУ 7.7 (синхронизированная по Id и IdDоc )
Есть ТИС -> БП 3.0 будет синхронизированная по сгенерированному GUID. По нему могу однозначно определить Id либо IdDoc и наоборот
Есть БУ77 -> БП 3.0 пока что внутренне никак не связанные, так как перекачиваю остатки штатными обработками.
Все решаемо. На худой конец я могу перекачать из БУ 7.7 в БП 3.0 не GUID, а Id, сунув его в так любимый тобой общий реквизит. Потом по нему и зарегистрировать в торговле объекты БП 3.0, Просто не хотелось плодить лишнюю сущность
Гость
8 - 15.10.2016 - 22:42
6-USSR > "Это документированная (штатная) возможность."
Интересно. Образчик можно? В личку, или как?
Для общего развития...
9 - 16.10.2016 - 05:40
(8)
ТребОбъект.ОбменДанными.Загрузка = Истина;
ТребОбъект.УстановитьСсылкуНового(ТребСсылка);
Гость
10 - 20.10.2016 - 00:41
либо засовывай guid сразу в xml при выгрузке, а при загрузке разбирай, либо кидай guid куда-то во внешнее хранилище, хотя бы в текстовой файл, и читай оттуда в обработчике "перед записью", или как там его
потом делай, как написал, только "объект" вместо "ТребОбъект", и проверь, что ссылка пустая, или будет ошибка при повторной загрузке
11 - 20.10.2016 - 09:30
(10)Вопрос и был как проще засунуть. Я так понял что в конвертациях 8.x -> 8.y GUID пишется в файл в обработке, его нигде нет в свойствах объектов. И мне также хотелось бы.
При повторной загрузке универсальная обработка обмена должна переписывать объект
12 - 20.10.2016 - 09:36
(10)я хочу пользоваться штатными обработками, только допилить acc_acc8 и usn_acc8 на предмет выгрузки этого самого GUID. Вся проблема из за того что хозяин хочет все семерочные бух-ии в отдельные базы БП 3.0. Если бы в одну, то и ничего не надо было городить. А так одни и те же элементы справочников есть в нескольких базах БУХ 77 сразу и надо их как то не размножать со стороны торговли. Чтобы торговля видела только один, независимо от базы 3.0. Можно конечно просто регистратор GUID в торговле разрезать по фирмам
13 - 20.10.2016 - 10:58
Синхронизация по GUID возможна только при обмене 8-8. В противном случае придётся курочить саму КД (флажок "Искать по внутреннему идентификатору" недоступен в обменах 7-8) и обработки обмена.
14 - 20.10.2016 - 11:03
(13)Это мне понятно. Про это и тема к знатокам, как это сделать с минимальными усилиями. Время пока есть подождать
15 - 20.10.2016 - 12:18
2(14) Боюсь, придётся тебе приобрести бесценный опыт и самому стать знатоком! :)
16 - 20.10.2016 - 15:25
Да блин, работа разовая и хочется минимально напрячься )


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены