Cинхронизация информации о справочнике номенклатур

[Ievgenii]

Вопрос:

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

Интерисуют примеры "из жизни".

Спасибо
Женя

[fed]

Никогда не слышал об УСПЕШНЫХ децентрализованных инстолляциях Аксапты. В реальности - обычно гораздо дешвле поставить терминальный сервер для обслуживания удаленных филиалов чем мучаться с синхронизацией.
Если же это не филиалы, а просто разные бизнесы, связанные общим или перекрестным владением - проще поставить две отдельных аксапты (это же два несвязанных или слабосвязанных бизнеса) и просто в конце периода консолидировать балансы.

В 2001-2003 годах, когда каналы связи были дорогими, я слышал о попытках прикрутить репликацию (в том или ином виде) к Аксапте, но по моему они заглохли еще на стадии создания прототипа.

[lev]

На предыдущем месте работы было что то похожее. Был офис и магазины, с разными базами между которыми была настроена репликация через "почтовую систему" от Коруса.
С этой репликацией были сплошные проблемы, и в итоге полноценного онлайна не получилось. Так же уходило куча времени на поддержку репликации.
В общем fed прав, терминал проще и дешевле.

[Ievgenii]

Ясно, спасибо. А что вы скажете про синхронизацию master data между Ax и другими системами (CRM как пример), в которых номенклатуры, контакты и так далее также создаються?

[sukhanchik]

На одном из клиентов, с которым я связан (DAX 4.0) - интегрируется WMS (перекресточное решение Колумбуса) и "основная" системы. Связь организована достаточно просто - выгрузили DBF - загрузили DBF. Есть ограничение (упрощение), что какие-то поля редактируются в WMS (вес, объем к примеру), остальное - (в т.ч. создание и удаление) - в "основной". Много кода в связи с этим, который занимается выгрузкой и загрузкой. Судя по датам в коде - код тянется с предыдущих проектов с "подшлифовкой" под конкретного клиента. Насколько я понял по коду - ситуация с удалением номенклатуры не обрабатывается.
Кол-во номенклатур (записей в InventTable) около 20 тыс.

Также у нас организован Интернет-магазин (правда на отдельном сервере, не администрируемом нами), в которую организована выгрузка номенклатур без использования AIF, но в формате XML (опять-таки - программирование свое).
Но тут опять-таки принято ограничение - номенклатуры вводятся только в АХ. Соответственно - при выгрузке номенклатур - создается некий журнал выгрузки.
Каждая следующая выгрузка "собирает" данные для выгрузки заново и сравнивает "собранные" данные с журналом предыдущей выгрузки. Окончательный файл обмена формируется как разница между "текущими" и "прошлыми" данными по журналу выгрузки. Т.о. удаление номенклатуры происходит корректно (шлется информация об удалении)
В XML-файле кроме всего прочего содержатся еще все картинки, прикрепленные к исходной записи (в кодировке base64).

[jonny]

У нас для синхронизации разных инсталяций аксапты, а так же аксапты и 1С используется система с интеграционными таблицами(промежуточными), передача данных с помощь MS DTS, обработка изменений на принимающей стороне пакетными заданиями. Все работает вот уже как три года, нареканий нет.

[mazzy]

Цитата:

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

В реальности - обычно гораздо дешвле поставить терминальный сервер для обслуживания удаленных филиалов чем мучаться с синхронизацией.

Ап-солютно согласен.

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

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

Цитата:

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

Был офис и магазины, с разными базами между которыми была настроена репликация через "почтовую систему"...

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

Цитата:

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

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

Журнал?
Обычно достаточно сравнить дату и время модификации с датой последней выгрузки.

Насчет удаления. Дык, нельзя же удалять номенклатуру, если по ней уже есть проводки. Можно только заблокировать.

Так ли уж часто выполняется удаление, чтобы этим парится?

Цитата:

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

В XML-файле кроме всего прочего содержатся еще все картинки, прикрепленные к исходной записи (в кодировке base64).

Ой...

[mazzy]

Цитата:

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

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

Если все же подумать над синхронизацией еще раз, то станет ясно, что если и возникает потребность в синхронизации, то не столько в синхронизации самой номенклатуры, сколько в синхронизации подчиненных номенклатуре, контактам, вендорам справочников (то, что скрыто в "и так далее")

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

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

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

и уж стоит отметить, что в аксапте уже реализована синхронизация платежей с клиент-банковскими системами

Цитата:

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

