Выгрузка измененных клиентов во внешнюю систему

[mazzy]

Цитата:

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

Ну проблема что в АХ это не так. Т.е. в таблице LogisticsPostalAddress, LogisticElectronicAddress нет типа адреса(что это клиент или не клиент) и там хранятся адреса для всех сущностей( в том числе и для транзакционных).

Ну, во-первых, это не проблема, а задача! А проблема - это DirParty в целом.
Будь проклят тот архитектор, который начал портить Аксапту с этого фреймворка

Смотри:
1. с точки зрения бизнес-логики адреса - это не бесконечный список произвольных адресов, это вполне конретные адреса с определенной ролью - юридический адрес, адрес склада 1, адреса склада N, почтовый адрес и т.п. причем один и тот же адрес может использоваться для разных ролей адресов
2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец)
3. но я сильно сомневаюсь, что в системе приемнике адреса реализованы точно также

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

поэтому, задача "выгрузить-и-загрузить LogisticsPostalAddress, LogisticElectronicAddress" - это полный бред программистского подхода. нафиг это никому не нужно.

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

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

Цитата:

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

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

а ты похоже пытаешься выгрузить данные из DirParty одним запросом...
как скажешь.

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

для решения конкретной технической задачи "быстро, запросом узнать изменились ли записи в конкретной таблице с таким-то фильтром" вполне подойдет shadow-таблица

Цитата:

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

Получается остается только решение предложенное DSPIC.

как скажешь.

Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.

Но если остается только это. что ж поделать. как скажете

[DSPIC]

Цитата:

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

Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..

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

Цитата:

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

Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..

Эмм... как скажешь

[EVGL]

Цитата:

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

2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец)

Доводы в пользу DirParty:
0) Intercompany
1) В теории так легче синхронизироваться с CRM. В теории.
2) В самой таблице может быть тоже много общего, например между клиентом и поставщиком: название и юридическая форма, естественно, но и DUNS, номер в "ЕГРЮЛ", "ИНН" (меня регулярно разочаровывает, что в DirPartyTable нет VatNum). Недавно имел диагностику на клиенте, у которого почти каждый грузоотправитель одновременно и грузополучатель.