Горячий ветер 2022

Коломенский кайт клуб "Семь ветров" при поддержке Комитета по физической…

Как Валерий Шувалов снег убирал в 2022 году

Руководитель администрации города Валерий Шувалов проверил лично, как происходит расчистка…

В доме красногорского стрелка нашли долговые расписки Рассказова

В доме убийцы нашли черную бухгалтерию, где фигурируют крупные суммы,…

Дальнобойщики против "Платона"

Дальнобойщики бастуют по всей России. «Недовольство растет. Власти это замалчивают».…

«
»

Возможные причины ошибок при отправке отчета. Ошибка загрузки эд в цб что это


Возможные причины ошибок при отправке отчета

Код ошибки

Текст ошибки

Возможные причины, рекомендации по устранению

-10

He удалось расшифровать

Скорее всего файл отчета не был зашифрован вообще. Данная ошибка часто возникает при выгрузке файла отчета из 1С бухгалтерии, причем при выгрузке файлу уже присвоено расширение "ef4", как будто это зашифрованный файл.

-11

He удалось проверить ЭЦП.

Возможная причина -  ошибка сертификата - в данном случае следует связаться со спецоператором, выдавшим ЭЦП, или файл XML был подписан дважды, имеет смысл снова выбрать и подписать файл отчета.

-13

В сертификате отсутствует регистрационный номер страхователя.

Электронный сертификат страхователя, с помощью которого подписывали и шифровали файл отчета, не содержит внутри записи о рег.№ страхователя и его код подчиненности в системе ФСС, скорее всего это сертификат для работы с ПФР и ФНС, или УФК. Если подписывали с помощью arm.exe, при выборе личного сертификата цолжна стоять галочка "удовлетворять требованиям ФСС РФ".

-14

В сертификате отсутствует код подразделения ФСС.

Электронный сертификат страхователя, с помощью которого подписывали и шифровали файл отчета, не содержит внутри записи о коде подразделения в системе ФСС

-15

Ошибка.

 

-16

Неверный формат регистрационного номера страхователя.

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

-17

Неверный формат кода подразделения ФСС.

В сертификате, выданном спецоператором, неправильно указан код подразделения ФСС, требуется переиздание сертификата.

-18

Отчет зашифрован на ключе отличном от открытого ключа ФСС

При выполнении действия подписания и шифрования файла отчета в качестве сертификата уполномоченного лица Фонда выбран не Хасянов Ренат Алиевич (Департамент ИТ ФСС РФ), а другой сертификат - отличный от того, который нужно выбрать, необходимо выбирать сертификат Хасянова Рената Алиевича. При выборе сертификата в хранилище "другие пользователи" галочка "удовлетворять требованиям ФСС РФ" должна быть снята.

 

При возникновении данной ошибки проверьте установлена ли у Вас обновленная версия АРМ  и обновлен ли сертификат уполномоченного лица ФСС.

-19

Отчет не зашифрован или не подписан.

Необходимо подписать и снова  отправить файл отчета программным средством предложенным спецоператором или воспользоваться бесплатной программой APM

-20

Неизвестный формат.

 

-21

Файл поврежден.

На одном из этапов формирования, подписания и отправки файла отчета произошла ошибка. Имеет смысл повторить данные действия.

-41

Не найден издатель сертификата.

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

-42

Ошибка при проверке сертификата.

 

-43

Сертификат отозван.

Сертификат, которым подписан файл более не действителен. Данная ошибка может возникать, если файл отчета подписан старым сертификатом при наличие вновь выданного или сертификат скомпрометирован. В данной ситуации следует проверить правильность выбранного для подписания сертификата или обратится к спецоператору, выдавшему ЭЦП.

-44

Не найден или просрочен СОС издателя сертификата.

Ошибка возникала, когда на уровне УЦ ФСС не был обновлен корневой сертификат УЦ страхователя (закончился срок его действия), или отсутствовал или был неработоспособен список отзыва (решается на уровне УЦ ФСС РФ (Москва) и УЦ страхователя)

-45

Сертификат поврежден.

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

-46

Сертификат просрочен

Сертификат, которым подписан файл более не действителен. Данная ошибка может возникать, если файл отчета подписан старым сертификатом при наличие вновь выданного или срок действия сертификата окончен. В данной ситуации следует проверить правильность выбранного для подписания сертификата или обратится к спецоператору, выдавшему ЭЦП.

