Имя: Пароль:
1C
 
Написал новую схему РИБ-обменов, сейчас отлаживаю.
Ø (Волшебник 19.03.2015 16:00)
,
0 Гений 1С
 
гуру
03.03.15
12:58
Суть в чем?
Выгружаю в файл send получателю все объекты, зарегистрированные для него.
У получателя загружаю эти объекты из файла send.
Если загрузка успешна, переименовываю файл send в файл read.

Перед выгрузкой всегда загружаю у отправителя файл read от получателя, для всех объектов снимаю регистрацию (при этом контролирую, изменились ли объекты в базе и файле read), если изменились, не снимаю.

Конфу передаю автоматом, целиком, процедура тоже реализована.


Как-то так. Потому что типовая РИБ запарила двумя проблемами:
1. Блокировка при выгрузках. На 100 точках это жесть.
2. Потерей данных при обменах. Непонятно почему происходит, началось после введения параллельных выгрузок на точки.
116 Torquader
 
09.03.15
11:41
(115) Просто, если не отлаживать свой код, то можно написать большую кучу никому не нужного неработающего кода.

P.S. посмотри просто приоритеты изменений.
117 vde69
 
09.03.15
12:04
(115) и сделать новые ошибки, которые потом будет проще не искать а писать новую схему

и так до бесконечности :)
118 Serginio1
 
09.03.15
12:13
(115) Там на коленке написать сравнение объектов по метаданным. А объекты считываются через сериализатор. Зато можно найти причину, что бы не напороться на неё в своей схеме.
119 Гений 1С
 
гуру
09.03.15
18:17
(116) (117) если уйти от порочной схемы на более простую, ошибок будет меньше
120 Злопчинский
 
10.03.15
03:19
(115)  нифига не проще
Комуто просто было влом работать кропотливо
То ли тебе
То ли франчу

Даже как неспец совсем тупо бы сделал по факту установки расхождения между базами методом половинного деления восстановление из бэкапов базы там и тут и сравнения объектов там и тут
121 Злопчинский
 
10.03.15
03:20
(119)  простые схемы имееют тенденцию превращаться в сложные в условиях отсутствия возможности четких регламентов
122 2mugik
 
10.03.15
07:19
(90)предположим последнее сообщение имело номер 99

я записываю док1 (версия 221)
делается выгрузка пакета с номером 100
подтверждения нет....
я снова меняю док1 (версия 222)
выгружаю пакет (номер его будет то же 100, ведь состав пакета не изменился...)

Ради интереса проверил. 8.2.19.90. Создал конфу с одним доком. КАЖДАЯ выгрузка имеет свой номер. Даже если ничего не менял в базе.

Так что ничего пропадать не должно.
123 Kyon8
 
10.03.15
09:27
(102) Небось в тестовых копиях работали регламентные задания обмена ))
124 gosn1ck
 
10.03.15
09:35
(0) как конфу передаёте в вашей схеме?
125 vde69
 
10.03.15
09:37
(123) кстати очень может быть, классические грабли :)
126 IШаман
 
10.03.15
09:39
Весь мир уже давно пользуется плодами прогресса, один только Гений1с до сих пор трахается с распределенными базами. Если найдется умный человек и покажет его руководству какие выгоды те получат от единой базы и прикинут затраты на РИБ и на единую базу начальство Гения будет просто в шоке.
127 IШаман
 
10.03.15
09:40
А теперь по сабжу, по сути это лисепед очередной при чем без тормозов ибо тормоза придумал трус.
128 gosn1ck
 
10.03.15
09:43
почему лисапед? кто тут предложил рабочее решение для обмена 1000 точек розницы? я не видел, покажите, куплю
129 IШаман
 
10.03.15
09:50
(128) потому что он и не разобрался в причинах проблем которые в типовом обмене выозникают, и не создал ничего принципиально нового. Просто взял и на основе имеющегося создал что то свое обрезав ряд контрольных функций - таким образом может это и работает чуть быстрей но в качестве маштабируемого решения добавит еще больше гемороя чем типовое.
130 gosn1ck
 
10.03.15
09:59
(129) вы считаете, что всегда есть возможность засунуть всех пользователей в единую базу? представьте, что вам необходимо автоматизировать фронт макдака. будете останавливать продажи бургеров из-за пьянового дяди который центральную магистраль положил?
131 IШаман
 
