Ошибка 217 r keeper не получается напечатать чек

• Главная
• Полезная информация
• Самоучитель
• Ошибки

Вероятно многие встречались с таким вот «партизаном» при старте или завершении приложения:

Очень информативное сообщение, сразу понятна причина ошибки, место и способ ее решения.
Впрочем, если без шуток, что это вообще такое?
Конечно-же это исключение, но ни тип исключения, ни его описание нам не доступны — просто «Runtime error 217» и адрес, а дальше сами…

Если честно, раньше я как-то даже не задумывался по поводу данного исключения, т.к. в моих проектах оно явление редкое, пока однажды у целой череды пользователей не начала воспроизводится именно 217-я ошибка.
Впрочем, даже тогда я не пошел по правильному пути и просто добавил дополнительный уровень логирования в проект, по результатам которого достаточно оперативно нашел причину и исправил ее.
Но, по сути, я просто потратил свое время…

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

Теория и анализ проблемы

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

Для начала я немного освежил мои представления об ошибках в принципе, перечитав часть статьи «Обработка ошибок — глава 1.2.2» за авторством Александра Алексеева, откуда вынес информацию о том, что ошибка 217 будет отображена в том случае, если не инициализирован модуль SysUtils, причем это у Александра проиллюстрированно достаточно наглядно:

Открыть картинку в полный размер…

На основании данной картинки можно сделать грубый вывод: пока SysUtils жив — все исключения должны отображаться в нормальном виде, о чем идет отдельное упоминание:

Например, если вы видите сообщение о runtime-ошибке, то, судя по приведённой схеме, маловероятно, чтобы ошибка возникла в обработчиках событий на форме. Зато гораздо вероятнее, что она возникает, скажем, в какой-то секции finalization (которая выполняется после секции finalization модуля SysUtils) или в назначенной процедуре ExitProcessProc. Но, разумеется, причина ошибки может сидеть где угодно — в том числе и в упоминаемых обработчиках событий.

Ну что-ж давайте проверим, пишем код, в котором SysUtils должна быть финализирована позже модуля Unit1, в котором искусственно генерируем исключение:

unit Unit1;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;
 
type
  TForm1 = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
initialization
 
finalization
 
  raise Exception.Create('finalization exception');
 
end.

Билдим, запускаем, закрываем форму и… Runtime error 217.

Утверждение о том, что 217 отображается после финализации SysUtils полностью верное, но давайте-ка посмотрим на сам код финализации:

procedure FinalizeUnits;
...
begin
...
  Count := InitContext.InitCount;
  Table := InitContext.InitTable^.UnitInfo;
...
  try
    while Count > 0 do
    begin
      Dec(Count);
      InitContext.InitCount := Count;
      P := Table^[Count].FInit;
      if Assigned(P) then
...
        TProc(P)();
...
      end;
    end;
  except
    FinalizeUnits;  { try to finalize the others }
    raise;
  end;
end;

Смотрите что происходит: в процедуре FinalizeUnits вызываются все финализирующие процедуры, адреса которых расположены в массиве InitContext.InitTable^.UnitInfo в том порядке, в котором происходила их инициализация, т.е. самые первые расположены в начале массива (а финализация идет с конца).
Где-то в самом низу расположен и SysUtils + System, ну а мы, с нашим модулем Unit1 где-то в самом верху.
Но вдруг происходит исключение в нашем модуле и «бабах», порядок катарсиса нарушен.

После «бабах» FinalizeUnits вызывается повторно, пропуская наш модуль, вызвавший исключение, вследствие чего разрушается SysUtils и разные, встречающиеся по пути, class destructor-ы, до кучи грохается System с менеджером памяти (сидящий одним из первых в начале списка), после чего идет контрольный выстрел в лоб — RAISE, вот тут-то мы и приплыли — здравствуй 217.

А что если произойдет исключение в секции инициализации любого модуля?

Да все тоже самое:

procedure InitUnits;
...
begin
...
  try
...
  except
    FinalizeUnits;
    raise;
  end;
end;

Делаем вывод: любое необработанное исключение в секциях инициализации или финализации будет приводить к потере описания исключения и приводить к ошибке 217.

На этом с теорией, думаю, закончим.
Имея на руках понимание о причине возникновения Runtime error 217, попробуем получить на руки более привычный нам вариант сообщения об исключении.

Отключаем финализацию модулей

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

Его анализ заключался в следующем: общая инициализация обработчика исключений производится в процедуре InitExceptions модуля SysUtils, а финализация вызовом DoneExceptions.