-503

XML-файл с отчетом не прошел форматный контроль

 

 

Ошибка: код 1840, сообщение Элемент 'F4INF2', атрибут 'TaxType': [свойство 'enumeration'] Значение '' не является значением из числа допустимых: {'011', '021', '032'}.

Не заполнен или не правильно заполнен шифр II раздела

 

Ошибка: код 1840, сообщение Элемент 'F4INF1', атрибут 'TaxType': [свойство 'enumeration'] Значение '0' не является значением из числа допустимых: {'041', '051', '061', '071'}.

Не заполнен или не правильно заполнен шифр I раздела

 

XML-файл с отчетом не прошел форматный контроль:

Ошибка: код 1824, сообщение Элемент 'PAYM_ORDER', атрибут 'DT': ' ' неверное значение для типа 'xs:date'.

 Ошибка возникает при выгрузке отчета из программы 1С Бухгалтерия – не заполнена или не правильно заполнена дата платежного документа.

-504

В сертификате указано несуществующее подразделение Фонда

Ошибка может возникнуть вследствие ошибки сертификата - в данном случае следует связаться со спецоператором, выдавшим ЭЦП.

-505

Неверное имя файла.

Зашифрованный файл расчета, предназначенный для передачи в Фонд социального страхования, должен иметь название <номер страхователя>_<расчетный год>_<отчетный квартал>.ef4

Например, зашифрованный файл расчета страхователя с реестровый номером 3712000456 за 1-й квартал 2011 года должен называться 3712000456_2011_03.ef4

-506

Несколько вторых разделов (узлы F4INF2) имеют одинаковые шифры налогообложения

 

 

 

 

-507

Нет файла ..xml

 

-508

Отчет не прошел логический контроль

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

-509

Отчетный период в XML-файле не совпал с отчетным периодом в имени загруженного файла

 

-510

Ошибка хранилища

 

-511

Произошли ошибки при чтении XML-файла с отчетом:

 Критическая ошибка: код 4, сообщение Документ пуст или не является XML

-512

Расчетный год в XML-файле не совпал с расчетным годом в имени загруженного файла

 

-513

Peг.номер в сертификате не совпадает с peг.номером в имени файла

Файл отчета подписал ЭЦП пренадлежащей организации отличной от организации, указанной в отчете

-514

Регистрационный номер в XML-файле не совпал с регистрационным номером в сертификате ЭЦП

 

 

 

 

-515

Файл не зашифрован или не подписан.

 

-517

Слишком большой файл

 

-518

Слишком маленький файл

 

-519

Неверная контрольная сумма файла

 

-1757

Не удалось загрузить XSD-схему для проверки структуры XML-файла

 

r29.fss.ru

ТАБЛИЦА КОДОВ РЕЗУЛЬТАТА ЛОГИЧЕСКОГО КОНТРОЛЯ ЭЛЕКТРОННЫХ ПЛАТЕЖНЫХ ДОКУМЕНТОВ ПОЛОЖЕНИЕ ЦБ РФ от 23.06.98 N 36-П (ред. от 25.09.2000) "О МЕЖРЕГИОНАЛЬНЫХ ЭЛЕКТРОННЫХ РАСЧЕТАХ, ОСУЩЕСТВЛЯЕМЫХ ЧЕРЕЗ РАСЧЕТНУЮ СЕТЬ БАНКА РОССИИ"