10.03.15
10:00
(130) Я бы на фронт в макдаке, 1с вообще бы не ставил.  Там впрочем именно так и сделали.
132 gosn1ck
 
10.03.15
10:15
(131) так о каких плодах прогресса вы говорите, которые избавляют от секса с РИБом ?
133 IШаман
 
10.03.15
10:18
(132) Для начала возможность получать интернет практически в любой точке мира.
А насчет фронта на 1с это вообще глупость редкостная,  нахрена в базе назначение которой по сути регистрировать продажи еще и данные об остатках при чем эти данные заведомо искаженные? Возьмите за правило что всегда лучше просто не знать чем не знать но думать что знаешь.
134 Остап Сулейманович
 
10.03.15
10:20
(128) пАтамучтА лисапед он и есть лисапед. И нифига он не решает проблему обмена с 1000 точек розницы.
В мобильной платформе РИБ вообще не используется. Ввиду ограниченных возможностей платформы. А обмен работает и отлажен и методики выложены. Сырьоже их просто влом изучить. Начил изобретать лисапед.
135 vde69
 
10.03.15
10:32
(133) полно магазинов у которых на фронте 1с, для примера Hoff, 3 кита, да и вообще почти все хозяйственные, мебельные, автомобильные и т.д.

разумеется на супермаркет 1с ставить это не айс, но это ПОКА !!!

И тут скорее дело в лицензиях а не в техническом развитии...

разумеется фронт в сетях нужно делать не по прямой схеме урбд. Я-бы сделал такую архитектуру

1. Центральная конфигурация для фронта, изменяется крайне редко, двух этапный непересекающийся обмен (на кассы штрих коды, товары, цены, в центр транзакции касс), без контроля остатков и т.д.
от нее узлы, на каждый магазин, в самом магазине или общий терминал, или выгрузка на раб места со своим обменом.

2. Упр конфигурация - там проги делают чего от них хотят, конфигурация меняется часто. От нее узлы - в магазины

---------------------------------------------
обмен продаж
касса -> база фронта магазина -> центральная база фронта -> урп центральная база -> упр база магазина

---------------------------------------------
обмен цены, номенклатура
урп центральная база -> упр база магазина
урп центральная база -> центральная база фронта -> база фронта магазина -> касса
136 IШаман
 
10.03.15
10:37
(135) А читать умеешь я же написал что  на фронте нужна только регистрация продаж и возможность потом сбросить данные о продажах и все. Все остальное от лукавого и от неграмотности отдельных личностей.
137 gosn1ck
 
10.03.15
10:37
(133) это не возможно получить инет в любой точке мира. в наших точках за уралом до сих пор файлики обмена на флешках переносят. причем не достаточно иметь просто инет, наверно вам не надо говорить, что он должен быть стабильным и широким.
не понял вашего вопроса. мы работаем на данных, которые на 95-97% показывают правду в учете, понимаем это и закладываем риски. Вы предлагаете отделу продаж не знать о продажах вовсе, чем знать что мы продали 10000 штук +-500штук?
138 gosn1ck
 
10.03.15
10:40
(135) на практике фронт меняется очень часто, чем хотелось бы, вашу схему очень тяжело поддерживать
139 IШаман
 
10.03.15
10:40
(137) Я предлагаю нормально организовать работу тех кому надо планировать продажи поставки и т.д. чтоб в определенный момент у них была точная информация.
140 gosn1ck
 
10.03.15
10:48
(139) уважаемый коллега, с каким максимальным количеством точек розничной сети вы сталкивались в сталкивались? кажется, что вы хотите нагнуть бизнес пользователей со стороны IT. я ни в одной конторе не видел, чтобы что-то было организовано нормально, особенно в продажах. вчера бакс вырос, сегодня санкции. как в этих условиях что-то нормально организовывать?
141 IШаман
 
10.03.15
10:51
(140) Ну да ну да, гораздо интересней навести еще больше беспорядка а потом с перменным успехом броться с ним - тогда реально чувствуешь себя гением.
142 gosn1ck
 
10.03.15
10:52
(141) и всё же представим, что звёзды сошлись и инет есть везде. о каком решении вы говорили ранее?
143 IШаман
 
10.03.15
10:54
(142) Я говорил о том самом решении когда человек который принимает решения о заказах товара в магазин имеет возможность подключиться к базе и получить в ней реальные остатки в любой момент времени.
144 IШаман
 
