06.04.2020

Требования к разработке драйверов подключаемого оборудования (версия 3.3)

Внимание! Данные требования устарели. Актуальные требования размещены в статье.

• Изменения в стандарте
• Введение
• Разработка драйвера для подключения оборудования локально к устройству пользователя
•     Общие требования к разрабатываемому драйверу и его архитектуре
•     Обязательные функции и методы, связанные с использованием драйвера подключаемого оборудования в системе
•     Описание методов, специфичных для типов подключаемого оборудования
  • Требования к разработке драйверов для электронных весов
  • Требования к разработке драйверов для электронных весов с печатью этикеток в режиме "OFFLINE"
  • Требования к разработке драйверов для дисплеев покупателя
  • Требования к разработке драйверов для терминалов сбора данных
  • Требования к разработке драйверов для ККТ с функцией передачи в ОФД
  • Требования к разработке драйверов для принтеров чеков
  • Требования к разработке драйверов для принтеров этикеток
  • Требования к разработке драйверов устройств ввода (сканеры штрихкода, считыватели магнитных карт и т.д.)
  • Требования к разработке драйверов для эквайринговых терминалов
  • Требования к разработке драйверов для RFID считывателей
•     Подключение драйверов разработанных по стандарту «1С: Совместимо» к конфигурации БПО
  • Подготовка драйвера к загрузке в конфигурацию БПО
  • Загрузка подготовленного драйвера в конфигурацию БПО
  • Использование драйвера предварительно установленного на локальных компьютерах
• Подключение программно-аппаратных комплексов с помощью файлового обмена
• Подключение программно-аппаратных комплексов с помощью web-сервиса "EquipmentService"

Изменения в стандарте

Примечание. Устаревшие версии требований доступны в архиве.

Начиная с версии стандарта 3.3  в данном документе объединены требования к разработке драйверов подключаемого оборудования и требования к разработке драйверов мобильных устройств.
Для каждого типа оборудования указана возможность использования данного типа оборудования в мобильных приложениях и перечислены типы клиентов "1С:Предприятия".

В соответствии с данными требованиями фирма 1С выпускает два продукта:

• 1С:Библиотека подключаемого оборудования (начиная с версии 2.1.4)
  Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.
• 1С:Библиотека подключаемого оборудования для мобильных приложений (начиная с версии 2.12)
  Поддержка: мобильное приложение.

Введение

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

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

Поддерживается взаимодействие с программно-аппаратными POS-системами (от англ. "Point of Sale" - "Точка продаж") обеспечивающих розничные продажи.
Взаимодействие обеспечивается с помощью файлового обмена с помощью встроенного в библиотеку "1С:Библиотека подключаемого оборудования" модуля "1С: ККМ-Offline".

Библиотека поддерживает работу сторонних программно-аппаратных комплексов различного назначения с помощью Веб-сервиса оборудования. Для осуществления обмена необходимо опубликовать Веб-сервис "EquipmentService" входящий в состав библиотеки. Веб-сервис обрабатывает запросы на получение и обработку данных от программно-аппаратных комплексов и возвращает стандартный результат во внешний программно-аппаратный комплекс.  

Рис. 1. Схемы взаимодействия конфигураций системы программ «1С:Предприятие» с подключаемым оборудованием

Общую структуру документа можно разделить на две части: требования к разработке драйвера для подключения оборудования локально к устройству пользователя и подключение аппаратно-программных систем с помощью веб-сервиса оборудования.

Разработка драйвера для подключения оборудования локально к устройству пользователя

Оборудование подключается к системе с помощью драйвера, разработанного в соответствии с технологией создания внешних компонент. Технология определяет интерфейс взаимодействия между платформой 1С и драйвером. Реализация драйвера возможна с использованием стандартных компонентных объектов только для Windows (COM-интерфейс) и собственной технологии фирмы 1С – NativeAPI .

Разработка драйвера в технологии NativeAPI имеет ряд преимуществ. С помощью технологии можно создавать внешние компоненты, которые могут подключаться как в клиентском приложении, в том числе в тонком и web-клиенте, мобильном клиенте, мобильном приложении, так и на сервере "1С:Предприятия", разработать универсальные программные компоненты для Windows, Linux, Android и iOS.

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

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

1. Общие требования к разрабатываемому драйверу и его архитектуре

Разрабатываемый драйвер должен:

1. Быть разработан в виде внешней компоненты по технологии создания внешних компонент, приведенной в статье "Технология создания внешних компонент".
2. Внешняя компонента для работы с подключаемым оборудованием должна содержать только один объект, реализующий расширение встроенного языка, и возвращать методом «RegisterExtensionAs» имя расширения, совпадающее с второй частью ProgID компоненты. Пример: для компоненты с ProgID «AddIn.Scanner» функция должна возвращать «Scanner». Имя расширения не должно содержать пробелов и недопустимых символов (в соответствии с правилами формирования имен объектов "1С:Предприятия").
3. Обеспечить возможность реализации функционала в полном объеме (должны быть реализованы и работать все методы) для подключаемого типа оборудования. Если оборудованием данная функция не поддерживается, должно возвращаться "False", а в описании ошибки, возвращаемом методом "ПолучитьОшибку/GetLastError", содержится текст, что данная функция оборудованием не поддерживается.
4. Предоставлять русскоязычные и англоязычные названия методов (например ПолучитьОшибку() - GetLastError() и др.).
5. Поддерживать работу с несколькими экземплярами устройств, в рамках процедур в которых используется данное оборудование.
6. При возникновении ошибки в работе предоставлять подробное описание произошедшей ошибки, позволяющее пользователю понять причину ее возникновения и возможный способ устранения.
7. При возникновении внештатных ситуаций (некорректные действия пользователя, отсутствие запрашиваемого метода или функции, передача некорректных значений и др.) корректно обрабатывать их. Не должно быть аварийных завершений работы драйвера и прочих действий драйвера, которые могут привести к нарушению нормальной работы пользователя.
8. Принимать/возвращать и обрабатывать таблицы значений в виде XML документа (текст в формате XML с кодировкой UTF-8, передаваемый с помощью параметра типа STRING).
   Для упрощения обработки структур данных используются наименования атрибутов только на английском языке.
9. Обрабатывать метод SetLocale для локализации драйвера в соответствии с полученным кодом локализации и настраивать свое окружение (текстовые надписи, сообщения об ошибках и т.д.). Драйвер должен поддерживать локализированное окружение для локального кода региона и локализацию окружения на английском языке. Если полученный код локализации отличается от предусмотренного в драйвере, то драйвер должен настроить свое окружение на использование английского языка. Более подробно использование метода SetLocale описано в документе "Технология создания внешних компонент".

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

• Однокомпонентный драйвер - Драйвер, представляющий из себя один файл - внешнюю компонент, и предназначенный для использования только с системой программ «1С:Предприятие». При разработке драйвера в виде одного файла все используемые run-time библиотеки и другие необходимые файлы должны статически включаться в драйвер, так как на устройстве пользователя их может не оказаться или они могут быть другой версии. Рекомендуемая технология для разработки данного драйвера - NativeAPI.
• Многокомпонентный драйвер - Драйвер представляющий из себя сложный программно-аппаратный комплекс, предназначенный для использования как с системой программ «1С:Предприятие» , так с программными решениями сторонних производителей. Разрабатываемый драйвер состоит из двух частей:
  • Интеграционный компонент - промежуточный компонент для связи "1С Предприятия" с основной поставкой драйвера. Имеет интерфейс, разработанный в соответствии общими требованиями к драйверу и технологией разработки внешних компонент, но не реализует функционала драйвера подключаемого оборудования. Интеграционная компонент реализует функционал поиска установленной основной поставки драйвера, его инициализацию и переадресацию вызовов. Все используемые run-time библиотеки и другие необходимые файлы должны быть статически включены в компоненту.
  • Основная поставка драйвера - драйвер поставщика, реализованный по произвольной технологии и состоящий из произвольного набора файлов. Протокол взаимодействия драйвера с интеграционным копонентом не регламентируется данными требованиями. Поставка драйвера осуществляется посредством инсталляции из дистрибутива поставщика.

ВНИМАНИЕ: Для типа оборудования "Дисплей покупателя", "Устройства ввода", "Принтеры чеков", "Терминал сбора данных", "Электронные весы" допускается разработка драйвера в однокомпонентной архитектуре. Для других типов оборудования необходимо использовать многокомпонентную архитектуру!

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

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

Драйвер поддерживает два основных этапа работы с оборудованием в конфигурации:

• Регистрация и настройка оборудования
• Использование оборудования пользователем в процессе работы

Регистрация и настройка оборудования

1. Получение описания драйвера вызовом метода «ПолучитьОписание(GetDescription)».
2. Получения доступных параметров для настройки драйвера методом «ПолучитьПараметры(GetParameters)».
3. Построение формы настройки драйвера на основании списка доступных параметров.
4. Сохранение параметров настройки драйвера в базе данных конфигурации.

Использование оборудования пользователем в процессе работы

