Статьи

Передача файлов по средствам ASN.1

Поскольку мы знаем, что любой файл состоит из массива байт, то для передачи по средствам ASN.1 нам надо знать: блок, длину блока, имя файла и можно создавать свой peer-to-peer. Мы можем ставить в очередь и передавать неограниченное число блоков данных, которые можно собирать в конкретные файлы. Хоть миллион файлов будет передаваться параллельно по блокам, как это делается в torrent клиентах.

Приводим пример, задаем произвольный файл, первый блок, длину блока данных.

Нам не важен язык написания, хоть Java, хоть C#. Абстрактный пример будет на Java.

Задаем глобальную переменную – размер блока передачи

static int blocksize = 0x3E80;

Задаем первый блок для передачи

int block = 0x01;

Задаем дескриптор файла

String filePath = «C:/Downloads/11.jpg»;

System.out.print(String.format(«block = %d \r\n», block));

System.out.print(String.format(«blocksize = %d bytes \r\n», blocksize));

Переходим к реализации функции получения блока данных

byte[] hex = GetBlock(filePath,block);

private static byte[] GetBlock(String filePath, int block) throws IOException {

//Используем произвольный доступ к файлу в режиме read

RandomAccessFile file = new RandomAccessFile(filePath, «r»);

//Получаем смещение согласно номеру блока

file.seek(GetSeek(block));

byte[] bytes = new byte[blocksize];

//Согласно смещению считываем 16 кб данных

file.read(bytes);

file.close();

return bytes;

}

//Вспомогательная функция смещения

private static long GetSeek(int block)

{

if (block == 1) {return 0;}

else {return ((block-1)*blocksize); }

}

//Самое важное еще предусмотреть, что длина файла может быть меньше 16 кб или последний блок может быть меньше 16 кб

System.out.print(String.format(«hex = %s \r\n»,GetHex(hex)));

Для контроля выводим в Hex режиме

GetHex(hex);

//Создаем stringbuilder и собираем строчку

private static String GetHex(byte[] bytes)

{

StringBuilder sb = new StringBuilder();

for (byte b : bytes) {

sb.append(String.format(«%02x», b));

}

return sb.toString();

}

Собираем произвольную TLV структуру

CreateTLV(block,filePath, hex);

private static void CreateTLV(int block, String fd, byte[] hex) {

StringBuilder TLV = new StringBuilder();

//Fd name

TLV.append(0x03);

//Fd name

TLV.append(0x03);

java.io.File file = new java.io.File(fd);

long f = file.length();

TLV.append(GetLen(f));

TLV.append(f);

//Integer block

TLV.append(0x02);

String str = Integer.toString(block);

TLV.append(GetLen(str.length()));

TLV.append(block);

//Block info

TLV.append(«03»);

TLV.append(GetLen(hex.length));

TLV.append(GetHex(hex));

//System.out.print(String.format(«TLV structure = %s \n», TLV.toString()));

System.out.print(«Bytes [] = » + TLV.toString());

}

Напишем дополнительную функцию по переводу dec в hex по определению TLV структуры

private static String GetLen(int length) {

StringBuilder str = new StringBuilder();

if (length< 0x80) str.append(Integer.toHexString(length));

if ((length> 0x80) && (length< 0x100))

{

str.append(81);

str.append(Integer.toHexString(length));

return str.toString();

}

if (length> 0x100)

{

str.append(82);

str.append(Integer.toHexString(length));

}

System.out.print(String.format(«GetLen= %s \n», str.toString()));

return str.toString();

}

Получаем результат

block = 1

blocksize = 16000 bytes

hex = ffd8ffe00010 ……..16 кб данных

Размер файла

GetLen= 8220964

Блок

GetLen= 1

Размер блока = 3e80 = 16 кб

GetLen= 823e80

3

82 2096

4433a2f446f776e6c6f6164732f31312e6a706721103823e80ffd8ffe000104a46494600010101004800480000ffe20240

2 1

1

3 82 3E80

16 кб первого блока

Тоже самое проделываем со вторым блоком и всеми остальными. По итогу передаем массив байт через сокет, раскладываем на TLV структуру и собираем файлы.

Криптография. Создание сигнатуры

Одной из массовых систем для шифрования, для цифровой подписи является система RSA. Как уже было рассмотрено, в данной системе есть этап генерации ключей, передачи, шифрование и расшифровка. Если мы говорим про передачу отдельных параметров по средствам сети, то важно эти данные защищать, накладывать подписи, в противном случае есть риск компрометации данных/компрометации параметров ключей.
На практике часто используется SHA256RSA, SHA1RSA, ГОСТ серии 34.10 (где-то в государственных предприятиях)
SHA256 with RSA — это эффективный асимметричный метод шифрования. Этот алгоритм сначала вычисляет уникальный хэш исходных данных с помощью алгоритма SHA256. Хэш затем шифруется с помощью частного ключа с использованием алгоритма RSA
SHA1 with RSA — это эффективный асимметричный метод шифрования. Этот алгоритм сначала вычисляет уникальный хэш исходных данных с помощью алгоритма SHA1. Хэш затем шифруется с помощью частного ключа с использованием алгоритма RSA
Погружаем дальше
Алгоритм SHA-1 (англ. Secure Hash Algorithm 1-bit) – это безопасный алгоритм хеширования, применяющийся для шифрования, размер выходных данных при этом составляет 160 бит. С помощью алгоритмов хеширования создаются уникальные хеши с необратимым кодированием.
Алгоритм SHA-256 (англ. Secure Hash Algorithm 256-bit) – это безопасный алгоритм хеширования, применяющийся для шифрования, размер выходных данных при этом составляет 256 бит. С помощью алгоритмов хеширования создаются уникальные хеши с необратимым кодированием.
На языке C# используем пространство System.Security.Cryptography класс RSACryptoServiceProvider.
Для упрощения работы используем библиотечные функции импортирования ключей и вычисления сигнатуры, проверки сигнатуры.
Для подписания данных:
Первое, задаем входные данные, для которых определяем хеш значение, второе, определяем halg = Хэш-алгоритм, который следует использовать для создания хэш-значения, опционально смещение и количество байт.
Для подписания хэш алгоритма:
Первое, хеш значение подписываемых данных, второе, идентификатор хэш-алгоритма (OID), используемый для создания хэш-значения данных.
В результате получаем подпись System.Security.Cryptography.RSA для указанных данных. Размер подписи будет равен 256 байт.
Производим обратную процедуру – верификация подписи.
1. Получаем хэш значение входных данных (или хэш значение файла)
2. Указываем идентификатор хэш-алгоритма (OID), используемый для создания хэш-значения данных.
3. Данные подписи, которые требуется поверить.
На выходе получаем положительный или отрицательный результат