10.03.15
10:54
+(143) А то что кассиру нежрен делать в центральной базе это просто не обсуждается.
145 Serginio1
 
10.03.15
10:55
(128) Я так понимаю, что в общей базе не нужно хранить  данные по каждому чеку, а нужны суммарные данные по точке за день, что делается просто выгрузкой суммарных данных и не нужно отслеживать изменения по куче документов.
146 IШаман
 
10.03.15
10:58
(145) Да,  именно так а все остальное от лукавого.
147 gosn1ck
 
10.03.15
11:03
(144) я думал мы говорим о рознице, у которой ~1000 точек и о том как ускорить выгрузку\загрузку с этими точками ... (145) так и делаем :) но с каждой точкой обмен 2-3 минуты, а их 1000. сколько часов будем обмениваться? :)
148 IШаман
 
10.03.15
11:05
(147) У вас в один момент времени база может принимать данные только от одной точки?
149 gosn1ck
 
10.03.15
11:11
(148) давайте сразу перейдем к выгрузке? так как с параллельностью загрузки никогда проблем не было в платформе 1с
150 Serginio1
 
10.03.15
11:13
(147) А в чем проблема с сумарной выгрузкой? Уж точно максимум 2-3 секунды.
151 IШаман
 
10.03.15
11:17
(149) А какие проблемы с выгрузкой?
152 Serginio1
 
10.03.15
11:19
(147) Для розницы я бы сделал регистрацию выгружаемых объектов из центральной базы по дате времени с индексом по дате времени. А при запросе данных выступала бы максимальная полученная дата.
Лучше конечно использовать номер транзакции. Но и даты достаточно. Всегда можно передавать избыточные данные и загружать данные с предварительным сравнением
153 Serginio1
 
10.03.15
11:20
152 в регистре сведений.
154 Serginio1
 
10.03.15
11:36
Да еще можно регистр сведений с ответами, где хранится максимальное время ответа от каждого магазина, для чистки регистра изменений
155 vde69
 
10.03.15
11:38
(147) такие вещи делают с промежуточной консолидацией, о чем я и писал ранее...
157 Гений 1С
 
гуру
10.03.15
23:06
(124) целиком. выгружаю в спец каталог с именем файла например config_2014_03_22.cf

При обмене сперва прога лезет в каталог, если находит, копирует файл локально, затем отвязывает главный узел (под спец. пользователем с повышенными правами), затем через командную строку натягивает конфу.

при входе если ГУ отвязан, он привязывается и перезапуск.

Плюс: перестали возникать ошибки "Конфа не соответствует ожидаемой".

Минус: нельзя пульнуть конфу на пару точек для проверки, она уходит сразу на все. Нужно быть внимательным. Зато и полечить просто - не нужно делать выгрузки на все точки, достаточно заменить файл конфы.
158 Гений 1С
 
гуру
10.03.15
23:06
(123) я такое встречал, да, но там номера сообщений мелкие, не грузилось. Да бывало такое, но это быстро находится и лечится. реально классические грабли. Проблема то не в этом.
159 Гений 1С
 
гуру
10.03.15
23:07
(126) ты будешь удивлен, но Единая База рассматривалась и была послана .... в лес. Ибо гладко на бумаге, но я указал, где овраги. и слава богу.
160 Гений 1С
 
гуру
10.03.15
23:08
(129) в чем будет гимор, интересно? гыгыгы.... в частном данном случае наоборот, решилась куча проблем. Особенно с блокировкой.
161 Гений 1С
 
гуру
10.03.15
23:10
(133) вы батенька идеалист, наверное считаете что в любой точке москвы можно получить шикарный интернет. Вынужден вас разочаровать. Увы и ах, особенно в ТЦ порой с интернетом туго.

(135) основная проблема фронта на 1С - это то, что невозможно точно зафиксить транзакцию пробития чека. у драйвера Fr1c нет возможности гарантированно узнать, был пробит чек или нет. Сбой во время пробития - и неопределенность вида - 1С не знает, был пробит чек или нет.
162 Гений 1С
 
гуру
10.03.15
23:10
(136) не только. Еще на фронте нужна приемка товара, контроль остатков и ревизии.
163 Torquader
 
