Имя: Пароль:
1C
1С v8
Как объединить два объекта справочника при обмене без потери данных?
,
0 Kirumit
 
09.11.17
18:55
1с предприятие, 8.3.

Настроен обмен между серверами. Обмен работает. Есть Головная компания, а есть филиал 1 и филиал 2.
Филиал 1 - это грузоотправитель.
Филиал 2 - грузополучатель.

Объект: элемент справочника, номенклатура К-700 с заводским номером ХС7878 и прочими данными.

Описание:
1. Схема такая, головная компания выписывает документ на бумаге на отправку техники К-700 ХС7878 в количестве 1 штуки из филиала №1 в филиал №2. Отправляем им, в т.ч по системе.

///Условие:
А. В базе Филиала №1 в форме номенклатуры К-700 ХС7878 заполнены данные о годе выпуске, о ее пробеге в ходе эксплуатации в филиале №1 и др. данные. Пример: Филиал №1, 10.10.2017, пробег, 100 км.
Б.В филиале № 2 связь временно отсутствует, пришла только бумага через какое-то время///


2. Филиал №1 (грузоотправитель) в системе проводит документ об отправке К-700 ХС7878 в Филиал №2. Запись по обмену попадает в систему Головной компании. В базе головной компании существует элемент:
К-700 ХС7878

3. Спустя какое-то время (в момент фактического получения)Филиал №2 проводит в системе документ о получении К-700 ХС7878 из Филиала №1.
3.1. Филиал №2 к тому же вносит свои данные в номенклатуру, Пример: Филиал №2, 20.11.2017, пробег, 118 км.
3.2. Связь наладилась, данные из Филиала №2 отправлены в базу Головной компании.

4. В базе Головной компании создались два элемента (с разными данными):
К-700 ХС7878
К-700 ХС7878


Проблема:
Подскажите пожалуйста, с помощью чего можно реализовать так, чтобы система при совпадени по наименованию и заводскому номеру, объединял бы эти два элемента в одну. При этом данные также объединялись. Скорее всего надо будет потом и во всех других базах сделать подобное, т.е. заменить в т.ч. и в документах.

Пример:
было так:
1.К-700 ХС7878, Филиал №1, 10.10.2017, пробег, 100 км.
2. К-700 ХС7878, Филиал №2, 20.11.2017, пробег, 118 км.

стало так:
1. К-700 ХС7878, Филиал №1, 10.10.2017, пробег, 100 км. Филиал №2, 20.11.2017, пробег, 118 км.

Может есть конечно более простой вариант? Подскажите пожалуйста?

//Примечание:
пробовали работать с регистром сведений "Соответствие ссылок обмена". Не совсем подходит. В итоге в базе создается 1 элемент, но данные сохраняются только введенные в филиале №1. ///

с уважением
1 Cyberhawk
 
09.11.17
18:56
"Может есть конечно более простой вариант? Подскажите пожалуйста?" // Подсказываю: НСИ раздается и стекается в единцый центр
2 Kirumit
 
09.11.17
18:58
Cyberhawk - это понятно. У нас также. Но в вопросе рассматривается случай, когда в одной из баз данных нет, в связи с временным отсутствием связи. Такое может быть.
3 Йохохо
 
09.11.17
19:10
используйте что то типа НоменклатураПоставщиков из типовых
4 mistеr
 
09.11.17
19:55
(2) В этом случае выпускается приказ директора: новые объекты не создавать, ждать связи, получать обмен и находить нужный.
5 Cyberhawk
 
09.11.17
20:01
(2) Создание и редактирование НСИ только в одной центральной базе, в дочерних узлах это должно быть запрещено технически
6 Cyberhawk
 
09.11.17
20:02
Но даже создание элемента в дочернем узле никак не мешает схеме дочка1 --> центр --> дочка2
7 h-sp
 
10.11.17
00:11
(2) при следующем сеансе связи данные придут и встанут на место
8 Kirumit
 
10.11.17
09:43
1. Пользователи которые должны забивать данные могут и не знать что у них связи нет. В любом случае вобьют данные.
// @mistеrВ этом случае выпускается приказ директора: новые объекты не создавать, ждать связи, получать обмен и находить нужный.

2. Филиал может вести самостоятельную хозяйственную работу. т.е. Техника может прийти с завода изготовителя в филиал по заказу самого филиала. Данные о новой технике поступают в Головной офис намного позже.
// Cyberhawk Создание и редактирование НСИ только в одной центральной базе, в дочерних узлах это должно быть запрещено технически. Но даже создание элемента в дочернем узле никак не мешает схеме дочка1 --> центр --> дочка2

3. При следующем сеансе связи не встает на месте. В головном офисе как было 2 номенклатуры так и остались.
// h-sp при следующем сеансе связи данные придут и встанут на место

4. Т.е. как я понимаю отсутствует в системе 1с по работе с такими данными? Т.е. чтобы если находит дубли не удаляла дубль а делала слияние в один объект с сохранением данных?
9 h-sp
 