Ясно, спасибо. А что вы скажете про синхронизацию master data между Ax и другими системами (CRM как пример), в которых номенклатуры, контакты и так далее также создаються?

дык, в том то и дело, что по-разному и каждый раз это уникальное творчество и результат поиска компромиссов.

а еще софт для Call-центров, в которых CRM-данные хранятся и обрабатываются в более полном и в более специализированном виде.

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

С MS CRM вообще отдельная пестня.
MS CRM умеет работать в оффлайн режиме, когда продавец работает на персональном компе, не подключенном в сеть. А когда продавец подключается в сеть, то MS CRM автоматически синхронизирует свои данные с MS CRM сервером.

И если понятно что делать с выгрузкой из CRM всяких коммерческих предложений...
то совершенно непонятно как загружать в CRM данные из Аксапты о дальнейших операциях (прошла оплата, заказ доставлен, срок доставки заказа изменен и т.п.)

В общем:
1. если говорить о синхронизации, то лучше говорить не только о главных справочниках, но и о подчиненных (номенклатура+цвет+размер+конфигурация+партии+гтд, контрагент+договор, спецификация+маршрут+операции)
2. лучше не начинать разбор вопроса с MS CRM. Он сильно усложнит задачу из-за встроенного в него оффлайн-режима.

[sukhanchik]

Цитата:

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

Журнал?
Обычно достаточно сравнить дату и время модификации с датой последней выгрузки.

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

Цитата:

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

Насчет удаления. Дык, нельзя же удалять номенклатуру, если по ней уже есть проводки. Можно только заблокировать.

Да.. конечно согласен. тут моя мысля ушла не в ту сторону

[Weez]

Принимал участие в разработке функционала для синхронизации нужных справочников между удаленными инсталляциями Аксапты. Данные из различных таблиц падали в разные текстовые файлы и архивировались на лету. Работало практически как часы.
Подобное делал и для обмена данными с WMS - тоже особых проблем не замечано, задача крутилась в пакетнике и успешно отрабатывала.

[AlGol]

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

Как показывает опыт, затраты на передачу данных (на разработку и внедрение этого процесса) занимают меньше 20ти процентов от всего объема. Основная проблема - это обработка этих данных на местах. Вы должны понимать, зачем пришли данные и как их нужно обработать с учетом, например, того что эти же данные могут редактироваться на месте. И скорее всего вас попросят во многих случаях сделать так чтобы их можно было корректировать на месте.

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

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

Все это работает, везде есть свои проблемки и свои преимущества. Главное, чтобы выбранная платформа нигде не ущемляла необходимые потребности.

[twilight]

Мы делали промежуточные таблицы в Аксапте для загрузки / выгрузки данных. Сначала данные попадают в промежуточные таблицы, потом уже обрабатываются / выгружаются пакетным заданием. Таким образом синхронизировали справочники номенклатур, контрагентов. Загружали / выгружали заказы на покупку / заказы на продажу, обрабатывали накладные.

[EVGL]

Цитата:

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

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

Такая задача еще не стояла. Как и указывает Д. Фед., с версией 4.0 появилась возможность работать на едином приложении по всей Европе, поэтому все сидят в одной базе. Самое смешное, что синхронизировать номенклатуру не всегда возможно из-за огранизационных ограничений и в этом случае: представим себе, что филиалы в каждой стране работают с локальными поставщиками сырья. Нужно ли синхронизировать такое сырье? Очевидно, что нет.

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

• кому продано?
• что продано?

Подобная информация получается всегда упрощенной:

• код - имя - адрес - сегмент рынка
• код - название - классификация

Чтобы ее передать, можно использовать любой канал: почта, файлы, Web-сервисы. Чтобы ее подготовить, хватает маленькой собственной программы. Можно использовать и AIF.

[Yaroslav]

У нас в свое время в филиал в другом городе передавались:
InventTable + InventItemLocation + InventTableModule
Dimensions
LedgerJournalTable + LedgerJournalTrans
SalesTable + SalesLine --> PurchTable + PurchLine
И самое главное - был реализован мехнизм "передачи разносок", то есть при обработке накладной по заказу в источнике в приемнике автоматически обрабатывалсь накладная по закупке.
Как правильно заметили выше, основной геморрой был не с траспортом (мы использовали ftp-сервер), а с логикой.
А в конце концов все было решено административными мерами - вместо отдельного юр. лица филиал был преобразован в обособленное подразделение, передача товара ему превратилась в складское перемещение, учет был переведен в одно место и счастливые пользователи (ди и ИТ тоже) теперь используют терминал.