10.03.15
23:49
(161) У вас конечности не с того места растут.
У меня, почему-то, даже в поделке на VbScript, которая через тот же самый драйвер работает, но она не только знала, пробит чек или нет, но и умела проверять, что он оформлен правильно в ЭКЛЗ.

(162) Вот когда начинается приёмка товара с вводом нового, то сразу возникает вопрос - как это вообще можно вести в единой базе или в РИБ, так как одинаковые товары вводятся разными операторами в разные позиции.
Поэтому, если нет электронного обмена с поставщиками и они не во всех точках совершенно одинаковы, то вообще нафиг не нужна попытка объединить базы - достаточно сделать базу, в которой будут консолидироваться результаты.
164 Bober
 
11.03.15
21:38
(157) вот это жестко.
165 Immortal
 
13.03.15
20:03
(105) а я как раз про механизм передачи данных
166 Immortal
 
13.03.15
20:04
(157) почитай на 50 оттенков мутнее, там как раз про такое
167 Злопчинский
 
13.03.15
20:42
(161) Вообщем при пробитии чека аппарат возвращает код успеха. Если нет кода успеха - значит ошибка - в чем проблема принципиальная?
168 Immortal
 
13.03.15
21:59
(161) это в любом ПО так, 1С не при чем
другое дело что 1с после поднятия могла бы и слазить в фискальник за информацией, пробился чек или нет.
169 vde69
 
15.03.15
09:21
(168) а если фискальник пробился и тут фигак связь пропала, 1с лезет - тайм аут однако, ну думает 1с - нифига не вышло, и откатывает свою транзакцию... результат очевиден...
170 Torquader
 
15.03.15
11:30
(169) Просто, если связь пропала, то её нужно восстановить.
У меня, например, система перед пробитием чека запоминала номера операций в ФР-е и в случае потери связи проверяла сначала номера документов - если они не изменились, то операция на ФР-е не прошла, а если изменились и чек закрыт, то считается, что чек пробит.
Потом, отменять транзакцию в случае не пробития чека на ФР-е вообще нет смысла. Пробивать чек нужно не в транзакции, а отдельной обработкой, сделав запись документа до (с признаком начала пробития чека) и после (с признаком окончания).
171 Гений 1С
 
гуру
15.03.15
14:25
(170) это все припарки мертвому, ненадежные. В DrvFr1C нет метода для проверки завершенности транзакции. Это странно. С таким подходом супермаркеты не автоматизировать, гыгыгы...

(169) да, там штук 5 комбинаций. комп может тупо перезагрузиться, когда чек пробьется, и 1с не получит подтверждение пробитости чека, например.
173 Гений 1С
 
гуру
15.03.15
14:26
(163) как как. У товара ставится признак Новый и периодически новые товары синхронизируются, дубли заменяются. делов-то.
174 Гений 1С
 
гуру
15.03.15
14:27
(163) на уровне драйвера можно все получить, да.
но 1с не позиционирует себя как надежное решение для розницы, т.к. в типовом драйвере DrvFR1s нет возможности для проверки законченности транзакции. Вот и вся малина
175 Torquader
 
15.03.15
18:09
(174) В типовом драйвере есть метод, позволяющий получить состояние ФР-а и даже данные из ЭКЛЗ, чтобы не только понять состояние последнего чека, но и нужного чека по номеру - у меня так и работало. Причём, дату-время завершения чека только из ЭКЛЗ и можно получить, так как получение даты-времени до начала завершения чека не даёт гарантии, что он именно тогда завершится.
Конечно, всё без танцев с нескольким количеством бубнов не обходится, но, если захотеть, то всё получается.
И база данных в текстовых файлах тоже получается.
176 Stim
 
15.03.15
19:03
все не читал. со времен изобретения квадратно-круглого метода выгрузки начального узла это велосипед уже с треугольными колесами.

вместо того, чтобы настроить и использовать штатный риб, горе-одинесник тратит уйму человеко-ресурсов на безобразную г0вноподелку сверху.

гнать сцаными тряпками!
177 Остап Сулейманович
 
15.03.15
19:20
+ (176) Помимо прочего РИБ в мобильной платформе не поддерживается. Но методика обмена прописана в штатной документации. С использованием планов обмена и фильтрацией по реквизитам участвующих в обмене данных.
Одна пичаль. Это читать надо. И не пропишешь "мой гений дарит вам". А к "безобразную г0вноподелку" - влегкую.
178 Torquader
 
