возникла ошибка неизвестный код транзакции receivenoticesendconfirmation
Не удалось распаковать пакет электронных документов. Не настроена связь с контрагентом
Данная ошибка возникает в Текущих делах ЭДО при нажатии «Отправить и получить» и свидетельствует о том, что в папке «Распаковать» имеются пакеты электронных документов, автоматическая распаковка которых не была произведена из-за того, что настройка получения электронных документов находится не в состоянии «Присоединен» или отсутствует вовсе.
Открыв соответствующий пакет электронных документов можно убедиться, что отсутствуют обязательные поля, необходимые для распаковки пакета и последующего корректного принятия к учету (идентификатор получателя, идентификатор отправителя, контрагент). Для заполнения этих полей в некоторых случаях необходимо наличие в информационной базе приглашения между участниками ЭДО по данному документу в статусе «Присоединен».
Решение: Необходимо дождаться перевода приглашения в статус «Присоединен». После этого необходимые для распаковки данные автоматический будут заполнены, и пакет будет успешно распакован.
Отслеживать статус приглашения можно либо в настройке получения электронных документов по этому контрагенту, либо на вкладке «Приглашения» Архива ЭДО.
Если статус не меняется длительное время, это может быть вызвано наличием проблем при настройке роуминговой связи. Для решения вопроса в этом случае необходимо обратиться в техническую поддержку 1С-ЭДО.
В случае если ошибка распаковки сопровождается сообщением о неполученных приглашениях, ограниченных датой запроса необходимо выполнить их загрузку.
Для этого необходимо перейти в справочник «Организации», нажать «ЭДО – Учетные записи».
Двойным нажатием мыши открыть соответствующую Учетную запись ЭДО.
В открывшемся окне нажать «Ещё» и выбрать «Начальные даты запроса данных у оператора ЭДО».
Начальную дату запроса приглашений у оператора ЭДО необходимо очисть, после чего нажать «Записать и закрыть». Затем вернуться в раздел Текущие дела ЭДО и нажать «Отправить и получить».
С сервера оператора ЭДО в информационную базу будут загружены отсутствующие настройки, и документ успешно распакуется.
В данной транзакции уже происходили ошибки 1С 8.3 как исправить?
Программа 1С является самой популярной и наиболее удобной при автоматизации предприятия. В ней предусмотрены решения, созданные на базе одной платформы, соответственно, функционируют они по одному принципу, что значительно упрощает использование ПО. Нередко пользователи сталкиваются с сообщением «В данной транзакции уже происходили ошибки». Рассмотрим как в 1С 8.3 исправить подобную проблему.
Причина появления сообщения о повторных ошибках в 1С 8.3
Главная проблема заключается в том, что сообщение об ошибке «В данной транзакции уже происходили ошибки» неинформативно, нет никакой конкретики. Поэтому будем опираться на проблемы, с которыми чаще всего сталкиваются пользователи. Например, с технической стороны ошибка такого рода может возникнуть при первой транзакции, то есть и при первичном обращении к базе данных.
Подобная ошибка может произойти при обработки ситуации «Попытка-Исключение». Например, при создании записи «Объект_1» формируется исключительная ситуация, а сама ошибка появляется в «Ссылка_2.Наименование». То есть происходит запрос базы данных объектной модели.
В «Попытке-Исключение» начинается обработка операции, которая также должна быть выполнена в транзакции, которая, в свою очередь, может быть явной или неявной (создается в момент записи объекта).
1С: Предприятие 8.3 не поддерживает транзакций вложенного типа. Однако допускается создание вложенной конструкции сразу нескольких транзакций. Из-за наличия явной и неявной транзакции может возникнуть ошибка. То-есть программа запрещает транзакцию 1-го уровня на более низших уровнях.
Есть ли смысл исправлять ошибки транзакции, которые уже происходили
При работе с 1С 8.3 не стоит оставлять подобные вещи без внимания. Прежде всего, другой пользователь также может столкнуться с ней, но не поймет причин её возникновения. Если не выполнить отладку системы, то в дальнейшем могут возникнуть дополнительные проблемы. Так как оповещение «В данной транзакции уже происходили ошибки» появляется при первом обращении, то в журнале регистрации данная строка обязательно зафиксируется, но, опять же, без подробного пояснения. Хоть ошибка и располагается на нижнем уровне кода, она нарушит необходимую иерархию. Это приведет к сбою других функций и только еще больше запутает администратора.
При наличие некорректного кода, транзакции будут выполняться с нарушениями или не будут выполняться вовсе. Поэтому при возникновении таких сообщений стоит решить проблему.
Устраняем ошибку транзакции в 1С Предприятие версии 8.3
В первую очередь стоит очистить кэш базы данных. Сделать это можно вручную. Для этого:
Также можно выполнить удаление другим способом:
После того, как файл преобразуется, его можно запустить и весь пользовательский кэш удалится автоматически. Пробуем снова запустить программу и выполнить операцию. Если не помогло, то лучше всего обратиться к администратору. Также нужно помнить про основные особенности написания кода с использованием транзакций. Это поможет исключить ряд распространенных ошибок.
Особенности написания кода, которые помогут исключить ошибку в транзакциях
Прежде всего нужно опираться на нюансы корректной обработки исключений:
Решить проблему транзакций, в которых происходят ошибки, самостоятельно получается не всегда. Поэтому стоит попробовать выполнить простейшие действия – перезагрузить программу или очистить кэш. К более серьезным манипуляциям в 1С стоит переходить только при уверенности, что вы обладаете достаточным опытом.
Вы не умеете работать с транзакциями
Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку «В данной транзакции уже происходили ошибки»? Если да — то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.
Почему надо бить тревогу
Для начала, давайте разберемся, что же такое представляет собой ошибка «В данной транзакции уже происходили ошибки». Это, на самом деле, предельно простая штука: вы пытаетесь работать с базой данных внутри уже откаченной (отмененной) транзакции. Например, где-то был вызван метод ОтменитьТранзакцию, а вы пытаетесь ее зафиксировать.
Почему это плохо? Потому что данная ошибка ничего не говорит вам о том, где на самом деле случилась проблема. Когда в саппорт от пользователя приходит скриншот с таким текстом, а в особенности для серверного кода, с которым интерактивно не работает человек — это… Хотел написать «критичная ошибка», но подумал, что это buzzword, на который уже никто не обращает внимания…. Это задница. Это ошибка программирования. Это не случайный сбой. Это косяк, который надо немедленно переделывать. Потому что, когда у вас фоновые процессы сервера встанут ночью и компания начнет стремительно терять деньги, то «В данной транзакции уже происходили ошибки» это последнее, что вы захотите увидеть в диагностических логах.
Есть, конечно, вероятность, что технологический журнал сервера (он ведь у вас включен в продакшене, да?) как-то поможет диагностировать проблему, но я сейчас навскидку не могу придумать вариант — как именно в нем найти реальную причину указанной ошибки. А реальная причина одна — программист Вася получил исключение внутри транзакции и решил, что один раз — не карабас «подумаешь, ошибка, пойдем дальше».
Что такое транзакции в 1С
Неловко писать про азбучные истины, но, видимо, немножго придется. Транзакции в 1С — это то же самое, что транзакции в СУБД. Это не какие-то особенные «1С-ные» транзакции, это и есть транзакции в СУБД. Согласно общей идее транзакций, они могут либо выполниться целиком, либо не выполниться совсем. Все изменения в таблицах базы данных, выполненные внутри транзакции, могут быть разом отменены, как будто ничего не было.
Далее, нужно понимать, что в 1С не поддерживаются вложенные транзакции. Собственно говоря, они не поддерживаются не «в 1С», а вообще не поддерживаются. По-крайней мере, теми СУБД, с которыми умеет работать 1С. Вложенных транзакций, например, нет в MS SQL и Postgres. Каждый «вложенный» вызов НачатьТранзакцию просто увеличивает счетчик транзакций, а каждый вызов «ЗафиксироватьТранзакцию» — уменьшает этот счетчик. Данное поведение описано в множестве книжек и статей, но выводы из этого поведения, видимо, разобраны недостаточно. Строго говоря, в SQL есть т.н. SAVEPOINT, но 1С их не использует, да и вещь это достаточно специфичная.
Здесь и далее, специально для Воинов Истинной Веры, считающих, что код должен писаться только на английском, под спойлерами будет приведен аналог кода в англоязычном синтаксисе 1С.
На самом деле, нет. Мне совершенно не хочется дублировать примеры на английском только ради того, чтобы потешить любителей холиваров и священных войн.
Вы же наверняка пишете такой код, да? Приведенный пример кода содержит ошибки. Как минимум, три. Знаете какие? Про первую я скажу сразу, она связана с объектными блокировками и не имеет отношения непосредственно к транзакциям. Про вторую — чуть позже. Третья ошибка — это deadlock, который возникнет при параллельном исполнении этого кода, но это тема для отдельной статьи, ее рассматривать сейчас не будем, дабы не усложнять код. Ключевое слово для гугления: deadlock управляемые блокировки.
Обратите внимание, простой ведь код. Такого в ваших 1С-системах просто вагон. И он содержит сразу, как минимум, 3 ошибки. Задумайтесь на досуге, сколько ошибок есть в более сложных сценариях работы с транзакциями, написанных вашими программистами 1С 🙂
Объектные блокировки
Суть проблемы в том, что в указанном примере кода изменяется объект базы данных, но в другом сеансе может сидеть интерактивный пользователь (или соседний фоновый поток), который тоже будет менять этот объект. Здесь один из вас может получить ошибку «запись была изменена или удалена». Если это произойдет в интерактивном сеансе, то пользователь почешет репу, ругнется и попробует переоткрыть форму. Если это произойдет в фоновом потоке, то вам придется искать это в логах. А журнал регистрации, как вы знаете, медленный, а ELK-стек для журналов 1С у нас в отрасли настраивают единицы… (мы, к слову, входим в число тех, кто настраивает и другим помогает настраивать :))
Короче говоря, это досадная ошибка и лучше, чтобы ее не было. Поэтому, в стандартах разработки четко написано, что перед изменением объектов необходимо ставить на них объектную блокировку методом «ОбъектСправочника.Заблокировать()«. Тогда параллельный сеанс (который тоже должен так поступить) не сможет начать операцию изменения и получит ожидаемый, управляемый отказ.
А теперь про транзакции
С первой ошибкой разобрались, давайте перейдем ко второй.
Если не предусмотреть проверку исключения в этом методе, то исключение (например, весьма вероятное на методе «Записать()») выбросит вас из данного метода без завершения транзакции. Исключение из метода «Записать» может быть выброшено по самым разным причинам, например, сработают какие-то прикладные проверки в бизнес-логике, или возникнет упомянутая выше объектная блокировка. Так или иначе, вторая ошибка гласит: код, начавший транзакцию, не несет ответственность за ее завершение.
Именно так я бы назвал эту проблему. В нашем статическом анализаторе кода 1С на базе SonarQube мы даже отдельно встроили такую диагностику. Сейчас я работаю над ее развитием, и фантазия программистов 1С, чей код попадает ко мне на анализ, порой приводит меня в шок и трепет…
Почему? Потому что выброшенное наверх исключение внутри транзакции в 90% случаев не даст эту транзакцию зафиксировать и приведет к ошибке. Следует понимать, что 1С автоматически откатывает незавершенную транзакцию только после возвращения из скриптового кода на уровень кода платформы. До тех пор, пока вы находитесь на уровне кода 1С, транзакция остается активной.
Поднимемся на уровень выше по стеку вызовов:
Смотрите, что получается. Наш проблемный метод вызывается откуда-то извне, выше по стеку. На уровне этого метода разработчик понятия не имеет — будут ли какие-то транзакции внутри метода ОченьПолезныйИВажныйКод или их не будет. А если будут — то будут ли они все завершены… Мы же все тут за мир и инкапсуляцию, верно? Автор метода «ВажныйКод» не должен думать про то, что именно происходит внутри вызываемого им метода. Того самого, в котором некорректно обрабатывается транзакция. В итоге, попытка поработать с базой данных после выброса исключения изнутри транзакции, с высокой вероятностью приведет к тому, что «В данной транзакции бла-бла…»
Размазывание транзакций по методам
Второе правило «транзакционно-безопасного» кода: счетчик ссылок транзакций в начале метода и в его конце должен иметь одно и то же значение. Нельзя начинать транзакцию в одном методе и завершать ее в другом. Из этого правила, наверное, можно найти исключения, но это будет какой-то низкоуровневый код, который пишут более компетентные люди. В общем случае так писать нельзя.
Выше — неприемлемый говнокод. Нельзя писать методы так, чтобы вызывающая сторона помнила и следила за возможными (или вероятными — как знать) транзакциями внутри других методов, которые она вызывает. Это нарушение инкапсуляции и разрастание спагетти-кода, который невозможно трассировать, сохраняя рассудок.
Особенно весело вспомнить, что реальный код намного больше синтетических примеров из 3-х строчек. Выискивать начинающиеся и завершающиеся транзакции по шести уровням вложенности — это прям мотивирует на задушевные беседы с авторами.
Пытаемся исправить код
Вернемся к исходному методу и попытаемся его починить. Сразу скажу, что объектную блокировку мы чинить пока не будем, просто, чтобы не усложнять код примера.
Первый подход типичного 1С-ника
Обычно программисты 1С знают, что при записи может быть выдано исключение. А еще они боятся исключений, поэтому стараются их все перехватывать. Например, вот так:
Ну как, стало лучше, да? Ведь теперь, возможные ошибки записи обрабатываются и даже логируются. Исключения больше не возникнут при записи объекта. И в логе даже видно — на каком объекте, не поленился, вывел в сообщение ссылку вместо лаконичного «Ошибка записи справочника», как это часто любят писать вечно торопящиеся разработчики. Иными словами, налицо забота о пользователе и рост компетенций.
Однако, опытный 1С-ник здесь скажет, что нет, лучше не стало. По сути ничего не поменялось, а может даже стало и хуже. В методе «Записать()» платформа 1С сама начнет транзакцию записи, и эта транзакция будет уже вложенной по отношению к нашей. И если в момент работы с базой данных 1С свою транзакцию откатит (например, будет выдано исключение бизнес-логики), то наша транзакция верхнего уровня все равно будет помечена как «испорченная» и ее нельзя будет зафиксировать. В итоге этот код так и останется проблемным, и при попытке фиксации выдаст «уже происходили ошибки».
А теперь представьте, что речь идет не о маленьком методе, а о глубоком стеке вызовов, где в самом низу кто-то взял и «выпустил» начатую транзакцию из своего метода. Верхнеуровневые процедуры могут и понятия не иметь, что кто-то там внизу начинал транзакции. В итоге, весь код валится с невнятной ошибкой, которую расследовать невозможно в принципе.
Код, который начинает транзакцию, обязан завершить или откатить ее. Не взирая ни на какие исключения. Каждая ветка кода должна быть исследована на предмет выхода из метода без фиксации или отмены транзакции.
Методы работы с транзакциями в 1С
Не будет лишним напомнить, что вообще 1С предоставляет нам для работы с транзакциями. Это всем известные методы:
Первые 3 метода очевидны и делают то, что написано в их названии. Последний метод — возвращает Истину, если счетчик транзакций больше нуля.
И есть интересная особенность. Методы выхода из транзакции (Зафиксировать и Отменить) выбрасывают исключения, если счетчик транзакций равен нулю. То есть, если вызвать один из них вне транзакции, то возникнет ошибка.
Как правильно пользоваться этими методами? Очень просто: надо прочитать сформулированное выше правило: код, начавший транзакцию, должен нести ответственность за ее завершение.
Как же соблюсти это правило? Давайте попробуем:
Выше мы уже поняли, что метод ДелаемЧтоТо — потенциально опасен. Он может выдать какое-то исключение, и транзакция «вылезет» наружу из нашего метода. Окей, добавим обработчик возможного исключения:
Отлично, мы поймали возникающую ошибку, но что с ней делать? Записать сообщение в лог? Ну, может быть, если код логирования ошибок должен быть именно на этом уровне и ошибку мы тут ждем. А если нет? Если мы не ожидали тут никаких ошибок? Тогда мы должны просто передать это исключение выше, пусть с ними разбирается другой слой архитектуры. Делается это оператором «ВызватьИсключение» без аргументов. В этих ваших джава-сиплюсплюсах это делается точно так же оператором throw.
Так, стоп… Если мы просто прокидываем исключение дальше, то зачем тут вообще нужна Попытка? А вот зачем: правило заставляет нас обеспечить завершение начатой нами транзакции.
Теперь, вроде бы, красиво. Однако, мы ведь помним, что не доверяем коду ДелаемЧтоТо(). Вдруг там внутри его автор не читал этой статьи, и не умеет работать с транзакциями? Вдруг он там взял, да и вызвал метод ОтменитьТранзакцию или наоборот, зафиксировал ее? Нам очень важно, чтобы обработчик исключения не породил нового исключения, иначе исходная ошибка будет потеряна и расследование проблем станет невозможным. А мы помним, что методы Зафиксировать и Отменить могут выдать исключение, если транзакция не существует. Здесь-то и пригождается метод ТранзакцияАктивна.
Финальный вариант
Наконец, мы можем написать правильный, «транзакционно-безопасный» вариант кода. Вот он:
**UPD: в комментариях предложен более безопасный вариант, когда ЗафиксироватьТранзакцию расположен внутри блока Попытка. Здесь приведен именно этот вариант, ранее Фиксация располагалась после блока Попытка-Исключение.
Постойте, но ведь не только «ОтменитьТранзакцию» может выдавать ошибки. Почему же тогда «ЗафиксироватьТранзакцию» не обернут в такое же условие с «ТранзакцияАктивна»? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к «размазыванию» логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, «прячущего» старое.
Чек-лист рефакторинга
Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.
Паттерн:
Обернуть в «безопасную» конструкцию с Попыткой, Проверкой активности и пробросом исключения.
Паттерн:
Анализ и Рефакторинг. Автор не понимал, что делает. Начинать вложенные транзакции можно безопасно. Не нужно проверять условие, нужно просто начать вложенную транзакцию. Ниже по модулю он наверняка еще там извращается с их фиксацией. Это гарантированный геморрой.
Примерно похожий вариант:
аналогично: фиксация транзакции по условию — это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.
Паттерн:
Паттерн:
Данная транзакция уже не завершится в случае исключения. Нет смысла продолжать цикл. Код требуется переписать, сверяясь с исходной задачей. Дополнительно обеспечить более информативное сообщение об ошибке.
В заключение
Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята — основная проблема 1С, как экосистемы — это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я «НачатьТранзакцию()».
И знаете — самое главное, что это прекрасно. Простота разработки в 1С позволяет моментально реализовывать бизнес-идеи и встраивать их в процессы компании. Потом всегда можно отрефакторить, главное понимать как. И если вдруг вам нужна помощь в аудите вашей «медленной 1С» — обращайтесь к специалистам по оптимизации. Она совсем не медленная.
Ошибка отправки push-уведомления из 1С на мобильное приложение 1С Android
Коллеги, прошу помощи.
С августа 2019 года перестали отправляться push-уведомления из 1С в мобильное приложение 1С (мобильная платформа 1С) на Andoid.
До этого момента всё отлично отправлялось.
Ошибка следующая :
» Ошибка при вызове метода контекста (Отправить): Отправка сообщения 1 через GCM завершилась ошибкой: Error=DeprecatedEndpoint «
Платформа 1С: 8.3.9.2170, 8.3.12.1567, 8.3.15.1534 (самая актуальная из 8.3);
Мобильная платформа 1С: 8.3.13.45, 8.3.15.59 (самая актуальная из мобильных).
Описание механизма (который работал больше года) :
1. Сторонние сервисы не используются.
2. Создан проект в firebase.google.com;
2.1 Получен номер проекта (как номер отправителя);
2.2 Получен ключ сервера (для отправки push-уведомлений);
3. В мобильном приложении 1С при каждом входе обновляется IDПодписчика.
Код отправки push-уведомления из основной базы :
Код получения IDПодписчика в мобильном приложении 1С :
В интернете обсуждений такой проблемы, связанной с 1С нет. Никто push-уведомления не использует что ли?
Есть что-то похожее на английских сайтах посвящённое разработке мобильных приложений на Андроид. Но там решения основанные на правках в самом коде приложений.
Я так понял это проблема/задача 1С? Т.е. в самой платформе нужно что-то изменить?
Просто странно, что даже на последних версиях платформы не решена проблема. И почему-то нет похожих вопросов в рунете по 1С.
Коды ошибок Visa/MasterCard/МИР
В данной статье собраны коды ошибок действующих банков-эквайеров.
Часто встречающиеся ошибки:
Код 05 – отказ эмитента без указания причины
Код 17 – отказать, отклонено пользователем карты
Код 19 – не пройдена авторизация (как правило, при непрохождении 3ds авторизации)
Код 41 – утерянная карта
Код 43 – украденная карта
Код 51 – недостаточно средств для проведения операции
Код 57 – недопустимый тип операции для данного типа карты (например, попытка оплаты в магазине по карте предназначенной только для снятия наличных)
Код 61 – превышение максимальной суммы операции или количества попыток для данной карты; превышен лимит на терминале продавца; недостаточно средств на счете продавца, в случае выплат (более точное описание смотрите ниже, исходя из обслуживающего банка)
Код 62 – заблокированная карта
Код 65 – превышение максимального количества операции для данной карты
Код 83 – ошибка сети (технические проблемы)
Код 91 – эмитент недоступен (технические проблемы на стороне банка-эмитента)
Код 96 – системная ошибка/невозможно связаться с банком, который выдал карту (требуется сверка с эквайером)
Полный список кодов ПАО « Промсвязьбанк » :
| Result Code | Description | Описание |
| 0 | Approved | Операция прошла успешно |
| 1 | Call your bank | Позвоните в свой банк |
| 3 | Invalid merchant | Недействительный продавец |
| 4 | Your card is restricted | Ограничение в проведении операции на стороне эмитента |
| 5 | Transaction declined | Операция отклонена без указания причины |
| 12 | Invalid transaction | Недействительная операция, возможно ошибки в параметрах запроса к платёжной системе |
| 13 | Invalid amount | Недопустимая сумма |
| 14 | No such card | Такая карта не существует |
| 15 | No such card/issuer | Нет такой карты / эмитента |
| 20 | Invalid response | Неверный ответ |
| 30 | Format error | Ошибка в параметрах запроса к платёжной системе |
| 41 | Lost card | Карта утеряна (статус установлен у эмитента) |
| 43 | Stolen card | Карта украдена |
| 51 | Not sufficient funds | Недостаточно средств |
| 54 | Expired card | Срок действия карты истёк |
| 55 | Incorrect PIN | Неверный PIN-код |
| 57 | Not permitted to client | Операция не разрешена для клиента (как правило, о тказ приходит со стороны платёжной системы) |
| 58 | Not permitted to merchant | Не разрешено продавцу (заблокирован терминал) |
| 61 | Exceeds amount limit | Сумма операции превысила допустимый лимит (также, возможен отказ от платёжной системы) |
| 62 | Restricted card | Запрещённая карта |
| 63 | Security violation | Нарушение безопасности |
| 65 | Exceeds frequency limit | Превышен лимит |
| 75 | PIN tries exceeded | Превышено количество попыток ввода PIN-кода |
| 76 | Wrong PIN,tries exceeded | Неверный PIN-код, количество попыток превышено |
| 82 | Time-out at issuer | Тайм-аут при соединении с эмитентом |
| 83 | Transaction failed | Транзакция неуспешна |
| 86 | Unable to verify PIN | Невозможно проверить PIN-код |
| 89 | Authentication failure | Ошибка аутентификации |
| 91 | Issuer unavailable | Эмитент недоступен |
| 93 | Violation of law | Операция отклонена. Держателю необходимо обратиться в свой банк |
| 95 | Reconcile error | Возникает, когда операция была уже проведена. |
| 96 | System malfunction | Системная ошибка \ Возможно ошибки в параметрах запроса к платёжной системе |
| -2 | Bad CGI request | Неверно сформирован запрос к платёжному шлюзу |
| -3 | No or Invalid response received | Платёжный шлюз вовремя не получил ответ. Статус операции при этом может быть успешным или неуспешным. |
| -4 | Server is not responding | Сервер не отвечает |
| -5 | Connect failed | Сбой соединения |
| -8 | Error in card number field | Ошибка в поле номера карты |
| -9 | Error in card expiration date field | Введена неверная дата срока действия карты |
| -10 | Error in amount field | Ошибка в поле суммы |
| -11 | Error in currency field | Ошибка в поле валюты |
| -12 | Error in merchant terminal field | Некорректный запрос к платежному шлюзу |
| -17 | Access denied | Отказано в доступе (Возможно ошибка при формировании P_SIGN) |
| -18 | Error in CVC2 or CVC2 Description fields | Ошибка в поле CVC2 |
| -19 | Authentication failed | Аутентификация прошла неуспешно (3d-secure), возможны другие причины. |
| -20 | Expired transaction | Время проведения операции превышает значение параметра TIMESTAMP |
| -21 | Duplicate transaction | Отправлен повторный запрос с идентичными параметрами |
| 70001 | Not sufficient funds | Недостаточно средств на счете. |
Полный список кодов ПАО Банк «ФК Открытие»:
| Result Code | Description | Описание |
| 00 | Approved | Успешная транзакция |
| 01 | Refer to card issuer | Обратитесь к эмитенту карты |
| 02 | Refer to card issuer, special condition | Обратитесь к эмитенту карты, особое условие |
| 03 | Invalid merchant or service provider | Недействительный идентификатор продавца |
| 04 | Pickup card | Изъять карту |
| 05 | Do not honor | Транзакция была отклонена эмитентом без объяснения причин |
| 06 | Error | Эмитент карты вернул ошибку без дополнительных объяснений |
| 07 | Pickup card, special condition (other than lost/stolen card) | Изъять карту, специальные условия |
| 08 | Honor with identification | Не пройдена идентификация, проблема с идентификацией |
| 09 | Request in progress | Выполняется запрос |
| 10 | Approved for partial amount | Одобрено для частичной суммы |
| 11 | Approved, VIP Approved, VIP program | Одобрено для VIP, программа VIP |
| 12 | Invalid transaction | Запрошенная транзакция не поддерживается или недействительна для представленного номера карты |
| 13 | Invalid amount | Сумма превышает лимиты, установленные эмитентом для данного типа транзакции |
| 14 | Invalid card (no such number) | Эмитент указывает, что эта карта недействительна. |
| 15 | No such issuer | Номер эмитента карты недействителен |
| 16 | Approved, update track 3 | Утверждено, обновить |
| 17 | Customer cancellation | Отмена клиентом |
| 18 | Customer dispute | Открыт спор с клиентом |
| 19 | Re-enter transaction | Клиент должен повторно отправить транзакцию |
| 20 | Invalid response | Неверный ответ |
| 21 | No action taken | Никаких действий не предпринимается. Эмитент отказался без других объяснений |
| 22 | Suspected malfunction | Предполагаемая неисправность |
| 23 | Unacceptable transaction fee | Неприемлемая комиссия за транзакцию |
| 24 | File update not supported | Обновление файла не поддерживается |
| 25 | Unable to locate record | Невозможно найти запись |
| 26 | Duplicate record | Дублирующая запись |
| 27 | File update edit error | Ошибка редактирования обновления файла |
| 28 | File update file locked | Файл/обновления файла заблокировано |
| 29 | not used | не используется |
| 30 | Format error | Ошибка формата |
| 31 | Bank not supported | Банк не поддерживается коммутатором |
| 32 | Completed partially | Завершено частично |
| 33 | Expired card, pick-up | Срок действия карты истек |
| 34 | Issuer suspects fraud, pick-up card | Эмитент карты подозревает мошенничество |
| 35 | Contact acquirer, pick-up | Обратиться к эмитенту карты |
| 36 | Restricted card, pick-up | Ограничено эмитентом карты |
| 37 | Call ECHO security, pick-up | Обратитесь в службу безопасности |
| 38 | PIN tries exceeded, pick-up | Количество попыток получения PIN-кода превышает лимиты эмитента |
| 39 | No credit account | Нет кредитного счета |
| 40 | Function not supported | Запрошенная функция не поддерживается |
| 41 | Pickup card (lost card) | Карта была утеряна |
| 42 | No universal account | Нет универсальной учетной записи |
| 43 | Pickup card (stolen card) | Карта была украдена |
| 44 | No investment account | Нет инвестиционного счета |
| 45 | 50 not used | не используется |
| 51 | Not sufficient funds | Недостаточно средств на карте |
| 52 | No checking account | Нет текущего счета |
| 53 | No savings account | Нет сберегательного счета |
| 54 | Expired card | Срок действия карты истек |
| 55 | Incorrect PIN | Неправильный PIN-код держателя карты |
| 56 | No card record | Нет такой карты |
| 57 | Transaction not permitted to cardholder | Операция не разрешена держателю карты. Карта не разрешена для запрошенного типа транзакции. |
| 58 | Transaction not permitted on terminal | Транзакция не разрешена на терминале. Продавцу запрещен этот тип транзакции (заблокирован терминал; сработало ограничение и т.д. необходимо уточнять подробности у эквайера) |
| 59 | Suspected fraud | Предполагаемое мошенничество |
| 60 | Contact ECHO | Связаться с службой безопасности |
| 61 | Exceeds withdrawal limit | |
| 62 | Restricted card | Карта заблокирована |
| 63 | Security violation | Нарушение безопасности. Карта заблокирована |
| 64 | Original amount incorrect | Неверная исходная сумма |
| 65 | Activity count limit exceeded | Превышено допустимое количество ежедневных транзакций |
| 66 | Call acquirer security | Связаться со службой безопасности эквайера |
| 67 | not used | не используется |
| 68 | Response received too late | Ответ получен слишком поздно |
| 69 | 74 not used | не используется |
| 75 | PIN tries exceeded | Превышено допустимое количество попыток ввода PIN-кода |
| 76 | Invalid «to» account | Неверный счет. Дебетового счета не существует |
| 77 | Invalid «from» account | Недействительный счет. Кредитный счет не существует |
| 78 | Invalid account specified (general) | Связанная учетная запись с номером карты недействительна или не существует |
| 79 | Already reversed | Уже отменено |
| 80 | Visa transactions: credit issuer unavailable | Операции с Visa: эмитент недоступен |
| 81 | PIN cryptographic error found | Обнаружена криптографическая ошибка PIN-кода |
| 82 | Negative CAM, dCVV, iCVV, or CVV results | Некорректный CAM, dCVV, iCVV или CVV |
| 83 | Unable to verify PIN | Невозможно проверить PIN-код |
| 84 | Invalid authorization life cycle | Просроченная авторизация |
| 85 | not used | не используется |
| 86 | Cannot verify PIN | Невозможно проверить PIN-код |
| 87 | Network Unavailable | Сеть недоступна |
| 88 | Invalid CVC2 | Ошибочно введенный cvc2 |
| 89 | Ineligible to receive financial position information | Невозможно получить финансовую информацию |
| 90 | Cut-off in progress | Отключение в процессе |
| 91 | Issuer or switch inoperative | Банк-эмитент недоступен |
| 92 | Routing error | Ошибка маршрутизации |
| 93 | Violation of law | Нарушение закона |
| 94 | Duplicate transaction | Дублирующая транзакция |
| 95 | Reconcile error | Ошибка согласования/ошибка при расчетах с МПС/НСПК |
| 96 | System malfunction | Произошла системная ошибка |
| 97 | not used | не используется |
| 98 | Exceeds cash limit | Превышен денежный лимит |
| -2 | Bad CGI request | Запрос не прошел CGI-проверку |
| -3 | No or Invalid response received | Хост эквайрера (NS) не отвечает |
| -4 | Server is not responding | Нет соединения с хостом эквайрера |
| -5 | Connect failed | Ошибка соединения с хостом эквайрера (NS) во время обработки транзакции |
| -6 | Configuration error | Ошибка настройки модуля e-Gateway |
| -7 | Incorrect response from the acquirer host | Некорректный ответа хоста эквайрера (NS), например, отсутствуют обязательные поля |
| -8 | Error in card number field | Ошибка в поле «Card number» запроса |
| -9 | Error in card expiration date field | Ошибка в поле «Card expiration date» запроса |
| -10 | Error in amount field | Ошибка в поле «Amount» запроса |
| -11 | Error in currency field | Ошибка в поле «Currency» запроса |
| -12 | Error in merchant terminal field | Ошибка в поле «Merchant ID» запроса |
| -13 | System error | IP-адрес источника транзакции (обычно IP торговца) не соответствует ожидаемому |
| -14 | No connection | Нет соединения с PIN-клавиатурой Интернет-терминала либо программа-агент на компьютере/рабочей станции Интернет-терминала не запущена |
| -15 | Error in the «RRN» field of the request | Ошибка в поле «RRN» запроса |
| -16 | Another transaction is in progress on the terminal | На терминале выполняется другая транзакция |
| -17 | The terminal is denied access to the e-Gateway module | Терминалу отказано в доступе к модулю e-Gateway |
| -18 | Error in the «CVC2» or «CVC2 Description» field of the request | Ошибка в поле «CVC2» или «CVC2 Description» запроса |
| -19 | Error in request for authentication information or authentication failed | Ошибка в запросе на аутентификационную информацию либо аутентификация неуспешна |
| -20 | Permissible time interval exceeded | Превышен допустимый временной интервал (по умолчанию – 1 час) между значением поля «Time Stamp» запроса и временем модуля e-Gateway |
| -21 | Transaction has already been completed | Транзакция уже выполнена |
| -22 | Transaction contains invalid authentication information | Транзакция содержит ошибочную аутентификационную информацию |
| -23 | Error in transaction context | Ошибка в контексте транзакции |
| -24 | Inconsistency in the context of a transaction | Несоответствие в контексте транзакции |
| -25 | Transaction aborted by user | Транзакция прервана пользователем |
| -26 | Invalid BIN of the card | Неверный BIN карты |
| -27 | Seller name error | Ошибка в имени продавца |
| -28 | Error in additional data | Ошибка в дополнительных данных |
| -29 | Error in authentication link (damaged or duplicated) | Ошибка в ссылке аутентификации (повреждена или дублируется) |
| -30 | Transaction was rejected as fraudulent | Транзакция отклонена как мошенническая |
| -31 | Transaction in progress | Транзакция в процессе выполнения |
| -32 | Re-declined transaction | Повторная отклоненная транзакция |
| -33 | client authentication in progress | Транзакция в процессе аутентификации клиента с помощью авторизации случайной суммы или одноразового случайного кода |
| -34 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты | |
| -35 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты была отклонена автоматически после превышения лимита времени на эту операцию | |
| -36 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты была отклонена самим пользователем |