9.1 PostgreSQL как решить проблему ведения множества юр лиц?

Программирование на Атлантисе (VIP, FCOM, ARD), FastReport

Модераторы: m0p3e, edward_K, Модераторы

ecasoft
Местный житель
Сообщения: 645
Зарегистрирован: 29 мар 2005, 17:49
Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"

9.1 PostgreSQL как решить проблему ведения множества юр лиц?

Сообщение ecasoft »

Мы как партнеры десяток лет ставили автоматизацию множества юр лиц, которые работают на одинаковых справочниках (МЦ, каталоги налогов, организации и т.д. всего штук 15-20) на базе механизка SяHEМА (пути в разных БД указывают на одни файлы, так они становятся общими для разных БД) на Первасиве, а также делали корпоративную отчетность и интерфейсы просмотра документов разных баз данных и их прямого копирования между базами а-ля Нортан и все на механизме OpenTableByPath (позволяет открыть динамически под разными синонимами одну таблицу разных БД).
Как всем известно Галактика закрывает Первасив в 9.1, а с ним и эту всю описанную выше функциональность (файлов в PostgreSQL нет, а есть единая БД и таблицы не распределишь, OpenTableByPath не понятно что означает и его убрали).

Мы сейчас оказались в очень сложном положении,т.к. альтернативы для ведения корпорации (PostgreSQL) в Галактике не стало.

Единственный очень дорогой (примерно повторная закупка + удвоение сопровождение) и очень сложный )нужно все наработанное за десяток лет переписать на механизм филиальности (не уверены что и получется как у нас было - другая идея) при переходе на Ms SQL. Филиальности на PostgreSQL нет (нет такого в Прайсе).

Хотелось бы найти тех, кто попал в аналогичную ситуацию. А также опыт по использованию филиальности. Спасибо.
P S Пока начали с клиентами продумывать переход на 1С, как самый понятный (по реализации) и реальный (по цене для клиента) выход. Не в восторге, но выхода сами не видим.
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5187
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение edward_K »

На MsSql тоже есть возможность делать общими справочники, сам не деалал, но слышал.
Что же касается филиальности, то это с одной стороны требует четкого понимания какие справочники будут общие, какие нет, но с
другой стороны можно будет получать отчеты по всем филиалам сразу(при наличии прав разумеется).
LaaLaa

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение LaaLaa »

Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.

Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
LaaLaa

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение LaaLaa »

Как вариант синхронизировать справочники межу разными БД можно с помощью Корпо обмена.

Кроме того синхронизацию отдельных таблиц можно запрограммировать средствами смой СУБД на PL/pgSQL.
ecasoft
Местный житель
Сообщения: 645
Зарегистрирован: 29 мар 2005, 17:49
Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение ecasoft »

Всем спасибо за комменты!

Хорошая новость о тестировании филиальности на рассматриемой базе - будем ждать. Надеемся также, что и ценовая политика на филиальность будет разумная (сейчас при 13 небольших фирмах в корпорации цена на MS SQL переваливает 10000 $), т.к. если до этого никто вообще не платил за лицензии по филиальности ничего на Первасиве, то предложить ему такие суммы просто за лицензии, да + сопровождение будет плохой идеей :sad:

К сожалению, нет решения для кода, который был написал на ВИПе и который смотрел все БД. Там интерфейсы. Да и отчеты сводные получается нужно переписывать полностью, если использовать FASTREPORT и доступом к разным базам. Кто это все захочет оплачивать - непонятно. Новых приладных свойств это не добавит, а скорее сократит - как объяснить руководству предприятий ЗА ЧТО ОНИ БУДУТ ПЛАТИТЬ?

Чем плоха филиальность - все фирмы в обной БД. На это некоторые предприятия не пойдут никогда. Понятно почему.

Никто получается не использовал копроративность на Первасиве?

P S Жаль, что новшества приведут к неминуемой потере клиентов. Видимо у Галактике слишком много клиетов, что она их так просто вышвыривает.
LaaLaa

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение LaaLaa »

На Первасиве филиальности не было. Ее технически не возможно было там сделать.

Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
m0p3e
Местный житель
Сообщения: 1386
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение m0p3e »

ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и работать будет однозначно быстрее.
spark
Местный житель
Сообщения: 476
Зарегистрирован: 19 окт 2005, 13:38
Контактная информация:

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение spark »

LaaLaa писал(а):Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.

Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?
LaaLaa

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение LaaLaa »

spark писал(а):"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?
Может быть техподожерка имеет опыт в этом. Попробуйте вопрос там задать.
ecasoft
Местный житель
Сообщения: 645
Зарегистрирован: 29 мар 2005, 17:49
Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение ecasoft »

m0p3e писал(а):ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и рабо втать будет однозначно быстрее.