15.03.15
19:22
На самом деле, проблема работы ФР даже не в драйвере - она глубже.
Начнём с того, что ФР как и любой принтер - пассивное устройство, то есть оно не умеет передавать команды в компьютер, а только отвечает на переданные компьютером.
В случае печати и завершения чека фискальные регистраторы Штрих-М (и Атол, так как они "потомки") выполняются команду за два этапа - сначала проверяется режим и возможность выполнить команду, потом выполняются вычисление и выдаётся ответ компьютеру, а только после ответа начинается печать чека.
Поэтому, чтобы узнать у ФР-а напечатал он чек или нет - нужно давать отдельную команду - запрос состояния (для ФР-а Штрих-М не так часто, так как эта команда очень замедляет исполнение печати).
179 Остап Сулейманович
 
15.03.15
19:29
(178) Классика жанра для кассовых аппаратов / фискальных регистраторов - печать чека только после фискализации.
Есть бумажный чек - гарантировано есть запись в фискальной памяти.
Драйвер всегда возвращает код результата операции.
180 Torquader
 
15.03.15
19:33
(179) Как раз у Штрих-М фискальник отвечает "закрытие чека выполнено успешно" и только начинает печатать чек. Понятно, что отменить чек после этой команды нельзя, а критические ошибки ФР-а рассматривать не обязательно, так как после них ФР отправляется в сервисную организацию, но, например, окончание бумаги в процессе печати требует выдать пользователю сообщение о том, что её нужно заменить, а также дать команду продолжения печати, чтобы допечатать чек на новом рулоне.
181 Torquader
 
15.03.15
19:34
P.S. работа с ФР и другим торговым оборудованием с РИБ никак не связано.
182 Остап Сулейманович
 
15.03.15
19:38
(181) По вопросам обмена рекомендую http://its.1c.ua/db/pubintromobile#content:117:hdoc. Там есть все, что сырожа пытается представить прорывом.
183 Остап Сулейманович
 
15.03.15
19:40
(182) Правда там основным транспортным каналом рекомендуют Web-сервис. Но в легкую обмен дополняется обменом файлами сообщений. И это там тоже есть.
184 Torquader
 
15.03.15
20:02
(183) Канал не важен - есть проблема, когда все узлы (например, вечером) должны обменяться с центром.
185 Остап Сулейманович
 
15.03.15
20:07
(184) Поделка от сырьожи эту проблему никак не решает.
186 Остап Сулейманович
 
15.03.15
20:09
+ (185) Нужна запись измененных данных - она должна быть выполнена. Параллельная запись в одну таблицу БД - это фантастика даже в исполнении сырожи.
187 Torquader
 
15.03.15
20:10
(186) Параллельная запись в одну таблицу - для нормальных SQL-серверов - это повседневная реальность.
189 Остап Сулейманович
 
15.03.15
20:27
(188) Да ладно... Я же не настаиваю на том, что это невозможно. Я говорю, что при любом варианте записи нужно время. И переименование файлов из send в read этот процесс никак не ускорит.
190 Torquader
 
15.03.15
23:22
(188) Ну, поставьте FireBird и посмотрите, как оно работает - можно даже в одну строку параллельно писать, только вот второму будет "сюрприз" при COMMIT-е.
Так что, думаю, взрослые SQL-сервера тоже это умеют, если не из коробки, то после настройки.
Просто, если "хорошим" программистам 1С дать такой инструмент, то "гвоздей назабивают аш мама не горюй".
191 Immortal
 
17.03.15
00:38
(169) речь про другую ситуацию, когда 1с рухнула.
фискальник сам по себе очень надежен и его ПО падает на порядок реже.
192 Torquader
 
17.03.15
00:44
(191) Можно перед пробитием чека записать его содержимое в текстовый файл, чтобы потом можно было восстановить.
Но, если сделать запись до пробития и запись после, то ничего теряться не должно.
Случай, когда база 1С "отправилась коту под хвост" мы не рассматриваем как и случай, когда "за фискальником пришёл белый лис".
193 eeeio
 
17.03.15
03:10
Если не ошибаюсь, то для избавления от проблемы блокировки при выгрузке (и если не страшен риск ущерба целостности данных) достаточно установить размер транзакции = 1 (ну или 100).
194 Гений 1С
 
гуру
17.03.15
10:07
(175) и как называется типовой метод из DrvFr1s, дружище? гыгыгы...
195 Гений 1С
 