1. Инициализация устройства сохраненными в базе параметрами методом «УстановитьПараметр(SetParameter)».
2. Подключение оборудования с помощью метода «Подключить(Open)» с текущими значениями параметров, установленными вызовами метода «УстановитьПараметр(SetParameter)». Метод «Подключить(Open)» возвращает идентификатор подключенного экземпляра устройства.
3. Вызов обязательных функций и методов, специфичных для данного типа подключаемого оборудования, с использованием идентификатора подключенного экземпляра устройства.
4. Получение кода ошибки и описания ошибки методом «ПолучитьОшибку(GetLastError)» в случае ее возникновения.
5. Отключение устройства методом «Отключить(Close)» по идентификатору подключенного экземпляра устройства.

ВНИМАНИЕ: Все значения интерфейсных элементов (наименование, описание, заголовки, сообщения) должны быть реализованы на языке, установленном кодом локализации. (см. п.9 раздела Общие требования к разрабатываемому драйверу и его архитектуре.)

** - Версия требований – версия текущего документа (Версии 2.00 соответствует число 2000. Версии 2.4 соответствует число 2004. Текущей версии 3.3 соответствует число 3003.

ОписаниеДрайвера (DriverDescription)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит информацию о драйвере.

* - Обязательно для только для многокомпонентных драйверов.
** - Обязательно для только типов оборудования: “ККТ“, “ЭквайринговыйТерминал“, “ВесыСПечатьюЭтикеток“. Для типа оборудования “ККТ“ рекомендуется включать ведения лога драйвера по умолчанию. Настройку уровня детализации логирования можно вывести в параметры драйвера. В лог файл рекомендуется включать информацию полученную от 1С - в частности XML пакеты данных.

Пример XML описания драйвера :

<?xml version="1.0" encoding="UTF-8"?>
<DriverDescription 
      Name="Драйвер ККТ" 
      Description="Драйвер ККТ" 
      EquipmentType="ККТ" 
      IntegrationComponent="true" 
      MainDriverInstalled="true" 
      DriverVersion="1.1" 
      IntegrationComponentVersion="1.1" 
      DownloadURL="http://files.1с.ru/file.ZIP" 
      LogIsEnabled="true" 
      LogPath="C:\Users\drivers\"/>

ТаблицаПараметров (TableParameters)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит описание всех параметров драйвера и описание визуального интерфейса настройки драйвера.

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

Пример текстового XML описывающего параметры драйвера:

 <?xml version="1.0" encoding="UTF-8" ?>
 <Settings>
      <Page Caption="Параметры">    
      <Group Caption="Параметры подключения">
           <Parameter Name="Model" Caption="Модель" TypeValue="Number"/> 
           <Parameter Name="Port" Caption="Порт" TypeValue="Number" DefaultValue="0">
              <ChoiceList>
                  <Item Value="0">Клавиатура</Item>
                  <Item Value="1">COM1</Item>
                  <Item Value="2">COM2</Item>
               </ChoiceList>
           </Parameter>
           <Parameter Name="Parity" Caption="Четность" TypeValue="Boolean" DefaultValue="true"/>
           <Parameter Name="Speed" Caption="Скорость" TypeValue="Number" DefaultValue="1"/>
         </Group>
      </Page>
 </Settings>

В результате будет сформирована следующая форма для ввода параметров:

ТаблицаДействий (TableActions)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит описание дополнительных действий для настройки и управления драйвером в форме настройке оборудования, доступной администратору.
Данные действия будут отображаться пунктами меню в разделе "Функции", после пункта меню "Тест устройства" на форме настройки экземпляра подключаемого оборудования. При выборе определенного пункта меню будет вызван метод драйвера "ВыполнитьДополнительноеДействие" с параметром "ИмяДействия", соответствующий данному пункту меню. При выполнении данного действия драйвер может создавать дополнительные диалоговые окна в соответствии с документом "Технология создания внешних компонент".

Пример текстового XML описывающего дополнительные действия:

 <?xml version="1.0" encoding="UTF-8" ?>
 <Actions>
      <Action Name="SettingLog" Caption="Параметры журналирования"/> 
 </Actions>

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

3. Описание методов, специфичных для типов подключаемого оборудования

3.1. Требования к разработке драйверов для электронных весов

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Конфигурациями поддерживаются следующие возможности работы с весами on-line:

1. Ввод значения веса тары, используемой для упаковки взвешиваемого товара.
2. Получение значения веса товара за вычетом веса тары.

3.2. Требования к разработке драйверов для электронных весов с печатью этикеток в режиме "OFFLINE"

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Работа с электронными весами с печатью этикеток заключается в выгрузке таблицы товаров. Таблица формируется на основе базы данных средствами конфигурации. Обработка выгрузки таблицы товаров в электронные весы должна предусматривать выгрузку несколькими итерациями путем последовательных вызовов метода «ВыгрузитьТовары (UploadGoods)» с пакетами данных определенного размера (например, по 100 записей) с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".

ТаблицаТоваров (GoodsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные:

 
<?xml version="1.0" encoding="UTF-8"?>
 <Table>
    <Record PLU="1" Code="1003" Name="Яблоки Антоновка" Price="95,50" ShelfLife="7" IsWeightGoods="true"/>
    <Record PLU="2" Code="1023" Name="Салат Болгарский" Price="500,00" IsWeightGoods="true" 
            Description="Состав: свекла, морковь, ветчина, мясо, сыр, яйцо, лук репчатый, майонез" ShelfLife="5"/>
 </Table>

3.3. Требования к разработке драйверов для дисплеев покупателя

Поддержка: тонкий клиент, web-клиент, толстый клиент.

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

3.4. Требования к разработке драйверов для терминалов сбора данных

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Работа с терминалами сбора данных (ТСД) заключается в выгрузке таблицы товаров из конфигурации и загрузке данных об отобранных товарах.
Таблица для выгрузки в ТСД формируется на основе базы данных средствами конфигурации. Обработка выгрузки таблицы товаров в ТСД должна предусматривать выгрузку несколькими итерациями путем последовательных вызовов метода «ВыгрузитьТаблицу (UploadTable)» с пакетами данных определенного размера (например, по 100 записей) с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

В терминал загружается таблица товаров, и по ней отбираются товары. Предусматривается как частичная так и полная выгрузка. Из терминала загружается таблица отобранных товаров.
Загрузка таблицы товаров производится однократно методом «ЗагрузитьТаблицу (DownloadTable)».

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".  Если пакет один, то статусу пакета присваивается "last".

ТаблицаТоваров (GoodsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные: 

 
<?xml version="1.0" encoding="UTF-8"?> 
<Table FullLoad="true">
    <Record BarCode="4008110271538" Name="Блокнот для заметок" UnitOfMeasurement="Штуки" CharacteristicOfNomenclature="" 
                        SeriesOfNomenclature="" Quality="" Price="25,30" Quantity="7"/>
    <Record BarCode="2900001355643" Name="Финики в банке" UnitOfMeasurement="Штуки" CharacteristicOfNomenclature="" 
            SeriesOfNomenclature="" Quality="Зеленые" Price="95,50" Quantity="7"/>
</Table>

ТаблицаЗагрузки (DownloadTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные: 

<?xml version="1.0" encoding="UTF-8"?> 
<Table>
    <Record BarCode="4008110271538" Quantity="1" AlcoholExciseStamp="20N00001CKO68OY4QYX3T1731224004002671B1IEHLWKNFXFO8FPMERND09WMB8FYV7"/> 
    <Record BarCode="2900001355643" Quantity="2"/> 
</Table>

3.5. Требования к разработке драйверов для ККТ с функцией передачи в ОФД

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

При работе с ККТ с функцией передачи данных в ОФД поддерживаются следующие операции:

• Получение данных из ККТ для регистрации фискального накопителя и последующей работы;
• Операции с фискальным накопителем: 
  • Регистрация
  • Изменение параметров регистрации
  • Закрытие
• Формирование документов открытия и закрытия смены;
• Формирование фискальных чеков;
• Формирование фискальных чеков коррекции;
• Формирование фискальных отчетов о текущем состоянии расчетов;
• Формирование нефискальных отчетов (отчет без гашения);
• Получение текущего состояние ККТ;
• Печать чеков внесения/выемки денежных средств;
• Печать текстовых документов;
• Открытие денежного ящика.

ВНИМАНИЕ: Данный стандарт определяет требования к ККТ на основании формата фискальных документов версии по приказу Федеральной налоговой службы от 29.08.2019 № ММВ-7-20/434@ "О внесении изменений в приложение № 2, к приказу Федеральной налоговой службы от 21.03.2017 № ММВ-7-20/229@" (Зарегистрирован 25.12.2019 № 56978).
Если драйвер Заявителя не поддерживает работу с некоторыми тегами, не обязательными для формата 1.05, то перечень этих тегов должен быть указан в заявке на сертификацию.

Описание структуры TableParametersKKT

Текст в формате XML, передаваемый с помощью параметра типа STRING.

* Данные поля обязательны для фискализированных ФН.

Описание структуры ParametersFiscal

Текст в формате XML, передаваемый с помощью параметра типа STRING.
Данная таблица расширяет таблицу ТаблицаПараметровККТ (TableParametersKKT) следующими атрибутами:

* Данное поле обязательно при процедуре изменение параметров регистрации.

Описание структуры InputParameters

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML:

 <?xml version="1.0" encoding="UTF-8"?>
 <InputParameters> 
	<Parameters CashierName="Иванов И.П." CashierINN="32456234523452"/>
 </InputParameters>

Описание структуры OutputParameters

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Описание структуры OperationCounters

Описание структуры DocumentOutputParameters

Описание структуры CheckPackage

Текст в формате XML содержит описание передаваемого для формирования чека. Структура описывает параметры и последовательность формирования фискального чека.

Данное поле обязательно только для чека коррекции. Передается только при вызове метода СформироватьЧекКоррекции (ProcessCorrectionCheck).

CorrectionData - Данные коррекции. XML Структура.

AgentData - Данные агента. XML Структура.

VendorData - Данные поставщика. XML Структура.

GoodCodeData - Код товарной номенклатуры. XML Структура.

UserAttribute - Дополнительный реквизит пользователя, XML Структура.

Описание структуры DocumentPackage

Текст в формате XML содержит описание текстового документа. Структура описывает последовательность формирования текстового документа.

Справочные таблицы

Системы налогообложения

Признаки способа расчета

Признаки предмета расчета

Признак агента

Признаки агента по предмету расчета

Код типа маркированной продукции

3.6. Требования к разработке драйверов для принтеров чеков

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

При работе с принтерами чеков поддерживаются следующие операции:

• Печать текстовых чеков (с возможностью печати штрихкодов);
• Открытие денежного ящика.

Алгоритм печати чека.

При подключении устройства командой "Подключить" драйвер инициализирует устройство печати, в том числе определяет кодировку для печати чеков.
При формировании чека конфигурация посылает команду "НапечататьТекстовыйДокумент" для печати текстового документа на принтере чеков. Содержимое печатаемого документа определяется структурой ДанныеДокумента.

Описание структуры DocumentPackage

Текст в формате XML содержит описание текстового документа. Структура описывает последовательность формирования текстового документа.

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<Document>
	<Positions>
		<TextString Text="Участие в дисконтной системе"/>
		<TextString Text="Дисконтная карта: 00002345"/>
		<Barcode BarcodeType="EAN13" Barcode="2000021262157"/>
	</Positions>
</Document>

3.7. Требования к разработке драйверов для принтеров этикеток

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.

Работа с принтером печати этикеток заключается в выгрузке в драйвер сформированного пакета данных об этикетах. Пакет формируется средствами конфигурации и содержит описание форматирования шаблона этикетки и набора данных для формирования этикеток. Драйвер печати этикеток должен предусматривать обработку сформированного массива этикеток несколькими итерациями, путем последовательных вызовов метода «ПечатьЭтикеток (PrintLabels)» с пакетами данных определенного размера (например, по 100 этикеток) и с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".

ТаблицаЭтикеток (LabelsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Структуру передаваемого пакета можно разделить на две составляющие секции:

• Formatting - Секция описания форматирования шаблона этикетки. Присутствует однократно и только в первом пакете и описывает поля (элементы "Text", "Barcode", "Image" и "UserData"), входящие в шаблон этикетки, и их форматирование.
• Labels - Секция набора данных для формирования этикеток. Секция присутствует в каждом пакете только один раз, и содержит данные для заполнения каждой их этикеток которые необходимо распечатать.

Пример текстового XML, содержащий данные:  

 
<?xml version="1.0"?> 
 <Data> 
    <Formatting Width = "60" Height="40">
	<Text FieldName="Наименование" Left="1" Top="1" Width="55" Height="10" FontName="Tahoma" FontSize="8" FontStyle="Italic"/>
	<Text FieldName="Цена" Left="1" Top="11" Width="55" Height="10" FontName="Tahoma" FontSize="8" FontStyle="Bold Italic" Border="Left Top Right Bottom"/>
	<Barcode FieldName="Штрихкод" Type="EAN13" Left="1" Top="22" Height="10" PrintHRI="true" FontSize="8"/>
   </Formatting>
   <Labels>
        <Label Quantity="2">
	    <Record FieldName="Наименование" Value="Блокнот для заметок"/>
	    <Record FieldName="Цена" Value="43,5"/>
	    <Record FieldName="Штрихкод" Value="4008110271538"/>
        </Label>
        <Label Quantity="3">
	    <Record FieldName="Наименование" Value="Яблоки антоновка в банке"/>
            <Record FieldName="Цена" Value="78,5"/>
	    <Record FieldName="Штрихкод" Value="2900001355679"/> 
        </Label>
   </Labels> 
</Data> 

3.8. Требования к разработке драйверов устройств ввода (сканеры штрихкода, считыватели магнитных карт и т.д.)

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Данные устройства реализуют функцию автоматического считывания закодированной различными способами информации и асинхронной передачи ее в конфигурацию "1С:Предприятия". Драйвера устройств такого типа не предусматривают специфических для оборудования методов, которые можно вызывать из конфигураций.

Работа с драйвером строится следующим образом:

1. При инициализации объекта компоненты ему передается указатель на интерфейс "1С:Предприятия", с помощью которого можно вызывать метод:
   HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData)
2. При каждом успешном считывании кода сканером или считывателем драйвер должен вызывать метод HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData).
3. Переданные данные размещаются в очереди сообщений. Сообщения из очереди обрабатываются только после обработки всех системных сообщений "1С:Предприятия". При переполнении очереди полученные сообщения игнорируются.

Описание методов, доступных для асинхронного вызова из драйвера*

* - Описание остальных функций, доступных для вызова из драйвера, см. в документе «Технология создания внешних компонент»
** - В параметре bstrWho драйвер передает уникальный идентификатор подключенного устройства.
*** - Параметр bstrWhat используется для поддержки событий различных типов. Для сканеров должен содержать строку «Штрихкод» («Barcode»). Для считывателей магнитных карт, соответственно: «ДанныеКарты» («TracksData»). В случае ошибки этот параметр должен содержать значение "ОшибкаДрайвера" («DriverError»). В этом случае параметр bstrData должен содержать описание ошибки.
 

3.9. Требования к разработке драйверов для эквайринговых терминалов

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

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

• Оплата картой
• Отмена платежа по карте
• Возврат платежа по карте
• Блокирование суммы на счете карты
• Списание заблокированной суммы со счета карты
• Отмена блокировки суммы на счете карты
• Аварийная отмена операции
• Получение итогов дня по картам

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

Оплата картой

При необходимости оплатить покупку платежной картой Система вызывает метод "ОплатитьПлатежнойКартой", передавая во входном параметре сумму к оплате для списания с карты и номер считанной карты. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПечатьКвитанцийНаТерминале). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Отмена платежа по карте

Если происходит отмена платежа, то Система вызывает метод "ОтменитьПлатежПоПлатежнойКарте", передавая во входных параметрах сумму, которая была указана для списания с карты, номер считанной карты, код RRN операции, по которой совершается отмена, и код авторизации. Драйвер в ответ возвращает результат выполнения функции. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Возврат платежа по карте

При возврате платежа Система вызывает метод "ВернутьПлатежПоПлатежнойКарте", передавая во входном параметре сумму к возврату на карту, номер считанной карты, код RRN операции, по которой совершается возврат, и код авторизации. Драйвер в ответ возвращает результат выполнения функции, а в выходные параметры записывает код RRN, код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Блокирование суммы на счете карты

При необходимости заблокировать сумму на счете платежной карты Система вызывает метод "ПреавторизацияПоПлатежнойКарте", передавая во входном параметре сумму для блокировки и номер считанной карты. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПечатьКвитанцийНаТерминале). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Списание заблокированной суммы со счета карты

При необходимости списания заблокированной суммы со счета платежной карты Система вызывает метод "ЗавершитьПреавторизациюПоПлатежнойКарте", передавая во входном параметре сумму для списания с карты, номер считанной карты, код RRN операции блокировки и код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПечатьКвитанцийНаТерминале). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Отмена блокировки суммы на счете карты

