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

[imir]

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

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

Звучит утопически и вот что мне привиделось:

Делаем импорт записей таблиц.

Для того, чтобы обеспечить уникальность данных:
1) Все номерные серии в филиалах делаем с префиксом филиала
2) Коды складов и проч, которые руками - тоже с префиксом.

! 3) Ключевой момент - каждой базе выделяем диапазон RecId. - т.е. тупо лезем в systemseq.. и ставим следующее значение. Благо сейчас оно 64bit - если весь диапазон с отрицательными значениями распилить на 11 баз - думаю все равно лет на 100 хватит.

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

Строим консолидированную отчетность, курим бамбук.

Собственно вопрос - что я упустил? )

[Zabr]

Цитата:

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

распилить на 11 баз - думаю все равно лет на 100 хватит.

Если с ростом бизнеса вместо 10 будет 100 городов, и в 10 раз увеличатся обороты в каждом регионе, то хватит на 1 год.

[imir]

Цитата:

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

Если с ростом бизнеса вместо 10 будет 100 городов, и в 10 раз увеличатся обороты в каждом регионе, то хватит на 1 год.

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

[_scorp_]

Цитата:

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

для построения сводной отчетности по сути...

Если цель только эта, то слишком сложный путь Вы выбрали. Я бы посмотрел в сторону OLAP.

[Ivanhoe]

Как часто происходит консолидация?
Какой объем данных?
Как отслеживаются "новые документы"?
Как отслеживаются исправления?
Что делать если настройки будут разные в разных Аксаптах?
Кто гарантирует одинаковость разноски документов (суммарная обработка, ручные округления и т.п.)?
....
А теперь главный вопрос: какая консолидированная отчетность нужна?

[George Nordic]

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

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

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

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

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

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

[lev]

Цитата:

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

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

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

Звучит утопически и вот что мне привиделось:

Делаем импорт записей таблиц.

Для того, чтобы обеспечить уникальность данных:
1) Все номерные серии в филиалах делаем с префиксом филиала
2) Коды складов и проч, которые руками - тоже с префиксом.

! 3) Ключевой момент - каждой базе выделяем диапазон RecId. - т.е. тупо лезем в systemseq.. и ставим следующее значение. Благо сейчас оно 64bit - если весь диапазон с отрицательными значениями распилить на 11 баз - думаю все равно лет на 100 хватит.

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

Строим консолидированную отчетность, курим бамбук.

Собственно вопрос - что я упустил? )

Ох...
Работал в одной компании, где было:
1. куча магазинов со своими база.
2. одна база в центральном офисе (консолидирующая магазины).
3. почтовая система, через которую ходили туда сюда документы.

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

Скажу откровенно, это был ТИХИЙ УЖАС (вспоминаю волосы шевелятся )
С почтой были проблемы, и в итоге магазин с офисом не сходился НИКОГДА))) Поддержка занималось тем что досылала сообщения, доразносила накладные и т.п.
В результате отчетности по движению товара, остатков на магазинах, балансу по поставщикам да и всей отчетности связанной с движением товара просто НЕ БЫЛО.
Ну и про то что офисная база пухла с молнейносной скоростью, я вообще молчу

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

[imir]

Цитата:

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

Если цель только эта, то слишком сложный путь Вы выбрали. Я бы посмотрел в сторону OLAP.

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

1) ХД с интерфейсом, причем стандартным, стандартные запросы отчеты, формы.

2) Возможность вносить еще какие-то данные попутные - т.е. наполнять ХД любыми доступными способами -для просто ХД пришлось бы придумывать процедуры импорта дополнительных данных.

3) Теоретически - вообще вести отдельный учет в этой базе, использовать ее как центр для нормативно-справочной информации.

всего этого просто ХД не могет - нужны спец продукты не дешевые.

[imir]

Цитата:

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

Как часто происходит консолидация?
Какой объем данных?
Как отслеживаются "новые документы"?
Как отслеживаются исправления?
Что делать если настройки будут разные в разных Аксаптах?
Кто гарантирует одинаковость разноски документов (суммарная обработка, ручные округления и т.п.)?
....
А теперь главный вопрос: какая консолидированная отчетность нужна?

Объем данных приличный и еще и поэтому вариант разносить документы меня напряг

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

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

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


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

[imir]

Цитата:

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

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

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


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

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

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

[imir]

Цитата:

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

Ох...
Работал в одной компании, где было:


Скажу откровенно, это был ТИХИЙ УЖАС (вспоминаю волосы шевелятся )
С почтой были проблемы, и в итоге магазин с офисом не сходился НИКОГДА))) Поддержка занималось тем что досылала сообщения, доразносила накладные и т.п.
В результате отчетности по движению товара, остатков на магазинах, балансу по поставщикам да и всей отчетности связанной с движением товара просто НЕ БЫЛО.

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

Вот собственно поэтому первый вариант у меня прямо перед глазами встал и все проблемы как вы описали тоже

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

[George Nordic]

Цитата:

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

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

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

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

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

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

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

[imir]

Цитата:

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

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

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

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

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

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

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

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

[imir]

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

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

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

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

4) ....?

[nix0root]

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

[fed]

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

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

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

[Vadik]

Цитата:

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

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

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

[imir]

Цитата:

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

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

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

[Vals]

Цитата:

И есть 11-я - консолидирующая, для построения сводной отчетности по сути.

Всё это вы хотите сделать только для построения сводной отчётности?

[imir]

Цитата:

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

Ты еще забыл про межфилиальные рассчеты.

Да, забыл сказать - бухло вообще пока за рамками проекта, соотв. всякие ОПИУ и балансы, эллиминации нас минуют.

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