гуру
17.03.15
10:08
(176) штатный риб не значит лучший риб. ;-)
горе поделка работает лучше штатного риб, как быть? чую холивар
196 Гений 1С
 
гуру
17.03.15
10:09
(191) вот именно. 1с упала и чек не получит подтверждения от фр.
197 Гений 1С
 
гуру
17.03.15
10:09
(191) или кабелек задели и подтверждение не прошло в 1с.
198 Гений 1С
 
гуру
17.03.15
10:10
(192) она не отправилась, комп перезагрузился. Скажем так, при объеме 100 магазинов с нагрузкой 100 чеков в день в среднем случалось 2-3 коллизии с ФР при штатной схеме подтверждения.

не забудьте также, что типовая 1с ставит статус пробит и пытается перепровести чек, а перепроведение чревато неудачей (при блокировках), так что типовая Розница весьма крива в этом плане.
199 Гений 1С
 
гуру
17.03.15
10:11
(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.

(182) Стыдно давать ссылки на закрытые ресурсы, не комментируя содержимое.
200 Злопчинский
 
17.03.15
10:19
(198) штатные схемы вообщем страдают херней обычно. Хочешь чтобы работало устойчиво и быстро - надо переписывать. Это еще и на семерочной рознице так было.
201 Злопчинский
 
17.03.15
10:25
GetEKLZDocument ПолучитьДокументЭКЛЗ
Метод позволяет по номеру КПК, который следует указать в свойстве KPKNumber, извлечь из ЭКЛЗ и распечатать документ, соответствующий этому номеру. Перед вызовом метода в свойстве Password указать пароль системного администратора. В свойство UDescription возвращается название ККМ из ЭКЛЗ.
204 Torquader
 
17.03.15
20:17
(201) Лучше смотреть в сторону GetEklzState, так как там можно увидеть дату и время последнего документа.
205 vde69
 
17.03.15
20:26
------------------------------------------------
eeeio
193 - 17.03.15 - 03:10
Если не ошибаюсь, то для избавления от проблемы блокировки при выгрузке (и если не страшен риск ущерба целостности данных) достаточно установить размер транзакции = 1 (ну или 100).

------------------------------------------------
Гений 1С
199 - 17.03.15 - 10:11
(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.


------------------------------------------------
Прикольно, сначала появились блокировки

Г1С придумал отменить транзакции и распиарил это на инфостарте
потом именно из-за отмены транзакции пошли пропадания данных
и тут Г1С стал бороться с потерями данных (вместо того, что-бы признать, что сделал ошибку и вернутся к проблеме блокировок) он опять начинает изобретать сомнительную схему и ее пиарить....

ничего в нашем мире не меняется !!!
206 Torquader
 
17.03.15
20:54
Размер транзакции в 1 объект не должен приводить к потере данных, так как транзакция всё равно будет отрабатываться.
А вот отказ от транзакций вообще действительно может приводить к потере данных из-за блокировок, которые таким образом отменили.
209 Гений 1С
 
гуру
19.03.15
10:41
(205) если транзакция отменяется, то и вся выгрузка отменяется как бы. не вижу проблемы
210 Garykom
 
гуру
19.03.15
10:52
(209) та ладно, мы вот как бы не видим проблемы юзать стандартный механизм риб (слегка отшлифованный)
211 Garykom
 
гуру
19.03.15
10:53
(210)+ вместо какой то неведомой ...
212 Гений 1С
 
гуру
19.03.15
14:35
(210) я список преимуществ написал, ты видимо его пропустил мимо ушей. В моей схеме меньше блокировок, например, т.к. при выгрузке таблица изменений не блокируется.
213 Гёдза
 
19.03.15
14:40
Не знаю как реализация, но сама идея пообъектной выгрузки и пообъектного снятия регистрации горазда лучше типового 1с риба и пачками изменений
214 Garykom
 
гуру
19.03.15
14:43
(213) гы, а пухнущая база не мешает? когда 100+ узлов? для каждого нужно каждый измененный объект хранить не? вместо пакета?
215 sikuda
 
19.03.15
15:10
(213) Эта идея как раз и тесно связана с "Потерей данных при обменах. Непонятно почему происходит, началось после введения параллельных выгрузок на точки."

Вы же тупо теряете ссылочную целостность. Аккуратно ее восстанавливать и есть решаемая задача.