Для отмены блокирования суммы на счете платежной карты Система вызывает метод "ОтменитьПреавторизациюПоПлатежнойКарте", передавая во входном параметре сумму для списания с карты, номер считанной карты, код RRN операции блокировки и код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПечатьКвитанцийНаТерминале). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Аварийная отмена операции

Если операция по платежной карте прошла успешно и слип-чек должен быть распечатан на ФР (определяется методом ПечатьКвитанцийНаТерминале), но возникла ошибка печати, то операция по карте должна быть аварийно отменена.

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

Для получения текста отчета Система вызывает метод "ИтогиДняПоКартам". Драйвер возвращает результат выполнения функции и текст отчета. 

* - Если информация, считанная с карты, передается в эквайринговую систему из конфигурации "1С:Предприятия", содержание этого поля должно отвечать требованиям конкретной эквайринговой системы.
** - Если при печати необходимо формировать несколько отдельных документов, в тексте для их разделения должна присутствовать строка "[отрезка]" или "[cut]". 
          Текст не должен содержать управляющие символы с кодами 1-8, 11-12, 14-31.

3.10. Требования к разработке драйверов для RFID считывателей

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Работа с RFID считывателями в "1С:Предприятие" осуществляется в асинхронном режиме. Открытие новой сессии считывания меток осуществляется командой «ОткрытьСессиюRFID». О всех новых метках попадающих в зону действия антенны считывателя передаются уведомление в "1С:Предприятие" внешним событием. Внешним событием передается идентификатор пакета, содержащий данные меток. После обработки внешнего события "1С:Предприятие" получает данные меток вызовом метода «ПолучитьДанныеМетокRFID» по идентификатору пакета (вызов данного метода служит подтверждением, что данные были доставлены).
Закрытие сессии считывания меток осуществляется командой «ЗакрытьСессиюRFID». Запись данных в метку осуществляется в рамках открытой сессии методом «ЗаписатьДанныеВМеткуRFID». Метка идентифицируется по TID и EPC. В метод передаются данные для записи и необходимый банк памяти (EPC или USERMEMORY) куда будут записываться данные.