Если каким либо образом отключить вызов DoneExceptions плюс не дать разрушиться менеджеру памяти, заблокировав вызов блока финализации System — на руки мы получим сообщение об исключении в приемлимом виде.

Как вариант решения был предложен следующий код, который нужно подключить к файлу проекта самым первым модулем (будет работать начиная с D2005 и выше):

unit suShowExceptionsInInitializeSections;
 
interface
 
uses
  SysUtils;
 
implementation
 
uses
  Windows;
 
//Получение структуры PackageInfo нашего приложения
//В System она находится в переменной InitTable, но не видна из других модулей
function GetInitTable: PackageInfo;
var
  Lib: PLibModule;
  TypeInfo: PPackageTypeInfo;
begin
  Result := nil;
 
  Lib := LibModuleList;
 
  if not Assigned(Lib) then
    Exit;
 
  //Если загружено несколько модулей (BPL пакетов), то выходим,
  //я не изучал как работает механизм загрузки/выгрузки BPL, поэтому на всякий
  //случай выходим
  if Assigned(Lib^.Next) then
    Exit;
 
  Typeinfo := Lib^.TypeInfo;
  if Assigned(TypeInfo) then
  begin
    //Мы имеем TPackageTypeInfo
    //Теперь по нему можно получить PackageInfo
    //Воспользуемся особенностями компилятора.
    //В IDA видно, что ссылка TypeInfo указывает на середину структуры
    //PackageInfo программы
    //Поэтому для того что бы вычислить PackageInfo нужно вычесть из адреса
    //TypeInfo смещение этого поля
    Result := PackageInfo(PByte(TypeInfo) - (LongWord(@PackageInfoTable(nil^).TypeInfo)));
  end;
end;
 
//Отключить секцию финализации для всех модулей
procedure DisableAllFinalization;
var
  Loop: Integer;
  OldProtect: LongWord;
  InitTable: PackageInfo;
  Table: PUnitEntryTable;
begin
  InitTable := GetInitTable;
 
  if Assigned(InitTable) then
  begin
    Table := InitTable^.UnitInfo;
    if Assigned(Table) then
      //Разрешаем изменять структуру в которой хранятся ссылки на инициализаю/финализацию всех юнитов
      if VirtualProtect(Table, SizeOf(PackageUnitEntry) * InitTable^.UnitCount, 
        PAGE_READWRITE, OldProtect) then
        for Loop := 0 to InitTable^.UnitCount - 1 do
          Table^[Loop].FInit := nil;
  end;
end;
 
initialization
 
finalization
  //Сейчас идет финализация всех модулей, модуль SysUtils создан раньше, поэтому
  //он еще не финализирован. Наша задача здесь не дать ему финализироваться,
  //Как и другим модулям которые он использует (интересует только System),
  //это нужно для правильной отработки обработчиков исключений.
 
  //Сюда мы можем попасть по двум причинам
  //1. Произошел Exception во время инициализации каком-то модуля
  //2. Нормальное завершение программы
  //
  //Мы не будем определять причину, так как процесс все равно завершается, а ОС
  //сама освободит занятые ресурсы после смерти процесса.
  //Но нужно иметь ввиду, данную технику использовать в DLL нельзя, что бы не
  //допускать утечек памяти
  if IsLibrary then
    Exit;
 
  //Мы не можем выборочно заблокировать финализацию юнитов по их имени
  //так как нет соответствующих данных в RTTI. Тем не менее, мы можем отключить
  //финализацию всех юнитов, которые идут в списке до этого
  //модуля. Таким образом если данный модуль расположить первым в DPR файле,
  //то мы минимизируем утечки.
  //Вычислять адрес процедуры финализации данного юнита не обязательно,
  //ведь к моменту выполнения данного кода уже финализированы все следующие юниты.
  //Поэтому просто заблокируем финализцию всех оставшихся
  DisableAllFinalization;
end.

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

Но, впрочем, давайте разберем логику работы данного кода:
Суть его проста, необходимо выйти на данные о загруженных модулях (включая BPL) в том виде, в котором их понимает Delphi приложение. Это было сделано посредством доступа к началу однонаправленного списка структур TLibModule. Первым элементом списка будет структура, описывающая текущий образ, откуда нам нужно всего-то и получить данные о структуре UnitInfo, которая содержит в себе данные как о количестве инициализированных модулей, так и об адресах их процедур инициализации и финализации в виде записи PackageUnitEntry.