Код результата Текстовое значение в реквизите "Текст пояснения" в записи подтверждения (ЭСИД с кодом "R") или в реквизите "Назначение платежа" возвращаемого платежа (в пакете ЭПД с кодом "B") Примечание
00 Средства зачислены на счет получателя Реквизиты ЭПД корректны. Средства зачислены на лицевой счет получателя, открытый в балансе ГРКЦ или в РКЦ (при централизованной обработке)
01 Средства зачислены на корсчет КО Реквизиты ЭПД корректны. Средства зачислены на корреспондентский счет КО получателя в ГРКЦ или в РКЦ при централизованной обработке или будут зачислены на корсчет КО в РКЦ при децентрализованной обработке
02 Платеж получен в ГРКЦ и направлен РКЦ - получателя Формируется при децентрализованной схеме обработки ВЭП. Реквизиты ЭПД корректны, за исключением, возможно, счета клиента Банка России в РКЦ - получателя. Средства направлены в адрес РКЦ - получателя
03 Средства возвращенного платежа зачислены на счет N 30811 в ГРКЦ Положительный результат контроля реквизитов возвращенного платежа. Средства зачислены на б/с N 30811 в ГРКЦ - получателе возвращенного платежа
11 Некорректный номер электронного документа Номер электронного документа содержит недопустимые символы
12 Некорректная дата ввода электронного документа Дата ввода электронного документа содержит недопустимый символ, не равна дате в служебной записи или больше текущей даты обработки
13 Некорректная дата выписки платежного поручения Дата выписки платежного поручения (ПП) содержит недопустимые символы. Дата выписки ПП больше текущей даты обработки
14 Некорректный номер исходного платежного поручения Номер исходного платежного поручения содержит недопустимые символы
15 Некорректный код очередности Код очередности содержит недопустимые символы
16 Некорректная дата платежа Дата платежа содержит недопустимый символ или значение, не являющееся датой
17 Некорректный вид операции Вид операции содержит недопустимый символ (должен быть равным 01)
18 Некорректное значение ИНН отправителя ИНН отправителя содержит недопустимый символ
19 Некорректное значение ИНН получателя ИНН получателя содержит недопустимый символ
20 Некорректный текст наименования отправителя Текст наименования отправителя содержит недопустимые символы
21 Некорректный текст наименования получателя Текст наименования получателя содержит недопустимые символы
22 Некорректный текст назначения платежа Текст назначения платежа содержит недопустимые символы
31 Некорректный БИК отправителя БИК отправителя (КО или учреждения ЦБ РФ) ЭПД содержит недопустимые символы или не найден в "Справочнике БИК РФ" или не соответствует БИК ГРКЦ в служебной записи
32 Некорректный корсчет отправителя Корсчет КО отправителя не соответствует по "Справочнику БИК РФ" указанному в платежном документе БИК КО или содержит недопустимые символы
33 Недопустимое значение корсчета отправителя В качестве БИК отправителя указан БИК учреждения ЦБ РФ при непустом значении корсчета или указан БИК КО при пустом значении корсчета
34 Некорректный БИК получателя БИК получателя (КО или учреждения ЦБ РФ) ЭПД содержит недопустимые символы или не найден в "Справочнике БИК РФ" или не соответствует БИК ГРКЦ в служебной записи
35 Некорректный корсчет получателя Корсчет КО получателя не соответствует по "Справочнику БИК РФ" указанному в платежном документе БИК КО или содержит недопустимые символы
36 Недопустимое значение корсчета получателя В качестве БИК получателя указан БИК учреждения ЦБ РФ при непустом значении корсчета или указан БИК КО при пустом значении корсчета
37 РКЦ - плательщика - не участник МЭР РКЦ, обслуживающий КО плательщика, не является участником МЭР в соответствии с установленным признаком в "Справочнике БИК РФ"
38 РКЦ - получателя - не участник МЭР РКЦ, обслуживающий КО получателя, не является участником МЭР в соответствии с установленным признаком в "Справочнике БИК РФ"
39 - У КО получателя отозвана лицензия -
41 Некорректный ключевой разряд в лицевом счете отправителя Ошибка при контроле ключа в лицевом счете отправителя
42 Недопустимый символ в лицевом счете отправителя Лицевой счет отправителя содержит недопустимый символ
43 Недопустимый номер БС второго порядка лицевого счета отправителя Лицевой счет отправителя содержит недопустимый балансовый счет второго порядка
44 Недопустимое значение лицевого счета отправителя При указанном в электронном документе БИК учреждения ЦБ РФ отправителя - пустое значение лицевого счета отправителя
45 Некорректный ключевой разряд в лицевом счете получателя Ошибка при контроле ключа в лицевом счете получателя
46 Недопустимый символ в лицевом счете получателя Лицевой счет получателя содержит недопустимый символ
47 Недопустимый номер БС второго порядка лицевого счета получателя Лицевой счет получателя содержит недопустимый балансовый счет второго порядка
48 Недопустимое значение лицевого счета получателя При указанном в электронном документе БИК учреждения ЦБ РФ отправителя - пустое значение лицевого счета получателя
49 Несуществующий лицевой счет получателя в ГРКЦ или РКЦ Лицевой счет получателя отсутствует в балансе ГРКЦ или РКЦ (при централизованной обработке)