ТаблицаМеток (TagsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные:

 
<?xml version="1.0" encoding="UTF-8"?>
 <Table>
    <Tag TID="E28011002000589616B408A1" EPC="3074367C34001E880A6D6168" USER=""/>
    <Tag TID="E28011002000589216B308A1" EPC="30751BD15C35BC0508B59F22" USER=""/>
 </Table>

1. При инициализации объекта компоненты ему передается указатель на интерфейс "1С:Предприятия", с помощью которого можно вызывать метод:
   HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData)
2. При попадании новых меток в зону действия антенны считывателя - драйвер формирует пакет с данными меток и передает уведомление в "1С:Предприятие" внешним событием. Во внешнем событии передается идентификатор пакета, содержащего данные. Внешние событие формируется посредством вызова метода HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData).
3. Переданные данные размещаются в очереди сообщений. Сообщения из очереди обрабатываются только после обработки всех системных сообщений "1С:Предприятия". При переполнении очереди полученные сообщения игнорируются.

Описание методов, доступных для асинхронного вызова из драйвера*

* - Описание остальных функций, доступных для вызова из драйвера, см. в документе «Технология создания внешних компонент»
** - В параметре bstrWho драйвер передает уникальный идентификатор подключенного устройства.
*** - Параметр bstrWhat используется для поддержки событий различных типов. Для RFID считывателей должен содержать строку «RFID».
 В случае ошибки этот параметр должен содержать значение "ОшибкаДрайвера" («DriverError»). В этом случае параметр bstrData должен содержать описание ошибки.