Рассмотрим сертификаты электронной подписи через призму стандарта ASN.1

Любой сертификат цифровой подписи или любой документ представляет собой данные в виде байт, массива байт. Нам необходимо знать хэш алгоритм, необходимо знать издателя сертификата, публичный /закрытый ключ, цепочку сертификатов, срок действия и тд. Сертификаты определяются по стандарту X.509, в системе хранятся в виде массива байт по стандарту ASN.1, что соответствует TLV структуре.
У каждого сертификата есть один из важных параметров : OID, Object identifier. Например, OID хеш алгоритма Sha256 в человеческом виде будет (1.2.840.113549.2.9), в Hex формате 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x09.
Возьмем публичный ключ, декодируем его из base 64 в byte массив, размер массива будет равен 162 байта. Пример:
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00 30 81 89 02 81 81 00 C2 AC 3D E3 D3 43 2C 88 4D 0C 7C 4C 3D AC 14 95 20 A6 45 11 B6 D3 BC 90….
Как мы уже знаем, 30 — секвенция, значит это не примитивный тип, после размера будет хранится ссылка на следующий блок информации. 81 размер, но ссылка, что следующий блок больше 0x80, но меньше 0х100. в 10 виде это 159 меньше чем 256. Проваливаемся дальше. Нам важно найти 0х06 идентификатор с OID. Кажется мы его нашли 06 09 2A 86 48 86 F7 0D 01 01 01. Это алгоритм 1 2 840 113549 1 1 11 т е sha256WithRSAEncryption. Дальше ищем RSA параметры с тегом 0х02 или 0x03 (бит стринг или целочисленное значение). d — частная экспонтента, dp, dq, exponent, modulus, inverseq, p, q. Экспортируем это все в структуру параметров. В публичном ключе нам важны два параметра modulus и exponent. В закрытом ключе нужны все параметры (поскольку это контейнер с ссылкой на все выпущенные публичные сертификаты). А дальше работаем на уровне Cryptoapi или на уровне CLI С#, JRM.

TLV и протокол ASN.1

TLV — схема кодирования для использования информационных элементов, сокращённо Tag-length-value.
ASN.1 — абстрактная синтаксическая нотация, в том числе международный телекоммуникационный стандарт.

1) Tag Первые два бита кодируют класс текущего блока, это может быть sequence, например, и другие типы, следующий бит равен 0x00, если у нас простые данные, но 0x01, если внутри значения блока содержится дополнительные блоки ASN.1. Остальные биты содержат тип данных, например integer, bit_string, bool, Null и другие.
Если идентификатор типа содержит значение выше 31, то в последних битах будут все 0х01 (по определению их 5 битов).
2. Length. Если длина информационного сообщения меньше 0x80, то размер кодируется одним байтом, если сообщение x>0x80 и >0x100, то к размеру добавляется идентификатор 81. Если сообщение больше 0x100, то длина будет 82. Если длина блока равна 201, то значение в 16 ричное системе будет
81C9, что соответствует 1000 0001, 1100 1001. Важно что общая длина сообщения не может выйти за объем =65535 в 10 степени. Вообще рекомендуется передавать небольшие блоки данных, блок данных 16 /32 Кб отправится быстрее, чем блок 64 КБ. Важно помнить, что на уровне сети и сетевого соединения находится много сетевых устройств, возможно задержка. Tcp протокол запрашивает подтверждение. да и блок 32 КБ делится предположим по 4 Кб, получается 8 блоков
3)Value. Тут тоже все не так просто. Текст переводится в массив byte. Числа в зависимости от набора процессорных инструкций декодируются как big endian и little endian. Т е имеет значение порядок байтов в памяти компьютера. 4-байтное целое число 0x01020304 будет сохранено в памяти системы big endian следующим образом: 0x01 0x02 0x03 0x04, в системе little endian обратный порядок 0x04 0x03 0x02 0x01. Важна не запись, а учёт формата хранения данных в памяти для обмена с другими системами.

Можно ли заработать на акциях?

Решил написать свой первый пост про акции и инвестиции. Год назад (в мае 2020 года) начал проявлять интерес к инвестициям в акции, тогда еще у меня была небольшая зарплата, поэтому решил купить акции Газпрома на 72 тысячи, в итоге продал пакет за 73 тысячи и заработал свою первую тысячу рублей.

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

Акции покупаю в приложении ВТБ инвестиции, соответственно когда у меня оборот составил 8 млн рублей,то я подал заявку на квалифицированного инвестора.

Мой портфель на 15 июня выглядел так, с учетом того, что первая покупка в 2021 году была 1 июня (пересобрал портфель), можно так сказать краткосрочный портфель для проверки своих теорий и экспериментов

Больше всего прибавила Алроса, Газпром и Фосагро, — в целом все акции прибавили.

Утвержденные дивиденды по акциям на ближайшие два месяца у меня составляют 38 тысяч рублей, на самом деле можно и больше, но аккуратно

Выплаченные дивиденды за май составили 12 тысяч рублей

15 июня пришлось продать акции Алроса, так как они портфеле давали всего +20000 (вместо +40000 неделей раньше). Достаточно рискованный актив был в моем портфеле.

17 июня акции компании Алроса упали до 131,9, т.е. потеряли свой рост за предыдущую неделю. Тоже самое произошло и с акциями других российских и зарубежных компаний.

Первая статья создана, писать ли новые-развернутые статьи или рассказывать о своих финансовых результатах?

Заработать на акциях возможно, но осторожно, не советую покупать иностранные активы, так как динамика их роста и падения непонятная и рискованна.

Поиск последовательных шаблонов (Sequential Pattern Mining) и построение ассоциативных правил в проекте Apache Spark

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

Для поиска подобных ассоциативных правил необходимо сначала находить последовательные шаблоны (Sequential Pattern Mining) – цепочки купленных товаров или запрошенных файлов, и затем исследуя их строить устойчивые ассоциации.

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

Одним из наиболее эффективных алгоритмов поиска ассоциативных правил является алгоритм FP-growth (https://basegroup.ru/community/articles/fpg). Его название можно перевести как «выращивание популярных (часто встречающихся) предметных наборов». Этот алгоритм позволяет не только избежать затратной процедуры генерации кандидатов, но и уменьшить необходимое число проходов по базе данных предметных наборов до двух.

В основе метода лежит предобработка базы транзакций, путем преобразования ее в компактную древовидную структуру, называемую Frequent-Pattern Tree – дерево популярных предметных наборов (откуда и название алгоритма). В дальнейшем для краткости будем называть эту структуру FP-дерево. К основным преимуществам данного метода относятся:

  1. Сжатие БД транзакций в компактную структуру, что обеспечивает очень эффективное и полное извлечение частых предметных наборов;
  2. При построении FP-дерева используется технология разделения и захвата (divide & conquer), которая позволяет выполнить декомпозицию одной сложной задачи на множество более простых;
  3. Позволяет избежать затратной процедуры генерации кандидатов, характерной, например, для алгоритма «a priori».

Идея алгоритма PrefixSpan

(http://ijaiem.org/Volume2Issue2/IJAIEM-2013-02-20-024.pdf)

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

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

Работа с алгоритмами FPgrowth и PrefixSpan

Действия:

А) Скачиваем предоставленные тестовые файлы с указанного диска.

Немного о выборках:

Имеем шесть выборок с разными параметрами (см. рис. 4.2):

— среднее число транзакций (T) для неоднородных баз или точное число транзакций для однородных баз (С) в клиентских последовательностях,

— среднее число предметов в транзакциях (I),

— количество клиентских последовательностей (D).

Копируем файлы с выборками в hadoop. Делаем так же, как уже делали в лабораторной работе № 2 (пункт 2.2.-> Создание таблиц):

hadoop fs -copyFromLocal /home/cloudera/Desktop/название_документа_с_выборкой /user/cloudera/

получаем:

Рис. 4.3. Результат копирования файлов с выборками.

Б) Тестируем алгоритм FP-growth

Запускаем Apache Spark командой spark–shell (в разных версиях Spark разные команды, ещё одна из них: spark2–shell) в терминале системы и ждём пока появится строка scala> (в нижней части экрана на рис. 4.4)

Рис. 4.4. Результат запуска Spark.

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

import org.apache.spark.mllib.fpm.FPGrowth

import org.apache.spark.rdd.RDD //импортируем библиотеки

val data =

sc.textFile(«/user/cloudera/название_документа_с_выборкой «)//загружаем датасеты

val transactions: RDD[Array[String]] = data.map(s => s.trim.split(‘ ‘))/ /преобразовываем датасеты в нужный формат

val fpg = new FPGrowth()//заводим переменную, отвечающую за работу алгоритма

  .setMinSupport(0.2) //Изменяемое значение параметра MinSupp

  .setNumPartitions(10) FP-growth где указываем MinSupp и NumPartitions

val model = fpg.run(transactions)//запускаем алгоритм FP-growh с указанными выше параметрами

model.freqItemsets.collect().foreach { itemset =>

  println(itemset.items.mkString(«[«, «,», «]») + «, » + itemset.freq)

}

//Печатаем найденные последовательности

val minConfidence = 0.8 //задаём MinConf

model.generateAssociationRules(minConfidence).collect().foreach { rule =>

  println(

    rule.antecedent.mkString(«[«, «,», «]»)

      + » => » + rule.consequent .mkString(«[«, «,», «]»)

      + «, » + rule.confidence)

}//Для полученных последовательностей ищем ассоциативные правила и выводим их.

Так же можно создать файл. В него скопировать текст программы и запустить его командой (лучший вариант запуска, так как в дальнейшем нужно будет редактировать код)

:load /home/cloudera/Desktop/название_файла_с_программой

Код этой программы без комментариев, чтобы просто “копипастнуть”.

import org.apache.spark.mllib.fpm.FPGrowth

import org.apache.spark.rdd.RDD

val data = sc.textFile(«/user/cloudera/c10d1k «)

val transactions: RDD[Array[String]] = data.map(s => s.trim.split(‘ ‘))

val fpg = new FPGrowth().setMinSupport(0.05)

val model = fpg.run(transactions)

model.freqItemsets.collect().foreach { itemset =>

  println(itemset.items.mkString(«[«, «,», «]») + «, » + itemset.freq)

}

val minConfidence = 0.5

model.generateAssociationRules(minConfidence).collect().foreach { rule =>

  println(

    rule.antecedent.mkString(«[«, «,», «]»)

      + » => » + rule.consequent .mkString(«[«, «,», «]»)

      + «, » + rule.confidence)

}

В результате выполнения получаем (рис. 4.5).

Оцениваем результат. Создаём файл на рабочем столе, куда копируем результаты выполнения программы. Аналогично делаем для разных выборок, измеряя время работы программы с помощью функции: System.currentTimeMillis()). Для этого в самое начало выполнения программы пишем команду:

val t0 = System.currentTimeMillis()
и получаем время, которое было на момент запуска программы. Далее в конце программы (до вывода результатов) выполняем команду:  println(System.currentTimeMillis() – t0).  Результаты заносим в заранее созданную для этого Excel–таблицу (рис. 4.6).
 Рис. 4.5. Результат запуска программы с алгоритмом FPGrowth.


Рис. 4.6. Время работы алгоритма FPGrowth. 
Если еще осталось время, можно, изменяя минимальные поддержку (MinSupp) и достоверность (MinConf), получить результаты для разных случаев.
 

В) Тестируем алгоритм PrefixSpan

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

import org.apache.spark.mllib.fpm.PrefixSpan //импортируем библиотеки
 
val sequences = sc.parallelize(Seq(
  Array(Array(1, 2), Array(3)),
  Array(Array(1), Array(3, 2), Array(1, 2)),
  Array(Array(1, 2), Array(5)),
  Array(Array(6))
), 2).cache() //задаём последовательности
val prefixSpan = new PrefixSpan()
  .setMinSupport(0.5) //Изменяемое значение параметра MinSupp
  .setMaxPatternLength(5) 

//заводим переменную, отвечающую за работу алгоритма PrefixSpan, где указываем MinSupp и MaxPatternLength

val model = prefixSpan.run(sequences) )//запускаем алгоритм PrefixSpan с указанными выше параметрами

model.freqSequences.collect().foreach { freqSequence =>
  println(
    freqSequence.sequence.map(_.mkString("[", ", ", "]")).mkString("[", ", ", "]") +
      ", " + freqSequence.freq)

}//Печатаем найденные последовательности

Выборки приходится вставлять непосредственно в код (3-я строчка) после команды:   val sequences = sc.parallelize (Seq(.

Чтобы не работать руками, пишем на любом языке программирования парсер для стандартных форматов. Если есть трудности с написанием, то пишем этот парсер в любом текстовом редакторе, например, NotePad++.

Можно распарсить выборку и самостоятельно Формат входных данных для алгоритма  JavaRDD<List<List<Integer>>>

Пример. Есть выборка:

1 2 3

4 5 6

7 8 9

Открываем файл с выборкой в Notepad++. Открываем замену символов. Заменяем пробелы на запятые. Заменяем начало строки на — Array(Array(. Конец строки заменяем на — )), Копируем полученное в код программы и запускаем.

Результаты так же заносим в excel-таблицу и файл.

Здесь можно также изменять минимальную поддержку (MinSupp).

4.3. Сравнение алгоритмов

Сравниваем время работы алгоритмов на одних и тех же выборках. Находим отличия.

Статья «Business Studio 5. What`s new?»

12 октября 2020 — официальный старт продаж новой версии системы бизнес-моделирования Business Studio 5. Среди ключевых нововведений – возможность управления жизненным циклом модели и поддержка мультиязычности. Об этих и других нововведениях читайте в статье «Business Studio 5. What’s New?»

Для более подробного ознакомления с возможностями системы Business Studio 5 мы приглашаем Вас на официальную презентацию новой версии, которая пройдет 8 и 9 октября 2020 в формате онлайн.

НОТАЦИИ ДЛЯ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

В настоящий момент существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Нотация управления бизнес-процессами (BPMN), нотация исполняемый язык бизнес-процессов (BPEL), расширенная цепочка событийных событий (eEPC), методология функционального моделирования (IDF0, IDF3). У каждой из данной нотации есть свои преимущества для тех или иных целей, и преимущества использования конкретного программного продукта для описания бизнес-процессов в соответствующих нотациях.

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

  • использование контекстной диаграммы;
  • поддержка декомпозиции;
  • доминирование;
  • выделение 4 типов стрелок (вход, выход, механизм, управление).

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

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

Для декомпозиции верхнеуровневых бизнес-процессов используется нотация IDF3.

Нотация IDEF3 — важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). В течение длительного
времени IDEF3 широко использовалась для создания моделей бизнес-процессов организации на нижнем уровне — при описании работ, выполняемых в подразделениях и на рабочих местах. Данная нотация являлась прототипом для создания нотации Aris eEPC.

Моделирование в нотациях IDF0, IDF3 приобрело популярность в программном продукте Erwin Business Process. Сейчас в данных нотациях можно моделировать в программном продукте Business studio, который создан в России. Программные продукты Erwin и Business studio являются дорогостоящими платными решениями (с 30 дневным бесплатным режимом). Нотация не служит для исполнения бизнес-процессов, а служит только для их анализа.

Нотация ARIS eEPC– расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

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

Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, графики Ганта в системе MS Project.

Данная нотация используется в программном продукте – Aris Express (бесплатная версия), Aris Toolset (платная версия), Business studio (платная версия).  Нотация не служит для исполнения бизнес-процессов, служит только для анализа бизнес-процессов.

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

Распространение BPMN поможет унифицировать способы представления базовых концепций бизнес-процессов (например, открытые и частные бизнес-процессы), а также более сложные концепции (например, обработка исключительных ситуаций, компенсация транзакций). Схемы в нотаци BPMN возможно трансформировать в нотацию BPEL.

Нотация используется как в бесплатных решениях (Bonita BPM, Bizagi и др), так и в платных решениях (Pega BPM, IBM BPM, Elma BPM и др.). Нотация может служить для моделирование исполняемых бизнес-процессов и не исполняемых.

BPEL (англ. Business Process Execution Language) — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.

В общем виде конфигурация BPEL-проекта выглядит следующим образом:

  • BPEL-визуальный редактор;
  • Сервер управления бизнес-процессами.

Основные файлы BPEL-проекта:

  • .bpel — логический синтез и координация веб-служб. Фактически алгоритм исполнения бизнес-процесса. (его графическое представление напоминает блок-схему и диаграмму потоков данных в одном лице).
  • .wsdl — описание интерфейсов для обмена сообщениями. «Как достичь веб-службы» (WSDL).
  • .xsd — описание структур данных проекта (XML Schema).

Пример описания бизнес-процесса представлен ниже:

<process name=»mathProcess» targetNamespace=»http://example.com/ws-bp/math»

 xmlns=»http://docs.oasis-open.org/wsbpel/2.0/process/executable»

 xmlns:math=»http://manufacturing.org/wsdl/math»>

    <partnerLinks>

        <partnerLink name=»Math» partnerLinkType=»math:exampleMath» myRole=»mathService» />

    </partnerLinks>

    <variables>

        <variable name=»numIn»   messageType=»math:unsignedInt»/>

        <variable name=»numOut»  messageType=»math:unsignedInt»/>

        <variable name=»num»     type=»xsd:unsignedInt»/>

    </variables>

    <sequence>

        <receive partnerLink=»Math» portType=»math:mathPort» operation=»secondDegree» variable=»numIn» createInstance=»yes»/>

        <assign name=»LoopCounterIncrement»>

          <copy>

             <from>$numIn.request</from>

             <to variable=»num»/>

          </copy>

          <copy>

             <from>$num * $num</from>

             <to variable=»numOut» part=»response»/>

          </copy>

        </assign>

        <reply operation=»secondDegree» partnerLink=»Math» portType=»math:mathPort» variable=»numOut»/>

    </sequence>

 </process>

Язык BPML дополняет язык реализации бизнес-процессов (Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web-сервиса. BPML преобразует («мэппирует») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.
Стандартные операции: 
  • Action: выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями.
  • Assign: присваивает новое значение показателю.
  • Call: запускает процесс и ждет его завершения.
  • Compensate: инициирует компенсацию для указанных процессов.
  • Delay: выражает промежуток времени.
  • Empty: ничего не делает.
  • Fault: выдает сообщение об ошибке в текущем контексте.
  • Raise: активизирует сигнал.
  • Spawn: запускает процесс без ожидания его завершения.
  • Synch: синхронизирует по сигналу.

В основном, язык BPEL используется в программном продукте Bizagi, Pega BPM, IBM BPM, JBPM. Нотация исключительно служит для исполнения бизнес-процессов.

После проведенного анализа нотаций для моделирования бизнес-процессов можно выделить следующие особенности:

  1. Программные продукты, где используются рассмотренные нотации, кроме BPMN, являются платными. Стоимость может доходить до нескольких тысяч долларов.
  2. Нотация IDF0 используется для описания верхнеуровневых бизнес-процессов, нотация IDF3 и eEPC служит для описания потока работы. Нотации используются в Erwin Business modeler и Aris. Данные нотации идеально читаются и подходят для анализа системы, бизнес-процессов.
  3. Нотация BPMN используется в нескольких профессиональных BPM системах и служит для моделирования исполняемых и не исполняемых бизнес-процессов. Чтение нотации для обычных работников затруднительно.
  4. Нотация BPEL используется программистами, чтение обычными пользователями затруднительно.

Разработка и исполнение бизнес-процессов в Bizagi BPM

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

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

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

Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0, или декомпозиция IDF0 до уровня потока работ (EEPC). А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.

У нас будут смоделированы неисполняемые бизнес-процессы (бизнес-процесс разработка программного обеспечения с техническим заданием, второй — доработка программного обеспечения без технического задания, третий — заведение технического требования, и четвертый — заведение требования на документацию программного обеспечения), произведен функционально-стоимостной анализ, затем они будут доработаны до исполняемых бизнес-процессов (будут добавлены графические формы, модели данных, пользователи и тд) и произведена автоматизация действий.

В качестве средства BPM была выбрана – Bizagi. Она удовлетворяет нашим условиям выбора. Эта система является бесплатная, прекрасно интегрируется с различными веб сервисами, пользователи прекрасно интегрируются с Active Directory, система использует операционную систему семейства Windows, SQL базу данных и IIS веб сервис. Система проста для разработки в ней бизнес-процессов и удобна в использовании.  Нотация для моделирования будет использоваться BPMN 2.0

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

Пользователи будут делиться на 9 бизнес ролей: контрагент – внешний клиент, менеджер проекта, руководитель проекта, аналитик, тестировщик, программист; администратор, бизнес аналитик и аналитик (не будут участвовать в бизнес-процессах, но такие бизнес роли будут предусмотрены системой).  

Бизнес-процесс «Разработка программного обеспечения с техническим заданием» будет автоматизировать бизнес-процесс начиная от момента подачи заявки клиента и заканчивая приемкой. 

Процесс «Разработка программного обеспечения» осуществляется по водопадной модели жизненного цикла разработки ПО. Каскадная (водопадная) модель строго следует последовательности всех этапов разработки ПО и не предполагает возвращения с текущего этапа на предыдущий. Модель жизненного цикла будет включать следующие этапы: выработка системных требований, выработка требований к ПО, анализ, проектирование, кодирование, тестирование, эксплуатация. Разработанная схема бизнес-процесса «Разработка программного обеспечения с техническим заданием» представлена ниже

После разработки бизнес-процесса необходимо разработать модель данных.

Главная таблица «DorabotkaPO» будет иметь следующий атрибутивный состав: email, веб сайт, дата заказа, имя, мобильный телефон, номер заявки, отчество, прикрепленный документ, сообщение, статус разработки, статус тестирования, фамилия и связь с таблицей «Approval» и «Концепция». Таблица «Approval» будет иметь следующие атрибуты: визирование менеджер, визирование менеджер проекта, дата визирования менеджером, дата визирования менеджером проекта, менеджер, менеджер проекта. Таблица «Концепция»: дата заявки, дата утверждения, имя пользователя, имя утвердившего, комментарий, концепция, утверждение и связь с таблицей техническое задание. «Техническое задание» имеет следующий атрибутивный состав: стоимость аналитика, стоимость программиста, стоимость тестировщика, трудозатраты на аналитика, трудозатраты на программиста, трудозатраты на тестировщика.

После разработка модели данных необходимо разработать визуальные формы.

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

Условия:

DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to true

DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to false

DorabotkaPOTZ.Statusrazrabotki is equal to false; DorabotkaPOTZ.Statusrazrabotki is equal to true;

DorabotkaPOTZ.Statustestirovaniya is equal to true;

DorabotkaPOTZ.Statustestirovaniya is equal to false;

После определения бизнес правил определяем исполнителей задач.

У нас будут существовать следующие роли: chief manager (руководитель проекта), devOps (системный администратор), manager (менеджер), programmer (программист), stakeholder (внешнее лицо), tester (тестировщик), admon viewer (администратор).

Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей.

Определяем условия для всех функций:

Or Role==Stakeholder or Role == Admon Viewer;

Or Role==Manager or Role == Admon Viewer;

Or Role==Chief manager or Role == Admon Viewer;

Or Role==Programmer or Role == Admon Viewer;

Or Role==DevOps or Role == Admon Viewer;

Or Role==Analyst or Role == Admon Viewer;

Or Role==Tester or Role == Admon Viewer;

Бизнес-процесс «Технологическое требование» будет автоматизировать процесс начиная от подачи заявки клиента для реализации технологического требования под необходимые нужды и заканчивая выкладыванием решения в открытый доступ. В качестве технологического требования может быть: создание серверной инфраструктуры, разворачивание необходимых виртуальных машин, настройка коммутационного оборудования и другое.

«Технологическое требование» будет включать следующие этапы: инициализация заявки, производственные работы, верификация инициатором и выкладывание в открытый доступ.

Разработанная модель данных бизнес-процесса «Технологическое требование» представлена ниже

Атрибуты главной таблицы «Требование»

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

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

Условия:

Tekhnologicheskoetrebova.ready is equal to true;

Tekhnologicheskoetrebova.ready is equal to false;

Tekhnologicheskoetrebova.status_analyst is equal to true;

Tekhnologicheskoetrebova. status_analyst is equal to false;

На этапе определения «Activity Action» (Events) на кнопку «Сохранить» в графическую форму процесса «Выполнение» добавляем следующие выражения:

Currenttask –в поле «номер заявки» будет подставляться системный номер заявки;

CurrentData – в поле «дата запроса» будет добавлять системная дата;

Выражение:

<TekhnologicheskoeTrebova.Nubertrebovanie> = Me.Case.CaseNumber;:

<TekhnologicheskoeTrebova.Requestdate> = DateTime.Now; После определения бизнес правил определяем исполнителей задач.

У нас будут существовать следующие роли: programmer (программист), stakeholder (внешнее лицо), devops (системный администратор), admon viewer (администратор), analyst (аналитик).

Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей. Определяем условия для всех функций

Or Role==Stakeholder or Role == Admon Viewer;

Or Role==Manager or Role == Admon Viewer;

Or Role==Chief manager or Role == Admon Viewer;

Or Role==Programmer or Role == Admon Viewer;

Or Role==DevOps or Role == Admon Viewer;

Or Role==Analyst or Role == Admon Viewer;

Or Role==Tester or Role == Admon Viewer;

Для запуска бизнес-процессов в корпоративной сети необходимо развернуть серверную операционную систему Windows, настроить DNS сервер, установить IIS сервер, развернуть базу данных.

В качестве серверной операционной системы была выбрана Windows Server 2012 R2. В качестве сервера базы данных был выбран — SQL Server.

SQL Server является одной из наиболее популярных систем управления базами данных (СУБД) в мире. Данная СУБД подходит для самых различных проектов: от небольших приложений до больших высоконагруженных проектов. SQL Server характеризуется такими особенностями как: 1) производительность. SQL Server работает очень быстро; 2) надежность и безопасность. SQL Server предоставляет шифрование данных; 3) простота. С данной СУБД относительно легко работать и вести администрирование.

После установки СУБД устанавливаем оснастку IIS и проверяем работоспособность веб сервера.

Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP (т.е все основные протоколы). По данным компании Netcraft на июнь 2015 года, почти 22 млн сайтов обслуживаются веб-сервером IIS, что составляет 12,32 % от общего числа веб-сайтов, остальные веб-серверы используют Apache, Nginx. Производим экспорт базы данных (формат bak) на разрабатываемой машине и импортируем ее на сервер через MSSQL Server Management

Проверяем работоспособность IIS и портала BPM Bizagi

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

Проверка работоспособности бизнес-процессов

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

Международная межбанковская система передачи платёжных документов SWIFT

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

В 1968 г. был зарождён данный проект. Целью проекта было обеспечение участвующих в проекте банков и других финансовых организаций в организации защищённой сети для передачи финансовых сообщений. Система начала полноценно функционировать в начале 1970-х гг. В 1987 г. был преодолён барьер в 1 млн сообщений в день.

В качестве соучредителей выступили 248 банков из 19 стран мира, Штаб-квартира находится в Бельгии, недалеко от Брюсселя.

По состоянию на 2015 год, членами Swift сообщества являются более 11 тысяч финансовых организаций в более чем 200 стран мира, и примерно 1/11 из этих компаний являются корпорациями, например, с государственным участием или без государственного участия (Например, Apple, Microsoft, Госкорпорация «Росатом», ПАО «Ростелеком» и другие). Примерный оборот ежедневных сообщений составляет 30 миллионов, примерно в денежном эквиваленте это десятки миллиардов долларов в день.

Адресация абонентов в системе SWIFT происходит по коду Business Identifier code, присваивается в соответствии со стандартом ISO 9362.

ISO 9362 — стандарт, устанавливающий универсальный метод идентификации участников финансовых расчётов. Официальное название стандарта — «Банковское дело. Банковские телекоммуникационные сообщения. Идентификационные коды банков».

Стандарт создан на основе разработанного компанией SWIFT метода идентификации банков — членов сети SWIFT. При этом компания SWIFT закреплена в роли уполномоченного органа ISO по регистрации кодов BIC.

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

  • исключается возможность различного понимая полученного или отправленного сообщения отправителем и получателем;
  • полный контроль передачи информации, фиксация транзакций;
  • возможность генерировать автоматически отчёты о проведённых операциях;

Иногда идентификация в системе SWIFT именуется как SWIFT-BIC, SWIFT ID или SWIFT code. 

Финансовые сообщения формируются по формату SWIFT MT.

Основные дата центры SWIFT расположены в Америке и Европе. Эти центры связаны с региональными центрами, которые устанавливаются в странах, вступивших в сообщество SWIFT. Сообщение от банка отправителя поступает по открытым или закрытым каналам связи в региональный центр. Ответственность за передачу сообщения до регионального центра несёт инициатор сообщения. В региональном центре все сообщения проверяются на соответствие стандартам SWIFT MT, накапливаются, шифруются и передаются по назначению. В системе применяется многоуровневая защита информации, которая обеспечивает сохранность и конфиденциальность передаваемых данных. Используются криптографические методы, соответствующие стандартам ISO. Ежедневно SWIFT передаёт платёжные поручения суммарной оценочной стоимостью более $6 трлн. Каждый год SWIFT передаёт около 1,8 млрд сообщений о совершении платежей.

MT101 – это запрос на перевод, позволяющий осуществить электронный перевод средств с одного счета на другой. Средства переводятся со счета клиента, заказавшего перевод, на счёт банка или финансовой организации получателя.

Допускается применение следующего набора символов:

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ – ? : ( ) . , ‘ + { }
CR LF Space

  • фигурные скобки {} не могут быть использованы в сообщении, а служат только разделителем для определения различных структурных блоков SWIFT
  • Тире “-“ не должно быть первым символом любой стороки

Тэг 20 – Номер перевода:

  • Обязателен
  • Записывается как :20:
  • 16 символов

Тэг 21 – Номер, заданный отправителем:

  • Опционально
  • Записывается как :21R:
  • 16 символов

Тэг 28D – Номер сообщения/Итого сообщений:

  • Обязателен
  • Записывается как :28D:
  • 5n/5n

Тэг 50C или 50L – Инструкции:

  • Опционально
  • Записывается как :50C: или :50L:
  • Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов)

Тэг 50F или 50G, или 50H – Информация отправителя:

  • Опционально
  • Записывается как :50F: или :50G:, или :50H:
  • Зависит от типа выбранного тэга 50F, 50G, 50H:
    :50F:
    • 35 символов (номер счета)
    • 4х35 символов (имя и адрес)

:50G:

  • /34 символа (счёт)
  • BIC (8 или 11 символов)

:50H:

  • /34 символа (счёт)
  • 4х35 символов

Тэг 52A или 52C – Информация об обслуживающей счёт отправителя организации:

  • Опционально
  • Записывается как :52A: или :52C:
  • Зависит от типа выбранного тэга 52A или 52C:
    • — :52A: — BIC (8 или 11 символов)
    • — :52C: — /34 символа

Тэг 51A – Отправляющая организация:

  • Опционально
  • Записывается как :51A:
  • BIC (8 или 11 символов)

Тэг 30 – Требуемая дата исполнения

  • Обязательно
  • Записывается как :30:
  • Дата в формате ГГММДД

Тэг 25 – Авторизация:

  • Опционально
  • Записывается как :25:
  • 35 символов

Детализация транзакции:

Тэг 21 – Номер транзакции:

  • Обязательно
  • Записывается как :21:
  • 16 символов

Тэг 21F – Номер операции конвертации:

  • Опционально
  • Записывается как :21F:
  • 16 символов

Тэг 23E – Код транзакции:

  • Опционально
  • Записывается как :23E:
  • 4-х символьный код и опциональное продолжение до 30 символов:
    • можно использовать только перечисленные 4-х символьные коды: CHQB, CMSW, CMTO, CMZB, CORT, EQUI, INTC, NETS, OTHR, PHON, REPA, RTGS, URGP
    • Если требуется добавить символы после кода, то требуется вставить”/”. Например:23E:URGP/ITSGETTINGLATE

Тэг 32B – Валюта/Сумма транзакции:

  • Обязательно
  • Записывается как :32B
  • 3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму

Тэг 50C или 50L – Инструкции:

  • Опционально
  • Записывается как :50C: или :50L:
  • Зависит от типа выбранного тэга 50C (BIC) или 50L (35 символов счета)

Тэг 50F или 50G, или 50H – Информация отправителя:

  • Опционально
  • Записывается как :50F: или :50G:, или :50H:
  • Зависит от типа выбранного тэга 50F, 50G, 50H:
    :50F:
    • 35 символов (номер счета)
    • 4х35 символов (имя и адрес)

:50G:

  • /34 символа (счёт)
  • BIC (8 или 11 символов)

:50H:

  • /34 символа (счёт)
  • 4х35 символов

Тэг 52A или 52C – Информация об организации, обслуживающей счёт отправителя:

  • Опционально
  • Записывается как :52A: или :52C:
  • Зависит от типа выбранного тэга 52A или 52C:
    • — :52A: — BIC (8 или 11 символов)
    • — :52C: — /34 символа

Тэг 56A или 56C, или 56D– Банк посредник:

  • Опционально
  • Записывается как :56A: или :56C:, или :56D:
  • Зависит от типа выбранного тэга 56A или 56C, или 56D

Тэг 57A или 57C, или 57D– Банк получателя:

  • Опционально
  • Записывается как :57A: или :57C:, или :57D:
  • Зависит от типа выбранного тэга 57A или 57C, или 57D:
    • : 57A: — BIC (8 или 11 символов)
    • : 57C: — /34 символа
    • : 57D:
      • /34 символа(счет)
      • 4х35 символов

Тэг 59 или 59A – Получатель:

  • Обязательно
  • Записывается как :59: или :59A:
  • Зависит от типа выбранного тэга 59 или 59A:
    :59:
    • /34 символа (номер счета)
    • 4х35 символов (имя, адрес)

:59A:

  • /34 символа (номер счета)
  • BIC (8 или 11 символов)

Тэг 70 – Информация о платеже:

  • Опционально
  • Записывается как :70:
  • 4х35 символов, могут быть использованы следующие коды: /INV/ , /IPI/ , /RFB/ , /ROC/ /TSU/

Тэг 77B – Данные для регулятора:

  • Опционально
  • Записывается как :77B:
  • 3х35 символов:
    • строка 1 – 8 символов Код/Страна/Текст
    • Строка 2-3 — дополнительный текст

Коды:

  • BENEFRES – Страна получателя
  • ORDERRES – Страна отправителя

Тэг 33B – Валюта/Сумма в заявлении на перевод:

  • Опционально
  • Записывается как :33B:
  • 3-х символьный код валюты (ISO 4217) и 15 цифр, определяющих сумму

Тэг 71A – Расходы по платежу:

  • Обязательно
  • Записывается как :71A:
  • 3-х символьный код, допустимо:
    • BEN – все транзакционные расходы несёт получатель
    • OUR – все транзакционные расходы несёт отправитель
    • SHA – транзакционные расходы разделяют стороны платежа

Тэг 25A – Счет, с которого списываются расходы по платежу:

  • Опционально
  • Записывается как :25A:
  • 34 символа

Тэг 36 – Курс обмена

  • Опционально
  • Записывается как :36:
  • 12 цифр

В нижеприведённом примере сообщения SWIFT MT101 указано, что сумма 123,45 EUR оплачена со счета GB12SEPA12341234123412 в банке BANKGB01XXX поставщику (Vakurin Andrey) на его счёт GB12SEPA12341234123498 в банке BANKGB02XXX. В назначении платежа указано, что оплата по инвойсу INV-0001

:20:123456789
:28D:1/1
:50H:/GB12SEPA12341234123412
ORDERING CUST NAME
ORDERING CUST ADDR LINE 1
ORDERING CUST ADDR LINE 2
ORDERING CUST ADDR LINE 3
:52A:BANKGB01XXX
:30:160211
:21:11FEB2016INV1
:23E:URGP
:32B:EUR123,45
:57A:BANKGB02XXX
:59:/GB12SEPA12341234123498
Vakurin Andrey
SUPPLIER ADDR LINE 1
SUPPLIER ADDR LINE 2
SUPPLIER ADDR LINE 3
:70:INV-0001
:77B:/BENEFRES/GB
:71A:SHA

Система SWIFT планирует постепенно переходить от формата SWIFT MT к сообщениям формата SWIFT MX, которые спроектированы по методологии ISO 20022 и содержат самые актуальные требования.