Bankir.Ru
3 декабря, суббота 20:37

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

Ретайл РБС фирмы ЦФТ

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Ретайл РБС фирмы ЦФТ

    Хотелось бы послушать мнения тех, кто внедрял Ретайл РБС фирмы ЦФТ о качестве этого ПО, проблемах которые возникли при его внедрении и т.д.

  • #2
    В нашем Банке используется новая версия RBS 3.12. Эта версия обеспечивает поддержку работы нескольких филиалов банка в едином информационно-финансовом пространстве. В системе предусмотрено ведение отдельного баланса для каждого филиала с возможностью получения консолидированных данных.

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

    Позволяет производить операции по картсчетам внешних платежных систем, приему коммунальных платежей в банкоматах и терминалах "Золотой Короны".

    Мы очень довольны данной программой. А вы?
    Последний раз редактировалось Gevorkova; 18.02.2003, 12:28.

    Комментарий


    • #3
      Есть вопросы к Gevorkova. В каждом филиале установлен отдельный Unit? Т.е. звено "Головной банк" - "филиал" работает в off-line режиме с периодической репликацией? В звене "филиал" -"доп.офис" - on-line"?

      Комментарий


      • #4
        Risk - то, что пошет Gevorkova - чьи то глупые шутки ...[/U]

        Комментарий


        • #5
          Gevorkova с контролем лимитов открытой валютной позиции В ритэйловом модуле ??? "Крутизна неимоверная"...

          GevorkovM Не огорчайтесь! за исключением ОВП всё остальное похоже на правду. "Золотая Корона" у Вас уже есть?
          А Ваша однофамилица только сегодня и зарегистрировалась...
          Gevorkova 18-02-2003 11:45 E-Mail B-Mail Профиль Поиск Контакт-лист Редактировать
          Форумянин
          Зарегистрирован: 18-02-2003

          Похоже, этот постинг и останется единственным

          Risk !!! Правильные вопросики!!!
          Да пребудет с Тобою Великая Сила! ©

          Комментарий


          • #6
            Маркелову - откуда такой оптимизм? Мы при внедрении столкнулись с рядом проблем, таких как послеоперационная касса, невозможности конвертировать при отнесении на расходы, раздрай в отчетности и т.д.

            Комментарий


            • #7
              GevorkovM Проблемы при внедрении есть и БУДУТ ВСЕГДА!!!
              Не хочу углубляться, но многое зависит от того, что у Вас стоит в окружении РБС...
              Мне, например, известны банки, которые получали доп.модуль РБС в качестве апгрейда "Золотой Короны" и переходили на него достаточно легко при "чужом" опердне...
              послеоперационная касса, невозможности конвертировать при отнесении на расходы, раздрай в отчетности Решение КАЖДОГО этого вопроса мне неизвестно, но т.к. они есть и многообразны, то дело не только в РБС.
              Так раздрай в отчетности начинается, как правило, если не внесены все категории и признаки в соответствующие справочники, или необходимые поля не заполнены в базе клиентов / счетов. Категории и признаки не всегда можно сконвертировать из предыдущего формата Вашей АБС. Приходится вносить ручками...
              Да пребудет с Тобою Великая Сила! ©

              Комментарий


              • #8
                Специально для Risk, раз уж ИБСОшники не отвечают...
                Не знаю, как в Банке у Gevorkova, но в теории должно быть примерно так:

                Банк и филиал, также, как и банк - отделение работают в on-line, используя общие базы данных в режиме реального времени (в филиале могут быть свои отделения). Разумеется, что в филиалах и отделениях устанавливаются АРМы. Разграничение функций и остального ведётся на уровне системных установок, прав и доступов...

                А уж сколько у Вас филиалов и отделений - это определяется Вашей оргструктурой и регламентируется програмнной лицензией.
                Удачи Всем!!!
                Да пребудет с Тобою Великая Сила! ©

                Комментарий


                • #9
                  К_Маркелов А как решаются проблемы разных часовых поясов филиалов?

                  Комментарий


                  • #10
                    GevorkovM проблемы разных часовых поясов филиалов?
                    Какие проблемы??? Работайте в режиме "seven X twenty four" и проблем не будет...

                    ... опять же "в теории" ...
                    Конечно же, при он-лайновой работе должны быть выделены регламентные часы, в которые НЕ проводится полный спектр межфилиальных операций. В случае России эти часы целесообразно делать в момент закрытия операционного дня ПО МОСКОВСКОМУ ВРЕМЕНИ и после разноски первых рейсов по счетам при наличии "технологии незавершенных расчётов" или после разноски всех рейсов при отсутствии таковой технологии.
                    В этот момент в других городах России - или ночь, или поздний вечер, т.е. клиентских операций со счетами - минимум.
                    Если же операционный день закрывается только утром, ... тогда он-лайн ... Москва-то ведь у Вас работает, а почему регионы не смогут???
                    Да пребудет с Тобою Великая Сила! ©

                    Комментарий


                    • #11
                      Давайте, несколько продолжим тему.
                      Итак, голова - в Москве, филиал - в Находке. Пусть разница в часовых поясах составляет 7 (семь) часов.
                      1. Закрываемся (сидя в Находке) концом опердня. Кассовые операции в течение дня шли: по физикам в RBS, по юрикам - в основной АБС. Если в он-лайне, то из г. Москва (предполагаем здесь и далее, что в филиалах нет Units) для закрытия дня в г. Находку должен быть оправлен файл с данными по сводным счетам по операциям с физиками в филиале, чтобы закрыть день в основной АБС. В Находке - около 19:00, в Москве - 12:00. Полет нормальный.
                      2. То же самое, но закрываем день утром в Находке 9:00, в Москве - 2:00 (чувствуете разницу - это ж сменный режим!).
                      3. Переместимся в Западную Сибирь (далее - ЗС). Пусть разница в часовых поясах составляет 4 (четыре) часа. Закрываемся вечером в ЗС 19:00, в Москве, 15:00 Отлично! Закрытие утром - опять "вторая смена".
                      Представьте теперь, что филиалы растянуты "от Москвы до самых до окраин..." - это предполагает наличие в голове подразделения, закрывающего ритейловые опердни в филиалах и при этом, репликация баз по основной АБС проходит ночью (по Москве). Т.е. по московским ночам каналы загружены репликацией баз по основной АБС + в Находке начался день и пошли физики (а мы, как бы в он-лайне по ритейлу!). Можно, конечно и продолжить, но плата за относительно недорогую, продвинутую и он-лайновую RBS - это требования к каналам связи! К сожалению, мне не известны опыты внедрения RBS в работу по-настоящему многофилиальных банков: какие там предлагались решения. Из списка банков, приведенного на сайте ЦФТ следует, что в основном, внедрение шло в небольшие (по филиальной сети) региональные банки. Есть ли мнения: насколько дорого организовывать он-лайн? Цена вопроса для офф-лайнового решения по-видимому такова: (N+1)* стоимость Unit, где, N - число филиалов.

                      Комментарий


                      • #12
                        Risk - а вот такой вопрос. У нас будет многофилиальная база, сервер один. Получается что все проводки идут с валютированием Московского времени. А это приведет к тому, что, хотя бы теоретически, проводки, которые должны пройти в завтрашнем календарном дне пройдут в сегодняшнем дне. Пример - в 5-00 утра в Находке(пусть маразматично, но у нас такая ситуация возможна из-за особенности работы с вечерней кассой) проводят проводку - у нее дата валютирования московская, поэтому пропишется она со временем 22-00. А это приведет к тому, что проценты на сумму начнут считаться на день раньше.
                        Меня очень пугает "московская" дата валютирования ...

                        Комментарий


                        • #13
                          GevorkovM что проценты на сумму начнут считаться на день раньше. Здесь не знаю "правильного" ответа.
                          Да пребудет с Тобою Великая Сила! ©

                          Комментарий


                          • #14
                            Ответ такой. Для RBS придется дописывать своеобразные фильтры по времени и номеру филиала, для формирования ритейлового дня в конкретном филиале. Т.е. проводки, появившиеся на сервере Головного банка сегодня, могут оказаться в "завтрашнем операционном ритейловом" дне филиала. И сборка всего опердня банка в основной АБС будет проводиться на основе закрытых опердней в филиалах. В чистом виде, просто так, закрыть ритейловый опердень всего банка на некоторый момент (без фильтров) - можно, но что это будет за результат?
                            Мне неизвестно, предлагает ли разработчик RBS промышленные решения для многофилиальных банков в режиме он-лайн с учетом сдвигов часовых поясов . Наверное нет, т.к. подавляющее большинство объявленных внедрений концентрировалось в одном часовом поясе.
                            Изготовление фильтров - это уже не вопрос "настроек" RBS, за это надо платить. А с учетом проблем обеспечения он-лайнового режима возникают вопросы цены и времени доработок.

                            Комментарий


                            • #15
                              Risk - согласен, но проблема еще и в том, что начисление %% происходит по календарной дате валютирования. У нас Ретайловский опердень закрывается в 16-00, мы могли бы колотить проводки после 16-00 в следующий опердень, и они бы правильно встали бы в выгрузки и отчеты, но проценты по ним будут считаться по дате валютирования
                              Пример: Опер.День 01.02.2003 закрыт в 16-00. Создали проводку в 17-00. Она попадет в опер.день 02.02.2003, но при начислении процентов программа видит эту сумму как-будто проводка находится в опер.дне 01.02.2003.
                              Не налетали на эту проблему?

                              Комментарий


                              • #16
                                К счастью нет, т.к. вопрос RBS находится в стадии обсуждения. По-существу, система фильтров должна работать непрерывно и проводку, которая по Находке осуществляется в 5:00 02.02.03, а по Москве в 22:00 01.02.03. надо сразу конвертировать в опердень Находки (ведется то он в Москве для он-лайна) с временем и датой "по Находке". Т.е. на сервере должно быть два ядра : одно (первое) с проводками и датами по Москве ("помойка"), другое (второе) - с локальными временами и датами для каждого филиала и начисление %% должно осуществляться по данным второго ядра. Описания такой конфигурации от ЦФТ я не встречал.
                                Странно вообще, здесь идет обсуждение RBS ее пользователями и потенциальными пользователями, а совсем не слышно мнение разработчиков. А вдруг мы все не так поняли и все давно решено? Или нет?
                                Иногда, отсутствие ответа - очень весомый ответ.

                                Комментарий


                                • #17
                                  Мы уже запустили РБС в Москвском ф-ле. Море ощущений(но не на форуме)
                                  Risk - а ты(Вы) из какого Банка?

                                  Комментарий


                                  • #18
                                    2 GevorkovM. Все обсуждается, но на эту тему - лучше по мылу.

                                    Комментарий


                                    • #19
                                      Проблемы с разницей во времени не только в RBS, но и в IBSО (И наверное в других on-line системах)

                                      Есть во Владивостоке банк "Дальневосточный", у них филиал в С-Пб (разница 7 часов). Борются они с этим. Судя по всему пока безуспешно.

                                      Комментарий


                                      • #20
                                        Как утопический вариант решения проблемы - это отмена статуса обособленного подразделения у Филиалов, с отнесением оных к внутренним подразделениям Банка Как следствие отсутствие множества балансов, лимитов и т.д. И будут все работать как допики, и ни о чем не тужить.
                                        Здесь все упирается в ЦБ.

                                        Теперь о грустном. Наличие нескольких ядер (Units), с ежедневной репликацией данных, ИМХО проблемы не решает в случае, если число Units будем меньше числа филиалов находящихся в разных часовых поясах.

                                        Давайте разберемся, зачем и для чего нам нужен on-line. ИМХО, единое информационное поле нужно для вынесения мотивированного суждения и т.д. и т.п. о клиенте, т.е. фактически для уменьшения кредитного и операционного рисков. Значит, все что от него требуется - это предоставление информации о клиенте в момент его обращения в банк. ВСЕ
                                        Так, что может было бы целесообразно разделить все на два потока. Первый - информация о клиенте (on-line), второй - аналитика (бух.учет - off-line) отдельно для каждого Филиала.
                                        Далее репликация аналитики, для привязки остатков по счетам к клиенту.

                                        Комментарий


                                        • #21
                                          Согласен. Как ни странно, он-лайн нужен для того, чтобы не покупать несколько UNITS. Уж очень нравится руководству цена. Все остальное типа: клиент в любом фодразделении фронт-офиса может управлять своими счетами - от лукавого. Для этого пластиковые карты, к примеру, и были созданы. Дальнешая логика развития процесса понимания масштаба бедствия - см. выше.
                                          Оф-лайн - это уже несколько UNITS.

                                          Комментарий


                                          • #22
                                            Это все понятно. К сожалению у ЦФТ данные о клиенте и аналитика в одном продаваемом пакете. От сюда и возникает необходимость нескольких юнитов при моем варианте.
                                            Хотя, опять же ИМХО, весь учет можно вести в действующей АБС, а RBS использовать на уровне доступа к информации о клиенте. Другой вопрос разумно ли тогда вообще RBS покупать

                                            Комментарий


                                            • #23
                                              Такой вот еще вопрос (наверное, 8 марта навеяло).
                                              Допустим, что в банке в качестве корневой, функционирует АБС, отличная от продукции ЦФТ. Допустим, внедряем RBS от ЦФТ. И здесь, как немой укор, возникает фигура кассового работника. Представьте себе допик с одним кассовым окном. Заходят в этот допик и юрики и физики. Кассовые операции по юрикам ведутся в основной АБС. А с физиками? Надо бы в RBS. А как же кассир? Это что же, надо выгружать одну "кассу" (в основной АБС) и загружать ЦФТ-ную, если после юрика к окошку подойдет физик? Допустим, сказано: "так надо".
                                              Попробуем теперь завершить день в кассе: часть кассовых документов - в RBS (по операциям с физиками), часть (по юрикам - в основной АБС). Ежели в филиале имеется собственный юнит - закрыться можно через сводые счета. Как быть с кассовыми документами (нумерация, к примеру) пока не очень ясно. Ежели RBS только в головном банке - это вообще, песня.
                                              По-видимому, и добавление второго кассового окна не изменит принципиально ситуацию - касса то в филиале все равно одна.
                                              Попытался ответить сам себе на вопрос - имеет ли смысл внедрение RBS при наличии основной АБС? К сожалению, не нашел оснований для положительного ответа. Наверное, все эти "несостыковки" - плата за несистемное, мозаичное решение.
                                              Уважаемые коллеги! Поделитесь, пожалуйста, (если имеете) мнением о практике учета кассовых операций обновременно в двух системах. Допускаю, что такого сценария и не существует.
                                              С уважением. Милым дамам - самые сердечные поздравления!

                                              Комментарий


                                              • #24
                                                Risk
                                                Наверное, все эти "несостыковки" - плата за несистемное, мозаичное решение.
                                                Это для всех "неродных" ретейлов. Хотя даже для "родных" АБС и Ретейла встречаются подобные нестыковки.
                                                Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                                Комментарий


                                                • #25
                                                  Вот как у нас решаются эти проблемы: У кассира стоит АРМ "Касса" РБС и обменный пункт(Документы в основном опердне кассир не подтверждает, он просто выдает деньги). У каждого кассира в РБС открыт свой лицевой счет кассы в каждой валюте. По этому счету потом формируется кассовый журнал. При выгрузке в основной опердень кассовый счет кассира подменяется на основной счет кассы. Кассовые журналы формируются отдельно по юрикам, физикам и еще реестр обменника. В РБС мы не контролируем остаток по кассе, проверяя только обороты. Да и вообще, мы пошли по тому пути, что в РБС проверяем остатки только по тем счетам, которые полностью находятся внутри РБС(423,47411,47502). Все остальные сверяем только оборотами.

                                                  Комментарий


                                                  • #26
                                                    Risk

                                                    Допустим, что в банке в качестве корневой, функционирует АБС, отличная от продукции ЦФТ. Допустим, внедряем RBS от ЦФТ. И здесь, как немой укор, возникает фигура кассового работника.

                                                    Укор возникнет и при наличии АБС от ЦФТ. Причина - в ЦФТ разные продукты делаются разными командами разработчиков.

                                                    Представьте себе допик с одним кассовым окном. Заходят в этот допик и юрики и физики. Кассовые операции по юрикам ведутся в основной АБС. А с физиками? Надо бы в RBS. А как же кассир? Это что же, надо выгружать одну "кассу" (в основной АБС) и загружать ЦФТ-ную, если после юрика к окошку подойдет физик?

                                                    Можно утешить себя, что для обслуживания этих типов клиентов используется специализированное ПО, пусть даже и разнородное.

                                                    Попытался ответить сам себе на вопрос - имеет ли смысл внедрение RBS при наличии основной АБС? К сожалению, не нашел оснований для положительного ответа. Наверное, все эти "несостыковки" - плата за несистемное, мозаичное решение.

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

                                                    Поделитесь, пожалуйста, (если имеете) мнением о практике учета кассовых операций обновременно в двух системах. Допускаю, что такого сценария и не существует.

                                                    Вынужден огорчить , существует.

                                                    Для каждого типа услуги (в Вашем случае - РКО юриков и ритейл) заводится некоторый идентификатор - номер кассы (понятно, что кассовый счёт - один). Формально это оправданно, т.к. документы по юр. лицам и физ.лицам хранятся отдельно и имеют разные сроки хранения.

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

                                                    Комментарий


                                                    • #27
                                                      Спасибо!
                                                      Независимо от типа "самостийной" ритейловой системы - это, пожалуй, самое рациональное решение.
                                                      Удачи!

                                                      Комментарий


                                                      • #28
                                                        GevorkovM

                                                        Михаил, добрый день !

                                                        Имел честь общаться с Вами по e-mail летом прошлого года (tv_junior@km.ru).
                                                        Как сейчас обстоят дела в Вашем Банке по внедрению продуктов ЦФТ ?

                                                        Комментарий


                                                        • #29
                                                          Поставили РБС в части депозитов. Сейчас готовимся к пластику. ..

                                                          Комментарий


                                                          • #30
                                                            GevorkovM
                                                            Если не секрет, с какими карточками работаете?

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X