4. Подключение драйверов разработанных по стандарту "1С: Совместимо» к конфигурации БПО"

Поддержка: тонкий клиент, толстый клиент.

В конфигурации БПО начиная с версия 1.1.1 добавлена возможность подключения новых драйверов, разработанных по стандарту «1С: Совместимо». 

Предоставляется возможность:

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

* -Только для драйверов разработанных по COM технологии. В данном режиме не поддерживается работа в web-клиенте и Linux клиенте.

4.1. Подготовка драйвера к загрузке в конфигурацию БПО

Подготовка однокомпонентного драйвера или интеграционной библиотеки поставляемых в виде архива внешней компоненты

Подготовка драйвера, поставляемого в виде архива внешней компоненты, для загрузки в конфигурацию БПО осуществляется согласно разделу "Подготовка внешних компонент для загрузки в конфигурацию" документа "Технология создания внешних компонент". Кроме того, в архиве должен присутствовать XML файл c именем "INFO.XML", содержащий информацию для загрузки драйвера.

XML файл должен иметь следующую структуру:

Пример файла "INFO.XML", описывающего информацию о драйвере:

<?xml version="1.0" encoding="UTF-8"?>
<drivers>
	<component progid="AddIn.EmulatorFP1C" type="ФискальныйРегистратор" name="1C: Эмулятор фискального регистратора" version="1.0.21.1"/>