10.11.17
10:01
(8) "если находит дубли не удаляла дубль а делала слияние в один объект с сохранением данных" - какой-то вообще бред несете. Пятница, понятно.
10 Karambol
 
10.11.17
10:10
Изначально отправляли из головной и в итоге в головной создалось два элемента? Видимо, неверно настроен ключ, по которому идет синхронизация.
Я бы пробег хранил не в реквизите, а в регистре. И увеличивал бы его при проведении документов.
11 Kirumit
 
10.11.17
10:52
1. имею ввиду что большинство решений о которых я знаю, если находят дубли то один из них просто удаляют.
//"если находит дубли не удаляла дубль а делала слияние в один объект с сохранением данных" - какой-то вообще бред несете. Пятница, понятно.

2.А. Ключ по которому идет синхронизация, это id элемента.
Проблема в том, что на одном из сервером создается еще один элемент (Номенклатура с тем же заводским номером), у которого естественно будет свой номер Id. Вы имеете ввиду что можно настроить синхронизацию не только по ID но и по наименование+заводской номер??? Т.е. в головной организации система сначала ищет по ID, если не находит ищет по связке Наименование+заводской номер. Если находит то что? Объединяет? как это сделать? Если это так?

2.Б. Пробег да у нас храниться в регистре. Но есть и другие данные которые храняться в справочнике. Пример: Дата изготовления, Проведенные ремонты, ТО и т.д.
//Изначально отправляли из головной и в итоге в головной создалось два элемента? Видимо, неверно настроен ключ, по которому идет синхронизация.
Я бы пробег хранил не в реквизите, а в регистре. И увеличивал бы его при проведении документов.
12 Kirumit
 
10.11.17
13:34
1. имею ввиду что большинство решений о которых я знаю, если находят дубли то один из них просто удаляют.
//@h-sp "если находит дубли не удаляла дубль а делала слияние в один объект с сохранением данных" - какой-то вообще бред несете. Пятница, понятно.

2.А. Ключ по которому идет синхронизация, это id элемента.
Проблема в том, что на одном из сервером создается еще один элемент (Номенклатура с тем же заводским номером), у которого естественно будет свой номер Id. Вы имеете ввиду что можно настроить синхронизацию не только по ID но и по наименование+заводской номер??? Т.е. в головной организации система сначала ищет по ID, если не находит ищет по связке Наименование+заводской номер. Если находит то что? Объединяет? как это сделать? Если это так?

2.Б. Пробег да у нас храниться в регистре. Но есть и другие данные которые храняться в справочнике. Пример: Дата изготовления, Проведенные ремонты, ТО и т.д.
//@Karambol Изначально отправляли из головной и в итоге в головной создалось два элемента? Видимо, неверно настроен ключ, по которому идет синхронизация.
Я бы пробег хранил не в реквизите, а в регистре. И увеличивал бы его при проведении документов.
13 Kirumit
 
10.11.17
13:34
it

1. имею ввиду что большинство решений о которых я знаю, если находят дубли то один из них просто удаляют.
// h-sp "если находит дубли не удаляла дубль а делала слияние в один объект с сохранением данных" - какой-то вообще бред несете. Пятница, понятно.

2.А. Ключ по которому идет синхронизация, это id элемента.
Проблема в том, что на одном из сервером создается еще один элемент (Номенклатура с тем же заводским номером), у которого естественно будет свой номер Id. Вы имеете ввиду что можно настроить синхронизацию не только по ID но и по наименование+заводской номер??? Т.е. в головной организации система сначала ищет по ID, если не находит ищет по связке Наименование+заводской номер. Если находит то что? Объединяет? как это сделать? Если это так?

2.Б. Пробег да у нас храниться в регистре. Но есть и другие данные которые храняться в справочнике. Пример: Дата изготовления, Проведенные ремонты, ТО и т.д.
// Karambol Изначально отправляли из головной и в итоге в головной создалось два элемента? Видимо, неверно настроен ключ, по которому идет синхронизация.
Я бы пробег хранил не в реквизите, а в регистре. И увеличивал бы его при проведении документов.
14 mistеr
 
10.11.17
17:03
(11) Надежного универсального решения этой проблемы не существует. Потому как вовлечен человеческий фактор. Не может алгоритм в общем случае определить, что два элемента, созданные разными людьми в разных филиалах, — это одно и то же. Алгоритм может только найти похожие по неким признакам и выдать ответственному пользователю: разберись и отметь дубли.

Для сокращения ручного труда можно использовать SKU производителя и прочие достаточно уникальные ключи.
15 zladenuw
 
10.11.17
17:20
Почитай в сп про это.
ПриПолученииДанныхОтГлавного
может поможет.
16 Kirumit
 
14.11.17
14:39
zladenuw а что такое сп? подскажите пжта
17 Cyberhawk
 
14.11.17
14:44
(16) http://www.forum.mista.ru/rules.php пролистай до раздела "Словарик"
18 Kirumit
 
14.11.17
17:07
Благодарю