zakonbase.ru

База знаний - Статусы документов

Состояние документа можно отслеживать по статусу в списке платёжных поручений:

Статусы документов

Ошибка контроля - электронный документ (далее - ЭД) сформирован, но при сохранении не прошёл проверку корректности заполнения полей и сохранён с имеющимися в нём ошибками. ЭД с таким статусом может быть изменён (отредактирован) либо удалён.

Создан - ЭД сформирован, прошёл проверку корректности заполнения полей и сохранён. ЭД с таким статусом может быть изменён (отредактирован), подписан либо удалён.

Импортирован - ЭД импортирован из бухгалтерской системы, прошёл проверку корректности заполнения полей и сохранён. Для дальнейшей обработки этот статус полностью равносилен статусу "Создан". ЭД с таким статусом может быть изменён (отредактирован), подписан либо удалён.

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

Подписан - ЭД подписан предусмотренным для него комплектом АСП. Документ с таким статусом может быть отправлен для исполнения в банк либо с документа может быть снята АСП (ЭД возвращается к статусу «Частично подписан»).

Доставлен - ЭД доставлен в банк. ЭД с таким статусом автоматически направляется на прохождение банковских проверок либо может быть отвергнут банком. Также Вы можете отозвать ЭД.

Принят - ЭД принят банком к обработке. Документ с таким статусом автоматически направляется на выгрузку в АБС либо может быть отвергнут банком. Также Вы можете отозвать ЭД.

В картотеке - ЭД принят банком и помещён в картотеку. ЭД с таким статусом Вы можете отозвать.

Удален - ЭД удалён из базы «Рабочие документы» (может быть удалён только со статусов "Создан", "Импортирован" и "Ошибка контроля"). ЭД в таком статусе можно найти в базе «Удаленные документы».

ЭП неверна - проверка подписи под ЭД на стороне банка дала отрицательный результат.

Ошибка реквизитов - ЭД не прошел собственные проверки системы при приёме на стороне банка.

Отозван - ЭД отозван по команде на отзыв (из статусов "Доставлен", "Принят") или по запросу на отзыв (подробнее см. "Как отозвать платежку").

Отвергнут банком - ЭД отвергнут банком (может быть переведён в этот статус со статусов "Доставлен", "Принят").

Отказан АБС - ЭД не прошёл проверки АБС.

Исполнен - ЭД исполнен банком.

 

Историю изменений статусов платёжного поручения можно посмотреть, выделив строку с платёжным поручением и нажав на кнопку  → :

Дорогие наши клиенты, вопросы по сервису Интернет-банк Light  Вы всегда можете задать в Сообществе поддержки клиентов в данном обсуждении.  Будем рады ответить!

sprosi.ubrr.ru

Формирование запросов через расчетную сеть Банка России — Bankir.Ru

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

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

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

Единственной альтернативой являлась SWIFT, использование которой для пересылки запросов и уточнений по переводам в рублях заметно расширилось в последние годы.

Но все эти средства связи имеют ряд принципиальных недостатков. Помимо общих формальных проблем с проверкой аутентичности, неоперативностью и трудоемкостью почты, ограниченным доступом банков к SWIFT (в настоящее время менее 20% банков и их филиалов, имеющих свои корреспондентские счета в Банке России, подключены к SWIFT), любые пересылаемые по этим каналам запросы и ответы могут быть обработаны только вручную. Важно отметить, что под ручной обработкой подразумевается не только процедура принятия решения по полученному сообщению (эта операция при любом способе пересылки уточнений требует визуального контроля полученного текста), здесь ручная обработка начинается уже на этапе поиска перевода, соответствующего полученному запросу.

Для решения этой проблемы Банк России реализовал в своей расчетной системе три типа электронных сообщений. В сентябре 2010 г. в составе УФЭБС появилось сообщение ED501 — конверт для сообщений участников расчетов в собственных форматах, а в августе 2011 г. в рамках реализации Указания ЦБ РФ от 27.12.2010 № 2550-У «О порядке подтверждения кредитными организациями (филиалами кредитных организаций) и другими клиентами Банка России правильности реквизитов расчетных документов при осуществлении электронных расчетов через расчетную сеть Банка России» в УФЭБС 2.5.0 были добавлены сообщения ED243 и ED244 — соответственно запрос и ответ по выполненным переводам.