</drivers>

Подготовка драйвера поставляемого в виде дистрибутива

Для подготовки драйвера необходимо упаковать дистрибутив инсталлятора в ZIP архив. Исполняемый файл дистрибутива должен иметь имя "setup.exe". Помимо исполняемого файла допускается наличие дополнительных файлов необходимых для работы установщика дистрибутива. Так же в архиве должен присутствовать XML-файл c именем "INFO.XML" содержащий информацию необходимую для загрузки драйвера. Структура данного файла такая же, как и структура "INFO.XML" предыдущего раздела.

4.2. Загрузка подготовленного драйвера в конфигурацию БПО

Поддержка: тонкий клиент, толстый клиент.

Для загрузки подготовленного драйвера необходимо перейти в раздел "Подключаемое оборудование\Драйверы оборудования".
В форме списка драйверов нажать "Добавить новый драйвер из файла" и в отрывшемся диалоге выбора файла выбрать подготовленный для загрузки файл драйвера.
После открытие формы загружаемого драйвера необходимо проверить корректность заполнения информации о драйвере (поля: Тип оборудования, Наименование, Идентификатор объекта), и нажать кнопку "Записать и закрыть".

4.3. Использование драйвера, предварительно установленного на локальном компьютере

Для подключения драйвера, предварительного установленного на локальном компьютере, необходимо перейти в раздел "Подключаемое оборудование\Драйверы оборудования".
В форме списка драйверов нажать "Создать", и в открывшейся форме создаваемого драйвера ввести необходимые параметры драйвера в поля: Тип оборудования, Наименование, Идентификатор объекта.
После заполнения необходимых данных нажать кнопку "Записать и закрыть". Данная возможность предусмотрена только для драйверов разработанных по COM технологии.
В данном режиме не поддерживается работа в web клиенте и Linux клиенте.

