18 декабря, понедельник 10:11
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Унификация форматов - оно нам надо?

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

  • Унификация форматов - оно нам надо?

    Вот, блин, зачем-то прочитал я две статьи в “Банки и технологии” №6 2003г. про унификацию форматов… Как говорится, чёрт дёрнул… Из слов участников “круглого стола” становится ясно, что проделана титаническая работа по освоению XML и созданию на его основе УФ.
    Может, кто-нибудь (Валерий, ты где) прояснит следующие вопросы, касательно именно рублёвых платежей:
    1. Почему УФ настолько упорно связывается с возможностью конвертации в SWIFT? Насколько я понял, тут речь не идёт чисто о валютных платежах… Зачем в таком случае Банку России при построении своей национальной платёжной системы лить воду на “мельницу буржуазии”?
    2. Ну, интерес Microsoft со своим BizTalk понятен…
    3. Зачем для чисто рублёвых платежей изобретать совершенно новый формат? То, что сейчас есть 10 региональных форматов и 10 разных региональных комплексов обработки платежей – конечно, плохо. И ведь никто Банку России не мешал ещё лет 5 назад сделать единый УФ для всех РЦИ на основе макета R. И точно так же ведь никто им не мешает сейчас использовать единый расчётный комплекс, уже готовый, достаточно хорошо уже оттестированный в МЦИ, для всех остальных РЦИ? Или мешает?
    4. Читал эти статьи и постоянно ловил себя на мысли – да, очень правильные слова, и УФ обязательно нужны, но если при разговоре о рублёвой платежной системе всем авторам вместо “УФ” вложить в уста “R-макет” – ничего не изменится! Остальные слова так и останутся правильными! Т.е. УФ на основе именно XML – совсем не панацея, и есть более простое решение для конкретной локальной задачи унификации.
    5. Итак, почему бы не взять за стандарт R-макет (допустим, даже слегка модифицированный, если уж есть такие потребности)? При этом вообще не придётся затрагивать уже функционирующие программные комплексы МЦИ, банков Москвы и области (а это, наверное, больше 70% всей банковской системы страны). Не придётся напрягать разработчиков разных АБС (хотя тут как раз понятен их интерес – чем больше нововведений, тем толще ручеёк и ощутимее звон монет ). Не придётся напрягать разработчиков банк-клиентов (т.к. уже многие используют форматы 1С и R-макет в качестве стандартов обмена).
    6. Понятно, что широкомасштабные эксперименты выгодны с разных точек зрения… Чем масштабнее задача – тем больше бонусы (вспомним хотя бы, с каким размахом решали проблему 2000 – не один коттедж, наверное, построился в Подмосковье). Но не стоит ли начать унификацию программных комплексов и освоение новых форматов с менее глобальных задач? Для начала – хотя бы выбрать из balance.exe и obved.exe что-то одно? Или делать постепенно на основе того же XML форматы обмена для многочисленных программ отчётности, которые плодит ЦБ?
    7. Я так понял, что на УФ хотят переходить уже в этом году. Господи, зачем это всё нам, несчастным банковским автоматчикам?
    44
    нужна на основе XML
    79.55%
    35
    нужна на основе макета R
    11.36%
    5
    не нужна
    2.27%
    1
    мне по барабану
    6.82%
    3

    Срок опроса истёк.


  • #2
    В принципе хоть XML хоть YAML хоть R макет - одна петрушка. НО рассмотрим два примера:
    Мы сделали формат для платежки:
    plat kredit='404081000012122' summa='2032.15'>
    Оплата за трафик включая НДС18%
    /plat>
    И вдруг ЦБ вводит скажем налоговые реквизиты, мы переделываем формат:
    (добавили ключ налог)
    plat kredit='404081000012122' summa='2032.15' nalog='123456654321'>
    Оплата за трафик включая НДС18%
    /plat>
    Итак при работе через DOM и (или) SAX все старое программное обеспечение продолжает работать.
    Теперь с R макетом. Колонку добавят не в конец строки - это как пить дать.
    Следовательно все что было после колонки переделать.
    Если этого мало могу привести еще несколько аргументов:
    1) для XML возможна верификация по DTD и ты уже не проверяешь а в теге сумма только числа?
    2)Для XML есть XSLT с помошью которого гораздо быстрее сделать отчет чем в Clipper, FoxPro или даже Perl Python Ruby.
    Вобщем если они не испортят идею всякими Бизтоками я двумя руками за.
    Конечно они могут и такое сделать
    plat R="23684230423-4923498239473497.....ОПЛАТА НДС 18%">

    Комментарий


    • #3
      В принципе хоть XML хоть YAML хоть R макет - одна петрушка. НО рассмотрим два примера:
      Мы сделали формат для платежки:
      plat kredit='404081000012122' summa='2032.15'>
      Оплата за трафик включая НДС18%
      /plat>
      И вдруг ЦБ вводит скажем налоговые реквизиты, мы переделываем формат:
      (добавили ключ налог)
      plat kredit='404081000012122' summa='2032.15' nalog='123456654321'>
      Оплата за трафик включая НДС18%
      /plat>
      Итак при работе через DOM и (или) SAX все старое программное обеспечение продолжает работать.
      Теперь с R макетом. Колонку добавят не в конец строки - это как пить дать.
      Следовательно все что было после колонки переделать.
      Если этого мало могу привести еще несколько аргументов:
      1) для XML возможна верификация по DTD и ты уже не проверяешь а в теге сумма только числа?
      2)Для XML есть XSLT с помошью которого гораздо быстрее сделать отчет чем в Clipper, FoxPro или даже Perl Python Ruby.
      Вобщем если они не испортят идею всякими Бизтоками я двумя руками за.
      Конечно они могут и такое сделать
      plat R="23684230423-4923498239473497.....ОПЛАТА НДС 18%">

      Комментарий


      • #4
        dd

        Дмитрий, привет!
        Постараюсь по-мере сил прояснить некоторые моменты по унифицированным форматам Банка России.Сразу оговорюсь, это мое частное мнение, а не официальная позиция ЦБ, АРБ или НП.

        Почему УФ настолько упорно связывается с возможностью конвертации в SWIFT?

        Здесь есть несколько причин. Одна из наиболее очевидных - крупные банки вложили уже много средств в услуги СВИФТ. Оборудование, траффик, обучение, поддержка и т.д. У них сушествует достаточно большой процент платежей через расчетную систему СВИФТ. Поэтому возможность конвертации из УФ в СВИФТ и обратно - это учет интересов крупных российских банков, а не "иностранной буржуазии". Есть и другие причины, но лучше говорить не о них, а о том, что наконец-то удалось с форматами найти компромисс, который устроил всех.

        И ведь никто Банку России не мешал ещё лет 5 назад сделать единый УФ для всех РЦИ на основе макета R.

        Если я не ошибаюсь, то как раз 4 года назад и начались работы по созданию единого формата. Тогда можно было взять за основу и R-макет, без учета тенденций развития информационных технологий и накопленного мирового опыта, сделать доморощенный унифицированный формат, который бы морально устарел сразу после своего внедрения. Так что ориентация ЦБ на XML - это стратегически верное решение. Подтверждение тому - работа СВИФТ, который тоже со своими форматами активно движется в сторону XML.

        УФ на основе именно XML – совсем не панацея, и есть более простое решение для конкретной локальной задачи унификации.
        Совершенно верно, на первый взгляд - это более простое решение. Но только на первый взгляд. Сделать УФ - это решить 10% проблем, а внедрить его по всем регионам - это и есть подводная часть айсберга, которая сразу не видна. Мне кажется, что XML-формат, который явно имеет преимущества перед всеми другими (это и Dem_aka_Deep верно подметил) стал еще и консолидирущей силой, объединившей регионы в вопросе выбора - какой именно формат лучше внедрять. Вы попробуйте найти аргументы для ТУ (уральского, тульского, тверского и других) что R-макет лучше чем форматы, которые они сейчас используют

        Не придётся напрягать разработчиков банк-клиентов
        Я думаю, что со временем действительно не придется. Некоммерческое Партнерство "Стандарты..." тоже приняло унифицированный XML-формат для этой области, который транспарентен по отношению к формату ЦБ и поддержан компаниями 1С, ЦФТ, Диасофт, РФК и многими другими.

        Понятно, что широкомасштабные эксперименты выгодны с разных точек зрения… Чем масштабнее задача – тем больше бонусы
        Вот тут я не согласен. Все эксперименты проводились при большом участии банков, компаний-разработчиков АБС, других организаций - все за счет их энтузиазма. Это даже не бонусы, а прямые затраты. Но если бы люди не пошли на это ради перспективы, то воз и ныне был бы там.


        Но не стоит ли начать унификацию программных комплексов и освоение новых форматов с менее глобальных задач? Для начала – хотя бы выбрать из balance.exe и obved.exe что-то одно?

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

        Или делать постепенно на основе того же XML форматы обмена для многочисленных программ отчётности, которые плодит ЦБ?
        И с этим я я совершенно согласен. Могу заверить, что и в этом направлении идет работа достаточно быстрыми темпами. Но это, как говорится, "в следующей серии"

        Я так понял, что на УФ хотят переходить уже в этом году. Господи, зачем это всё нам, несчастным банковским автоматчикам?

        Ну когда-то же это все-же придется сделать? Один раз потерпеть и снять наконец эту головную боль. Тем более, что и терпеть особенно не придется. Приказ ЦБ еще не обнародован, а большинство разработчиков АБС эти форматы в свои системы уже внедрили


        Dem_aka_Deep

        Вобщем если они не испортят идею всякими Бизтоками я двумя руками за.
        Спасибо за поддержку! Идея испорчена не будет. Все делается очень прагматично.

        Комментарий


        • #5
          Валерий в принципе, согласен... действительно, формат XML более удобен для модификации... с другой стороны - постоянно вспоминаю золотое правило: "работает - не трогай"... так зачем вообще затрагивать 70% работающей системы РУБЛЁВЫХ расчётов? а в то, что крупные банки в работе по рублям предпочитают использовать свифт - как-то не очень верится, если честно... живо представляю себе, как банк отправляет налоговые платёжки на 10-100-300 рублей по свифту... они что, деньги считать не умеют?

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

          Dem_aka_Deep Колонку добавят не в конец строки - это как пить дать.
          ну, при таком подходе нашего ЦБ к делу вообще любую идею можно испоганить... и тут прогрессивные технологии будут отдыхать в любом случае... возьми, глянь для примера новый (уже не совсем) план счетов - счет резервов сделали, к примеру, с номером 46108... таким образом, при необходимости добавления ещё трёх счетов на балансовом 461 - 46108,46109,46110 счёт резерва сделают 46111 (я просто уверен в этом ), хотя любой нормальный человек сделал бы резерв на 46199, и надолго забыл бы о существенных переменах в НПС...

          Комментарий


          • #6
            dd
            зачем вообще затрагивать 70% работающей системы РУБЛЁВЫХ расчётов?
            70% - это как мерить? По объему денег? Тогда верно. Но если считать количество платежей, то меньше. А если считать количество клиентов МЦИ по сравнению с клиентами БР обслуживаемыми в других ТУ, то эта цифра становится совсем маленькой.

            крупные банки в работе по рублям предпочитают использовать свифт - как-то не очень верится
            Понятное дело, налоговые платежи они через СВИФТ не отправляют. Но есть крупные рублевые суммы (особенно на межбанке) которые удобнее отправлять через СВИФТ.

            Комментарий


            • #7
              XML штука модная !!!

              Но что-то мне не вериться, что ЦБ будет блюсти стандарт. Скинут кастрированную версию отдаленно напиминающую XML ...

              P.S. Имеется "замечательный" пример использования XML - программа SMCLForms.exe "электронная анкета ФКЦБ". Размеры создаваемых ею файлов поражают воображение. А удобство редактирования ... :-(( плакать хочется.

              Комментарий


              • #8
                RedPank
                Но что-то мне не вериться, что ЦБ будет блюсти стандарт. Скинут кастрированную версию отдаленно напиминающую XML ...

                Ничего подобного. Можете узнать в компаниях БИС, Диасофт и Програмбанк - они встраивали этот формат в свои АБС. В нем XML Schema - в полный рост и все очень профессионально сделано.

                Комментарий


                • #9
                  налоговые платежи они через СВИФТ не отправляют. Но есть крупные рублевые суммы (особенно на межбанке) которые удобнее отправлять через СВИФТ.

                  На межбанке УДОБНЕЕ тоже через МЦИ, РКЦ и т.д., т.е. через расчетную сеть ЦБ РФ, как с точки зрения внутрибанковской работы, так и управления ликвидностью, снижения финансовых рисков. SWIFT используется при расчетах через корр.счета в коммерческих банках, которые используются в первую очередь из-за, скажем условно, несовершенства системы расчетов ЦБ в той ее части, которая касается межрегиональных расчетов. Была бы страна поменьше, без этих часовых поясов, или ЦБ организовал бы как-нибудь круглосуточные расчеты по всей территории РФ on-line - очень быстро бы объем расчетов через корр.счета упал... Посмотрите сами, в каких случаях используется SWIFT для рублевых платежей, в том числе и для межбанка... Это же сплошь расчеты московских банков с региональными.
                  Форматы тут ни при чем и суммы платежей тоже...

                  Комментарий


                  • #10
                    hamster
                    На межбанке УДОБНЕЕ тоже через МЦИ, РКЦ и т.д., т.е. через расчетную сеть ЦБ РФ,

                    Здесь я с Вами согласен. Раньше приводил этот пример не от себя, а только озвучил то, что говорили некоторые банки. Почему у них была такая мотивация - бог ведает

                    Комментарий


                    • #11
                      Наиболее, что мне понравилось, из всех форматов, которые я видел - это формат обмена Сбербанка по системе Эскорд. Одна платежка - одна строка. Поля разделены символом "|" и имеют названия-тэги в виде двух символов + плюс длина поля + символ ":", например: "ta10:1234567890|...|ee:". При этом положение тэга в строке - произвольное, при отсутствии поля (или пустое значение) тэг можно не указывать, ширина полей - по ширине значения. Ввод новых полей легко решается путем ввода новых тэгов с описанием формата значения. Вывод полей из формата обмена - просто не указывать. Единственное, что избыточно - это указание длины поля. Т.е. формат минимален по объему файла, легко модифицируется, легко обрабатывается. А Xml - погоня за модой (в данном случае). Хотя при обмене на уровне отчетности - возможно оправдан.
                      Не все так плохо, как кажется с первого взгляда...

                      Комментарий


                      • #12
                        2Dem_aka_Deep : Итак при работе через DOM и (или) SAX все старое программное обеспечение продолжает работать.

                        В применении к макетам обмена между банком и МЦИ\РЦИ даннная фраза забавно звучит, Вы не находите ? К примеру, появилось новое поле "Дата чего-то там", отображаемое в платёжном поручении; а банк, вооружённый мощной технологией XML, гордо заявляет : "А нам ничего переделывать не надо - всё и так работает", так, что ли ? Мне лично непонятны упования на некие волшебные форматы, несущие свет миру - ведь написать парсер текстового файла намного проще, чем бизнес-логику обработки отпарсенных полей...

                        Валерий : БИС, Диасофт и Програмбанк - они встраивали этот формат в свои АБС

                        Со своей кочки зрения ("Новая Афина") могу сказать, что ни разработка, ни использование парсеров региональных макетов на основе XML не приносит ни разработчику, ни банку никаких особых удовольствий.

                        ЗЫ. А SWIFT тут причём, поясните мне глупому ?
                        WBR, Александр Турчин

                        Комментарий


                        • #13
                          hamster Посмотрите сами, в каких случаях используется SWIFT для рублевых платежей
                          Сбер, например, все расчеты с банками-корреспондентами проводит через коррсчета с ипользованием SWIFT/Telex. Мы тоже стараемся с клиентами Сбера расчитываться через коррсчет у них. Во-первых, платежи идут в on-line, а во-вторых, Сбер, в отличие от МЦИ, денег за это не берет.
                          В каждой программе есть по крайней мере одна ошибка

                          Комментарий


                          • #14
                            Александр_Турчин
                            могу сказать, что ни разработка, ни использование парсеров региональных макетов на основе XML не приносит ни разработчику, ни банку никаких особых удовольствий

                            А вот слова К.Поскакалова (БИС):
                            "Доработка унифицированного формата, применяемого в Пензе, потребовала от нас самых наименьших усилий по сравнению с другими форматами. Фактически, для XML-формата нам программировать ничего не пришлось, его настройка в наших системах и время тестирования было минимальными."

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

                            А SWIFT тут причём, поясните мне глупому ?
                            Да ни причем тут СВИФТ

                            Комментарий


                            • #15
                              Александр_Турчин Легче написать парсер? Это если документация на формат нормальная. Я писал конвертацию из (и в) регионального формата в Р макет. Сколько седых волос мне это принесло-ужас. То суммы в трех местах, то дебет в третьей колонке если это межрегиональный платеж, а если внутрирегиональный в четвертой....

                              Насчет избыточности XML могу сказать только то, что тут все зависит от ГОЛОВЫ создателя данной схемы. Всегда есть золотая середина. Можно тег назвать ROW, а можно eto_ochen_vashnaya_kolonka_kotoraya_nikome_ne_nushna
                              Вот берем мы этот Эскорт. И начинаем прикручивать к нему шифрацию, электронную подпись, писать маршрутизаторы документов.... (кстати можно кучу дармоедов прокормить). А тут w3c уже сделал все, и язык запросов уже есть и не надо извлекать букву Ё (а значит дармоеды сидят голодными).

                              "А нам ничего переделывать не надо - всё и так работает" Действительно если ЦБ вводит некий реквизит для учета автострахования, а наш банк этим не занимается, то все бросать и срочно переделывать тысячу и один парсер не надо. Можно и повременить.

                              Да XML не панацея, да в pretty print моде он избыточен. Но это лучшее что есть. Я знаю его недостатки (текстовый формат всегда медленнее в обработке бинарного), например при работе через DOM все дерево в памяти (есть хитрые реджимы когда не так), а значит 5 мегабайтный справочник БИК потребует 32 мегабайт (минимум) памяти. Но есть SAX, даже открою секрет есть SAX генератор....
                              А мода на XML прошла когда лопнули дот комы.

                              Комментарий


                              • #16
                                Big_Mike
                                Мы тоже стараемся с клиентами Сбера расчитываться через коррсчет у них. Во-первых, платежи идут в on-line, а во-вторых, Сбер, в отличие от МЦИ, денег за это не берет.

                                А что используете для связи? SWIFT или банк-клиент? К сожалению, не нашел с ходу Ваш банк в BIC Directory... Если банк-клиент - то экономия на трафике видна (внутрибанковские затраты - вопрос, но это в принципе решаемо, хотя далеко не везде решено), но если рассматривать SWIFT - а выше речь шла о нем - то себестоимость МТ103 для рублевых переводов около 5-6 руб, т.е. вполне сопоставима с расходами через МЦИ (а если платить пораньше, то через МЦИ и дешевле будет). Что же до on-line - а чем, по Вашему, МЦИ практически отличается от on-line? Обработка порциями? Ну и что? Деньги зачисляются на счета клиентов все равно в тот же день, а при желании банка - сразу после рейса; можно клиенту позволить платить из поступивших средств в тот же день...
                                Кроме того, Сбер есть Сбер - при его объемах можно проводить политику развития расчетов через корр.счета, аккумулируя ресурсы - но большинству-то это зачем? Если уж говорить о перспективах использования SWIFT для рублевых платежей, то речь нужно вести об использовании, условно говоря, "присоединенных файлов" в поле 77T MT103, т.е. пересылке информации произвольного формата...

                                Комментарий


                                • #17
                                  hamster А что используете для связи?
                                  Телекс
                                  Сбер есть Сбер - при его объемах можно проводить политику развития расчетов через корр.счета, аккумулируя ресурсы - но большинству-то это зачем?
                                  А куда деваться? Если Сбер аккумулирует - мы же должны эти деньги как-то использовать.
                                  Обработка порциями? Ну и что?
                                  Почти ежедневно создаются стрессовые ситуации. Особенно с межбанком. Если отправить деньги в 11-15, то корреспондент увидит их только в 15-00. До 18-00 рейс не успели отправить - извольте ждать 20-00. Приходится приноравливать работу банка к расписанию рейсов МЦИ. Не смертельно, конечно, но зачем?
                                  В каждой программе есть по крайней мере одна ошибка

                                  Комментарий


                                  • #18
                                    Big_Mike

                                    Сбер, например, все расчеты с банками-корреспондентами проводит через коррсчета с ипользованием SWIFT/Telex.

                                    Не совсем правдивая информация. Региональные подразделения СБ РФ используют собственные разработки на основе технологии "Клиент-Банк", т.е. удалённые рабочие места с ЭЦП.

                                    Комментарий


                                    • #19
                                      Валерий От себя замечу, что для многофилиальных банков и разработчиков, чьи системы работают в разных регионах поддержка одного формата, а не нескольких, в общем-то важна.
                                      вот оно! конечно!!!
                                      и для таких банков, кстати, будет удобнее перевести ЧАСТЬ филиалов на уже давно используемый в головной конторе формат, чем переводить ВСЕ филиалы, включая головную контору (это в предположении, что голова в Москве)...

                                      Мы же с XML работаем уже более 4 лет и его преимущества прочувствовали на практике уже давно. И относимся к нему не как к можному течению, а как к повседневному инструменту. Может все дело в том, что надо время, чтобы "отделить мух от котлет"?
                                      Валера, у вас ведь немного другие задачи, согласись? Ваши задачи как раз ближе к отчётности и всем тем программам, которые ЦБ плодит в неимоверных количествах... Вот ими бы и заняться! Было бы просто сказочно! А то, например, формат импорта ФОР (kliko, for_kb) - вроде бы с тегами, а с другой стороны, на теги там просто плюют
                                      Собственно, эту темку я и завёл, чтобы в котлетах не было непрожаренных мух

                                      Комментарий


                                      • #20
                                        Big_Mike
                                        Телекс
                                        Ну так перевод по телексу отправить - это уже расходы, вполне сопоставимые с МЦИ (рублем больше или меньше - нет смысла считать).
                                        Если Сбер аккумулирует - мы же должны эти деньги как-то использовать.
                                        Не очень понятно. Сбер у себя аккумулирует, он же и использует. Закройте корр.счет там - получите аккумулирование ВАШИХ средств в РКЦ, будет много удобнее. Но ладно, это отдельная тема.
                                        Почти ежедневно создаются стрессовые ситуации. Особенно с межбанком. Если отправить деньги в 11-15, то корреспондент увидит их только в 15-00. До 18-00 рейс не успели отправить - извольте ждать 20-00. Приходится приноравливать работу банка к расписанию рейсов МЦИ. Не смертельно, конечно, но зачем?

                                        Не понимаю! Во-первых, отправить два-три перевода по межбанку - на это нужно около трех минут на весь цикл, от загрузки переводов из внутрибанковской системы до получения справки из МЦИ. Где тут можно чего не успевать - не знаю. Дискретность обработки? Так ведь практически все живут в этом же режиме. Если у Вас весь межбанк только со Сбером - тогда, конечно, Вы от использования корр.счета выигрываете, но в норме-то контрагентов должно быть много, даже у небольшого банка... ну, хотя бы десяток. И как все прочие будут деньги получать быстрее, чем через МЦИ? Это же им всем нужно корр.счета в Сбере открывать. Кажется, последняя сколь-нибудь серьезная попытка создания такой системы предпринималась Торибанком (мир его праху)...

                                        Комментарий


                                        • #21
                                          dd

                                          Вот ими бы и заняться! Было бы просто сказочно!
                                          Дык.. Занимаемся А форматы по платежам, надеюсь, прочистят дорогу и другим форматам. Как видишь - не все так просто.

                                          Собственно, эту темку я и завёл, чтобы в котлетах не было непрожаренных мух

                                          Это правильно! Спасибо!

                                          Комментарий


                                          • #22
                                            М-да, интересная тема.

                                            Imho, унификация форматов нужна! При этом хотелось бы видеть этот унифицированный формат не только на этапе банк - РКЦ, а на всех этапах. которые проходит рублевая платежка. То еть необходимо унифицировать всю цепочку КЛИЕНТ1 - БАНК1 - (БАНК2...)- РКЦ1 - РКЦ2 - БАНК2 - (БАНК3...) - КЛИЕНТ2. В это случае, не пришлось бы писать каждый раз под клиента с какой-то редко встречающейся прогаммой бухучета свою конвертацию в банк-клиент. И т.д. То есть все программы, которые так или иначе работают с рублевыми платежками по всей стране, должны были бы понимать этот унифицированный формат.

                                            Комментарий


                                            • #23
                                              Shuric
                                              То еть необходимо унифицировать всю цепочку
                                              Боюсь, что решение такой задачи в этой стране может быть осуществлено только одним способом: слить все банки в один... и ведь сколько других задач может быть заодно решено.
                                              А в реальной, сегодняшней жизни... так ли уж трудно написать какой-то определенный конвертор? Работы, как правило, на пару часов, не первый раз... Так стоит ли огород городить, если не иметь в виду что-нибудь более существенное? Типа единственного банка?

                                              Комментарий


                                              • #24
                                                Shuric

                                                хотелось бы видеть этот унифицированный формат

                                                Формат уже сделан и принят НП. Будет опубликован в ближайшее время вот здесь (сообщу об этом):
                                                http://www.stp.ru/stan/

                                                Ну а формат от ЦБ - тоже уже известен.
                                                Таким образом, их всего 2, причем - оба XML и сходны по структуре. Одного формата добиться нельзя - сами понимаете почему. Но согласовывать их для автоматического преобразования один в другой - можно.

                                                Комментарий


                                                • #25
                                                  Shuric Вот насчет КЛИЕНТ1 - БАНК1 не согласен. Это может привести (и приведет) что у некоего унифицированного формата не будет поддержки какихто данных для особенной услуги оказываемой конкретным банком. Остановка в развитии и конкуренции.
                                                  Тут одна особенность - тут все (ну ия - каюсь) говорят о некоем *формате* XML. Нет такого формата данных. Это формат (скажем так) описания метаданных. Поэтому
                                                  XML в 1С, ваш XML и мой XML это разные форматы. Другое дело что XML кроме описания метаданных предоставляет еще и инструментальные средства (XSLT) для преобразования между вашим и моим XML (естественно пишем сами)

                                                  Комментарий


                                                  • #26
                                                    2 Dem_aka_Deep Вот насчет КЛИЕНТ1 - БАНК1 не согласен. Это может привести (и приведет) что у некоего унифицированного формата не будет поддержки какихто данных для особенной услуги оказываемой конкретным банком.

                                                    Не понял?!! Форматы рублевых документов четко регламентированы инструкциями ЦБ РФ. Какие еще доп. услуги могут быть в рублевой платежке?
                                                    Если вы говорите, о каких-то дополнительных реквизитах той-же платежки, которые, может поддерживать клиент-банк, то эту процедуру (добавления своих реквизитов в формат) можно предусмотреть в этом самом унифицированном формате.

                                                    2hamster А в реальной, сегодняшней жизни... так ли уж трудно написать какой-то определенный конвертор? Работы, как правило, на пару часов, не первый раз... Так стоит ли огород городить, если не иметь в виду что-нибудь более существенное? Типа единственного банка?

                                                    Не знаю, как у Вас, а у меня за прошедший год в сумме, наверное, ушло недели 2 на написание всяких-разных конвертеров из АБС в банк-клиенты других банков, настраивание АБС под изменения форматов файлов обмена с РКЦ, изменения конвертилок из бух-их программ в банк-клиент.

                                                    Комментарий


                                                    • #27
                                                      Механизатор учёта Не совсем правдивая информация.
                                                      Извините, но нельзя ли покорректнее? Я никого не обманываю. За региональные отделения говорить не могу, но в Москве корротношения только через SWIFT/Telex
                                                      hamster Во-первых, отправить два-три перевода по межбанку - на это нужно около трех минут на весь цикл,
                                                      Межбанк - это не только формирование и отправка рейсов, но еще и заключение договоров. А тут различные ситуации бывают.
                                                      Если у Вас весь межбанк только со Сбером
                                                      Речь идет не толькл о межбанке, но и о клиентских платежах в адрес клиетов Сбера
                                                      В каждой программе есть по крайней мере одна ошибка

                                                      Комментарий


                                                      • #28
                                                        Shuric
                                                        у меня за прошедший год в сумме, наверное, ушло недели 2 на написание всяких-разных конвертеров из АБС в банк-клиенты других банков, настраивание АБС под изменения форматов файлов обмена с РКЦ, изменения конвертилок из бух-их программ в банк-клиент.
                                                        Sorry, но складывается впечатление, что у Вас очень много разных программ связи... может, с унификации средств связи с контрагентами начать? Или с оптимизации корр.сети? Ладно, sorry еще раз... я понимаю, что этим не автоматизаторы должны заниматься. Мне отчасти проще, ибо корр.счета и немалая часть конверторов в моих руках, больше свободы для выбора вариантов поведения...
                                                        Big_Mike
                                                        Межбанк - это не только формирование и отправка рейсов, но еще и заключение договоров. А тут различные ситуации бывают
                                                        Но это же два разных модуля. Обработка сделки (включая формирования платежки) - это один модуль. Кстати, с момента совершения сделки до завершения обработки у меня уходит 20-30 секунд. Небольшой добавок в весь процесс, да? Дальше расчеты, о которых речь, и какие проблемы?
                                                        Речь идет не толькл о межбанке, но и о клиентских платежах в адрес клиетов Сбера
                                                        О межбанке речь была заведена в самом начале, там, где упоминались якобы преимущества SWIFTа для платежей на большие суммы... И для клиентов не вижу смысла использовать корр.счета: экономии не вижу; распыление ресурсов между РКЦ и комм.банками опять же не в плюс; внутрибанковские заморочки, конечно, зависят от банка, можно улучшать, однако в любом случае - лишние движения, лишняя вероятность путаницы, несвоевременного подкрепления кор.счета и т.д. Сколько ни занимаюсь расчетами - вижу, что ресурсы нужно концентрировать в одном месте, особенно небольшому банку. Средний еще может рассматривать варианты с расчетами в валюте - там на комиссиях можно играть. Но рубли-то сегодня по корр.счетам гонять только для регионалов имеет видимый смысл...

                                                        Комментарий


                                                        • #29
                                                          2 hamster
                                                          Sorry, но складывается впечатление, что у Вас очень много разных программ связи... может, с унификации средств связи с контрагентами начать?

                                                          В том - то и дело. Мы - региональный банк. У нас открыто несколько кор. счетов в других банках (в основном московских + Сбер). Конечно, каждый из этих корсчетов используется не очень активно, за исключением Сбера. Но, каждый московский банк дает свою прогу Банк-банк. У каждого свой формат импорта-эксопрта. А представьте себе клиента. Сейчас большинство клиентуры имеют счета в нескольких банках. И для каждого им (или банковским автоматизаторам, как у нас)приходится писать конвертилки под каждый клиент-банк.

                                                          Комментарий


                                                          • #30
                                                            hamster
                                                            с момента совершения сделки
                                                            Моменту совершения сделки предшествует процесс переговоров, процесс принятия решений итд. Я же говорю, ситуации разные бывают.
                                                            И для клиентов не вижу смысла использовать корр.счета
                                                            А Сбер видит, и все клиентские платежи в наш адрес на коррсчет зачисляет.
                                                            может, с унификации средств связи с контрагентами начать?
                                                            ИМХО из области фантастики. Как может банк унифицировать систему связи с МЦИ и почту ГУ ЦБ? Или как убедить унифицироваться Сбер и МДМ, к примеру?
                                                            В каждой программе есть по крайней мере одна ошибка

                                                            Комментарий

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

                                                            Свернуть

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

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