Электронные сообщения для обеспечения переписки в расчетной системе Банка России

В нынешней реализации ED501 представляет собой простой механизм пересылки любых текстовых сообщений между банками. Единственное рекомендуемое ограничение накладывается на размер такого сообщения — не более 7 Кб, чего вполне достаточно для пересылки текстовых сообщений в несколько листов, если, конечно, не увлекаться пересылкой документов с разнообразными шрифтами и рисунками. При этом в УФЭБС упоминается, что форматы таких сообщений являются предметом двусторонних соглашений между отправителем и получателем. Таким образом, ED501 в общем случае можно использовать для обеспечения практически любой вспомогательной переписки между банками — от пересылки уточнений по переводам до подтверждения межбанковских сделок.

ED243 и ED244, напротив, представляют собой строго формализованные сообщения, предназначенные для уточнения различных реквизитов платежных поручений. Подобно сообщениям MT195 и MT196 SWIFT, для ED243 и ED244 предусмотрен набор числовых кодов, указывающих на характер запроса или ответа, причем запрос может содержать только эти коды, но не текст; таким образом, в настоящее время нет возможности с помощью ED243 отправить какой-либо нестандартный запрос.

Сравнивая эти три типа электронных сообщений, необходимо отметить существенные различия в указании адресатов в ED501, с одной стороны, и ED243 и ED244 — с другой. Эти различия не вполне объяснимы логически, но именно они существенно сужают область применения ED244, которое потенциально является очень перспективным инструментом.

В ED501 в качестве адресата документа может быть указан любой банк или филиал, которому присвоен свой БИК, для этой цели в ED501 предусмотрен специальный реквизит, который фактически является единственным параметром этого сообщения, — остальные, такие как дата, уникальный номер, служат лишь идентификаторами отправляемого сообщения. Напротив, в ED243 и ED244 адресация осуществляется через ссылку на некое сообщение, являющееся первичным: для ED243, запроса по переводу, таким первичным сообщением служит, очевидно, полученный перевод, по которому и делается запрос. Для ED244, ответа на запрос, в качестве первичного сообщения рассматривается запрос по переводу, то есть ED243. Кроме того, в ED244 есть возможность указать перевод, на который ссылается соответствующее ED243.

Практическое применение ED243, ED244 и ED501

Хотя сообщение ED501 внедрено уже более года назад, широкого распространения оно не получило, несмотря на то что его универсальность позволяет в принципе решать очень широкий круг задач. Возможных причин можно выделить несколько. Во-первых, следует отметить региональные ограничения на использование ED501. Например, изначально ED501 в московском регионе было возможно отправлять только в пределах региона. И хотя с 1 августа 2011 г. одновременно с появлением ED243 и ED244 эти ограничения были отменены, на практике, как минимум во многих случаях, они остаются, о чем следует сказать отдельно далее. Другим существенным фактором является фактическая необязательность ED501 для принимающей стороны. В УФЭБС указывается, что ED501 используется для пересылки сообщений между участниками расчетов во взаимно согласованных форматах, то есть, строго говоря, повсеместное использование ED501 требует заключения двусторонних соглашений между всеми банками, что практически нереально.

Смысл указанной оговорки понятен: обязательность обработки любого сообщения должна дополняться алгоритмом такой обработки, чего нельзя сделать для сообщений, содержание которых может быть произвольным. С другой стороны, письма, пересылаемые между банками по почте, содержание которых также не формализовано, тем не менее, считаются — при надлежащем оформлении — юридически значимыми документами. Было бы целесообразно несколько изменить статус ED501, определив его как письмо банка, подписанное аналогом первой и второй подписи уполномоченных лиц, каким оно де-факто и является уже сегодня, поскольку подписывается теми же инструментами, что и реестры переводов, отправляемые через Банк России.

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

Ввод в действие ED243 и ED244 был оформлен Указанием ЦБ РФ от 27.12.2010 № 2550-У, в котором был определен статус этих документов. Таким образом, банки были вынуждены так или иначе принимать их в обработку, дорабатывать свое программное обеспечение, что косвенно способствовало и некоторому расширению использования ED501.

Первые месяцы использования новых электронных сообщений показали следующее.