Подключение программно-аппаратных комплексов с помощью файлового обмена

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.

Тип офлайн оборудования: ККМ

Работа с программно-аппаратными POS-системами (активными системными контрольно-кассовыми машинами) в режиме "Офлайн" заключается в файловом обмене информацией. В POS-систему из конфигурации выгружается данные (настройки, прайс-лист, заказы), в конце рабочего дня в конфигурацию загружаются данные о продажах (формируются в разрезе кассовых смен с детализацией по чекам), зарегистрированных POS-системой в течение смены.

Выгружаемые на ККМ данные формируется на основе данных информационной базы средствами конфигурации (драйвер "1С:Офлайн оборудование"). Имена файлов и пути размещения задаются пользовательскими настройками.

Список команд, поддерживаемых драйвером "1С:Офлайн оборудование" библиотеки подключаемого оборудования

ImportData.xml

Данные выгрузки (ExportData)

Секция настроек (Settings)

Секция видов электронной оплаты (ElectronicPaymentOptions)

Секция прайс-листа (PriceList)

Список алкогольных реквизитов (Alcohol)

Секция характеристик товаров (Characteristics)

Секция упаковок товара (Packs)

Условие наличия атрибутов "Code", "Barcodes", "Price", "Balance"

Таблица товаров имеет древовидную структуру. Товар может иметь иметь набор характеристик и набор упаковок.
Упаковки могут быть описаны как в секции товаров, так и в секции характеристик в случае, если учет товаров ведется в разрезе характеристик.
Атрибуты "Code", "Barcodes", "Price", "Balance",  указываются для последнего (нижнего) уровня иерархии.

Например, для товара "Майка дет." вида "Одежда" необходимо вводить характеристику "Размер". Товар может продаваться как упаковкой по 3 шт., так и поштучно.
В этом случае формируется записи во всех трех секциях, код присваивается записям: "Майка дет."+"р-р. 22" в секции "Характеристики"
и для "Майка дет."+"р-р. 22"+"Уп." в секции "Упаковки".

* обязательный атрибут/секция
** может присутствовать, но не обязательно
- атрибут/секция должны отсутствовать

для базовой ЕИ (unit) - значения указываются только для базовой единицы измерения, значения для упаковок должны указываться в секции упаковок

Секция единиц измерения (Units)

Секция штрихкодов (Barcodes)

Секция данных агентов (AgentsData)

Секция данных поставщиков (VendorsData)

Секция заказов (Orders)

Секция товаров заказа (Goods)

Данные для загрузки (ImportData)

Секция отчетов о продажах (SaleReports) Элемент SaleReport

Секция списка товаров чека (Goods)

Секция документов вскрытия алкогольной тары (AlcoholTareOpenings)

Общие таблицы

Секция оплат (Payments)

Секция дополнительных реквизитов (Extensions)

Подключение программно-аппаратных комплексов с помощью web-сервиса "EquipmentService"

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Библиотека поддерживает обмен со сторонними программно-аппаратными комплексами различного назначения с помощью web-сервиса.
Для осуществления обмена необходимо опубликовать web-сервис "EquipmentService" входящий в состав библиотеки. 

Тип офлайн оборудования: Прайс-чекер

Требования поддержки методов:

Методы web-сервиса EquipmentService

Метод PostDocs

Метод GetDocs

Пакет прайс-листа (PriceListPackage)

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PriceListPackage xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PackageTotal="2" PackageNumber="1">
    <IsFormed>true</IsFormed>
    <PriceList>
        ...
    </PriceList>
</PriceListPackage>

Секция отчетов прайс-чекера (PriceCheckerReports)

Элемент PriceCheckerReport:

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PriceCheckerReports xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <PriceCheckerReport Date="2017-09-11T12:00:00" Number="505" UUID="986cb877-1272-4d15-ada7-692473a40717">
        <Goods>
            <Good Code="100" Barcode="2100020307795" GoodUUID="1918351e-9327-445e-a648-893700731916"/>
        </Goods>
    </PriceCheckerReport>
</PriceCheckerReports>

Ответ отправки документа (PostDocsResponse)

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PostDocsResponse xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <IsSuccess>true</IsSuccess>
    <Description>Данные успешно загружены</Description>
</PostDocsResponse>