Мт103 что это такое
Переводы в иностранной валюте с покрытием как способ минимизации риска возврата платежей
Главная > Документ
| Информация о документе | |
| Дата добавления: | |
| Размер: | |
| Доступные форматы для скачивания: |
Переводы в иностранной валюте с покрытием
как способ минимизации риска возврата платежей
В международной банковской практике существует два метода осуществления платежей.
Первый, более простой и чаще употребляющийся – последовательный перевод средств “по цепочке”.
При этом способе клиент передает в Банк заявление на перевод средств, в котором, в частности, указаны наименование бенефициара, номер его счета в обслуживающем банке, наименование этого банка (банка бенефициара) и, довольно часто, наименование банка-посредника, в котором банк бенефициара держит счет в валюте платежа.
Для исполнения перевода банк плательщика направляет по системе SWIFT/телекс платежное поручение (электронное сообщение–ключеванного* формата MT103) в адрес того своего банка-корреспондента, в котором он держит счет в валюте платежа, воспроизводя в нем вышеперечисленные платежные реквизиты. В соответствии с инструкциями банка-отправителя платежа банк-корреспондент списывает с его счета сумму перевода и осуществляет дальнейший перевод средств уже через свой банк-корреспондент, указывая ему платежные инструкции из первоначального платежного поручения. И так, по цепочке, банки передают друг другу платежные инструкции и деньги до тех пор, пока средства не будут зачислены на счет бенефициара в обслуживающем его банке. Как мы видим, деньги и платежные инструкции при этом способе следуют от банка к банку в неразрывной связке, поэтому все банки, участвующие в сделке знают наименование плательщика и его банка. Если кто-то из них имеет проблемы по линии финансового мониторинга (они находятся в списках проблемных стран, под санкциями США и/или ЕЭС и т.п.), то ЛЮБОЙ банк-участник последовательной цепочки может отказаться исполнять платежное поручение такого клиента/банка и задержать/вернуть средства инициатору платежа.
Содержание первого, так называемого «прямого поручения» (direct payment МТ103) практически такое же, что в первом случае, за исключением того, что в нем не указываются банки-посредники по осуществлению платежа, но обязательно идет ссылка на референс, т.е. исходящий номер платежа покрытия (второго сообщения МТ202). Таким образом, очень важно, что еще ДО осуществления платежа “с покрытием” банк-отправитель и банк бенефициара должны осуществить обмен телексными ключами или ключами SWIFT, и в этом наши клиенты-перевододатели могут существенно помочь своему банку.
Для этого они должны связаться со своими контрагентами-бенефициарами с тем, чтобы последние обратились в обслуживающий их банк с просьбой обменяться ключами с ОАО МАБ «Темпбанк», поскольку в ближайшем времени ожидают платежей именно от этого конкретного банка. В случае подтверждения бенефициаром своему банку необходимости осуществить транзакцию с конкретным банком отправителя обмен ключами осуществляется обычно в короткие сроки.
Второе поручение (сообщение формата МТ202) называется «платежом покрытия» (cover payment). В нем банк-отправитель указывает своему банку-корреспонденту в качестве получателя средств банк бенефициара, куда было отправлено первое платежное поручение МТ103, а платежную цепочку банк-корреспондент уже выстраивает сам. Таким образом, в сообщении МТ202 отсутствует информация о наименовании плательщика и назначении платежа, что значительно снижает риск неисполнения платежа кем-либо из участников расчетов.
* Электронный ключ в системе телекоммуникационных межбанковских сообщений аналогичен подписи и печати банка на бумажном платежном документе.
Информационные потоки в случае использования метода платежа «с покрытием»
Платежи stp и «ручная доработка» денежных переводов в иностранных банках
«Международные банковские операции», 2011, N 1
Как правило, платежные инструкции, посылаемые в иностранный банк, в достаточной степени формализованы и заложены в стандарты SWIFT. И, хотя любой алгоритм обработки строится в целом в соответствии с этими стандартами, конкретные реализации могут различаться. Причины могут быть разными: от различного представления о качестве сервиса для клиентов до использования разных расчетных систем, форматы сообщений в которых могут отличаться от стандартов SWIFT.
Решение такой задачи можно разложить на несколько составляющих:
Вторая часть этого процесса, выбор способа перевода (если не рассматривать частный случай, когда полученные платежные инструкции сводятся к распоряжению кредитовать некий счет на балансе получателя этих инструкций), определяется валютой платежа: получатель платежных инструкций просто перенаправит их в банк или платежную систему, которые являются для него основными корреспондентами для выполнения переводов в заданной валюте. Таким образом, задача системы обработки заключается в распознавании адресата перевода и форматировании исходящих платежных инструкций в соответствии с теми требованиями, которые предъявляют к банку его корреспонденты, будь то банки или расчетные системы.
Решение этой задачи требует выполнения нескольких очевидных условий, которые можно считать основными принципами, положенными в основу STP:
Идентификация банка, в который необходимо направить средства
Как следствие, возникает задача выбора универсального идентификатора банка, который можно было бы использовать независимо от того, через какие расчетные системы или банки будет проходить перевод.
Использование почтового идентификатора в качестве эквивалента номера счета имеет и еще один недостаток, связанный уже с определенной бессистемностью его использования банками. Нередко банк регистрирует несколько кодов для своих не только филиалов или отделений в одном городе, но и отдельных подразделений, то есть многие коды BIC являются действительно всего лишь почтовыми адресами в сети SWIFT, которые не относятся ни к каким счетам банка. По существу, это означает, что использования только BIC Directory в общем случае недостаточно для формирования перевода, нужна дополнительная информация о том, какие именно коды являются идентификаторами корреспондентских счетов банков.
Полнота платежных инструкций
Значительная часть переводов требует использования на одном из этапов какой-либо расчетной системы; соответственно, цепочка платежа в данном платежном поручении должна начинаться с участника такой расчетной системы, который уже будет кредитовать счет банка бенефициара или его корреспондента. Любая расчетная система будет требовать явного указания ее участника; любой ее участник будет требовать явного указания банка или конечного бенефициара, счет которого он должен будет кредитовать.
Здесь необходимо подчеркнуть, что для платежных поручений, поступающих из расчетных систем, допустимым способом дальнейшего перевода считается только кредитование счета на балансе банка, получившего платежные инструкции. Если такой способ невозможен, перевод возвращается. С другой стороны, аналогичное по сути платежное поручение, содержащее инструкцию отправить средства в некий произвольный для получателя этих инструкций банк, но поступившее от банка-корреспондента, может рассматриваться как распоряжение выполнить перевод в указанный банк любым удобным способом; такие платежные поручения нередко выполняются.
Отсюда следует основное правило формирования платежных поручений: построение цепочки перевода, начинающейся с банка бенефициара, должно завершаться либо банком, в который направляется платежное поручение, либо банком, расположенным в стране происхождения валюты платежа, и банки, входящие в цепочку, должны быть связаны друг с другом корреспондентскими счетами в валюте платежа. Это правило неявно предполагает, что любой банк, расположенный в стране происхождения валюты, подключен к соответствующей расчетной системе и, соответственно, любой другой банк, расположенный в той же стране, который будет выполнять готовящееся платежное поручение, сможет отправить средства в указанный банк с использованием такой расчетной системы. Разумеется, из каждого правила теоретически могут быть исключения, но банки, оказывающие стандартные расчетные услуги своим корреспондентам, к таким исключениям не относятся.
Если платежное поручение направляется в банк, который расположен за пределами страны происхождения валюты, то оно, как правило, без изменений пересылается далее в следующий банк-корреспондент по выбору этого банка до тех пор, пока не попадет в банк, подключенный к необходимой расчетной системе.
Указание участников перевода средств в отдельных полях
Разделение платежного поручения на последовательность полей, содержащих цепочку платежа, призвано обеспечить однозначность процесса идентификации банка. Указание двух банков (или филиалов) в одном поле фактически означает необходимость выбора для перечисления средств одного из двух формально равноправных счетов. Различные вспомогательные инструкции типа «для дальнейшего зачисления на счет» могут обрабатываться только вручную.
Между тем в реальной практике расчетов, в первую очередь в долларах США (впрочем, практически исключительно в этом случае), цепочка платежа, которую необходимо указать в платежном поручении (в соответствии с принципами, изложенными в разделе «Полнота платежных инструкций»), достаточно часто состоит из трех банков (один из которых зачастую всего лишь филиал предыдущего, но это в общем случае дела не меняет). Цепочки из большего числа банков встречаются довольно редко, но и трех банков достаточно, чтобы принципы автоматической обработки переводов, заложенные в стандарты SWIFT, уже не работали на протяжении всей цепочки платежа.
Использование IBAN
При формировании МТ103 поле 72 используется на практике главным образом для указания филиала банка бенефициара или его адреса, во-первых, в случаях, когда такой филиал является третьим банком в цепочке перевода (после своей головной конторы и ее корреспондента), и, во-вторых, в тех случаях, когда этот филиал либо не имеет своего BIC, либо определить этот BIC по указанному адресу затруднительно, вследствие чего в качестве однозначного идентификатора банка приходится использовать в поле 57А BIC его головной конторы.
В задачу данной статьи не входит подробный рассказ о структуре IBAN; всю текущую информацию об этом стандарте можно найти на официальном сайте ECBS, Европейского комитета по банковским стандартам (http://www.ecbs.org).
Введение IBAN теоретически позволяет обойтись в платежном поручении вообще без явного указания банка бенефициара, поскольку вся информация о нем содержится внутри IBAN; однако в настоящее время нормативные документы ЕС требуют, чтобы банк бенефициара был указан явно. Одно из следствий избыточности информации о банке бенефициара при наличии IBAN: многие европейские банки рассматривают сам факт наличия поля 72 при переводах евро в качестве основания для ручной доработки и взятия дополнительной комиссии вместо того, чтобы закладывать какие-либо алгоритмы обработки этого поля в свои системы автоматической обработки.
Это относится не ко всем банкам, как минимум некоторые допускают использование поля 72. Однако при наличии IBAN целесообразно минимизировать использование поля 72, для того чтобы максимально уменьшить вероятность ручной доработки переводов и тем самым ускорить их обработку на всех этапах. Это относится к переводам в любых валютах, не только в евро.
При использовании IBAN возникает еще один практический вопрос: необходимо ли указывать в поле 57А BIC именно того филиала, банковский код которого входит в IBAN, или достаточно указать BIC головной конторы, которая уже сама на основании кода в IBAN перечислит средства в необходимый свой филиал? Проблема актуальна не только потому, что во многих случаях требуемый филиал просто не имеет своего BIC, но и потому, что зачастую по представленным клиентом реквизитам определить точный BIC филиала затруднительно, справочников национальных банковских кодов нередко под руками нет.
Практика работы через VTB Bank (Deutschland) AG показывает следующее: если в поле 57А указан BIC головной конторы немецкого банка и ее BLZ не соответствует включенному в IBAN, то перевод попадает на ручную доработку. Если же перевод направляется за пределы Германии, то аналогичные расхождения не контролируются и перевод обрабатывается как STP. Возможное объяснение очевидно: перевод в пределах Германии отправляется через RTGS+ непосредственно в нужный филиал банка бенефициара, соответственно, необходима коррекция указанного в МТ103 кода. Для перевода же за пределы Германии VTB Bank (Deutschland) AG обычно использует сеть своих корреспондентов, взимая дополнительную комиссию, включающую в себя их усредненные расходы. Можно предположить, что расходы на доработку переводов, которую при необходимости должны будут проводить его корреспонденты, также включены в эту комиссию.
Вышесказанное призвано в первую очередь проиллюстрировать тот факт, что каждый банк работает в своих условиях и по своим методикам и степень необходимого контроля платежных реквизитов определяется этими условиями работы, которые, к сожалению, обычно не видны со стороны. Общедоступные правила STP, которые отдельные банки публикуют на своих сайтах, как правило, ограничиваются указаниями использовать только опцию A в соответствующих полях без указания, насколько точной должна быть такая адресация. Таким образом, указание BIC головной конторы вместо BIC филиала, обслуживающего бенефициара, может быть допустимо, но в общем случае может зависеть от правил, устанавливаемых банком-корреспондентом.
Стандартизация STP
В связи с этим актуальной становится стандартизация платежных поручений, удовлетворяющих типовым требованиям STP, как отдельной категории сообщений, пусть и с ограниченными возможностями, но обеспечивающими эффективную обработку большинства стандартных переводов.
В качестве примера стандарта платежного поручения, предназначенного для STP, можно привести МТ103+, сокращенный вариант базового МТ103. Сокращения коснулись тех полей и кодовых слов, которые заведомо должны вызывать ручную обработку перевода. Большая часть отброшенных полей и кодов в обычной практике не используется.
Если вернуться к основным принципам STP, перечисленным выше, можно отметить, что одно лишь ограничение на указание банков с помощью только BIC уже обеспечивает выполнение немалой их части. Открытыми остаются вопросы распознаваемости BIC системами обработки и полноты цепочки платежа.
Однако возможности МТ103+ явно недостаточны для обеспечения переводов в долларах США. Во-первых, для таких переводов достаточно характерны цепочки платежа из трех или даже большего числа банков; в ряде случаев банки могут не иметь BIC; наконец, использование американских расчетных систем CHIPS и Fedwire тоже вносит свои особенности. В связи с этим задача разработки если не нового стандарта, то по крайней мере стандартных приемов оформления МТ103, обеспечивающих STP, представляется актуальной.
В первую очередь необходимо отметить основные особенности обработки платежных поручений в зарубежных банках и расчетных системах, которые так или иначе могут влиять на выбор рекомендаций. Наибольший практический интерес представляют здесь некоторые особенности работы основных американских расчетных систем, CHIPS и Fedwire; многие требования, предъявляемые банками к оформлению платежных поручений в долларах США, так или иначе вытекают из этих особенностей.
Преобразование платежных поручений в расчетных системах
Как отмечалось в начале статьи, в данном изложении предполагается использование SWIFT для пересылки платежных поручений между банками, что позволяет не рассматривать вопросы преобразования платежных поручений при их пересылке. Однако при расчетах в долларах США значительная часть переводов осуществляется с использованием американских расчетных систем, CHIPS или Fedwire, и здесь указанное предположение некорректно; при таких переводах могут возникать некоторые проблемы, связанные с необходимостью преобразования сообщений SWIFT в сообщения CHIPS или Fedwire и обратно. При расчетах в евро подобные вопросы не возникают в силу того, что значительная часть европейских расчетных систем построена на платформе SWIFT (которая, в свою очередь, является европейской разработкой, учитывающей в первую очередь европейские представления о методике расчетов).
Далее будут отмечены только те особенности форматов CHIPS и Fedwire, которые нередко приводят к заметным искажениям передаваемой информации, а иногда и к задержкам в обработке переводов на том или ином этапе.
Преобразования в CHIPS
Основными особенностями формата сообщений CHIPS, влияющими на конечный результат обработки перевода, являются:
После перехода к МТ103 американские банки стали включать в формируемые ими сообщения CHIPS информацию об указателях расходов, списанных комиссиях и изначально отправленных суммах (информацию из полей 33B, 71A и 71F получаемых ими МТ103) как текстовую информацию в поле 600 сообщений CHIPS, то есть как часть деталей платежа. Фрагмент одного такого сообщения приведен ниже:
Видно, что к деталям платежа просто добавлено содержимое полей исходного МТ103. Комиссия самого американского банка, равная 20 USD, явно не отражена, о ее существовании и величине можно лишь догадываться, исходя из имеющихся данных.
В данном случае задача определения суммы комиссии и ее источника проста, так как было известно содержание отправленного американскому корреспонденту МТ103. Сложнее обстоит дело с получаемыми из американских банков МТ103, поскольку в этих случаях, на основании только таких МТ103, не всегда можно определить точный и полный путь платежа, да и тарифы участвовавших в процессе банков обычно неизвестны. Более того, приходится учитывать, что в общем случае неизвестны ни алгоритмы переводов информации из исходных МТ103 в сообщения CHIPS американскими банками, ни алгоритмы считывания этой информации и перевода ее в конечные МТ103 участниками CHIPS, получающими эти сообщения. Некоторые примеры МТ103, полученных из американских банков, приведены в табл. 1.
Примеры сообщений МТ103, полученных из американских банков
Эти примеры демонстрируют несоответствие реальных МТ103, получаемых из американских банков, формальным правилам SWIFT: суммы указанных комиссий, даже с учетом тех, которые отражены в не предназначенных для этого полях, не всегда равны разности сумм, указанных в полях 33B и 32A. Из них, однако, можно по крайней мере догадаться, какая сумма была отправлена изначально.
Следующий пример МТ103, полученного из VTB Bank (Deutschland) AG, показывает, что в процессе переработки платежного поручения американскими банками информация о первоначально отправленной сумме может пропасть безвозвратно:
Указанная здесь комиссия в 10 USD является комиссией VTB Bank (Deutschland) AG, комиссия его американского корреспондента (в данном случае Citibank, NA) списывается со счета этого банка и на сумму перевода не влияет. Первоначально же отправленная сумма была равна 5000 USD, указатель расходов в исходном МТ103 был OUR. В данном случае 15 USD являлись комиссией American Express Bank Ltd., корреспондента Investbank PLC, списанной на основании соглашения типа bene deduct, но вся информация об этом в итоге пропала.
В полях платежных поручений SWIFT (MT103, MT202 и т.д.) предусмотрена возможность указания банков с помощью BIC и различных цифровых кодов одновременно. Для переводов, которые должны выполняться через CHIPS, в качестве таких идентификаторов могут использоваться номера корреспондентских счетов банков, коды участников (//CP) и UID (//CH).
Исходя из того что вероятность ошибки при вводе числового кода выше, чем при вводе BIC, обычно рекомендуется указывать банк с помощью только BIC. Однако такой подход в некоторых частных случаях вызывает проблемы.
Рассмотрим частный случай, который тем не менее демонстрирует реальное состояние нынешних систем обработки платежных поручений в ведущих мировых банках; состояние, надо отметить, несколько неожиданное.
В настоящее время многие небольшие российские банки вынуждены проводить расчеты в долларах США через свои корреспондентские счета в российских или европейских банках, поскольку открыть счет в американском банке достаточно сложно. Наиболее популярные среди них европейские банки-корреспонденты, такие как, например, VTB Bank (Deutschland) AG, имеют достаточно высокий уровень автоматизации, и априори такие расчеты не должны вызывать особых проблем, за исключением разве что относительно раннего времени отсечения и почти неизбежно возникающей ручной обработки МТ103 по переводам в пользу клиентов российских банков, поскольку в первоначальных МТ103 российский банк в большинстве случаев, при стандартных методиках форматирования, будет размещаться в поле 72.
Тем не менее на практике довольно часто отмечалось, что не только коммерческие, но и межбанковские переводы в пользу российских банков попадают на ручную доработку в европейских банках-корреспондентах.
Потеря нескольких часов иногда бывает заметной. Анализ нескольких таких случаев обнаружил неожиданное.
Переводы в адрес российских банков оформлялись в полном соответствии со стандартными рекомендациями, например:
На практике, однако, OWHBDEFF нередко получал MT202, в которых бенефициар указывался в поле 58 с опцией D вместо опции A. Несколько различных примеров таких MT202 приведены в табл. 2 (сохранены только поля 58D).
Примеры заполнения поля 58D в сообщениях MT202
Таких примеров набралось достаточно много, причем способ заполнения поля 58D явно зависел от того, через какую именно пару американских банков поступали средства в OWHBDEFF; по одному и тому же маршруту из раза в раз получался один и тот же вариант.
В результате проведенных переговоров как минимум один американский банк признал, что в его системе действительно существуют ошибки при формировании сообщения CHIPS в тех случаях, когда для BIC невозможно найти UID (т.е., проще говоря, когда указанный банк не имеет счета ни в одном из американских банков). Источник ошибки явно связан с историей развития CHIPS: видимо, система обработки создавалась во времена, когда UID был основным идентификатором; BIC, вероятно, появился в качестве допустимого позднее. У автора, к сожалению, нет возможности проследить в подробностях всю историю развития CHIPS. Имеющиеся обрывочные данные позволяют, однако, предположить, что по крайней мере в 1995 г. BIC уже был стандартизован в CHIPS в качестве допустимого идентификатора.
Решение задачи очевидно уже из вида вышеприведенных МТ202: необходимо в исходном МТ202 предоставить американским банкам информацию, которую их системы могли бы автоматически подставить в поле числового идентификатора так, чтобы в итоге был получен корректный результат, то есть явно указать номер корреспондентского счета MEZTRUMM в OWHBDEFF. И проблема действительно исчезает.
Преобразования в Fedwire
Fedwire обычно используется, если перевод направляется в пользу клиента американского банка. Такие переводы относятся к простейшим, и проблемам здесь возникать просто неоткуда. Переводы за пределы США с помощью Fedwire выполняются крайне редко, хотя время от времени встречаются рекомендации использовать именно Fedwire для выполнения крупных межбанковских переводов.
Здесь следует отметить, что механизм разделения переводов в Fedwire на коммерческие и межбанковские не совсем ясен. С одной стороны, в сообщениях Fedwire предусмотрено поле 3600 (Business Function), в котором можно явно указать код перевода, который может принимать в числе прочих значения CTR (коммерческий перевод) или BTR (межбанковский перевод). С другой стороны, есть поле 1510 (Type Code, Subtype Code), в котором Type Code может принимать значения 10 (перевод, отправитель и получатель которого могут быть третьими сторонами), 15 (так называемый Foreign Transfer, перевод от или в пользу зарубежных центральных банков и других международных учреждений, счета которых находятся в ФРБ Нью-Йорка) или 16 (так называемый Settlement Transfer, перевод, отправитель и получатель которого либо (1) депозитарный институт, являющийся субъектом требований к резервам, либо (2) участник соглашения об урегулировании требований, который признается ФРС). При этом согласно Fedwire Reference Card значение BTR может относиться только к переводам, тип которых 15 или 16. Из приведенных здесь описаний видно, что межбанковские переводы российских банков друг другу или зарубежным контрагентам в огромном большинстве случаев должны иметь тип 10 и, следовательно, код CTR, то есть обозначаться в Fedwire как коммерческие переводы.
Мт103 что это такое
Если Вы работаете в системе от имени пользователя, который входит в более чем одну из числа зарегистрированных в системе организаций, и при входе в систему не выбрали одну из организаций – система предложит указать организацию, от имени которой создается документ:
Ряд полей окна уже будет заполнен системой. Поля с белым фоном заполняются или редактируются вручную. Поля с серым фоном заполняются либо пользователем путем выбора значений из списка, либо системой автоматически (в частности, после заполнения связанных полей).
Введите или отредактируйте значения реквизитов:
В поле Референс при необходимости измените номер документа. По умолчанию система нумерует документы по порядку создания в течение календарного года.
В поле Дата при необходимости измените дату документа. По умолчанию поле заполняется текущей датой.
В поле Дата и время отправки введите дату и время отправки.
Данное поле отображается только при определенных настройках на стороне банка.
В поле Дата и время получения введите дату и время получения.
Данное поле отображается только при определенных настройках на стороне банка.
Поле Тип будет заполнено типом сообщения автоматически и не подлежит редактированию.
Данное поле отображается только при определенных настройках на стороне банка.
Поле I/O будет заполнено направлением сообщения автоматически и не подлежит редактированию.
Данное поле отображается только при определенных настройках на стороне банка.
Данное поле отображается только при определенных настройках на стороне банка.
Поле Отправитель заполняется автоматически реквизитами банка-респондента.
Если в справочнике ответственных лиц организации присутствует только одна запись, относящаяся к текущей организации, и политика банка предусматривает автоматическое заполнение информации об ответственном исполнителе, данная группа полей будет заполнена автоматически.
В поле Дата валютирования укажите желаемую дату валютирования (не ранее текущей даты).
В поле Код валюты укажите цифровой код валюты расчета вручную или из справочника валют.
В поле Сумма межбанковского расчета укажите сумму расчета.
В блоке 33В: Валюта / Сумма расчетного документа укажите валюту и сумму расчетного документа.
В поле Курс конвертации при необходимости укажите курс конвертации валют.
В блоке 59: Бенефициар введите значения реквизитов получателя:
В поле Счет № введите номер счета бенефициара.
В поле Наименование и адрес введите наименование организации бенефициара и адрес, по которому он зарегистрирован.
В блоке 52A: Банк плательщика при необходимости укажите реквизиты банка плательщика.
Данное поле отображается только при определенных настройках на стороне банка.
В поле Идентификация стороны укажите идентификацию стороны банка-посредника.
В поле Идентификация стороны укажите идентификацию стороны банка-посредника.
В поле Идентификация стороны укажите идентификацию стороны банка бенефициара.
Заполните информацию о платеже, о кодах операций и инструкций, о деталях расходов отправителя и получателя:
Поле 23B: Коды банковской операции будет заполнено автоматически и не подлежит редактированию.
В блоке 23Е: Коды инструкций при необходимости добавьте коды инструкций, определяющие информацию о платеже, о способе извещения или оплаты. В поле может указываться несколько кодов инструкции в порядке, указанном в справочнике кодов инструкций поля 23Е, в этом же справочнике определены коды, которые нельзя указывать одновременно. Инструкции могут быть выполнены, только если банк, для которого они предназначены, работает с указанными кодами инструкций, при этом за исполнение инструкций банки взимают дополнительную плату.
При переводе в украинских гривнах (UAH) поле 23Е не заполняется.
В таблице блока 23Е: Коды инструкций появится новая запись.
Добавьте необходимое количество кодов.
В поле Код типа операции введите код типа операции – 3 символа: допускаются латинские заглавные буквы и цифры.
В поле 70: Информация о платеже укажите либо информацию об этой операции, либо ссылку на другое сообщение, содержащее сведения, которые должны быть переданы клиенту-бенефициару.
В блоке 71А: Детали расходов укажите вручную или выберите из справочника типов комиссий за перевод код деталей расходов.Выбор значения определяет, какая из сторон будет нести расходы по операции.
В блоке 71F: Расходы отправителя укажите валюту и сумму расходов отправителя.
В блоке 71G: Расходы получателя укажите валюту и сумму расходов получателя.
При необходимости может быть заполнено поле 72: Информация отправителя получателю в свободном формате.
В поле 77В: Обязательная отчетность при необходимости может быть указан код (коды) информации для государственных и/или контролирующих органов, которая требуется властями в стране Получателя или Отправителя. Заполняется в свободном формате.
Сохраните внесенные изменения:
Система проверит корректность заполнения полей, после чего:
При отсутствии ошибок и замечаний:
Чтобы вернуться к редактированию и внести необходимые исправления:
Произойдет возврат к окну документа.
Чтобы сохранить документ с текущими значениями реквизитов (при отсутствии блокирующих ошибок):
В зависимости от выбранного варианта сохранения:
Если был выбран вариант «сохранить и закрыть», произойдет возврат к списку документов в рабочей области. Сформированный документ появится в списке со статусом «Создан» (при наличии только предупреждений) или «Ошибка контроля» (при наличии хотя бы одной ошибки).
Если был выбран вариант «потоковый ввод», окно экранной формы ЭД будет очищено и подготовлено к созданию аналогичного документа с нуля. Сформированный документ можно будет в дальнейшем найти в списке валютных переводов со статусом «Создан» (при наличии только предупреждений) или «Ошибка контроля» (при наличии хотя бы одной ошибки).
Завершите создание ЭД:
Если проверка обнаруживает ошибки, исправьте их и вернитесь к сохранению документа или сохраните ЭД с ошибками в статусе «Ошибка контроля», чтобы отредактировать его позже (см. инстр. «Редактирование документов» ).
Если ошибки не обнаруживаются, система предложит подписать и, если Ваших полномочий подписи достаточно для полного подписания данного документа, отправить ЭД в банк.
Подпишите и, если необходимо, отправьте ЭД в соответствии с инстр. «Подпись одного или нескольких документов» ).
Документ будет сохранён и отобразится в форме списка документов данного типа со статусом, соответствующим выполненному варианту завершения создания ЭД.
В результате выполнения указанных действий ЭД будет создан и сохранен. В зависимости от Вашего выбора при создании документа, он может быть также подписан и отправлен в банк.