Во-первых, необходимо отметить, что в расчетной системе Банка России до сих пор не обеспечивается гарантированная доставка новых сообщений адресату. Причины этого пользователю, как правило, не ясны. Например, документы, направляемые за пределы московского региона, часто (ED501 — практически всегда) отбраковываются с диагностикой «Неверный УИС получателя», хотя этот параметр формируется по тому же алгоритму, что и для успешно отправляемых сообщений. В ряде случаев ED501 отбраковываются с диагностикой «Получатель не является участником электронного документооборота», хотя ED243 в его же адрес отправляются успешно.

Во-вторых, необходимо отметить, что в настоящее время структура ED243 и ED244 соответствует только одной жестко заданной схеме документооборота: запрос по полученному переводу и ответ на полученный запрос. Между тем значительная часть переписки формируется до получения запроса по переводу — нередко отправитель замечает свою опечатку самостоятельно или узнает о ней от своего контрагента задолго до того, как из банка поступит запрос. Часть таких уточнений связана с назначением платежа, то есть реквизитом, который при зачислении практически не проверяется. Запросы по назначению платежа чаще всего инициируются не банком получателя, а отправителем, причем нередко месяц-два спустя после выполнения перевода: очевидно, необходимость таких уточнений обнаруживается при выверке платежей бухгалтериями прдприятий и происходит это без участия банков.

Далее, поскольку адресация ED243 основана на параметрах полученного перевода, у банка нет возможности использовать этот тип сообщения для запроса по отправленному им самим переводу — ведь он сам и является составителем документа, на который предполагается сделать ссылку.

Разумеется, для других схем документооборота, включая только что упомянутые, можно использовать универсальное ED501, однако, как говорилось выше, это сообщение пока имеет очень ограниченный радиус действия.

Вышеуказанные ограничения на использование всех трех электронных сообщений в совокупности приводят к тому, что значительная часть переписки осуществляется или по почте, или с использованием SWIFT. Отчасти это можно объяснить определенной консервативностью и необходимостью доработки используемого программного обеспечения банков, но, с другой стороны, требуемые доработки не так уж велики. Одной из основных причин медленного распространения в целом удобного и эффективного сервиса Банка России является понимание того, что этот сервис все равно не решает всех необходимых задач. В частности, можно отметить, что ряд банков, реализовавших новые электронные сообщения в своих системах и использующих их в повседневной практике, сохранил возможность отправки запросов и ответов по SWIFT. Среди таких банков достаточно отметить Сбербанк, запросы и ответы от которого приходят в настоящее время как по SWIFT, так и через Банк России, причем оба этих канала связи используются примерно с одинаковой частотой.

О развитии методов ведения переписки по переводам в рублях

Анализ первых месяцев работы показал, что сообщения ED243 и ED244 оказались в целом весьма эффективным инструментом, их появление стимулировало банки ускорить внедрение электронного документооборота, чего не произошло год назад при появлении ED501. Однако потенциал этих сообщений намного выше.

Для расширения использования всех трех электронных сообщений необходимо в первую очередь обеспечить гарантированную доставку каждого такого сообщения до любого участника системы расчетов Банка России. В настоящее время при подготовке запроса приходится гадать, дойдет ли сообщение до адресата, вследствие чего по возможности операторы предпочитают использовать проверенную временем SWIFT. Исключением являются только ответы на ED243, но эти ответы пока составляют сравнительно небольшую долю всех сообщений.

Во-вторых, необходимо модернизировать нынешний набор электронных сообщений так, чтобы обеспечить возможность эффективных запросов по уточнению реквизитов или отзыву выполненных переводов, не дожидаясь встречного запроса от банка получателя. В процессе подготовки этой статьи появилась информация о новой версии унифицированных форматов — УФЭБС 2.5.1, в которой эта возможность реализована за счет добавления в ED244 дополнительного кода, указывающего, что это сообщение является уточнением без ссылки на запрос.

Наконец, целесообразно несколько расширить набор кодов, определяющих характер запроса и ответа. Наиболее важными с практической точки зрения вариантами представляются запрос о подтверждении зачисления средств получателю и запрос на отзыв выполненного перевода. В обоих случаях речь идет о переводах, отправленных банком, который инициирует запрос, то есть в нынешней структуре сообщений целесообразно вести речь о дополнительной модернизации ED244. Для реализации запроса о статусе перевода придется добавить новый код, а для запроса об отзыве достаточно несколько изменить описание кода 01, определив его как просьбу вернуть перевод независимо от причин — в настоящее время предполагается, что просьбу вернуть перевод можно отправить только при невозможности представить требуемые уточнения.