Блокирование финализации модулей происходит посредством присвоения параметру FInit значения nil у каждой записи PackageUnitEntry.

При обниливании данного параметра FinalizeUnits не сможет произвести вызов обработчика и в итоге тот самый raise, о котором я писал выше, сможет достаточно корректно произвести отображение возникшего исключения.

Но вот дальше все сложнее.

Пытаемся причесать хорошую мысль

Идея здравая и причины понятны, но вот как-же так, ресурсы все-же не освобождены, FastMem перестанет нормально работать (она собирает утечки как раз при финализации), да и совместимости маловато, к примеру, как я и сказал выше, под Delphi 7 данный код вообще работать не сможет.

После первого часа обсуждений в IT отделе мы даже умудрились прийти и к такому выводу: «да и хрен с ними с SysUtils и System — что-то критичного они за собой не несут».
А потом, опять начали спорить — ну не устраивал нас этот подход, вроде все хорошо, но не аккуратненько как-то.

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

И тут, сидя в отладчике и прогоняя код по 70-му разу пришла мысля.
Дык эта… а как вообще выводится сообщение о произошедшем исключении?

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

Попробуем-ка проэмулировать вызов ExceptHandler.
Пишем тестовый юнит и подключаем его к проекту самым первым:

unit Test;
 
interface
 
uses
  SysUtils;
 
var
  E: Exception;
 
implementation
initialization
finalization
  E := AcquireExceptionObject;
  if E <> nil then
  begin
    ShowException(E, ExceptAddr);
    E.Free;
    Halt(1);
  end;
end.

Запускаем на выполнение и…

Получилось.

Встроившись в цикл финализации, мы отобразили произошедшее исключение и продолжили финализацию дальше вызовом Halt(1).

В итоге задача решена, грамотно и документировано, и совместимо с Delphi 7, но…

А не развить ли идею?

Есть такое понятие, как «наведенные ошибки», т.е. ошибки произошедшие из-за того что перед ними тоже произошла ошибка.

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

Тоже самое может произойти и в процедурах инициализации/финализации, причем исключение, произошедшее в финализации скроет от нас саму причину.

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

uses
  Classes;
 
var
  Logger: TFileStream;
 
const
  StartLog: AnsiString = 'Начало работы приложения' + sLineBreak;
  EndLog: AnsiString = 'Работа приложения завершена' + sLineBreak;
 
implementation
 
initialization
 
  Logger := TFileStream.Create('A:MyLog,txt', fmCreate);
  Logger.WriteBuffer(StartLog[1], Length(StartLog));
 
finalization
 
  Logger.WriteBuffer(EndLog[1], Length(EndLog));
  Logger.Free;
 
end.

Мало у кого в системе присутствует диск «А» поэтому результатом этого кода будет либо «Runtime error 216» (именно 216, а не 217), либо, если подключим код из предыдущей главы:

Exception EAccessViolation in module Project2.exe at 001B1593.
Access violation at address 005B1593 in module ‘Project2.exe’. Read of address 00000000.

А ведь причина то кроется в самом первом исключении, которое нами не отображается и с наскока разобраться в причине ошибки не получится.

Для того чтобы исправить эту несправедливость, можно немного причесать код и довести его до вот такого состояния:

unit ShowExceptSample;
 
interface
 
uses
  SysUtils,
  Classes;
 
implementation
 
type
  PRaiseFrame = ^TRaiseFrame;
  TRaiseFrame = packed record
    NextRaise: PRaiseFrame;
    ExceptAddr: Pointer;
    ExceptObject: TObject;
    ExceptionRecord: PExceptionRecord;
  end;
 
var
  // Указатель на вершину списка исключений
  CurrentRaiseList: Pointer = nil;
 
// Функция возвращяет текущее исключение со стека
function GetNextException: Pointer;
begin
  if CurrentRaiseList = nil then CurrentRaiseList := RaiseList;
  if CurrentRaiseList <> nil then
  begin
    Result := PRaiseFrame(CurrentRaiseList)^.ExceptObject;
    PRaiseFrame(CurrentRaiseList)^.ExceptObject := nil;
    CurrentRaiseList := PRaiseFrame(CurrentRaiseList)^.NextRaise;
  end
  else
    Result := nil;
end;
 
var
  ExceptionStack: TList;
  E: Exception;  
 
initialization
 
