Проблемы работы ERP в многофилиальной и территориально разнесённой компании СНГ.

[SlavaK]

Кomar, спасибо за ответ, но как всегда возникли дополнительные вопросы:

Цитата:

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

Интересно, а почему нельзя тогда применять ритейловое ПО не только для розничной торговли, но и для мелкооптовой/оптовой торговли? Или функционал у ритейлового ПО сильно обрезан? Может быть у Вас есть ссылки где можно почитать про технические и функциональные возможности Axapta ретейл?

Цитата:

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

Ну так и мы очень сильно сомневаемся в этом решении, но пока других вариантов в Axapta не видим. Другое дело если бы 3-ёх звенка Axapt-ы ещё позволяла бы сохранять на клиенте часть данных, а при появлении связи выкидывала бы их на сервер Центральной БД, как в Midas, но насколько я понял в Axapt-е такая функция не реализована?

Цитата:

Изначально опубликовано komar
Добавление полей - это не проблема,

Уточните, пожалуйста - при добавлении нами поля в таблицу Axapt-ы все механизмы Базовой Конфигурации, которые работают с этой таблицей, будут так же безошибочно отрабатывать?

Цитата:

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

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

Цитата:

Изначально опубликовано komar
Как правило, партнер поддерживает тлько свои доработки, Навижн - стандартную версию, а то, что написали сами, будете сами и чинить, или платить дополнительно денег.

В связи с этим вопрос, а при покупки лицензии на модуль исходники модуля предоставляются? Т.е. есть возможность сотрудникам предприятия, на котором проходит внедрение, самим исправить код Базовой конфигурации, перекомпилить и затем использовать его?

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

А может быть ещё лучше найти ERP-систему в которой возможность репликации уже реализована, наравне с удовлетворяющем нас функционалом.