Народ, покритикуйте идею интеграции

[George Nordic]

Не делайте так.

Подумайте над преимуществом единой инсталляции.
Ведите каждую компанию в отдельно настроенной компании.

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

Отдельно обратите внимание на сторнирующие документы (сторно, кредит-нота, возвраты и т.п.)

При раздельной инсталляции - приложения раъедутся. 100%

С Уважением,
Георгий

[imir]

Цитата:

Сообщение от George Nordic

Не делайте так.

Подумайте над преимуществом единой инсталляции.
Ведите каждую компанию в отдельно настроенной компании.


При раздельной инсталляции - приложения раъедутся. 100%

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

Приложения не должны разъезжаться по регламенту, но допустим что разъедутся - при импорте это не так критично - добавь новые поля, таблицы или не грузи вообще специфичные для филиалов поля.

[George Nordic]

Цитата:

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

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

Приложения не должны разъезжаться по регламенту, но допустим что разъедутся - при импорте это не так критично - добавь новые поля, таблицы или не грузи вообще специфичные для филиалов поля.

Ой какие слова знакомые. Не из Сибири ли организация часом?

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

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

С Уважением,
Георгий

[imir]

Цитата:

Сообщение от George Nordic

Ой какие слова знакомые. Не из Сибири ли организация часом?

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

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

Ну все крупные компании частично из Сибири

Протянуть свою оптику конечно можно - стоить будет как сам проект Аксапты дополнительно. Плюс они ж явно будут работать в разных компаних, если в одной базе - соотв. отчетность все равно писать кросскомпанейскую либо еще отдельно ХД строить.
Я вобщем-то не против, но в данной части решение уже тоже принято.

>>собирайте данные раз в день

Ну вот - не хотят раз в день - есть у их ХД сейчас - страдает неактуальностью, задержками, хотят как раз оперативности. Можно ведь вообще факт грузить свернуто по дням - так тоже - детали нужны, до документа, до позиции. Требования понятно космические - тем интереснее

[imir]

Я вот вобщем хотел вернуться к сути решения - архитектуре

1) Не напорюсь-ли я на какие-то подводные камни - допустим - дефрагментацию RecId, экспорт-импорт компании делать, понятно - не будем.

2) Допустим с уникальными индексами мы разобрались с помощью префиксов - точно-ли?

3) Заработают-ли стандартные отчеты, когда в систему в одну кучу свалятся закрывающие проводки, закрытие складов и проч. радости с 10 баз?

4) ....?

[Vadik]

Цитата:

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

Я вот вобщем хотел вернуться к сути решения - архитектуре

Есть же ХД - заставьте его таки работать, не навешивайте экспорты-импорты и интеграции - не взлетит

[imir]

Цитата:

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

Есть же ХД - заставьте его таки работать, не навешивайте экспорты-импорты и интеграции - не взлетит

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

Вот взлетит или нет - хотелось бы реально понять сейчас

[nix0root]

Я бы использовал кубы олап на основе materialized views, обновления их поставил бы исходя из того временного интервала кот необходим.
Т.е. materialized views InventTrans состояла бы из InventTrans-ов 10 филиалов.
Выделяешь под это дело хороший сервачок, если базы под ораклом (10R2) я бы посоветовал IBM AIX 5 к примеру, клиентам для отчетности ставишь discoverer plus с OLAP опцией и вперед!

[imir]

Цитата:

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

Я бы использовал кубы олап на основе materialized views, обновления их поставил бы исходя из того временного интервала кот необходим.

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