finalization
 
  // Смотрим, есть ли вообще исключения?
  E := GetNextException;
 
  if E <> nil then
  begin
    ExceptionStack := TList.Create;
    try
 
      // если есть, собираем о них информацию
      while E <> nil do
      begin
        ExceptionStack.Add(E);
        E := GetNextException;
      end;
 
      // и отображаем их в том порядке, в котором они произошли
      while ExceptionStack.Count > 0 do
      begin
        E := ExceptionStack[ExceptionStack.Count - 1];
        ExceptionStack.Delete(ExceptionStack.Count - 1);
        ShowException(E, ExceptAddr);
        E.Free;
      end;
    finally
      ExceptionStack.Free;
    end;
 
    // финализируем все что осталось
    Halt(1);
  end;
end.

Здесь идея проста, функция GetNextException по сути повторяет вызов AcquireExceptionObject, но после своего вызова не теряет ссылку на следующее в очереди исключение, а запоминает адрес следующего фрейма во внешней переменной.
После чего все исключения заносятся в список (самое последнее будет первым в списке) и выводятся программисту с соблюдением очередности, в результате чего нам будет сразу понятно, что сначала произошло вот это:

И уже только после него пошли всякие там AV.

Теперь по поводу остальных кодов ошибок.
Почему я начал именно с «Runtime error 217»?
Ну потому что она наиболее легко воспроизводима, а так технически, используя выше приведенный модуль, мы получим на руки вполне нормальное описание всех возможных Runtime ошибок, коих в наличии у нас вон сколько:

  reMap: array [TRunTimeError] of Byte = (
    0,   { reNone }
    203, { reOutOfMemory }
    204, { reInvalidPtr }
    200, { reDivByZero }
    201, { reRangeError }
{   210    Abstract error }
    215, { reIntOverflow }
    207, { reInvalidOp }
    200, { reZeroDivide }
    205, { reOverflow }
    206, { reUnderflow }
    219, { reInvalidCast }
    216, { reAccessViolation }
    218, { rePrivInstruction }
    217, { reControlBreak }
    202, { reStackOverflow }
    220, { reVarTypeCast }
    221, { reVarInvalidOp }
    222, { reVarDispatch }
    223, { reVarArrayCreate }
    224, { reVarNotArray }
    225, { reVarArrayBounds }
{   226    Thread init failure }
    227, { reAssertionFailed }
    0,   { reExternalException not used here; in SysUtils }
    228, { reIntfCastError }
    229, { reSafeCallError }
    235, { reMonitorNotLocked }
    236  { reNoMonitorSupport }
{$IFDEF PC_MAPPED_EXCEPTIONS}
{   230   Reserved by the compiler for unhandled exceptions }
{$ENDIF PC_MAPPED_EXCEPTIONS}
{$IF defined(PC_MAPPED_EXCEPTIONS) or defined(STACK_BASED_EXCEPTIONS)}
{   231   Too many nested exceptions }
{$ENDIF}
{$IF Defined(LINUX) or Defined(MACOS)}
{   232   Fatal signal raised on a non-Delphi thread }
    ,
    233 { reQuit }
{$ENDIF LINUX or MACOS}
{$IFDEF POSIX}
    ,
    234  { reCodesetConversion }
{$ENDIF POSIX}
    ,
    237, { rePlatformNotImplemented }
    238  { reObjectDisposed }
);

Итог

Вот таким небрежным кодом, мы можем получить то, о чем нам не хочет говорить ошибка под кодом 217.

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

А если нет — значит буду вторым.

Отдельный респект соавтору и вдохновителю данной статьи — Виктору Федоренкову.

Удачи.

В соответствии с предписаниями ФЗ №54, собственники бизнеса должны использовать контрольно-кассовые машины (далее — ККМ) нового образца, имеющие фискальный накопитель (далее — ФН), а также возможность выхода в интернет. Устройство используется для кодирования и записи сведений о совершённых кассовых операциях, а также для последующей их отправки оператору фискальных данных (далее — ОФД). После обработки полученных данных, оператор передаёт их в ФНС.    

При работе на ККМ пользователь может периодически сталкиваться с неполадками ,связанными с ФН. Тогда касса печатает на документе код ошибки, который указывает пользователю на ту или иную проблему. Ниже мы расскажем о том, что значат конкретные кода ошибок ФН и разберём пути их решения.      

Пути решения ошибки ФН 211

Ошибка ФН 211 сообщает пользователю о неправильном формате хранения документов в ФН. 

Причины возникновения ошибки:

• Соединение с ФН было потеряно по причине того, что он был отсоединён от ККМ.

• Повредился шлейф, соединяющий ФН с ККМ. 

