9.1 PostgreSQL как решить проблему ведения множества юр лиц?
Модераторы: m0p3e, edward_K, Модераторы
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
9.1 PostgreSQL как решить проблему ведения множества юр лиц?
Мы как партнеры десяток лет ставили автоматизацию множества юр лиц, которые работают на одинаковых справочниках (МЦ, каталоги налогов, организации и т.д. всего штук 15-20) на базе механизка SяHEМА (пути в разных БД указывают на одни файлы, так они становятся общими для разных БД) на Первасиве, а также делали корпоративную отчетность и интерфейсы просмотра документов разных баз данных и их прямого копирования между базами а-ля Нортан и все на механизме OpenTableByPath (позволяет открыть динамически под разными синонимами одну таблицу разных БД).
Как всем известно Галактика закрывает Первасив в 9.1, а с ним и эту всю описанную выше функциональность (файлов в PostgreSQL нет, а есть единая БД и таблицы не распределишь, OpenTableByPath не понятно что означает и его убрали).
Мы сейчас оказались в очень сложном положении,т.к. альтернативы для ведения корпорации (PostgreSQL) в Галактике не стало.
Единственный очень дорогой (примерно повторная закупка + удвоение сопровождение) и очень сложный )нужно все наработанное за десяток лет переписать на механизм филиальности (не уверены что и получется как у нас было - другая идея) при переходе на Ms SQL. Филиальности на PostgreSQL нет (нет такого в Прайсе).
Хотелось бы найти тех, кто попал в аналогичную ситуацию. А также опыт по использованию филиальности. Спасибо.
P S Пока начали с клиентами продумывать переход на 1С, как самый понятный (по реализации) и реальный (по цене для клиента) выход. Не в восторге, но выхода сами не видим.
Как всем известно Галактика закрывает Первасив в 9.1, а с ним и эту всю описанную выше функциональность (файлов в PostgreSQL нет, а есть единая БД и таблицы не распределишь, OpenTableByPath не понятно что означает и его убрали).
Мы сейчас оказались в очень сложном положении,т.к. альтернативы для ведения корпорации (PostgreSQL) в Галактике не стало.
Единственный очень дорогой (примерно повторная закупка + удвоение сопровождение) и очень сложный )нужно все наработанное за десяток лет переписать на механизм филиальности (не уверены что и получется как у нас было - другая идея) при переходе на Ms SQL. Филиальности на PostgreSQL нет (нет такого в Прайсе).
Хотелось бы найти тех, кто попал в аналогичную ситуацию. А также опыт по использованию филиальности. Спасибо.
P S Пока начали с клиентами продумывать переход на 1С, как самый понятный (по реализации) и реальный (по цене для клиента) выход. Не в восторге, но выхода сами не видим.
-
- Заслуженный деятель интернет-сообщества
- Сообщения: 5188
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: SPB galaxy spb
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
На MsSql тоже есть возможность делать общими справочники, сам не деалал, но слышал.
Что же касается филиальности, то это с одной стороны требует четкого понимания какие справочники будут общие, какие нет, но с
другой стороны можно будет получать отчеты по всем филиалам сразу(при наличии прав разумеется).
Что же касается филиальности, то это с одной стороны требует четкого понимания какие справочники будут общие, какие нет, но с
другой стороны можно будет получать отчеты по всем филиалам сразу(при наличии прав разумеется).
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.
Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.
Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Как вариант синхронизировать справочники межу разными БД можно с помощью Корпо обмена.
Кроме того синхронизацию отдельных таблиц можно запрограммировать средствами смой СУБД на PL/pgSQL.
Кроме того синхронизацию отдельных таблиц можно запрограммировать средствами смой СУБД на PL/pgSQL.
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Всем спасибо за комменты!
Хорошая новость о тестировании филиальности на рассматриемой базе - будем ждать. Надеемся также, что и ценовая политика на филиальность будет разумная (сейчас при 13 небольших фирмах в корпорации цена на MS SQL переваливает 10000 $), т.к. если до этого никто вообще не платил за лицензии по филиальности ничего на Первасиве, то предложить ему такие суммы просто за лицензии, да + сопровождение будет плохой идеей
К сожалению, нет решения для кода, который был написал на ВИПе и который смотрел все БД. Там интерфейсы. Да и отчеты сводные получается нужно переписывать полностью, если использовать FASTREPORT и доступом к разным базам. Кто это все захочет оплачивать - непонятно. Новых приладных свойств это не добавит, а скорее сократит - как объяснить руководству предприятий ЗА ЧТО ОНИ БУДУТ ПЛАТИТЬ?
Чем плоха филиальность - все фирмы в обной БД. На это некоторые предприятия не пойдут никогда. Понятно почему.
Никто получается не использовал копроративность на Первасиве?
P S Жаль, что новшества приведут к неминуемой потере клиентов. Видимо у Галактике слишком много клиетов, что она их так просто вышвыривает.
Хорошая новость о тестировании филиальности на рассматриемой базе - будем ждать. Надеемся также, что и ценовая политика на филиальность будет разумная (сейчас при 13 небольших фирмах в корпорации цена на MS SQL переваливает 10000 $), т.к. если до этого никто вообще не платил за лицензии по филиальности ничего на Первасиве, то предложить ему такие суммы просто за лицензии, да + сопровождение будет плохой идеей
К сожалению, нет решения для кода, который был написал на ВИПе и который смотрел все БД. Там интерфейсы. Да и отчеты сводные получается нужно переписывать полностью, если использовать FASTREPORT и доступом к разным базам. Кто это все захочет оплачивать - непонятно. Новых приладных свойств это не добавит, а скорее сократит - как объяснить руководству предприятий ЗА ЧТО ОНИ БУДУТ ПЛАТИТЬ?
Чем плоха филиальность - все фирмы в обной БД. На это некоторые предприятия не пойдут никогда. Понятно почему.
Никто получается не использовал копроративность на Первасиве?
P S Жаль, что новшества приведут к неминуемой потере клиентов. Видимо у Галактике слишком много клиетов, что она их так просто вышвыривает.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
На Первасиве филиальности не было. Ее технически не возможно было там сделать.
Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и работать будет однозначно быстрее.
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и работать будет однозначно быстрее.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...LaaLaa писал(а):Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.
Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Может быть техподожерка имеет опыт в этом. Попробуйте вопрос там задать.spark писал(а):"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
m0p3e писал(а):ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и рабо втать будет однозначно быстрее.
Вы видимо на MS SQL, т.к. филиальности на рассматриваемой БД нет. На Ms Sql наши клиенты не хотят, а на PostgreSQL ее нет в Прайсе даже. Вот появилась информация, что будет вроде. До осени будет ждать. Для одно клиента это нормально, если не считать, что придется переписать код, который нарабатывался лет 5-6. Большой вопрос финансовый тут.
Для другого клиента одна БД для нескольких фирм не подходит. Тоже много кода.
Вопрос в принципе в чем. Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности. Если наберем группу, то возможно реализация в Галактике такого функционала.
-
- Местный житель
- Сообщения: 645
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: г.Королев МО ООО "Эффективная Комплексная Автоматизация- СОФТ"
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Описанный механизм был поставлен внедренцами из ТОП-Софт в ЮКОСе в конце 90-х. Именно в ЮКОСе я впервые и уведел его, когда работал с этой компанией позже по договору. У нас все клиенты - корпорации из большого число ЮЛ и еще филиалов с общими таблицами. Этот функционал отлично подходил для реализации ведения деятельности в рамках корпорации. Сначало сделали для одной фирмы, а когда показывали других, то другие брали с удовольствием. И так было более 10 лет.LaaLaa писал(а):На Первасиве филиальности не было. Ее технически не возможно было там сделать.
Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
Понятно, что Первасив файловая система, а тут БД. И может механизм и устаревший, но другого нет.
Филиальности, как сами Вы знаете на платформе нет. Что делать клиентам? Они не видят этих функций (не знаю устаревгие они или нет)- они видят прикладные решения, которые хотят увидеть и платят деньги десятки лет, а каждый год ездят на конференции и так говорят, что у них Галактика работает хорошо.
Теперь давайте скажем, что функции устарели...клиентам скажем, что Галактика в том виде, как Вы ее эксплуатировали больше не будет работать, а за то, как мы вам сделает года через три Вы будете платить в два раза больше. Может пойти по пути создания аналогичного современного механизма доступа к различным БД по аналогии с устаревшими? Эмуляция этих функций?
-
- Местный житель
- Сообщения: 2896
- Зарегистрирован: 24 июн 2005, 12:12
- Откуда: Иркутская область
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
здесь поддержу ecasoft
Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
-
- Постоянный гость
- Сообщения: 76
- Зарегистрирован: 07 июн 2007, 12:32
- Откуда: Витебск
- Контактная информация:
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Я тоже пользовался функцией opentablebypath , на двух успешных и работающих проектах. Если не будет ее эмуляции, то придется ее делать самому. Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива. Этот механизм у меня в четырех организациях внедрен.
Если по opentablebyPath есть номер пир, сообщите его, чтоб мы Минскую поддержку тоже пошевелили. Хочется к концу года перейти на 9.1. Но и переделывать все самим не хотелось бы.
Если по opentablebyPath есть номер пир, сообщите его, чтоб мы Минскую поддержку тоже пошевелили. Хочется к концу года перейти на 9.1. Но и переделывать все самим не хотелось бы.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Ну в принципе функционал Enterprise, который работает на оракле и сиквеле, по сути таже самая shemealias.Dmitry_Sol писал(а): Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива.
Re: 9.1 PostgreSQL как решить проблему ведения множества юр
Да уже минимум лет 10 никакой борьбы нет. На 1000 пользователей с 1С один с "Галактикой", где здесь борьба-то?Алексей писал(а):Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
Мне тоже приходилось OpenTableByPath когда-то использовать. Клиент имел энное количество юр. лиц, все вели учет по единым правилам, но каждое - в своей БД, и было написано несколько специфических отчетов, консолидирующих данные по всем ЮЛ.ecasoft писал(а):Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности.
Может, вам легче и быстрее будет собрать группу противников отказа от Первазива?ecasoft писал(а):Если наберем группу, то возможно реализация в Галактике такого функционала.
А хотите еще один вариант, получше? Вы с "Галактикой" давно работаете, ВИП у вас наверняка куплен и пара грамотных программистов найдется. Сейчас заключать договоры на АО и обновляться пользователи вынуждены по одной-единственной причине - из-за изменений законодательства. "Непрерывно наращиваемый функционал", о котором так любят говорить разработчики, 99,9% пользователей нахрен не нужен, у них уже всё устоялось, а с каждым обновлением только новые глюки добавляются. Откажитесь от обновлений из корпорации и поправляйте "Галактику" сами, только лишь в объеме, минимально необходимом для поддержки изменений в законодательстве. Сначала на своих клиентах это дело отладите, а потом кинете клич по всей Руси великой, стоимость установите вместо 3% в месяц, допустим, 1%, и 8 из 10 нынешних пользователей "Галактики" с радостью уйдут из корпорации и от ее партнеров к вам.