|
Как объединить два объекта справочника при обмене без потери данных? | ☑ | ||
---|---|---|---|---|
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
|
Благодарю
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |