[Тестирование IT-систем, Разработка мобильных приложений, Разработка для интернета вещей, Бизнес-модели] Марк маркировал, маркировал, да и вымаркировал. Маркировка

[Тестирование IT-систем, Разработка мобильных приложений, Разработка для интернета вещей, Бизнес-модели] Марк маркировал, маркировал, да и вымаркировал. Маркировка — это ж просто!?

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
28-Авг-2020 20:36

Цитировать

В этом году вышло сразу несколько статей о практике работы с новой системой маркировки “Честный знак”. Написаны они “айтишниками” IT-отделов компаний-участников оборота, что отражает их взгляд на ход пилотного проекта и первые дни запуска боевой системы. Например, вот и вот.

Систему часто критиковали и критикуют, в основном из-за частых изменений API, багов личного кабинета и белых пятен в некоторых процессах.

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

Кратко о нас
Клеверенс занимаемся софтом для мобильных работников, в основном под специальное оборудование терминалов сбора данных (ТСД) и регистраторов выбытия (РВ).
Кому-то может показаться, что вот есть лес, в лесу дерево, на дереве жук, а на жуке живет микроб, и ниша софта для ТСД — это про микробов на жуке.
На это можно ответить, что мобильность персонала — очень крупный растущий рынок, а специальное железо с готовым софтом — это вообще будущее всего текущего железа. В конце концов, любая реально прорывная штука — это результат многих лет труда в узкой нише (см. известное интервью Андрея Дороничева про мобильный YouTube).
В основном продукты Клеверенс продаются с уже готовой интеграцией с учетными системами, которые (интеграции) мы сами же пишем и поддерживаем (например, Склад 15).
Весь софт и железо стараемся обкатывать на реальных производствах, складах, магазинах и т.д. Например, когда проект маркировки обуви только начинался поехали в Китай, чтобы обкатать бизнес-процессы, параллельно сняли видео об этом.
Что такое система маркировки и «Честный знак»
Грубо говоря, это государственно-частный интернет вещей на штрихкодах и RFID для тотального прослеживания движения единиц товаров.
По системе маркировки существует очень много информации, главным ресурсом является сайт «Честный знак».

Отношение участников рынка к маркировке
Не секрет, что отношение участников рынка к маркировке полярное. От “Россия, вперед!” и “Идея хорошая, но реализация подкачала” до “опять маленьких обижают”.
Из плюсов называется обеление рынка и контроль цепочек поставок. Из минусов — снятие с ЕНВД при торговле маркированным товаром.
Практически весь крупный бизнес за маркировку. Мелкие предприниматели, которые хотят работать красиво и в белую — тоже за маркировку, для них это конкурентное преимущество перед серыми рынками.

Против маркировки в основном малый и средний бизнес, который считает всё это лишней нагрузкой для себя.

Претензии в основном формулируются как “снова душат малый бизнес” или “у вас столько денег и людей, могли бы сразу сделать то-то и то-то”, “бизнес-процесс такой-то не продуман”. Хотя именно на малый бизнес и его процессы были потрачены основные деньги — это сайт с личным кабинетом участника, облачный регистратор эмиссии кодов и т.п.
Отдельно стоит позиция айтишников, о ней ниже.
При этом информационный портал «Честного знака», на котором публикуется информация, сделан просто отлично. Например, где найти информацию на английском языке? Вот тут. А на китайском? Вот тут.
Проблемы на старте, о которых все говорили
Пока шел пилот, в системе было много багов. В основном их успели излечить до 1 июля 2020.
Обещали, что на старте будет работать лучше ЕГАИСа, и в целом правда доступность сервиса выше.
Сейчас в табаке и обуви система всегда доступна, всё отрабатывает быстро, кроме редкого выключения на технологические работы вечером на пару часов.

Но ключевая проблема на старте была в том, что “не запрягши не поедешь”, а 99% числа участников оборота (по количеству) тупо игнорировали эту систему, не регистрировались, не давали нагрузку, ждали судного дня, а потом требовали переноса сроков.

Еще летом 2019 года мы тестировали нагрузку в нашей «Кировке» и смотрели, как маркировка отреагирует на заказ и выпуск 10 млн кодов, единоразово (сейчас уже так делать нельзя). Процесс занял меньше 10 минут.
Но тогда в системе было зарегистрировано крайне мало участников, и было видно, что народ начнет шевелиться чуть ли не в самый последний день.

Об этой проблеме все знали, к ней готовились, но когда подошел дедлайн по обуви, всё равно случился коллапс. Некоторые УОТы кинулись выписывать себе бесплатные коды на остатки на 20 лет вперед, это в пике дало увеличение нагрузки на сервера в х40 раз. Такие игрища, конечно, даром не пройдут, потому что система цифровая и, что называется, “все ходы записаны”.
К сожалению, пострадали и пионеры маркировки — это те компании, которые с первого дня были в пилоте маркировки, добросовестно старались, но в конце тоже просили о переносе сроков.
Тут надо сказать, что государственная система — это не айфончик, чтобы с первого дня продаж вызывать восторги. И цель её создания была не в том, чтобы собирать лайки от айтишников или снимать видео-обзоры по типу “вот когда выйдет, тогда и посмотрю, решу для себя, надо ли покупать”.
Почему-то люди ждут, что с первого дня система будет работать так, как будто ей уже 5 лет в продуктиве.
Вообще, если ждать по такой логике, когда всё будет идеально, то надо всё переносить на 2030й, а лучше на после покорения Марса, ага.
Позиция айтишников

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

В целом в проекте много разного железа и международных стандартов, что приносит классическим айтишникам одни только боль и страдания.
Айтишники — очень въедливые и умные люди, со своим мнением по любому вопросу. И никакого единого мнения по поводу маркировки, кроме претензий по работе API, в общем-то нет.
API системы меняется чаще, чем этого хотелось бы для сценария “сделал и забыл”. Но при этом считается, что в API надо надобавлять еще кучу методов для работы с групповыми упаковками (агрегатами), для упрощенной авторизации и т.п., но это опять означает изменение API.
Мы сами айтишники, и у нас такая же двойная позиция, что в API не хватает методов, но при этом API меняется слишком часто. Тут, как говорится, “флаг расистский, но это наша история”.

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

Технические аспекты маркировки
Технические проблемы, с которыми сталкиваются айтишники, в основном сводятся к следующему списку:

Сисадминские вопросы с УКЭП, которые были и будут до тех пор, пока есть фрагментация по версиям операционных систем и браузеров
Кодерские вопросы, которые нельзя решить путем гугления на StackOverflow, потому что система новая и уникальная, несмотря на использование открытого ПО
Внедренческие вопросы, когда люди пользуют “online barcode generator” или “сканер в разрыв клавиатуры”, а потом удивляются, почему вышла ерунда

Посмотрите, тут и Java, и Reactive (RxJava), и Spring и даже Netflix:

Чтобы составить собственное мнение можно почитать техночат в телеге.
Авторизация
Авторизация в ИС МП происходит в 2 этапа.
Сначала нужно запросить некий псевдослучайный “ключ”, который нужно подписать и отправить на урл “/api/v3/auth/cert/“ (причем на момент написания этого материала в конце url обязательно должен был стоять слэш “/“, иначе не работало, что выглядит странно).
Получение “ключа” происходит так (нужно подставить нужный хост, их много разных, в зависимости от того, песочница это или боевой, одежда или что-то другое):

// получаем на /api/v3/auth/cert/key “ключ” и данные, необходимые для авторизации
var uri1 = new Uri("<нужный хост>/api/v3/auth/cert/key")
var randomDataResponse = REST.Invoke<RandomDataResponse>(uri1, "GET", timeout);

Затем нужно подписать этот псевдослучайный “ключ” при помощи выбранного КЭП и отправить в ГИС МТ, чтобы получить в ответ авторизационный токен.
Для этого ищем сертификат КЭП по выбранному пользователем отпечатку (certificateThumb). Сертификат находится в данном случае в “Личных” локальной машины. Также контекст сертификата должен быть связан с хранилищем ключевой пары (такие сертификаты отмечены иконкой ключика в списке сертификатов в оснастке windows):

Получение сертификата в коде для формирования подписи:

X509Certificate2 cert = null;
using(store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
{
store.Open(OpenFlags.ReadOnly);
cert = from c in store.Certificates where string.Compare(c.Thumbprint, certificateThumb, true) == 0 select c;
}

Подписываем таким образом:

// данные для подписи
var content = new ContentInfo(randomDataResponse.Data);
var signedCms = new SignedCms(content, false);
// настраиваем сертификат для подлиси, добавляем дату
var signer = new CmsSigner(SubjectIdentifierType.IssuerAndSerialNumber, cert);
signer.SignedAttributes.Add(new Pkcs9SigningTime(DateTime.Now));
// формируем подпись
signedCms.ComputeSignature(signer, false);
var sign = signedCms.Encode();

Подписанное CMS-сообщение (sign) — это и есть та проверочная подпись, которую нужно отправить для авторизации, предварительно преобразовав в формат Base64.

var tokenRequest = new TokenRequest();
tokenRequest.UUID = randomDataResponse.UUID;
tokenRequest.Data = Convert.ToBase64String(sign);
// получаем токен на /api/v3/auth/cert/
var uri2 = new Uri("<нужный хост>/api/v3/auth/cert/")
var tokenResponse = REST.Invoke<TokenResponse>(uri2, "POST", tokenRequest);

В ответ приходит JWT токен, закодированный в Base64.
К слову, отправляемые документы в дальнейшем подписываются таким же образом, только формируется так называемая “открепленная” подпись:

var signedCms = new SignedCms(content, true);

Вспомогательные классы (со схемой, идентичной XSD-схемам документов из API):

/// <summary>
/// Ответ на запрос GET /api/v3/auth/cert/key для авторизации.
/// </summary>
public class RandomDataResponse
{
/// <summary>
/// уникальный идентификатор сгенерированных случайных данных, тип string
/// </summary>
[Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]
public string UUID { get; set; }
/// <summary>
/// случайная строка, тип string
/// </summary>
[Newtonsoft.Json.JsonProperty(PropertyName = "data")]
public string Data { get; set; }
}
/// <summary>
/// Данные для запроса авторизационного токена.
/// POST /api/v3/auth/cert/
/// </summary>
public class TokenRequest
{
/// <summary>
/// uuid - уникальный идентификатор подписанных данных из /api/v3/auth/cert/key
/// </summary>
[Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]
public string UUID { get; set; }
/// <summary>
/// подписанные УКЭП зарегистрированного участника случайные данные в base64
/// </summary>
[Newtonsoft.Json.JsonProperty(PropertyName = "data")]
public string Data { get; set; }
}
/// <summary>
/// Ответ на запрос авторизационного токена.
/// POST /api/v3/auth/cert/
/// </summary>
public class TokenResponse
{
/// <summary>
/// Авторизационный токен в base64-строке
/// </summary>
[Newtonsoft.Json.JsonProperty(PropertyName = "token")]
public string EncodedTokenBase64 { get; set; }
}

Если вам удалось авторизоваться — вы прошли небольшой квест.
Проблемы с генерацией и чтением штрихкодов
Система маркировки построена на международных стандартах, за исключением части с криптографией. Это отлично и достойно похвалы.
К сожалению, средний айтишник никаких стандартов не читает, ни про что не изучает, а сразу лепит свои велосипеды из бесплатных компонентов про генерацию штрихкодов, печать, бизнес-процессы и т.п.
Первая же трудность — распечатать штрихкод маркировки в своём дизайне. Из коробки “Честный знак” предоставляет бесплатный инструмент, но с ним никто, конечно, разбираться не стал, ведь есть “online barcode generator” и встроенные редакторы отчетов в 1С/SAP/NAV/DAX.
Засада в том, что современный штрихкод — это не просто графическое представление символов (об этом у нас выйдет отдельная статья). Поэтому сразу всплыли проблемы префиксов, разделителей, кодировок, обязательных непечатемых символов и прочее такое, про что никто знать не знал и разбираться не хотел.
Пример со спецсимволом GS (ASCII 29)

Пример со спецсимволом FNC1 (ASCII 232)

Скриншоты сделаны из приложения «Чекмарк».
Вот кусок исходного кода «Чекмарка», который выполняет разбор штрихкода, отсканированного камерой и разобранного нашей платформой:

Откуда взялись спецсимволы? Из стандарта. «Честный знак» сделали всё по стандарту, и участникам оборота товаров тоже надо было читать стандарт.
КСТАТИ: Проверку корректности содержимого DataMatrix можно произвести только с помощью сканирования камерой (даже если сканировать с ТСД, нужен доступ к камере). Потому что все сканеры штрихкодов в соответствии со стандартном не должны возвращать 1в1 то, что они считали, как минимум должны выбрасывать первый символ FNC1. В целом, сканеры могут добавлять или убирать важные символы штрихкода при сканировании, переставлять блоки местами, в зависимости от настроек, всё это мешает проверке.
Т.к. системная интеграция — это не про программы, а про людей и про то, как они пишут и читают спецификации, то наличие этих спец символов сразу привело к некоторому разногласию при обмене штрихкодами.
Например, могли, особо не вчитываясь в спецификации, добавлять в штрихкод строку из 4 символов “FNC1” вместо одного символа ASCII 232 (FNC1). А еще, при обмене между подсистемами такие символы часто фильтруются и теряются, до печати доходят уже без таких символов, при этом в обычных текстовых редакторах спец. символы часто не отображаются и люди удивляются, почему же что-то не так, если штрихкоды совпадают.
Так же, если не указывать символ FNC1 в штрихкоде, некоторое оборудование или ПО может не понять что это такое и как его разбирать, т.к. этот символ вначале штрихкода как раз указывает на то, что это формат GS1 DataMatrix.
Один из последних примеров, на котором споткнулись почти все, было появление скобок и знаков препинания в серийном номере.

Откуда в серийном номере скобки и знаки препинания? Из стандарта! Стандарт GS1 позволяет их использовать. Т.к. серийный номер в длину имеет всего 13 символов, а товаров под маркировку очень много, приходится использовать все доступные символы.
Отдельные лулзы — скобки в серийном номере. Они там разрешены стандартом, но никто их не ждал. В так называемой человеко-читаемой форме представления (HID) скобки имеют специальный смысл: они обрамляют номера значимых групп символов. Например, “(21)” означает, что дальше в строке будет идти серийный номер.
Если наивно думать, что в штрихкоде хранится просто строка символов, то в строке “(21)abcd12(3)d(1,(91)” серийным номером видится “abcd12”, а часть про “(1,” кажется вообще ошибкой.
На самом деле серийный номер тут “abcd12(3)d(1,”, а после запятой стоит нечитаемый символ GS. И дело не в том, что серийный номер должен быть 13 символов (потому что формально длина серийника в GS1 DataMatrix может быть другой, и в шинах, например, она бывает 20 символов). Дело именно в невидимом GS, который надо учитывать, и который в полях любой учетной системы не выводится, не принимается для ввода и вообще запрещен (и в обычном Блокноте его тоже не видно, не выводится, нужен Notepad++).
Наличие таких спец символов накладывает ограничение на передачу и хранение данных штрихкодов, их нужно экранировать или кодировать, например в Base64.
КСТАТИ: существует стандарт на хранение и передачу таких штрихкодов в виде строки (ISO/IEC 15424-2018), но почему-то им никто не пользуется. Данные штрихкода GS1 DataMatrix, хранимые в виде строки, должны начинаться на “]d2”.
Сейчас почти все исправили свои компоненты печати штрихкодов (наверное). Но кто вообще читает стандарты, правда?
На проверку, домашнее задание: вот эта тема, что если поле фиксированной длины, то GS вставлять не нужно, а если длина переменная, и значение поля не максимальной длины, то вставлять нужно. На самом деле это правило работает не так. Спецсимвол GS не вставляется только если AI начинается с пары цифр из этой вот таблицы:

А во всех остальных случаях вставляется. Ваш код генерации/разбора ШК работает так же?
Еще одна проблема — сканирование штрихкода маркировки ламерскими средствами типа “сканер в разрыв клавиатуры”. До маркировки самой большой проблемой было, что где-то обрезается или вставляется лишний ноль. Со введением новых кодов маркировки тулзы со сканированием выведены на совершенно новый уровень.
Зачастую это не проблемы самого сканера или его настроек, а проблемы с отсутствием опыта и понимаем принципов штрихкодирования.
Например, при подключении сканера «в разрыв клавиатуры» (или при эмуляции такого режима), а также при подключении сканера как HID-устройства, возможны проблемы с заменой одних символов в считанном штрихкоде на другие или пропадание определенных символов.

Схема подключения сканера в разрыв клавиатуры
При работе в указанных режимах сканер передаёт компьютеру не сами символы из штрихкода (sic!), а коды нажатий клавиш клавиатуры, которые нужно было бы нажать, чтобы набрать на клавиатуре символы из этого штрихкода.
При этом очевидно, что одной клавише клавиатуры может соответствовать сразу несколько возможных символов, в зависимости от языка раскладки и нажатий клавиш-модификаторов (Shift, Caps Lock, Alt и Ctrl).
Например, при нажатии на вот эту клавишу в нижней правой части клавиатуры:

Результатом может быть любой из символов ‘?’, ‘/’, ‘,’ или ‘.’, в зависимости от выбранной раскладки и использования клавиш-модификаторов. Какой конкретный введётся символ — определяется настройками клавиатуры операционной системы, а не сканером.
Именно из-за этого вместо одних серийников на кассе выбывают совершенно другие, либо код вообще “не найден”.
Кстати, этих проблем можно было бы избежать, если бы в серийный была чексумма, когда по последней цифре можно проверить, правильный ли код, правильно ли он считался/ввелся. У расчетных счетов, ИНН, номеров карт, у EAN13, у всего последняя цифра является чексуммой для проверки, чтобы люди и машины не ошибались при вводе.

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

Криптохвост есть только в штрихкоде и не хранится в базе маркировки, чтобы никакой хакер не мог подломить базу и печатать чужие штрихкоды.
Т.е. это своеобразная цифровая подпись. Но т.к. штрихкод не резиновый, а товаров много, то длина этой цифровой подписи небольшая, что не позволяет пользоваться открытыми для всех ключами шифрования.
Конечно, все серийные номера лежат в базе данных маркировки, но если проверять по ней в онлайне, то при любом падении интернета сразу встанут все склады и магазины.
Криптохвост призван решить эту проблему, но пока (на лето 2020 года) не заработал в полную силу.
Дело в том, что криптография российская и привязана к железкам. Но альтернативы российской крипте всё равно нет, государственная российская система не может использовать иностранную крипту, это будет дыра. Поэтому придется терпеть российскую, это разумно и не сложно.

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

С этим столкнулись все, кто попробовал интегрироваться с API маркировки. Было очень много вопросов в чатах типа “Почему не авторизуется?”, “Как подписать?”, “Поделитесь примером!”, “Подпись сформировали но приходит отказ, почему?” и много других.
Чаще всего ошибки были банальны. Например, после подписи изменяли данные, либо терялся пробел или как-то несущественный символ, но для подписи это критично, и после отправки в API приходил отказ без объяснений, т.к. подпись не проходила проверку.
К счастью в чатах чаще всего помогали и отвечали на такие вопросы. В целом, все эти проблемы лечатся или уже были излечены к 1 июля 2020.

В части “Честного знака” к 1му июля 2020 весь процесс от производства товара до его выбытия через кассу или доставку интернет-магазина был продуман, расписан, протестирован и запущен в боевом контуре. Например, у нас есть видеоролик такого сквозного процесса для молочной продукции.

Что мы сами думаем о маркировке
Мы в Клеверенсе думаем, что софтовые проблемы не главное. Хуже то, что участники оборота товаров до сих пор не понимают сути изменений. Это гораздо большая проблема, чем софтверные баги.
Люди относятся к маркировке как к еще одному бухгалтерскому отчету, который можно составлять сидя у компа в 1С/SAP/NAV/DAX, корректировать, менять задним числом и т.п. Типа пользоваться будут бухгалтеры и логисты, а айтишники должны “запилить” под это нужные модули и обработки.
Главный запрос наших клиентов в том, чтобы склад/китайцы/тетямаша что-то насканировали, а потом это “корректно” загрузилось в 1С/SAP/NAV/DAX. И мы это успешно делаем.
Но это очевидная ошибка, которая вскроется, когда компании начнут сводить остатки друг с другом, а государство начнет штрафовать.
Что такое на самом деле система маркировки
Маркировка товаров — это система отражения реальных движений.
Реальные проблемы с маркировкой
Это чисто наше IMHO.
Все реальные проблемы автоматом вытекают из того, для чем на самом деле является система маркировки, а именно, системой отражения реальных движений.
Во-первых, реальный учет движений противоречит текущим принципам учета по всей цепочке, когда всё учитывается по SKU, по партии или по среднему. Задним числом сводить и исправлять — наше всё.
Учетная система в любой компании — представляет собой причесанную и исправленную сказку о том, как всё здорово получилось после 100500 созвонов, исправлений, перепроведений и вычищения ошибок.
На одной из расширенных встреч у крупного иностранного дистрибутора лекарств только после часа обсуждения главный логист, наконец, округлил глаза и сказал “это что же, разные штрихкоды у каждой пачки?”. А слова “уникальный”, “серийный номер”, “каждый экземпляр”, “всё сканировать” и т.п., видимо, пролетели мимо.
Во-вторых, реальный учет движений противоречит текущим бизнес-практикам и принципам разделения ответственности.
Даже если компания крупная и у сотрудника нет прав на правку каких-то документов — есть телефон, можно позвонить или написать тому, кто может поправить.
Или, например, документы подписываются КЭП директора каким-то низовым сотрудником, а если есть двухэтапная аутентификация, то через пересылку SMS. В системе маркировки есть блок про пользователей и их права, можно выдавать всем отдельные КЭП, но люди этого делать не спешат.
Это явная проблема, которая будет решаться предоставлением всё больших прав и инструментов учета тем простым сотрудникам, которые находятся прямо рядом с маркированным товаром.
Сверх того, правила расчета себестоимости или учета движений в учетной системе основаны на усреднениях и упрощениях типа FIFO/LIFO и средней цены. И те принципы учета, которые повсеместно десятилетиями применяются от производства до розницы, основаны на этих упрощениях и идут в разрез с реальным прослеживаем уникальных единиц.
Из-за этого на практике получается, например, что в систему маркировки товары отправляются по FIFO/LIFO, а реально отгружается то, что стояло ближе в выходу.
Это тоже решается специальным оборудованием и софтом для простых сотрудников, которые по роду своей работы не могут сидеть у компа.
Еще одна проблема — это попытка “натянуть сову на глобус” и втащить коды маркировки во все стандартные документы ERP, чтобы там их видел бухгалтер, логист или ответственный менеджер.
Хотя смотреть ему на них не за чем, сделать он с ними ничего не может.
И правда, ну как может бухгалтер или менеджер, глядя в монитор может понять, что там вчера насканировал склад, и почему тут выделенные красным расхождения по трем штучкам сигарет из тысяч?
Это тоже решается инструментами для низового персонала с доступом ко всей нужной информации.

Ну т.е. это не технические проблемы каких-то систем, которые в целом к 1 июля 2020 уже были исправлены, а вопросы перестройки работы компаний на новые рельсы.

Выводы
Самый главный плюс маркировки в том, что государство заставило всех цифровизироваться и переходить на ЭДО с цифровыми подписями и криптографией.
«Прилив поднимает все лодки», и переход всего рынка на общие рельсы дает большой синергетический эффект.
Всем удачной автоматизации!
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_razrabotka_dlja_interneta_veschej (Разработка для интернета вещей), #_biznesmodeli (Бизнес-модели), #_markirovka (маркировка), #_vzgljad_iznutri (взгляд изнутри), #_gosudarstvo_i_internet (государство и интернет), #_blog_kompanii_kleverens (
Блог компании Клеверенс
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_razrabotka_dlja_interneta_veschej (
Разработка для интернета вещей
), #_biznesmodeli (
Бизнес-модели
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 01:28
Часовой пояс: UTC + 5