| 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
| Да блин, работа разовая и хочется минимально напрячься ) | |
Интернет-форум Краснодарского края и Краснодара |