Вы видимо на MS SQL, т.к. филиальности на рассматриваемой БД нет. На Ms Sql наши клиенты не хотят, а на PostgreSQL ее нет в Прайсе даже. Вот появилась информация, что будет вроде. До осени будет ждать. Для одно клиента это нормально, если не считать, что придется переписать код, который нарабатывался лет 5-6. Большой вопрос финансовый тут.

Для другого клиента одна БД для нескольких фирм не подходит. Тоже много кода.

Вопрос в принципе в чем. Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности. Если наберем группу, то возможно реализация в Галактике такого функционала.
ecasoft
Местный житель
Сообщения: 645
Зарегистрирован: 29 мар 2005, 17:49
Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение ecasoft »

LaaLaa писал(а):На Первасиве филиальности не было. Ее технически не возможно было там сделать.

Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
Описанный механизм был поставлен внедренцами из ТОП-Софт в ЮКОСе в конце 90-х. Именно в ЮКОСе я впервые и уведел его, когда работал с этой компанией позже по договору. У нас все клиенты - корпорации из большого число ЮЛ и еще филиалов с общими таблицами. Этот функционал отлично подходил для реализации ведения деятельности в рамках корпорации. Сначало сделали для одной фирмы, а когда показывали других, то другие брали с удовольствием. И так было более 10 лет.
Понятно, что Первасив файловая система, а тут БД. И может механизм и устаревший, но другого нет.
Филиальности, как сами Вы знаете на платформе нет. Что делать клиентам? Они не видят этих функций (не знаю устаревгие они или нет)- они видят прикладные решения, которые хотят увидеть и платят деньги десятки лет, а каждый год ездят на конференции и так говорят, что у них Галактика работает хорошо.
Теперь давайте скажем, что функции устарели...клиентам скажем, что Галактика в том виде, как Вы ее эксплуатировали больше не будет работать, а за то, как мы вам сделает года через три Вы будете платить в два раза больше. Может пойти по пути создания аналогичного современного механизма доступа к различным БД по аналогии с устаревшими? Эмуляция этих функций?
Алексей
Местный житель
Сообщения: 2896
Зарегистрирован: 24 июн 2005, 12:12
Откуда: Иркутская область

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение Алексей »

здесь поддержу ecasoft
Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
Dmitry_Sol
Постоянный гость
Сообщения: 76
Зарегистрирован: 07 июн 2007, 12:32
Откуда: Витебск
Контактная информация:

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение Dmitry_Sol »

Я тоже пользовался функцией opentablebypath , на двух успешных и работающих проектах. Если не будет ее эмуляции, то придется ее делать самому. Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива. Этот механизм у меня в четырех организациях внедрен.
Если по opentablebyPath есть номер пир, сообщите его, чтоб мы Минскую поддержку тоже пошевелили. Хочется к концу года перейти на 9.1. Но и переделывать все самим не хотелось бы.
spark
Местный житель
Сообщения: 476
Зарегистрирован: 19 окт 2005, 13:38
Контактная информация:

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение spark »

Dmitry_Sol писал(а): Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива.
Ну в принципе функционал Enterprise, который работает на оракле и сиквеле, по сути таже самая shemealias.
KATZ
Местный житель
Сообщения: 473
Зарегистрирован: 29 мар 2005, 17:49

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Сообщение KATZ »

Алексей писал(а):Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
Да уже минимум лет 10 никакой борьбы нет. На 1000 пользователей с 1С один с "Галактикой", где здесь борьба-то?
ecasoft писал(а):Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности.
Мне тоже приходилось OpenTableByPath когда-то использовать. Клиент имел энное количество юр. лиц, все вели учет по единым правилам, но каждое - в своей БД, и было написано несколько специфических отчетов, консолидирующих данные по всем ЮЛ.
ecasoft писал(а):Если наберем группу, то возможно реализация в Галактике такого функционала.
Может, вам легче и быстрее будет собрать группу противников отказа от Первазива?

А хотите еще один вариант, получше? Вы с "Галактикой" давно работаете, ВИП у вас наверняка куплен и пара грамотных программистов найдется. Сейчас заключать договоры на АО и обновляться пользователи вынуждены по одной-единственной причине - из-за изменений законодательства. "Непрерывно наращиваемый функционал", о котором так любят говорить разработчики, 99,9% пользователей нахрен не нужен, у них уже всё устоялось, а с каждым обновлением только новые глюки добавляются. Откажитесь от обновлений из корпорации и поправляйте "Галактику" сами, только лишь в объеме, минимально необходимом для поддержки изменений в законодательстве. Сначала на своих клиентах это дело отладите, а потом кинете клич по всей Руси великой, стоимость установите вместо 3% в месяц, допустим, 1%, и 8 из 10 нынешних пользователей "Галактики" с радостью уйдут из корпорации и от ее партнеров к вам.
Ответить