Сравнение себестоимости различных вариантов ведения переписки

В настоящее время Банк России взимает с отправителей ED243 и ED244 по 9 руб. за одно сообщение. ED501 пока пересылаются бесплатно — возможно потому, что эти сообщения в настоящее время используются крайне редко. В первую очередь необходимо сопоставить указанную цену с ценой сообщений SWIFT аналогичного назначения, которые сейчас используются, пожалуй, чаще, чем ED243. Одно такое сообщение (обычно MT999) обходится банку примерно в 5 руб. (чуть больше € 0,1). Помимо упоминавшейся выше уверенности сотрудников банка в надежности SWIFT, которая используется для уточнений намного дольше новых электронных сообщений Банка России, почти двукратная разница в цене также не способствует переходу на ED243 и ED244.

Разумеется, 9 руб. — не так уж много по сравнению с расходами на переписку по факсу и почте, здесь имеются в виду в первую очередь не столько прямые расходы на связь, сколько расходы на оплату труда персонала, занятого подготовкой таких писем. По оценкам, цикл подготовки и отправки одного письма, включая подготовку текста, печать, подпись у руководства и т.д., занимает от 30 минут до часа, то есть себестоимость этого процесса составляет не менее 100 руб. по самым минимальным оценкам.

Однако необходимо учитывать и стоимость внедрения системы обеспечения переписки с использованием ED243 и ED244. В частности, одна из предлагаемых на рынке реализаций стоит около $4 тыс. плюс около $400 ежемесячно за ее поддержку. На примере одного из средних банков можно оценить число отправляемых запросов и ответов как 10 штук в день, то есть в данном примере себестоимость одного сообщения составит уже около 60–70 руб. за сообщение, то есть на порядок больше, чем при использовании SWIFT, которая большинством средних банков сегодня уже используется.

Между тем структура системы обеспечения такой переписки в среднем банке может быть сравнительно простой. Практика показала, что ее реализация требует около недели работы одного программиста. С целью упрощения структуры программы и поиска переписки процедура была основана на копировании отправленного или полученного перевода в отдельную базу данных, к которой был добавлен модуль формирования запросов и ответов с возможностью выбора способа отправки сообщения через Банк России или по SWIFT.

Здесь, кстати, стоит отметить, что одновременно с появлением ED243 и ED244 Банк России начал распространять через свой интернет-сайт базу соответствия кодов БИК и активных кодов SWIFT, что заметно облегчило использование SWIFT как альтернативу этим сообщениям.

Вместо заключения: как уменьшить потребность в переписке?

В завершение данной статьи целесообразно вспомнить о том, что в середине 2010 г. одновременно с распространением информации о разработке Банком России электронных сообщений для обеспечения запросов и ответов на сайте Банка России появился проект изменений в основной документ, регламентирующий безналичные расчеты в рублях, — Положение ЦБ РФ от 03.10.2002 № 2-П «О безналичных расчетах в Российской Федерации». Один из пунктов этого проекта предусматривал следующее: «Допускается зачисление денежных средств по номеру счета получателя и значению иного реквизита (поля) расчетного документа, поступившего в банк получателя в электронном виде, по которому идентифицируется получатель денежных средств, или по номеру счета получателя, указанному в расчетном документе, поступившем в банк получателя в электронном виде, если условие о зачислении денежных средств на основании данных реквизитов предусмотрено договором между банком получателя и получателем».

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

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

Еще одним потенциальным источником недоразумений является ИНН, статус которого в платежных поручениях определен недостаточно четко. Фактически действующие нормативные акты требуют, чтобы банки только проверяли его наличие, но не правильность, в том числе и во время обработки в банке получателя. Такая неопределенность приводила к многочисленным запросам в Банк России, ответы на которые сводились к тому, что банки не вправе не зачислять средства на счета получателей на основании неверного ИНН1.

Тем не менее в ED243 и ED244 предусмотрен специальный код для запроса и ответа об уточнении ИНН. Таким образом, облегчая техническую сторону переписки, новые электронные сообщения усиливают методологическую неопределенность.

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

 

bankir.ru


.