• Накопитель не был фискализован, либо был закрыт архив ФН.

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

Пути решения ошибки ФН 212

Ошибка сообщает о том, что ФН имеет неверное состояние. Разберём вероятные причины данной ошибки и пути их решения:

• Пользователь попытался закрыть смену, хотя она ещё не была открыта. Требуется осуществить перезагрузку устройства, после чего заново открыть смену. 

• Соединения с ФН не установлено – требуется убедиться в том, что чип подсоединён к ККМ.

• ККМ не зарегистрирована – зарегистрировать ККМ в ФНС.

Если после всех манипуляций проблема не была решена, это может значить, что ФН был сломан, либо шлейф не подсоединён к ККМ. В таком случае необходимо отнести аппарат в сервисный центр. 

Пути решения ошибки ФН 217

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

Для исправления ситуации пользователю необходимо выставить в настройках правильное время и дату. Чтобы узнать, какое время проставлено в последних ФД, пользователю необходимо выпустить отчет, в котором отображено состояние расчётов. Чтобы предупредить неполадки при открытии смены, требуется убедиться в правильности значений даты и времени.      

Пути решения ошибки ФН 235

При создании ФД, ККМ перенаправляет их ОФД. Если пересылка невозможна (к примеру, отсутствует связь с оператором, либо торговля ведётся на улице, где нельзя подсоединиться к сети), то устройство откладывает пересылку. Все ФД должны пересылаться ОФД на позже одного месяца с момента операции, если же чек не будет отправлен вовремя, чип заблокируется.

Причиной данной ошибки может послужить превышение времени хранения данных. 

Для исправления ситуации, требуется переслать все проведённые ФД оператору. Настроить интернет-соединение и проверить, не истёк ли срок действия соглашения с ОФД. 

Пути решения ошибки ФН 234

Все ФН содержат в себе ключ фискального признака, который находится в криптопроцессоре. Он не позволяет сфальсифицировать ФД и гарантирует безопасность информации. ФН имеет ограниченный срок работы (13, 15 и 36 месяцев), и когда этот срок выходит, устройство блокируется.    

Причиной ошибки 234 является окончание срока работы или ресурса памяти ФН.

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

Другие ошибки фискального накопителя

Ниже в таблице мы привели кода других популярных ошибок, причины их возникновения и пути решения.

Не все неполадки, которые возникают во время использования ККМ, могут быть связаны с поломкой ФН. Иногда неполадка может заключаться в самой ККМ – при этом код ошибки отображается на экране устройства. Также трудности в работе могут возникнуть из-за сбоев кассового ПО. К примеру, в «1С: Розница» при открытии смены может возникнуть такая неполадка, как: «Ошибка определения доступных касс ККМ. Не смогли определить доступные кассы ККМ». В случае появления данного сообщения ,лучше обратиться за помощью к специалистам сервисного центра.

Наш каталог продукции

У нас Вы найдете широкий ассортимент товаров в сегментах кассового, торгового, весового, банковского и офисного оборудования

Те, кто работает с онлайн-кассами, уже могли столкнуться с тем, что фискальный накопитель (ФН) может выдавать ошибку. Что удобно, обычно ФН в этот момент печатает на чековой ленте код ошибки – при этом номера при одинаковой ошибке будут совпадать у разных касс независимо от производителя. Т.е. перечень кодов ошибок у касс «Эвотор» будет таким же, как у ККТ «АТОЛ», Viki Print и т.д.

Мы разберем самые популярные ошибки фискального накопителя, в числе которых ошибки с кодом 235, 234, 231, 210, 211 и 212.

Ошибка ФН с кодом 235 «Ресурс хранения данных исчерпан»

Ошибка 235 означает, что на фискальном накопителе есть запись, которая в течение 30 дней не была отправлена ОФД. Если такая запись есть, закрыть смену невозможно, а работа кассы блокируется.

Чтобы решить ошибку, проверьте:

• Связь с оператором фискальных данных;
• Наличие интернет-соединения;
• Исправность фискального накопителя.

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

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

Если причина в неполадках с Интернетом, нужно проверить следующее:

1. Настройки инициализации и соединения с маршрутизатором, исправность проводного или беспроводного соединения.
2. Работу SIM-карты: установлена ли она, исправна.
3. Средства на балансе сотового оператора или интернет-провайдера.
4. Работоспособность оборудования на стороне провайдера – для этого обратитесь в техподдержку обслуживающей вас компании.
5. Для касс «АТОЛ» – проверить, установлено ли приложение EthernetOverUSB либо EthernetOverTransport и корректность его работы.
6. Для касс VikiPrint – проверить, запущенно ли приложение ComProxy и корректность его работы.
7. Для касс «Штрих-М» – проверить корректность настройки RNDIS.

