Bankir.Ru
11 декабря, воскресенье 03:19

Объявление

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

Ключ не спасает от ошибки...

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

  • Ключ не спасает от ошибки...

    Название темы - чисто риторическое. Ситуация банальна и стара как мир, а потому - я уверен - знакома большинству из здесь присутствующих. Причина открытия темы - почему-то раньше она здесь не обсуждалась (может и моя вина - плохо искал, в таком случае прошу модератора строго не судить ).
    Итак, тетенька-операционист набивает платежки в опердне. Шпарит одну за другой. После набора БИКа банка-получателя система автоматом заполняет название банка и корсчет. Очередная платежка ключуется на ура и идет в пачку на отправку. Тетенька на межбанковских расчетах также не глядя выгружает пачку из опердня и отправляет куда надо.
    Через день звонит клиент и сообщает, что его контрагент денежки почему-то до сих пор не получил. После стандартной в таких случаях процедуры выясняется, что не смотря на успешное ключевание денежки ушли не в тот банк. Дальше - спешное исправление ошибки за счет средств банка, уговоры клиента не гневаться, грозные меры "дисциплинарного воздействия", в общем, "кино и немцы".
    То, что ключ не гарантирует уникальность БИКа банка получателя при одном и том же счете получателя (т.е., одну и ту же цифру контрольного ключа при том же счете получателя могут дать несколько БИКов), также, думаю, большинству известно.
    Большинство скажет - а где же тот самый пресловутый контроль? А с контролем все в порядке есть приказ, по которому каждая платежка перед отправкой распечатывается и визируется дважды - исполнителем (операционистом) и контролером (оператором межбанковских расчетов). Теоретически все ОК, на практике тетеньки жалуются на большую загрузку, и потому не успевают толком оформить и т.д. Ну, загрузка - это тема для отдельного разговора, а в итоге, как сказал Райкин "один коронки штампует, другой вставляет, а за дикцию никто не отвечает".
    ITшники, как всегда, предлагают самый легкий для них самих способ: убрать к дьяволу автоматическую вставку корсчета и названия банка по БИКу из справочника, пусть, дескать все набирают ручками, а после наборе сделать
    проверку на соответствие БИКа, корсчета и названия по справочнику.
    Операционисты в один голос кричат, что тогда их вообще похоронят, поскольку "такую груду платежей" они будут набирать до второго пришествия. Лучше пусть зарплату повысят и штат увеличат.

    All: Как вы думаете кто прав?
    11
    ITшники
    36.36%
    4
    Операционисты
    9.09%
    1
    Суть не в этом
    54.55%
    6

  • #2
    убрать к дьяволу автоматическую вставку корсчета и названия банка по БИКу из справочника, пусть, дескать все набирают ручками
    А еще надо им логарифмические линейки раздать - пусь-ка бЫра проверят "НДС в том числе"! А еще лучше - в столбик пускай пощитают!

    Комментарий


    • #3
      Господин Некоторые практикуют двойную набивку и затем автоматом сравнение. Так что тщательнее надо. Или на БАНК-КЛИЕНТ переводить всех, пущай клиент сам за все отвечает.
      Но, как сказал Маркиз де Сад Захер Мазоху: "Ну, имейте же терпение, мой друг!" (Т.Шаов (с))

      Комментарий


      • #4
        Господин пусть, дескать все набирают ручками,
        ...и цифры суммы платежа ещё пусть пишут словами для надёжности, а IT-специалисты сделают автоматическую проверку на существование соответствия слов цифрам, что бы исключить ошибку ещё на этапе ввода.

        А, если операционист не только время потеряет, но и опять ошибётся? Например, глянет случайно (или с преступным умыслом) на БИК, банк и счёт другой платёжки и введёт его - ключ счёта получателя тоже не выявит ошибку.

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

        Комментарий


        • #5
          Господин

          Уважаемый AVKomarov прав в нижней части своего постинга

          А мы, ITшники, всегда, предлагаем самый легкий способ И не только для нас самих

          Давайте рассмотрим Вашу ситуацию Если я что-то не так понял, поправьте

          Хочется чтобы:
          1. После набора БИКа банка-получателя система автоматом заполняла название банка и корсчет
          2. При этом давалась гарантия, что платежка "правильная", т.е. БИК, коррсчет, название банка - соответствуют друг другу (что обеспечивается п. 1), и что клиентский счет - это счет именно из этого банка

          Вариантов решения несколько Например:

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

          2. Вместо того, чтобы колотить БИК, осуществлять заполнение всех полей по выбору счета корреспондента (не Банка) из некоего списка корреспондентов. Это более реально. Но, где гарантия, что у одного клиента не будет например 2 одинаковых счета в банках со схожими в контексте данной темы БИК? Или у разных Так что визуальный контроль остается в любом случае

          3. Переводить всех на Банк-Клиент, как советует CAP Но это как-бы ITшников касается косвенно Уговаривайте клиентов

          4. Гнать платежки через сканер Визуальный контроль все-равно остается

          Так что задача просто в том, чтобы найти разумный компромисс между 4 - мя сторонами: Операционист - Контроллер - IT - Клиент, а вопрос "Кто прав?" не при чем. Смотрите просто, что для Вас лучше и удобнее

          Комментарий


          • #6
            vsv Вариантов решения несколько ...
            Наверное можно и еще придумать чего-нить

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

            Так что правы по своему все, а решение - любыми способами переложить ответственность за правильность документа на клиента (клиент-банк и т.п.). Если провести серьезную работу с клиентами, не так уж это и сложно.

            Комментарий


            • #7
              Господин А еще, присоединяясь ко всем предыдущим предложениям насчет Клиент-Банка, сканирования и т.п., может быть все-таки подумать об увеличении штата операционистов или распределении функций?

              Комментарий


              • #8
                После стандартной в таких случаях процедуры выясняется, что не смотря на успешное ключевание денежки ушли не в тот банк. Дальше - спешное исправление ошибки за счет средств банка, уговоры клиента не гневаться, грозные меры "дисциплинарного воздействия", в общем, "кино и немцы".
                То, что ключ не гарантирует уникальность БИКа банка получателя при одном и том же счете получателя (т.е., одну и ту же цифру контрольного ключа при том же счете получателя могут дать несколько БИКов), также, думаю, большинству известно.
                чего-то я недопонял - в наборе БИКа ошибся операционист?
                если так то это и есть ошибка, если нет то непонятна проблема...
                то что набивается группа счет получателя - БИК банка получателя а не в совокупности с наименованием банка и коррсчетом то это разумно. А то что после набора платежки визуально не увидели различие с оригиналом в наименовании банка получателя так это просто ошибка и невнимательность...
                Последний раз редактировалось Томич; 21.08.2002, 07:22.

                Комментарий


                • #9
                  Shamai
                  Наверное можно и еще придумать чего-нить
                  Конечно

                  Комментарий


                  • #10
                    Томич то что набивается группа счет получателя - БИК банка получателя а не в совокупности с наименованием банка и коррсчетом то это разумно. А то что после набора платежки визуально не увидели различие с оригиналом в наименовании банка получателя так это просто ошибка и невнимательность...
                    целиком и полностью

                    Комментарий


                    • #11
                      Позвольте, господа, и мне несколько слов.
                      С "неуникальностью" ключа я лично несколько раз сталкивался.
                      Начиная от "отправки денег не туда" и заканчивая сменой БИК в
                      собственном банке, когда не пришлось "переключевывать" все счета.
                      Насколько я понимаю в ЦБ об этой "проблеме" знают: лет эдак 4-5 назад
                      (точнее не помню ) в период подготовки перехода на новый план счетов
                      было письмо ЦБ, в котором ЗАПРЕЩАЛОСЬ вводить автоматом к/с банка
                      на основании его БИК (не понимаю правда, каким образом это может
                      защитить собственно ключ лицевого счета и зачем это надо)

                      В итоге имеем: Контрольный разряд можно рассматривать только как
                      некоторое дополнительное средство контроля, а не "панацею".

                      Комментарий


                      • #12
                        Коллеги, во-первых, позвольте поблагодарить за проявленный к проблеме интерес.
                        Во-вторых, "банк-клиент", на мой взгляд, хотя и является наиболее безотказным средством переложить подобный риск на плательщика, тем не менее, не всегда применим в конкретной ситуации. Есть группа клиентов, которые упорно его не хотят, не смотря на все уговоры, посулы и угрозы. Причем, даже сами внятно не могут объяснить, почему. Но вопрос не в этом.
                        Лично мне кажется, что наиболее оптимальным способом решения проблемы является все же справочник корреспондентов. Беда только в том, что мануально формировать его долго и нудно. Есть такой вариант (опять же - не думаю, что открываю Америку, но все же...). Допустим, операционист набрал платежку. Перед вводом система его спрашивает: "Занести получателя в справочник корреспондентов?". Он говорит "да" и дело с концом. Либо "нет", если получатель сравнительно редок. Так вот вопрос - реализуема ли такая процедура, скажем, в Рстуле?

                        Комментарий


                        • #13
                          Господин
                          Так вот вопрос - реализуема ли такая процедура, скажем, в Рстуле?
                          Вы будете смеяться, но она там реализована на системном уровне

                          См. работу клавишь Ctrl-F3 и Ctrl-F9 из формы ввода документа
                          А почитать можно в доке mvodb.pdf (параграф ВВОД И ПРОВОДКА ДОКУМЕНТА) Дока есть на CD с RS'ом

                          Комментарий


                          • #14
                            Господин Лично мне кажется, что наиболее оптимальным способом решения проблемы является все же справочник корреспондентов.
                            Не всегда. Корреспонденты - тоже люди , и у них меняются БИКи, лицевые счета и т.п. Так что от дополнительного контроля тут никуда не деться...

                            Комментарий


                            • #15
                              Господин
                              ...позвольте поблагодарить за проявленный к проблеме интерес...

                              А интерес то не праздный !!! ИМХО, это вызвано не интересом, а
                              существованием самой ПРОБЛЕМЫ - возможностью поменять БИК банка
                              (а иже с ним корсчет с наименованием) не меняя при этом л/счета !!!
                              Даже если "переложить все на клиент-банк" - не решает, а только
                              усугубляет проблему. Поясню: "невнимательный клиент" ошибся в БИК.
                              Автоматически заполнились поля корсчет и наименование банка.
                              Клиент заполнил л/счет получателя и "О ЧУДО - ЕГО ПРОПУСТИЛИ - УРА".
                              С другой стороны, даже если БИК указан верно, а лицевой счет нет,
                              все равно существует вероятность его "неподконтрольности".
                              Конечно, скажите Вы, можно и "пяткой" платежку набирать и "вслепую".
                              Но скажите, пожалуйста, для чего тогда нужен такой "ключ" ?
                              А клиент может спросить:
                              А нафига мне такой "банк-клиент" ? А может просто БАНК ?

                              Задумчиво так: Что-же делать ........

                              Комментарий


                              • #16
                                В ответ на вопрос о ПРОБЛЕМЕ расскажу реальную историю из жизни реального клиента (история примерно двухлетней давности).
                                П.П. на примерно 5 лимонов рублей пересылается на корсчет какого-то прибалтийского банка в каком-то российском банке, а в назначении записано ".... для зачисления на счет XXXXX за YYYYY ... " ну из-за всяких валютных контролей пришлось клиенту назначение свое сократить сильно - названия клиента не осталось (хорошо, хоть номер контракта был). И вот в этом-то номере счета XXXXX клиент и описался - цифирь не ту наколотил.
                                2 недели доставали эти деньги из Прибалтики. А вы говорите - "ключ счета", "гарантия от ошибок"... Где в MT100 хоть какие-либо "ключи", "кодовые последовательности" и т.п? Весь мир работает, одна Россия "свой путь" ищет...

                                /kiv
                                /kiv

                                Комментарий


                                • #17
                                  Илюха Весь мир работает, одна Россия "свой путь" ищет...

                                  Вот именно, и я о том же. В отсутствии "контроля" тоже есть свои прелести:
                                  повышается мера ответственности исполнителя - ему ведь не на кого в этом
                                  случае свалить вину - сам и виноват.
                                  И кроме всего прочее (по моим сведениям) во всем мире , в том числе и в упомянутой Прибалтике, существует практика "страхования ошибок исполнителей" на очень "кругленькую" сумму. Мало не покажется -
                                  от компенсации нанесенного ущерба до уголовной ответственности.
                                  С ИТ никто разбираться не будет - ОШИБКА ИСПОЛНИТЕЛЯ и ТОЧКА .

                                  Комментарий


                                  • #18
                                    RNay Правильно, "человеческий фактор" он и в африке человеческий фактор.

                                    Комментарий


                                    • #19
                                      Господа!
                                      Объясните мне, почему за Банк-Клиентом не нужен последконтроль?!?!?!?
                                      Здесь это упоминается как очевидное - а мне не очевидно.

                                      Комментарий


                                      • #20
                                        За банк-клиентом контроль не нужен по причине того, что в договоре есть фраза "Банк не несет отвественности за корректность реквизитов и содержание платежного документа, переданного клиентом" -- т.е. в этом случае кривые реквизиты будут на совести не банка, а соотв. "девочки" клиента.
                                        А решение проблемы м.б. только одно -- доп. контроль. Например повторный ввод некоторого количества полей документа другим человеком.
                                        Serg Voronov

                                        Комментарий


                                        • #21
                                          2 Mic
                                          Потому, что в банке пришедший от клиента по клиент-банку электронный документ является ОРИГИНАЛОМ.
                                          А набитый с бумажной платежки руками (снятый сканером) является КОПИЕЙ. Поэтому копию мы можем (да и должны) сверить с оригиналом и назвать сверку "контролем" - а электронный документ сверять не с чем, он сам себе главный и последний...

                                          /kiv
                                          /kiv

                                          Комментарий


                                          • #22
                                            Serg_FSB А решение проблемы м.б. только одно -- доп. контроль. Например повторный ввод некоторого количества полей документа другим человеком

                                            А Вы можете привести пример хотя бы одной системы "банк-клиент",
                                            предполагающий такую процедуру ?

                                            В лучшем случае это:
                                            - набирает один человек
                                            - проверяет (просто смотрит) /подписывает другой
                                            - может ище и третий-лишний отправляет.

                                            А на практике - все это делает один человек.
                                            Поправьте, если что не так сказал.

                                            Комментарий


                                            • #23
                                              Serg_FSB
                                              кривые реквизиты будут на совести не банка, а соотв. "девочки" клиента.

                                              Очень хочется поспорить
                                              В какой момент заканчивается ответственность клиента за платеж и начинается ответственность банка?
                                              Возьмем бумажный документ: Ответственность банка начинается в тот момент, когда последний экземпляр со штампом банка передан клиенту. В этот момент платежка еще не введена в АБС - как правило это так. Конечно, операционист глазом на платежку посмотрел и принял решения принять документ, но тем не менее ошибка еще может быть обнаружена. И она уже становится проблемой банка.
                                              Теперь Банк-Клиент: Ответственность банка начинается в тот момент, когда клиенту отправлен квиточек о приеме его документа. Сам документ может быть в этот момент уже загружен в АБС или не загружен, это все равно, но ОШИБКА ЕЩЕ МОЖЕТ БЫТЬ ОБНАРУЖЕНА. Разницы нет.

                                              А потом из-за одного кривоватого документа РКЦ завернет всю посылку. И нельзя будет возложить ответственность за пару сотен неушедших платежей на одного клиента, который прислал "плохую" платежку, что бы там ни было написано в договоре.

                                              Илюха
                                              Потому, что в банке пришедший от клиента по клиент-банку электронный документ является ОРИГИНАЛОМ.

                                              Хорошо бы посмотреть определение термина "оригинал электронного документа". Уверен, что у Вас, так же как и у нас, это что-то "подписанное ЭЦП клиента". То, что загружено в АБС, является КОПИЕЙ независимо от способа доставки в банк. Понятно, что Вы гарантируете адекватный перенос данных, но ведь и изменения в документ вносите наверняка. Если клиент пишет в назначении символ № Вы не заменяете его на N? Если номер документа 13243546 Вы не режете его до 546 (или 43546, неважно)?

                                              Комментарий


                                              • #24
                                                RNay
                                                А Вы можете привести пример хотя бы одной системы "банк-клиент",
                                                предполагающий такую процедуру ?


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

                                                Комментарий


                                                • #25
                                                  2 Mic
                                                  Ну если упираться в определения, то оригинал бумажного документа тоже не вполне... Ну подписан он подписью, похожей на подпись из карточки. Даже печать похожая стоит. Вопрос про совпадение номера "зарегистрировано в реестре печатей " на бортике - даже не стоит, ну да не об том речь. А об том, что клиенту и в бумажном документе ничего не стоит вколотить 20-значный порядковый номер или 1000-значное назначение с буквами Ё,№ и прочими чудесами.
                                                  Преобразование формата документа к утвержденному (положениями ли ЦБ или инструкциями банка) ошибкой не является...

                                                  /kiv
                                                  /kiv

                                                  Комментарий


                                                  • #26
                                                    Mic Документы, пришедшие по Б-К, грузятся в АБС, а повторный ввод делается уже там

                                                    НЕ ПОНЯЛ ! На основании ЧАВО делается повторный ввод - ОШИБОК КЛИЕНТА ?!

                                                    Комментарий


                                                    • #27
                                                      RNay
                                                      НЕ ПОНЯЛ ! На основании ЧАВО делается повторный ввод - ОШИБОК КЛИЕНТА ?!

                                                      Возражение понятное. Повторяю свой постинг от 16.05.2002.
                                                      ------------------
                                                      В процессе совершения рублевых платежей у нас в банке по технологии задействованы два подразделения (на самом деле больше, но всякую постановку на позицию и т.п. здесь можно не учитывать) - ОО (отдел обслуживания, собственно операционисты) и ОР (отдел расчетов). Названия отделов условные. Операционист обслуживает клиента (мило улыбается, принимает шоколадки, ставит штампики, раздает выписки и т.п.) и производит первичный ввод документа в систему. В случае банк-клиента ввод, разумеется, не ручной, но зато присутствует этап печати бумажных документов. После этого принятые и проштампованные документы поступают в ОР.
                                                      Уже там, в ОР, производится верификация, формирование сеансов и собственно отправка платежей. Верификация имеет ряд целей:
                                                      1. убедиться, что для каждого электронного документа в системе есть бумажный оригинал в нужном количестве экземпляров.
                                                      2. рассортировать бумажные документы в пачки по типам для а) подшивки банковского экземпляра в документы дня и б) отправки бумажного документа в расчетную систему (таких мало, но есть).
                                                      3. сформировать сопроводительные документы к расчетам (сводные поручения, описи, реестр конвертов и т.п.)
                                                      4. проверить документ на отсутствие ошибок ввода.

                                                      Документ, пришедший по системе Банк-Клиент, ошибок ввода не содержит по определению. Но пункты 1-3 для него все равно должны быть выполнены. Кроме того, у документов Б-К есть другие беды - например, двоящиеся документы. Это когда клиент к трем часам дня опомнился, что ошибся в назначении платежа на пару символов и посылает документ повторно. Есть и другие. (Не хочу вдаваться в подробности, почему именно отзыв документа клиентом средствами Б-К не всегда может быть удовлетворен)

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

                                                      Комментарий


                                                      • #28
                                                        Господин Лично мне кажется, что наиболее оптимальным способом решения проблемы является все же справочник корреспондентов.

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

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

                                                        Комментарий


                                                        • #29
                                                          2 Mic
                                                          При бумажном документообороте банк отвечает перед клиентом за то, что платежка, ушедшая со счета клиента соотвествует бумажному носителю с точностью до замены определенных символов (№,ё, chr(13) и т.п.). Т.е. что при набивке документа операционист не ввел отсебятину.
                                                          При электронном документообороте этап "операционист" отсутствует. За все остальные неточности и погрешности отвечает сам клиент. А софт БК должен клиенту помогать -- ругаться на неправильные символы, проверять ключи, вести справочники корреспондентов и т.п.
                                                          Serg Voronov

                                                          Комментарий


                                                          • #30
                                                            Mic Документ, пришедший по системе Банк-Клиент, ошибок ввода не содержит по определению

                                                            А вот это как раз не ФАКТ !!!
                                                            И если КЛИЕНТ допустил ОШИБКУ, то БАНК не в состоянии ее "поймать".

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

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

                                                            Илюха Где в MT100 хоть какие-либо "ключи", "кодовые последовательности" и т.п? Весь мир работает, одна Россия "свой путь" ищет

                                                            А может перейти на всем на MT100 и стать цивилизованным обществом ?

                                                            Комментарий

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

                                                            Свернуть

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

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