AX2012R3: полная синхронизация данных POS-магазина

[Ivanhoe]

Ситуация странная, в R2, который сам внедрял точно не было такого - на новый магазин создавалось задание, остальные не трогались. По R3 уточняю у коллег, но это очень странно, если добавление магазина пересоздает справочник везде.

Ну и в целом, какие-то бешенные у вас ассортименты. Это что, запчасти какие-то? Даже в продуктовых гиперах активных позиций на магазин максимум тысяч 100 и это с запасом.

[PTG]

Цитата:

Сообщение от Ivanhoe

Ситуация странная, в R2, который сам внедрял точно не было такого - на новый магазин создавалось задание, остальные не трогались. По R3 уточняю у коллег, но это очень странно, если добавление магазина пересоздает справочник везде.

Ну и в целом, какие-то бешенные у вас ассортименты. Это что, запчасти какие-то? Даже в продуктовых гиперах активных позиций на магазин максимум тысяч 100 и это с запасом.

В R2, если не ошибаюсь механизм аналогичный AX5. Собственно мы перелезли с АХ5 на R3 и механизм уже другой.
Уточните пжлс еще у коллег, стоит ли под каждый магазин создавать свою отдельную группу данных канала?

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

Да ассортименты бешеные: от колбасы до ручек.

[mazzy]

Цитата:

Сообщение от ZornFire

delete from inventtable это вот зачем?

Именно

Цитата:

Сообщение от PTG

В R2, если не ошибаюсь механизм аналогичный AX5. Собственно мы перелезли с АХ5 на R3 и механизм уже другой.

и в r2 и в r3 существует понятие "иерархия таблиц"
в r2 эта иерархия настраивалась в справочнике аксапты.
в r3 эта иерархия существует в виде xml-файла, изменяется только в текстовом редакторе.

суть этой иерархии - сформулировать какие таблицы от каких зависят.
в результате при удалении одной записи POS может удалять все записи в ветке дерева, если таблица имеет подчиненные таблицы и включен параметр "Каскадное обновление".

мало того, "удаление и обновление с сервера" приводит к тому, что на POS посылается команда "удалить" и тут же в пакете огромный набор данных для подчиненных таблиц. Ведь на POS подчиненные записи будут удалены и их придется обновлять с новой номенклатурой.

повторюсь, в r3 точно такой же механизм. только настройка в xml-файле, а не в аксапте. насколько я помню, интеллекта в этот механизм не добавляли.

продукты, насколько я помню, находятся где-то в середине иерархии.
насколько я помню, к продуктам были пристроены с десяток других таблиц.

снятие галочки "Каскадное обновление" решает проблему с производительностью
но добавляет кучу геморроя с точки зрения целостности данных.

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

==========================
кстати, будете добавлять свои таблицы, также предельно внимательно следите за каскадным обновлением. с одной стороны каскадное обновление действительно гарантирует целостность. с другой стороны...

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

==========================
по идее число delete/insert должно быть минимальным всегда.
прежде чем менять настройки, галочки и джобы, разберитесь почему вообще возникают команды на удаление при реинициализации.