Если ни один из пунктов не помог обнаружить проблему, и срок гарантии ФН не истек, то неисправность может быть в самом фискальном накопителе (но это крайне редкий случай). В этом случае можно обратиться в сервисный центр для замены ФН по гарантии.

Ошибка ФН с кодом 234 «Исчерпан ресурс криптопроцессора ФН»

Если на фискальном регистраторе появилась ошибка 234 «Исчерпан ресурс криптографического сопроцессора ФН» (или «Исчерпан ресурс КС») — это значить что истек срок действия ФН и его необходимо заменить.

Сделать это можно следующим образом:

1. посмотреть дату и время последнего документа в ФН;
2. перевести дату в кассе на день последнего чека, время — на время несколько позже последнего документы;
3. закрыть смену при необходимости;
4. дождаться отправки всех документов в ОФД;
5. закрыть архив ФН;
6. зарегистрировать кассу с новым установленным ФН.

Если не получится сделать самостоятельно, необходимо обратиться в обслуживающую организацию.

Ошибка ФН с кодом 231 «Некорректное значение параметров команды ФН»

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

Убедитесь, что вы выбрали подходящий по параметрам ФН и проверьте корректность передачи системы налогообложения.

Ошибка ФН с кодом 210 «Ошибка обмена с ФН на уровне интерфейса I2C»

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

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

Третий вариант – устарела прошивка фискального накопителя, потребуется ее обновить.

Либо сам механизм ФН вышел из строя, о чем точнее вы можете узнать в сервисном центре.

Ошибка ФН с кодом 211 «Ошибка формата передачи ФН»

Эта ошибка может возникнуть в двух случаях:

1. Если фискальных накопитель отсоединился от кассы (нужно проверить подключение).
2. Сломался шлейф для подключения ФН, нужно его заменить.

Ошибка ФН с кодом 212 «Неверное состояние ФН»

Вот основные причины, по которым может возникнуть ошибка с кодом 212:

1. Попытка закрыть смену, которая не была открыта. Чтобы это исправить, нужно выключить онлайн-кассу, включить и открыть смену.
2. Возможно, нет связи с фискальным накопителем: нужно проверить, подключен ли шлейф к ФН и к самой онлайн-кассе.
3. Ошибки при регистрации кассового аппарата могут привести к некорректной работе ФН.
4. Может быть неисправен сам фискальный накопитель или шлейф для подключения к онлайн-ККТ.

Ошибки ФН с кодами 213, 214, 215 и 216

Может помочь перезагрузка кассового аппарата по питанию.

Если это не помогло для решения этих ошибок нужно закрыть архив фискального накопителя и заменить ФН.

Ошибка ФН с кодом 217 «В ФН переданы неверная дата или время»

Нужно проверить, верно ли выставлены в кассе параметры даты и времени и настроить их верно.

Ошибка ФН с кодом 218 «В ФН нет запрошенных данных»

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

Ошибка ФН с кодом 219 «Переполнение ФН (итог чека)»

Фискальный накопитель переполнен, его требуется заменить.

Ошибки ФН с кодами 225, 255 «Неверный номер ФН»

Скорее всего, номер ФН, вписанный в настройки кассы, не совпадает с реальным номером накопителя. Нужно указать правильный номер.

Ошибка ФН с кодом 232 «Превышение размеров данных ФН, передаваемых в формате TLV»

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

Ошибка ФН с кодом 233 «Нет транспортного соединения с ФН»

Чтобы убрать эту ошибку, нужно установить транспортное соединение с оператором фискальных данных, затем отправить на ФН соответствующую команду.

Ошибка ФН с кодом 236 «Сообщение от ОФД не может быть принято ФН»

Причиной может послужить неверно указанные параметры ОФД, их нужно исправить.

Ошибка ФН с кодом 237 «В ФН есть неотправленные фискальные документы»

Настройте подключение кассы к Интернету и убедитесь, что все данные с ФН отправлены ОФД. Проверить это поможет отчет о текущем состоянии расчетов.

Ошибка ФН с кодом 238

Этот код означает, что узнать более подробную информацию об ошибке можно с помощью команды чтения регистра 55.

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

Подключить техподдержку

Причину отказа работы системы R-Keeper поможет выявить код ошибки, выдаваемый программой: