Изменения функционала в версии 1.045 сервис пак 1.
ЕГАИС. Возврат немаркированной продукции с регистра склада без указания основания.
Накладные. Печатная форма Счет-фактуры.
Журнал сессий ТСД.
№ | Название | стр |
1 | Изменения1045 сп1 | 3 |
2 | Изменения1045 сп2 | 5 |
3 | Изменения1045 сп3 | 6 |
4 | Изменения1046 сп1 | 9 |
5 | Изменения1046 сп2 | 15 |
6 | Изменения1046 сп3 | 17 |
7 | Изменения1046 | 20 |
8 | Изменения1047 сп1 | 42 |
9 | Изменения1047 сп2 | 48 |
10 | Изменения1047 сп4 | 51 |
11 | Изменения1047 сп5 | 54 |
12 | Изменения1047 | 56 |
13 | Изменения1048 сп1 | 76 |
14 | Изменения1048 сп2 | 78 |
15 | Изменения1048 сп3 | 82 |
16 | Изменения1048 | 91 |
17 | Изменения1049 сп1 | 114 |
18 | Изменения1049 сп2 | 118 |
19 | Изменения1049 сп3 | 125 |
20 | Изменения1049 сп4 | 131 |
21 | Изменения1049 сп5 | 137 |
22 | Изменения1049.1 сп1 | 139 |
23 | Изменения1049.1 сп2 | 141 |
24 | Изменения1049.1 сп3 | 145 |
25 | Изменения1049.1 сп4 | 148 |
26 | Изменения1049.1 сп5 | 151 |
27 | Изменения1049.1 сп6 | 153 |
28 | Изменения1049.1 | 158 |
29 | Изменения1049 | 175 |
30 | Изменения1050 сп1 | 185 |
31 | Изменения1050 сп2 | 190 |
32 | Изменения1050 сп4 | 193 |
33 | Изменения1050 | 196 |
34 | Изменения1051 сп1 | 206 |
35 | Изменения1051 сп2 | 210 |
36 | Изменения1051 сп3 | 215 |
37 | Изменения1051 сп4 | 218 |
38 | Изменения1051 сп5 | 223 |
39 | Изменения1051 сп6 | 224 |
40 | Изменения1051 | 229 |
41 | Изменения1052 сп1 | 240 |
42 | Изменения1052 сп2 | 246 |
43 | Изменения1052 сп3 | 250 |
44 | Изменения1052 | 251 |
Изменения функционала в версии 1.045 сервис пак 1.
ЕГАИС. Возврат немаркированной продукции с регистра склада без указания основания.
Накладные. Печатная форма Счет-фактуры.
Журнал сессий ТСД.
В прошлых версиях при формировании возврата немаркированной алкогольной продукции (пиво, сидр ...) с помощью функции «Формирование и отсылка ТТН в ЕГАИС» расходной накладной, когда в накладной не указаны основания товародвижения, возврат производился с остатков первого регистра с поиском подходящих документов ЕГАИС для возврата только среди актов постановки на баланс независимо от того, указан ли для места хранения учетный регистр «торговый зал», или «склад».
В текущей версии, если у места хранения в настройках почтового модуля установлен признак «Учетный регистр - Склад», то при выполнении функции для накладной без оснований товародвижения показывается диалог: 
При выборе опции «Подбор партий среди всех имеющихся в наличии» возврат будет формироваться с поиском подходящих документов ЕГАИС, как среди актов постановки на баланс, так и ТТН на приход.
Печатная форма счет-фактуры приведена в соответствие с Постановлением Правительства РФ от 02.04.2021 № 534
Добавлена таблица SSTerminalLog для хранения информации о событиях при работе с Супермаг Мобайл. Детальность журнала зависит от данных, посылаемых ТСД. Полный объем информации о событиях передается Супермаг Мобайл Андроид версии 2.1. 579.22 и старше.
Предусмотрена регистрация следующих событий:
0 Установка соединения
1 Потеря связи (переход в оффлайн)
2 Выбор режима работы
3 Начало работы
4 Передача данных на сервер
При передаче данных в поле «Комментарий» заносится информация о выполненном задании.
Для получения информации о событиях работы с СупермагМобайл в сервер обмена данных добавлен аналитический объект:
IOSMIOTERMINALLOG Журнал сессий ТСД JSON
Объект имеет параметры вызова: pLocId - перечень кодов мест хранения через запятую, pDateFrom и pDateTo - даты С и По диапазона времени событий. Дата/время в формате DD.MM.YYYY HH24:MI:SS
Пример вызова:
curl.exe -s -X GET http://192.168.25.38:8095/out/json/IOSMIOTERMINALLOG/*/pLocId=4/pDateFrom=
"06.07.2021%2000:00:00"/pDateTo="06.07.2021%2010:00:00"
%20 – замещает пробелы
Дополнительно добавлен аналитический объект:
IOSMIOSTORELOCATIONS Места хранения JSON
Параметр вызова pClassID – коды классификатора мест хранения через запятую.
Структуру объектов можно посмотреть в администраторе сервера обмена данных в диалоге «Настройка объектов обмена» дважды щелкнув мышью по строке с объектом.
Изменения функционала в версии 1.045 сервис пак 2.
Администратор сервера приложений. Настройки для мобильного принтера этикеток.
Печатные формы.
Счет-фактура.
Универсальный передаточный документ.
В текущей версии в настройках мобильного принтера этикеток в администраторе сервера приложений оставлен только выбор файла шаблона этикетки: 
остальные параметры перенесены в программу Супермаг Мобайл.
Это позволяет для каждого мобильного принтера установить подходящие для него параметры, например, кодировку текста, печатаемого принтером.
Также в текущей версии формирование ценника для печати на мобильном принтере полностью перенесено в программу Супермаг Мобайл. Теперь содержание ценника не будет зависеть от выбора способа доступа к принтеру – прямое соединение ТСД с мобильным принтером или соединение через сервер приложений. В прошлых версиях при печати через сервер приложений содержание ценника формировалось сервером приложений, а при прямом соединении программой Супермаг Мобайл.
Печатная форма счет-фактуры приведена в соответствие с Постановлением Правительства РФ от 02.04.2021 № 534.
Печатная форма универсального передаточного документа приведена в соответствие с Постановлением Правительства РФ от 02.04.2021 № 534.
Изменения функционала в версии 1.045 сервис пак 3.
Прием немаркированного товара по УПД.
УПД на отгрузку. Интерфейс.
Почтовый модуль. Функция импорта артикула XML файла.
Калькулятор цен для РБ.
В предыдущих версиях процесс приема товара с использованием документов УПД на приход - Накладная поставщика – Приходная накладная не учитывал возможности наличия в УПД немаркированных товаров. Считалось, что в УПД для всех товаров всегда имеются КИЗ.
В текущей версии поддержана работа с УПД, содержащими немаркированные товары. В тех случаях, когда делаются проверки на несовпадение количества поступившего и принятого товара и на возможность приема без контроля совпадения КИЗ (доверительного приема), теперь предварительно выясняется - относится ли принимаемый артикул к маркированным или немаркированным товарам. Для немаркированного товара правила проверки доверительного приема КИЗ игнорируются.
В интерфейсе заголовка документа «УПД на отгрузку» название элемента «Поставщик» заменено на «Клиент».
В почтовый модуль добавлена функция ArticleByBarcodeUI для определения артикула при импорте XML файла по содержанию поля, предназначенного для хранения EAN штрихового кода артикула и/или таблицы с КИЗ. 
Функция исследует значение поля для хранения штрихового кода. если поле содержит данные, то определяет артикул по штриховому коду, также как функция ArticleByBarcode. В противном случае функция исследует содержание таблицы с КИЗ и определяет артикул по содержанию первого попавшегося кода КИЗ (КИЗ содержит 14 символов GTIN товара после кода применения 01, из которого, в свою очередь, можно получить EAN товара отбрасыванием лидирующего нуля).
XSD схема должна содержать, как поле «BARCODE» (название может быть произвольным), так и таблицу с полем «MARCCODE», тогда как XML файл может содержать как оба поля, так и какое либо одно из них.
Функция ArticleByBarcodeUI предназначена, в первую очередь для обработки УПД на приход при приеме УПД от разных поставщиков, которые по разному формируют содержание документа.
Для законодательства «Беларусь» изменен алгоритм расчета цен для режима округления "Цена без налогов". Изменение внесено в связи с изменением в законодательстве. В предыдущих версиях ведущим полем для расчетов были поля «Цена производителя» и «Оптовая надбавка». Поле «Цена без налогов» пересчитывалось при изменении значения любого из них. Кроме того, поле «Цена без налогов» не округлялась до точности валюты: 
В текущей версии ведущим полем для расчета является поле «Цена производителя» и «Цена без налогов», то есть «оптовая надбавка» пересчитывается при изменении значения любого из этих полей и только при изменении значения поля «Оптовая надбавка» выполняется пересчет поля «Цена без налогов» на основании значения поля «Цена производителя». «Цена без налогов» теперь округляется до точности валюты, также как поля «Сумма без налогов» и «Сумма»:
Изменения функционала в версии 1.046 сервис пак 1.
Администратор сервера приложений. Отображение пользователей дополнительных кейсов.
ЕГАИС. Подсчет алкоголя ТСД. Функция экспорта «в расходную накладную с отсылкой кассового чека в ЕГАИС». Отсылка чека в 3-м формате.
УПД. Повторный прием УПД по протоколу «УПД фильтр». Проверка наличия приходной накладной.
Контрагенты. Собственный контрагент, поля "Номер GLN" и "КПП".
Почтовый модуль. Функция экспорта GLN места хранения и импорта места хранения по GLN и КПП.
Касса Супермаг. ККТ СП801-Ф. ФФД 1.2.+
Наценивание. Алгоритм «Средневзвешенная розничная цена».
Административный модуль. Настройка печати комплекта документов из процессов.
Протокол загрузки весов Check Way. Выгрузка даты производства.
В администраторе сервера приложений на закладке «Пользователи» теперь показывается информация о разрешенном лицензией количестве пользователей дополнительных кейсов и о пользователях, которые воспользовались функциями дополнительных кейсов: 
В разделе «Подсчет алкоголя ТСД» в функции «в расходную накладную с отсылкой кассового чека в ЕГАИС» кассовый чек ЕГАИС теперь формируется и отсылается в 3-м формате. Интерфейс для ввода параметров заголовка чека остался прежним: 
Прием УПД с помощью «УПД фильтра» в режиме «с созданием накладной поставщика по УПД» теперь реагирует на ошибочную ситуацию, когда УПД принимается повторно, в то время, как приходная накладная по предыдущему УПД еще не создана, то есть, первичный УПД имеется, накладная поставщика создана, а поставку еще не приняли и, следовательно, повторного УПД быть не должно. В этом случае повторный УПД не принимается с ошибкой почтового модуля, сообщающей о наличии такого документа.
Например: 
В разделе «Склады и магазины» можно описать GLN и КПП места хранения. Эта информация представлена на закладке «Общие»: 
В тех случаях, когда место хранение разделяется между несколькими собственными контрагентами, место хранения для каждого контрагента будет иметь свой собственный GLN и КПП.
Чтобы описать перечень значений GLN и КПП одного и того же места хранения для разных контрагентов в разделе «Контрагенты» в таблицу на закладке «Собственный контрагент» добавлены колонки «Номер GLN» и «КПП»: 
При назначении нескольких контрагентов одному месту хранения считается, что GLN места хранения контрагента обладает уникальностью. Таким образом не может быть двух одинаковых GLN у разных мест хранения или разных контрагентов. Также не может быть одинаковых КПП у разных контрагентов в отношении одного места хранения, но могут быть одинаковые КПП в отношении разных мест хранения.
В функции экспорта и импорта данных XML фильтра почтового модуля внесены следующие изменения:
К функциям экспорта добавлена функция LocationGLN2. Функция имеет два аргумента – код контрагента и код места хранения. Функция возвращает номер GLN (Global Location Number) собственного контрагента в привязке к месту хранения. Если для места хранения собственный контрагент не задан или у него отсутствует GLN, то экспортируется GLN места хранения.
В функции импорта LocationByGLN место хранения теперь ищется вначале по значениям GLN в таблице мест хранения собственных контрагентов, затем, если данные не будут найдены, по значениям GLN мест хранений. Если данных не будет найдено, или будет найдено несколько мест хранения, будет сгенерирована ошибка.
В функции импорта LocationByKPP (Возвращает код места хранения по его КПП)
вначале ищется место хранения по значению КПП мест хранения и, если такого не найдется, то по КПП в таблице мест хранений собственных контрагентов. Если будет найдено несколько мест хранения, будет сгенерирована ошибка.
В функции импорта LocationByINNKPP (Возвращает код места хранения по его КПП и по наличию контрагента с заданным ИНН среди собственных контрагентов места хранения) алгоритм изменен так, что вначале место хранения ищется по сочетанию КПП и собственного контрагента, который определяется по ИНН в таблице мест хранения собственных контрагентов. Если ничего не найдено, то место хранения ищется по его КПП, а если таких будет найдено несколько - по наличию контрагента с заданным ИНН среди собственных контрагентов места хранения (собственный контрагент может быть назначен месту хранения без указания собственного значения КПП).
В кассовую программу Супермаг+ внесены изменения для поддержки протокола ФФД 1.2 при работе с ККТ СП-801Ф.
Кассовая программа автоматически определяет текущую версию протокола ФФД, с которым работает ФН в ККТ, и взаимодействует с ККТ либо по протоколу для ФФД 1.05, либо по протоколу для ФФД 1.2.
\\ В свойства группы классификатора товаров добавлен флажок «Наценивание прямых приходов «Средневзвешенная розничная цена»»: \\ !worddavf5145e08cc4cafd40c0eb16480d0c9df.png|height=403,width=623! \\ Значение атрибута распространяется на все артикулы группы и артикулы подчиненных групп, если для них это значение не переопределено. Определить атрибут для отдельного артикула нельзя. \\ Если флажок отмечен, то при выполнении процедуры наценивания прихода (кнопка «Наценить и принять» в приходной накладной или функция «Генерация актов изменения цены ...» приходной накладной) для не комплексных артикулов отмеченных групп будет выполняться алгоритм наценивания «Средневзвешенная розничная цена» вместо стандартного алгоритма наценивания. Алгоритм выполняется только для вида цены для кассы места хранения прихода. Для прочих видов цен действует стандартный алгоритм наценивания. \\ В алгоритме «Средневзвешенная розничная цена» новая цена считается стандартным образом, округляется, а затем корректируется по следующей формуле: \\ \[Новая цена\] = (\[Новая цена по стандартному алгоритму\] * \[Количество прихода\] + \[Текущая цена\] * \[Логистический остаток\]) / (\[Количество прихода\] + \[Логистический остаток\]), \\ Где \[Логистический остаток\] – это текущий остаток (без учета количества текущей поставки) за вычетом потерь и оперативных продаж, отрицательное значение обнуляется. \\ Дальше происходит округление цены по стандартному алгоритму. \\ Новый алгоритм применим только к прямым поставкам в место хранение и предназначен для сглаживания колебаний цены товаров с высоким удельным оборотом. \\ |
В административный модуль в раздел «База данных» на закладку «Конфигурация» добавлена группа данных «Печать из процессов ТСД»:
Для процессов «Прием по заказу ТСД» и «Произвольный подсчет ТСД» можно задать перечень и количество копий печатных форм, которые будут печататься автоматически по факту формирования документа с указанной операцией: 
Производитель весов Check Way расширил протокол весов в части загрузки дат возможностью загрузки прошлых дат. Это позволило модифицировать протокол загрузки весов и добавить в него загрузку даты производства. Для загрузки в весы даты производства надо отметить флажок в диалоге «Параметры загрузки весов» процедуры загрузки:
Флажок можно использовать для весов с обновленной прошивкой.
Дополнительно, в диалог настройки весов добавлен выбор номера структуры, в которой описывается способ формирования весового штрихового кода. Стандартные (системные) структуры с номерами до 9 включительно непригодны для использования. Для корректной печати весовых штриховых кодов необходимо загрузить в весы и использовать подходящие структуры: 
Изменения функционала в версии 1.046 сервис пак 2.
ЕГАИС. Отсылка акта постановки на баланс с причиной «Пересортица».
Калькуляция. Функция «Заполнить документ ценами последнего прихода».
Заказ в торговом зале ТСД. Нормирование количества заказа
Административный модуль. Печать из процессов ТСД
Поведение элемента выбора мест хранений при запрете просмотра мест хранений.
При отсылке в ЕГАИС акта постановки на баланс в торговом зале с причиной «пересортица» в Супермаг+ делается проверка, что в акте заполнено поле «Идентификатор акта списания в ЕГАИС» и в Супермаг+ имеется документ «Акт списания из торгового зала» с причиной «пересортица» и со значением поля «Ид. акта в ЕГАИС» таким же, как это указано в акте постановки на баланс.
Акт списания из торгового зала можно оформить, как документом «Акт списания из торгового зала», так и документом «ТТН ЕГАИС на отгрузку». Для использования ТТН ЕГАИС в качестве акта списания ТТН надо создать функцией «Формирование и отсылка ТТН в ЕГАИС» для расходной накладной с операцией «Списание», и определить в ТТН ЕГАИС основание списания «пересортица».
В прошлых версиях проверка наличия акта списания для акта постановки на баланс в торговом зале велась только среди документов «Акт списания из торгового зала». В текущей версии поиск ведется, как среди актов списания из торгового зала с причиной «пересортица», так и среди ТТН ЕГАИС на расход с операцией «Акт списания из торгового зала» и причиной «пересортица».
В алгоритм функции «Заполнить документ ценами последнего прихода» внесено изменение.
В прошлых версиях для поиска последних приходов использовалось место хранение документа и старшее для него место хранения.
В текущей версии для артикула каждого пункта спецификации калькуляции определяется наличие действующего обязательства склада, среди мест хранения поставки которого есть место хранения калькуляции. При его наличии, старшим местом хранения для артикула будет локальный склад из обязательства склада.
В процессе «Заказ в торговом заде ТСД» при получении журнала подсчета потребности в товаре из программы Супермаг Мобайл может быть создан документ «Заказ поставщику». При создании заказа поставщику в него помещается количество потребности товара. В прошлых версиях это количество всегда равнялось той величине, которая приходила из программы ТСД. В текущей версии количество заказа нормируется по условиям соглашения о поставках для артикула заказа. Под нормированием понимается округление количества заказа до размера упаковки заказа. Округление производится в ближайшую строну, за исключением случая, когда после округления получается ноль упаковок. В этом случае заказывается одна упаковка заказа.
В предыдущей версии в административный модуль было добавлено управление перечнем печатных форм и количеством копий для печати по факту генерации документа в процессе ТСД. В текущей версии в настройку перечня форм внесены следующие изменения:
Для приходной накладной добавлен выбор формы «форма внутреннего учета». 
Для расходной накладной убран выбор формы «акт на списание товара»: 
Возвращено прежнее поведение элемента выбора места хранения: в нем будут отображаться все места хранения, т.е. не будут учитываться права должности на просмотр мест хранения.
Изменения функционала в версии 1.046 сервис пак 3.
ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.
Формирование пакета заказов на базе контракта. Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.
Весы самообслуживания. Загрузка групп PLU.
Заказ в торговом зале ТСД. Передача данных об упаковке заказа.
При создании ТТН на отгрузку на основании расходной накладной или накладной на перемещение без оснований товародвижения, каждому отгружаемому артикулу необходимо поставить в соответствие код алкогольной продукции. Код алкогольной продукции в ТТН на отгрузку однозначно определяется для артикула маркированного алкоголя по алкогольной марки, которая берется из присоединенного процесса «Подсчет алкоголя ТСД», для немаркированного алкоголя берется из карточки товара, если артикулу соответствует единственный код алкогольной продукции. В противном случае поле «Алк. код» в ТТН останется незаполненным и отсылка ТТН будет невозможна.
В прошлых версиях для определения кодов алкогольной продукции для операций списания был создан алгоритм автоматического подбора кодов алкогольной продукции. Подбор выполняется в момент отсылки ТТН. Алгоритм определяет код алкогольной продукции на основании информации о текущих остатках, соответственно, торгового зала или склада.
В текущей версии действие алгоритма распространено на ТТН с операцией «продажа». Алгоритм работает, как для операций регистра торгового зала (списание, кассовая реализация), так и операций регистра склада (списание, продажа).
В версии Супермаг+ 1.042 при создании процесса «Формирование пакета заказов на базе контракта» в случае, когда процесс создается на базе маркетингового соглашения о поставке, из спецификации процесса перестали исключаться артикулы, не входящие в номенклатуру места хранения. Это было сделано для того, чтобы была возможность включать в заказ для маркетинговых поставок новые, пробные артикулы.
В текущей версии исключение артикулов управляется настройкой (Административный модуль - База данных – Конфигурация - Заказы поставщикам): 
По умолчанию флаг «Для процесса на базе маркетингового контракта не исключать артикулы, не входящие в номенклатуру места хранения» не установлен.
Для весов самообслуживания с сенсорными экранами для выбора товара реализована возможность использования групп ассортиментов в дополнение к группам номенклатур для загрузки в весы групп PLU. Выбор группы номенклатуры или ассортимента осуществляется в настройках весов на закладке «Свойства модели»: 
Тип выбранной группы индицируется префиксом: «ном.» - группа номенклатуры, «асс.» - группа ассортимента.
В текущей версии для выполнения заказа в торговом зале в программу ТСД дополнительно передается информация об упаковке заказа. Информация берется из действующего соглашения о поставке. Если на текущий момент действует как основное, так и маркетинговое соглашение о поставке, данные берутся из маркетингового соглашения.
Изменения функционала в версии 1.046
Лицензирование.
ЕГАИС.
Коды марок ЕГАИС. Перечень типов марок.
Грузораспорядители. Участники обмена УПД.
Функция проверки «Контроль заполнения грузораспорядителей в расходной накладной».
Печать грузоотправителя и грузополучателя.
Дополнительная характеристика контрагента «Идентификатор участника обмена УПД»
Экспорт. Выгрузка кода и названия грузораспорядителей.
УПД на отгрузку. Обмен с провайдером.
УПД на приход. Содержание файла ответа.
УПД. Заголовок документа.
КИЗ в процессах и документах.
Добавление КИЗ в спецификацию документов.
Упаковочные листы с КИЗ.
Произвольный подсчет ТСД. Упаковочный лист.
Касса Супермаг.+
Чек ЕГАИС. Формат 3.
ККТ СП802-Ф. ФФД 1.2
Проверка права продажи акцизного товара в ФН.
Контракты с поставщиками. Функция «Создать маркетинговый контракт».
Накладные. Диалог «Справка к ГТД/ТТН, Сертификат соответствия».
Подсчет товаров ТСД. Отгрузка заказа ТСД. Отгрузка перемещения ТСД. Управление статусом создаваемых документов.
Отгрузка заказа ТСД. Отгрузка перемещения ТСД. Смена статуса документа основания отгрузки.
Карточки. Контрагенты. Места хранения. Поиск в таблице данных.
Сервер обмена данными. Пользовательские аналитические данные.
Драйвер касс «УКМ4 XML». Выгрузка в кассу признака подакцизного товара.
Почтовый модуль. Функция экспорта в XML-пакет.
Административный модуль. Утилита «Исчерпание диапазона номеров документов».
Перечень исправленных ошибок и улучшений.
В текущей версии внесены изменения в систему лицензирования прав доступа к функциям Супермаг+. В прошлых версиях лицензия описывала перечень прав и количество сотрудников, которые могут пользоваться этими правами и, опционально, дату окончания действия лицензии. В текущей версии введено понятие основного и дополнительных кейсов, совокупность которых формирует лицензию. Каждый кейс описывает перечень прав и количество пользователей, которые могут пользоваться этими правами. Лицензия всегда включает основной кейс и может включать множество дополнительных кейсов.
Основной кейс описывает перечень прав на базовые функции системы и общее количество пользователей, которые могут пользоваться Супермаг+.
Дополнительный кейс описывает перечень прав на функции системы, которые предоставляются в дополнение к перечню прав основного кейса, и количество пользователей, которые могут воспользоваться дополнительными правами. Количество пользователей дополнительного кейса не увеличивает общее количество пользователей системы, которое описано в основном кейсе. Это те пользователи основного кейса, которым предоставлены дополнительные права.
Если лицензия содержит только основой кейс, она совпадает по формату и содержанию с прежней лицензией и может загружаться в сервер приложений предыдущих версий. Лицензия, содержащая дополнительные кейсы, может быть загружена только в сервер приложений текущей версии или более старших версий.
Ограничение срока действия, если оно указано в лицензии, распространяется, как и прежде, на всю лицензию.
Сохранены понятия основной и дополнительной лицензий, которые позволяли в прошлых версиях загружать две разные лицензии, каждая со своим независимым перечнем прав и количеством пользователем. В текущей версии в качестве основной лицензии можно загрузить как лицензию, содержащую дополнительные кейсы, так и лицензию, состоящую только из основного кейса. В качестве дополнительной лицензии можно загрузить лицензию, состоящую только из основного кейса.
В администраторе сервера приложений интерфейс отображения количества доступных и занятых пользователей остался прежним и показывает количество пользователей основного кейса.
В разделе «Коды марок ЕГАИС» можно запросить новые коды алкогольных марок для продукции с нечитаемыми марками старого образца (PDF417). Для этого необходимо считать с марки визуальную информацию и для каждого экземпляра продукции заполнить серию и номер акцизных и специальных марок и указать тип марки: 
В текущей версии перечень типов марок дополнен следующим списком:
187 ФСМ. «Алкогольная продукция свыше 9% до 0,5 л»
188 ФСМ. «Алкогольная продукция свыше 9% до 0,75 л»
189 ФСМ. «Алкогольная продукция свыше 9% свыше 0,75 л»
190 ФСМ. «Напитки алкогольные до 0,75 л»
191 ФСМ. «Напитки алкогольные свыше 0,75 л»
192 ФСМ. «Вина»
193 ФСМ. «Вина игристые (шампанские)»
194 ФСМ. «Вина ликерные»
195 ФСМ. «Алкогольная продукция плодовая»
196 ФСМ. «Алкогольная продукция до 9%»
197 ФСМ. «Алкогольная продукция свыше 9% до 0,1 л»
198 ФСМ. «Алкогольная продукция свыше 9% до 0,25 л»
В заголовок расходной, приходной накладных, УПД на приход и УПД на отгрузку добавлена закладка «Грузораспорядители». На закладке можно задать контрагентов грузоотправителя и грузополучателя, если они отличаются от контрагентов поставщика и плательщика, а также можно задать идентификаторы участников обмена электронного документооборота: 
При приеме УПД поля «Грузоотправитель», «Грузополучатель», «Собственный идентификатор участника обмена УПД» и «Идентификатор контрагента - участника обмена УПД» заполняются данными электронного УПД. В дальнейшем эти значения предполагается копировать в связанную с УПД приходную накладную. В текущей версии это не реализовано.
При заполнении этих полей в расходной накладной информация из них используется при создании УПД на отгрузку и, в дальнейшем, для заполнения обязательных полей электронного УПД при отсылке провайдеру ЭДО.
Если поля «Грузоотправитель» или «Грузополучатель» в расходной накладной не заполнены, то грузоотправителем будет считаться собственный контрагент расходной накладной, а грузополучателем - клиент расходной накладной.
Значение поля «Собственный идентификатор участника обмена УПД» можно не заполнять, если в настройках почтового модуля или сервера обмена данных имеется единственный абонент с фильтром УПД. В этом случае идентификатор участника обмена будет взят из атрибутов фильтра. Если поле заполнено, то УПД будет отослан тому абоненту, у которого в настройках фильтра УПД будет то же значение идентификатора участника ЭДО.
Значение поля «Идентификатор контрагента - участника обмена УПД» надо заполнять при использовании фильтра УПД ФНС XML. При использовании других фильтров УПД идентификатор контрагента - участника обмена ЭДО обычно проставляется в электронный УПД провайдером ЭДО, и заполнять его в УПД на отгрузку не обязательно.
Создана новая функция проверки 238 «Контроль заполнения грузораспорядителей в расходной накладной». По умолчанию функция находится в режиме «Отключена». Проверка срабатывает при смене статуса с «Отпущен со склада» до «Отпущен полностью», если в документе не указан грузоотправитель или грузополучатель.
Грузоотправитель и грузополучатель используются при печати документа и задаются в диалоге старта печатной формы: 
В прошлых версиях существовал способ запоминания грузоотправителя и грузополучателя для печати документа, если они отличались от поставщика и плательщика. Это делалось с помощью функций «сохранять контрагентов в документе» и «печать контрагента документа». В текущей версии эти функции удалены. Теперь, если в заголовке документа зафиксированы грузоотправитель и грузополучатель, они выводятся по умолчанию в интерфейсе печати документа, если их в заголовке документа нет, то в качестве грузоотправители и грузополучателя выводятся поставщик и плательщик.
В справочник дополнительных характеристик контрагентов добавлена системная дополнительная характеристика «Идентификатор участника обмена УПД» (Sys.SupplierUTDID).
Если для контрагента задано значение характеристики, то в расходной накладной необязательно заполнять поле «Собственный идентификатор участника обмена УПД» и/или «Идентификатор контрагента - участника обмена УПД». Эти данные будут автоматически подставлены в документ УПД на отгрузку, в случае его автоматического создания при смене статуса расходной накладной на «Отпущен полностью». Условия автоматического создания УПД на отгрузку см. раздел «УПД на отгрузку. Обмен с провайдером».
В разделе «Экспорт» в объект выгрузки «Документы/проводки» добавлены колонки для выгрузки кодов и наименований грузоотправителя и грузополучателя.
Реализован обмен с провайдером ЭДО при отгрузке маркированного и немаркированного товара. Общая схема формирования отгрузки и документооборота с контрагентом выглядит следующим образом:
\\
В файл ответа с результатом приема по УПД на приход (REPLY) добавлен тэг <ANSWERTYPE>, который может принимать значения «УПД» или «УКД». Например:
\\
<?xml version="1.0" encoding="UTF-8"?>
<PACKAGE name="7f6a074e-7152-401b-a434-bdd40c347f7f">
<REPLY description="Результат приемки">
<ID>UI0000000062</ID>
<CREATEDAT>2022-02-01</CREATEDAT>
<RESULT>2</RESULT>
<ANSWERTYPE>УПД</ANSWERTYPE>
<EDOID>3897523747</EDOID>
<SUPPLIERDOC>185</SUPPLIERDOC>
<SUPPLIERINVOICE>
</SUPPLIERINVOICE>
<SUPPLINVOICECREATE>
</SUPPLINVOICECREATE>
<CLIENTINN>7730107662</CLIENTINN>
<CLIENTKPP>772901001</CLIENTKPP>
<CLIENTGLN>AUD35</CLIENTGLN>
<OURCLIENTINN>7724308434</OURCLIENTINN>
<OURCLIENTKPP>772401001</OURCLIENTKPP>
<OURCLIENTGLN>Sem_CM</OURCLIENTGLN>
<LOCATIONGLN>sem_4</LOCATIONGLN>
<ACCEPTED docWI="1МС0467">
<ITEM>
<BARCODE>46200020</BARCODE>
<QUANTITY>20</QUANTITY>
<ARTICLE>000029</ARTICLE>
<SPECITEM>1</SPECITEM>
<DISPLAYITEM>1</DISPLAYITEM>
<BARCODEEXTERNAL>46200020</BARCODEEXTERNAL>
<ITEMPRICE>255</ITEMPRICE>
<ITEMPRICENOTAX>212.50</ITEMPRICENOTAX>
<CARDFULLNAME>Сигареты</CARDFULLNAME>
<CARDMEASUREMENTCODE>796</CARDMEASUREMENTCODE>
<VATRATE>20</VATRATE>
<VATSUM>850</VATSUM>
<TOTALPRICE>5100</TOTALPRICE>
<TOTALPRICENOTAX>4250</TOTALPRICENOTAX>
<MARKS>
<MARKCODE>010460143993125621nNc3bUI8005122000</MARKCODE>
<MARKCODE>010460143993125621pz>,!A:</MARKCODE>
</MARKS>
</ITEM>
<ITEM>
<BARCODE>4606203086627</BARCODE>
<QUANTITY>10</QUANTITY>
<ARTICLE>000999</ARTICLE>
<SPECITEM>2</SPECITEM>
<DISPLAYITEM>2</DISPLAYITEM>
<BARCODEEXTERNAL>4606203086627</BARCODEEXTERNAL>
<ITEMPRICE>143</ITEMPRICE>
<ITEMPRICENOTAX>119.1670</ITEMPRICENOTAX>
<CARDFULLNAME>Winston Silver</CARDFULLNAME>
<CARDMEASUREMENTCODE>796</CARDMEASUREMENTCODE>
<VATRATE>20</VATRATE>
<VATSUM>238.33</VATSUM>
<TOTALPRICE>1430</TOTALPRICE>
<TOTALPRICENOTAX>1191.67</TOTALPRICENOTAX>
<MARKS>
<MARKCODE>010460720309891021nNc3bUI8005122000</MARKCODE>
</MARKS>
</ITEM>
</ACCEPTED>
</REPLY>
</PACKAGE>
\\
В текущей версии тэг всегда будет принимать значение «УПД». Тэг добавлен для будущих версий, когда помимо исправительных УПД будут приниматься УКД (корректировочные документы).
\\
Помимо этого, для формирования содержания тэга <MARKCODE> более на используется тэг «CDATA». В прошлых версиях содержание тэга выглядело так:
\\
<MARKCODE>
<!\[CDATA\[ 010460143993125621pz>,!A: \]\]>
</MARKCODE>
\\
Теперь так:
\\
<MARKCODE>010460143993125621pz>,!A:</MARKCODE>
\\
Изменение внесено в связи с тем, что содержание тэга <MARKCODE> формируется по правилам ЦРПТ и не содержит нечитаемых символов.
\\ |
В процессе «Подсчет кодов КИЗ ТСД» при сканировании кода КИЗ из него извлекается код EAN и по нему идентифицируется артикул и количество товара, которое маркировано КИЗ. В случае, когда EAN код из КИЗ не обнаруживается в базе данных, показывается сообщение, например: 
Если нажать «Да», то показывается диалог, в котором можно определить артикул, просканировав EAN код на упаковке товара, или выбрав артикул вручную, и можно указать количество товара, которе идентифицируется КИЗ: 
Здесь надо обратить внимание на то, что если КИЗ нанесен на упаковку товара, то в поле «Штрихкод» можно сканировать EAN единицы товара и это будет корректно для идентификации артикула, но в этом случае надо будет поправить значение количества. 
Если КИЗ, нанесенный на товар или упаковку товара заведомо не является групповым, то есть не был выдан для маркировки остатков, можно отметить флажок «Сохранить штрихкод «….» из марки в карточке товара». Тогда при нажатии на кнопку «Ввод» одновременно с заполнением спецификации процесса произойдет добавление нового штрихового кода в карточку товара.
Штриховой код сохраняется в карточке товара со следующими параметрами: 
В момент сохранения штрихового кода диалог с параметрами не показывается. Если параметры штрихового кода отличаются от стандатных, их необходимо поправить в разделе карточек складского учета.
В разделе «Прием по заказу ТСД» в интерфейсе экземпляра процесса на закладке «Спецификация» в таблицу спецификации основания процесса (заказа поставщику) добавлена колонка «Накл. пост.», в которой выводится количество артикула из накладной поставщика, по которой был выполнен прием поставки: 
В разделе «Контроль остатков ТСД» в функцию печати для экземпляра процесса добавлен выбор печати спецификации процесса: 
В печатной форме выводится содержание спецификации с колонками «Количество», «Цена для кассы» и «Сумма». Подводится итог по сумме. 
В процессе «Контроль остатков ТСД» перед началом подсчета определяется перечень артикулов, для которых будет проводится проверка. Перечень определяется выбором группы товаров, номенклатуры или с использованием планограммы. При подсчете товаров часть артикулов из списка может быть не обнаружена и тогда перечень артикулов спецификации будет отличаться от перечня артикулов журнала, а их количество в спецификации будет равно нулю.
В административный модуль в разделе «База данных» на закладку «Конфигурация» в группу данных «Печать из процессов ТСД» добавлена опция «Контроль остатков ТСД» с типом документа «Спецификация процесса»: 
Если в настройке печати указать количество копий отличное от нуля, то при завершении процесса в программе ТСД и передаче данных на сервер будет выполнена печать спецификации процесса.
Опция применима для программы Супермаг Мобайл с версии 2.1.798.28 и 1.6.2262.34
В разделе «Заказ в торговом зале ТСД» на закладке «Спецификация» экземпляра процесса показывается колонка «Предл. Зак.». Значение колонки вычисляется по значениям других колонок как: «Зал» + «Максимум» - «Остаток». В текущей версии при вычислении предложения заказа если остаток отрицательный, то он принимается равным нулю.
Аналогичные изменения были внесены в программу Супермаг Мобайл с версии 2.1.789.23 и 1.6.2220.24
Изменения функционала в версии 1.047 сервис пак 2.
Подсчет кодов КИЗ ТСД. Контроль принимаемых КИЗ.
Прием заказа ТСД. Прием на основании УПД.
Приходная накладная. Мастер создания.
Контракт с поставщиком. Информация о соглашениях о поставках.
В интерфейс процесса подсчета кодов ТСД добавлена закладка «Контроль принимаемых КИЗ». Закладка показывается в случае, когда подсчете кодов КИЗ ведется на основании УПД на приход или на основании накладной поставщика.
В закладке показывается полный список КИЗ документа – основания подсчета и отметка того, что КИЗ был просканирован в процессе подсчета. Сканировать КИЗ можно не только находясь на закладке «Журнал», но и, в том числе, находясь на закладке «Контроль принимаемых КИЗ». Тогда отметки просканированных КИЗ будут сразу показаны на экране. 
На экране «Контроль принимаемых КИЗ» нет возможности принимать данные от сканера, работающего в разрыв клавиатуры. Для работы с таким сканером надо перейти на закладку «Журнал».
При использовании сканера «в COM порт» работа с КИЗ, в том числе содержащими новый или групповой код EAN, можно проводить, не покидая закладки «Контроль принимаемых КИЗ».
В процесс приема товара по заказу ТСД добавлена возможность принимать результаты подсчета, выполненные на основании заказа и УПД на приход: 
Для приема заказа с контролем количества поставки и кодов КИЗ по содержанию УПД была также модифицирована программа Супермаг Мобайл Андроид. Функциональность доступна с версии 2.1.816.32.
\\ В прошлых версиях в мастере создания приходной накладной (страница «\[на основании заказа\]») значение опции «Заполнять спецификацию товарами из заказа / накладной поставщика» запоминалось и предлагалось при следующем обращении к мастеру: \\ !worddav9664605d6bea865581acc14fe05e653d.png|height=246,width=362! \\ В текущей версии значение опции не запоминается и при создании документа всегда устанавливается в положение «не отмечено». \\ Название опции дополнено словом «… / УПД», что означает, что при создании приходной накладной на основании заказа могут использоваться не только накладные поставщика, но и УПД, созданные на основании заказа. \\ УПД при создании приходной накладной используются также, как и накладные поставщика. \\ УПД на приход предлагается использовать, если на основании заказа поставщику нет ни одной накладной поставщика в статусе «Принят». Если накладная поставщика имеется, у нее будет приоритет использования по отношению к УПД. Это позволяет сохранять преемственность работы с данными, оставшимися от предыдущих версий, когда при приходе УПД автоматически создавалась накладная поставщика. Если будет обнаружено несколько УПД, например, когда заказ поставляется частями, будет предложен диалог с возможностью выбора УПД по номеру и дате документа поставщика: \\ !worddavda40adc11ec6608579b84a77c2bd86d2.png|height=229,width=336! \\ При использовании УПД на приход, также как в случае использования накладной поставщика, КИЗ из УПД в приходную накладную не переносятся. \\ При использовании опции «Заполнить поле «Цена»» необходимо учитывать, что УПД принимается в том виде, в котором ее заполнил поставщик и, если он допустил грубые ошибки в расчете сумм, создание приходной накладной может быть заблокировано с показом соответствующей ошибки. \\ |
В интерфейс заголовка документа «Контракт с поставщиком» на закладке «Соглашения о поставках» в таблицу соглашений о поставках добавлены колонки «Количество мест поставки» и «Количество позиций»: 
Дополнительно разрешена сортировка строк по значению статуса.
Изменения функционала в версии 1.047 сервис пак 4.
Алкогольная декларация. Изменение XSD схемы файлов 7 и 8.
Контрагент по умолчанию для операций с розничным клиентом.
Подсчет товаров ТСД. Создание документа «Заказ от клиента».
Прием заказа ТСД. Изменение интерфейса для работы с УПД.
Подсчет кодов КИЗ ТСД. Функция экспорта данных «в приходную накладную». Простановка цен.
Сервер приложений. Журнализация процесса регистрации начала работы с ТСД.
В XSD схемах деклараций 7 «Декларация об объемах закупки этилового спирта, алкогольной и спиртосодержащей продукции» и 8 «Декларация о перевозках этилового спирта, алкогольной и спиртосодержащей продукции» для типа данных "П000000000003" «Код вида продукции» изменилось ограничение на длину кода с 3 до 5 символов. Соответствующее изменение внесено в процедуру генерации деклараций.
В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Документы» название атрибута «Контрагент по умолчанию для возврата от покупателя» заменено названием «Контрагент по умолчанию для розничного клиента»: 
Изменение названия связано с раширением обрасти применения атрибута. Первоначально атрибут предназначался для для подстановки контрагента в приходную накладную с операцией возврата от покупателя в тех случаях, когда документы создавались и регистрировались автоматически. В более поздних версиях атрибут стал применяться в случаях, когда бизнес процессы автоматического создания документов подразумевали отношения с розничным покупателем, в частности, при создании заказа от клиента, как пречека, например, при торговле по образцам.
В процессе «Подсчет товаров ТСД» изменен бизнес процесс работы с документом «Заказ от клиента». В прошлых версиях при получении от ТСД журнала с операцией «Заказ от клиента» создавался документ «Заказ от клиента» со статусом «Черновик».
В текущей версии название операции «Заказ от клиента» заменено названием «Сбор заказа клиента / пречек». Процесс «Подсчет товаров ТСД» подразумевает, что оператор видит, сканирует и регистрирует реальный наличествующий товар или товар представленный в виде образцов, и результат его работы может быть использован для формирования платежа и передачи клиенту партии товара.
В текущей версии ожидается, что программа ТСД передаст в экземпляр процесса данные, как о товарах и их количестве, так и о КИЗ маркированных товаров, чтобы созданный в процессе документ «Заказ от клиента» можно было бы передать кассовой программе для формирования чека.
Документ «Заказ от клиента» теперь создается в статусе «Согласован», в него проставляется клиент «Контрагент по умолчанию для розничного клиента» из настроек административного модуля (База данных->Конфигурация->Документы), вид платежа устанавливается в значение «Наличный / банковская карта», затребованное количество устанавливается равным собранному количеству.
В прошлых версиях была реализована возможность использования УПД в роли накладной поставщика при приеме заказа программой ТСД. В текущей версии интерфейс процесса доработан для того, чтобы в случае, когда основанием процесса является УПД, а не накладная поставщика, показывать данные из УПД в элементах интерфейса, в которых показывались данные накладной поставщика: 
В прошлых версиях функция экспорта данных «в приходную накладную» в процессе «Подсчет кодов КИЗ ТСД», либо проставляла цены из документа основания процесса, либо, в случае его отсуствтия, проставляла цены для кассы места хранения. В текущей версии, если у процесса нет основания, то в документ проставляются нулевые значения цены.
В код процедуры регистрации начала работы с программой ТСД добавлен вывод в журнал сервера информации о ходе выполнения процедуры LoadLocAndDatabaseDate. Процедура выполняет проверку возможности соединения с базой данных и считывает из базы данных информацию о локальных местах хранения для передачи их программе ТСД. Информация о ходе работы функции сохраняется в журнале в режиме работы «Детально».
Журнализация работы функции позволяет корректно диагностировать причину отказа программы ТСД в регистрации на сервере приложений. В случае медленной работы базы данных, когда отклик на запросы функции длится более минуты, программа ТСД принимает решение о неработоспособности базы данных и прекращает попытку установления соединения. Такое поведение может быть неверно воспринято, как отказ сервера приложений.
Изменения функционала в версии 1.047 сервис пак 5.
Накладные. Диалог редактирования ГТД / ТТН и сертификатов.
Функция нормирования количества заказа.
В версии 1.046 в приходных, расходных накладных и накладных на перемещение было внесено изменение в диалог «Справка к ГТД/ТТН, Сертификат соответствия». До изменения диалог использовался для редактирования полей спецификации «Справка к ГТД / ТТН», «Сертификат» и «Акциз». Из диалога был убран флаг «Акциз», который позволял ввести множество строк с перечнем акцизных марок. Как следствие, диалог стал однострочным, то есть стало можно ввести одно значение справки ГТД / ТТН и одно значение сертификата.
В текущей версии диалог изменен, чтобы поддержать ввод множества строк с номерами справок к ГТД / ТТН и сертификатами: 
Колонка с кнопкой «Выбор Сертификата» позволяет обратиться к функции выбора подходящего документа «Сертификат/Декларация соответствия», чтобы выбрать номер сертификата и добавить его в выбранную строку таблицы. 
В процессе «Формирование пакета заказа на базе контрактов», в разделе «Заказ поставщику» и в процессе «Заказ в торговом зале ТСД» исправлены функции нормирования количества заказа по условиям соглашения о поставке. Теперь округление количества заказа до размера упаковки заказа происходит в ближайшую сторону, а не в большую.
Изменения функционала в версии 1.047
Справочник «Классификатор ОКПД2».
Карточки складского учета. Группа классификатора ОКПД2.
ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.
Прием УПД. Режим приема УПД.
Функция проверки «Контроль наличия УПД при принятии приходной накладной»
Почтовый модуль. Протокол «УПД фильтр». Квитанция провайдера ЭДО.
Приходная накладная. Индикация состояния обмена УПД. Фильтр документов по состоянию обмена.
Накладная на перемещение. Регистрация КИЗ при перемещении товара.
Функция проверки «Контроль наличия КИЗ для маркированных товаров».
Функция проверки «Контроль статуса УПД / накладной поставщика при разоприходовании приходной накладной».
Подсчет кодов КИЗ ТСД. Экспорт данных в накладную на перемещение.
Резервирование товара документом «Заказ от клиента» в статусе «Согласован».
Документы. Функция «Упорядочить №№»
Формирование пакета заказов на базе контракта.
Цены маркетинговых контрактов.
Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.
Весы самообслуживания. Загрузка групп PLU.
Контроль остатков ТСД. Автоматическая генерация документов.
Контроль зала ТСД.
Отгрузка заказа ТСД.
Административный модуль.
Маркировка. Опция «Учет кодов КИЗ при приемке и отгрузке товаров».
Периоды. Интерфейс страницы.
Процедура обрезки базы данных.
Перечень исправленных ошибок и улучшений.
В раздел «Справочники» в группу справочников «Карточки» добавлен справочник «Классификатор ОКПД2». 
Справочник требуется заполнить самостоятельно теми данными, которые предполагается использовать. Группы классификатора, которые использовать не предполагается, например, слишком общие, как 10.5 в примере выше, или неприменимые к торгуемой продукции, заносить в справочник не следует. Это может привести к ошибкам в назначении групп классификатора товарам.
Для работы со справочником необходимо иметь функциональное право «Редактирование классификатора ОКПД2».
В разделе «Карточки складского учета» на закладку «Классификация» добавлено назначение артикулу группы классификатора ОКПД2: 
Назначить группу классификатора списку артикулов можно в функции «Изменение классификации» кнопки «Обработать»: 
Для поиска арткулов по значению группы классификатора ОКПД2 добавлен элемент «ОКПД2» в закладку «Прочее» фильтра карточек: 
Для отображения кода классификатора ОКПД2 в таблице отобранных карточек в диалог кнопки «Поля» добавлен флаг «Код ОКПД2»: 
Примечание: добавление нового поля в таблицу отобранных карточек привело к необходимости изменения внутренней архтектуры кода для отображений полей. В связи с этим настройки отбражения полей при обновлении версии будут сброшены и будут показываться только поля по умолчанию – артикул, название, тип карточки. После обновления потребуется заново отметить те поля, которые необходимо показывать в таблице. Настройка полей, отображающих дополнительные характеристики, не изменится.
При создании ТТН на отгрузку по расходной накладной или накладной на перемещение без оснований товародвижения, каждому отгружаемому артикулу необходимо поставить в соответствие код алкогольной продукции. Код алкогольной продукции в ТТН на отгрузку однозначно определяется для артикула маркированного алкоголя по алкогольной марки, которая берется из присоединенного процесса «Подсчет алкоголя ТСД» или, для немаркированного алкоголя, если в карточке товара артикулу соответствует единственный код алкогольной продукции. В противном случае поле «Алк. код» в ТТН будет пустым и отсылка такой ТТН без предварительного определения кода алкогольной продукции невозможна.
В прошлых версиях для определения кодов алкогольной продукции для операций списания был создан алгоритм автоматического подбора кодов алкогольной продукции. Подбор выполняется в момент отсылки ТТН. Алгоритм определяет код алкогольной продукции на основании информации о текущих остатках, соответственно, торгового зала или склада.
В текущей версии действие алгоритма распространено на ТТН с операцией «продажа». Алгоритм работает, как для операций регистра торгового зала (списание, кассовая реализация), так и операций регистра склада (списание, продажа).
Дополнительно, расширено действие функции «Подбор кодов алкогольной продукции». В прошлой версии она применялась только для ТТН на списание, созданных на основании кассовых документов. В текущей версии её действие распространено на все ТТН на списание и на продажу.
В прошлых версиях функция отсылки ТТН, прежде чем проводить анализ остатков для определения алкокодов, выполняла запрос в ЕГАИС для получения текущих актуальных остатков и начинала свою работу только после получения ответа из ЕГАИС. Если ЕГАИС присылал ошибку таймаута, функция использовала ранее полученные остатки с их коррекцией по документам, зафиксированным в ЕГАИС после времени получения остатков.
В текущей версии поведение функции изменено, чтобы избежать ожидания ответа от ЕГАИС. Функция проверяет факт наличия информации об остатках и их давность. Если остатки были считаны более суток назад, функция показывает сообщение о необходимости их обновления и запускает процесс обновления остатков, но не ожидает их получения, а позволяет продолжить работу со старыми остатками при согласии оператора. Новый алгоритм согласуется с процедурой ежедневного запроса остатков в ЕГАИС по расписанию. Если такой процесс настроен, алгоритм подбора алкокодов не будет обращаться в ЕГАИС.
Дополнительно, изменен алгоритм анализа остатков. Алгоритм теперь учитывает не только изменение остатка документами, зафиксированными в ЕГАИС после даты обновления остатков, но и документами, отосланными в ЕГАИС, для которых ответ еще не пришел.
В предыдущих версиях было поддержано три варианта работы с УПД на приход, которые задавались режимами приема УПД: «С предварительным приемом накладной поставщика», «С созданием накладной поставщика по УПД» и «Без накладной поставщика».
Вариант «С предварительным приемом накладной поставщика» предполагает, что поставщик присылает накладную поставщика, как уведомление об отгрузке, по ней производится прием поставки, результат приема (приходная накладная Супермаг+) отсылается поставщику, который в ответ (при согласии) присылает УПД, как документ, согласованный двумя сторонами и требующий только подтверждения со стороны получателя.
Вариант «С созданием накладной поставщика по УПД» предполагает, что поставщик присылает УПД, как уведомление об отгрузке, при приеме УПД создается накладная поставщика (для унификации процессов приема), по накладной поставщика делается прием поставки, результат отсылается поставщику, после чего, в случае приема с расхождениями, от него ожидается повторный исправленный УПД.
Вариант «Без накладной поставщика» предполагает, что поставщик не присылает никаких документов перед поставкой, поставка принимается на основании заказа, после чего результат приемки отсылается поставщику для формирования им УПД. При приеме УПД происходит автоматическое сличение состава УПД с ранее созданной приходной накладной и, при успешном сличении, подтверждение приема.
При работе с поставками выяснилось, что поставщик не всегда может обеспечить однозначную последовательность присылки УПД и прибытия поставки. То есть, могут быть случаи, когда УПД приходит раньше поставки и, тогда выставленный режим приема УПД «С созданием накладной поставщика по УПД» позволяет выполнить, как прием с контролем КИЗ, так и обмен документами с поставщиком в запланированной последовательности. Могут быть случаи, когда поставка прибывает до получения электронного УПД, и тогда, для поддержания корректного процесса, прием поставки откладывается.
В текущей версии выполнено объединение режимов приема «С созданием накладной поставщика по УПД» и «Без накладной поставщика» в один режим приема «Без накладной поставщика». Это обеспечило возможность приема поставки от одного и того же поставщика, как при наличии УПД к моменту прибытия поставки, так и в случае, когда она еще не пришла.
В новой трактовке режима приема «Без накладной поставщика», УПД от поставщика принимается без создания накладной поставщика, даже в том случае, когда УПД приходит до начала приема товара. Чтобы обеспечить возможность приема поставки с контролем КИЗ при отсутствии накладной поставщика были внесены изменения в процесс «Подсчет кодов КИЗ ТСД».
Для приема поставки в режиме «Без накладной поставщика» в диалог создания процесса «Подсчет кодов КИЗ ТСД» добавлен элемент «по УПД»: 
Если УПД уже принят, он может быть найден либо по заданному сочетанию номера документа поставщика, его даты и контрагента, либо поиском с помощью стандартного диалога выбора документа.
Когда УПД на приход выбран, прием ведется также, как в случае приема на основании накладной поставщика, то есть с проверкой сканируемых КИЗ на их наличие в УПД на приход.
После завершения подсчета выполняется экспорт данных в приходную накладную. Накладная создается в статусе «Черновик», в её основание помещаются УПД на приход и заказ поставщику, который берется из УПД. При смене статуса приходной накладной с «Черновик» на «Принят на складе» производится контроль полноты приема поставки по УПД. Затем поставщику отсылается либо подтверждение приема, либо отказ с описанием перечня принятых артикулов и их КИЗ. Во втором случае УПД на прием блокируется, и ожидается ответ от поставщика в виде исправительного УПД.
Если поставка прибыла до получения электронного УПД от поставщика, подсчет кодов КИЗ можно выполнить, указав контрагента, номер и дату документа поставщика из сопроводительных документов. Под номером документа поставщика понимается тот номер документа, который в УПД на приход показывается в поле «Номер УПД», в XML-схеме находится в поле <SUPPLIERDOC>, а в схеме ФНС XML - в поле <НомерСчФ>. 
Если задать эти параметры и нажать «Далее», будет призведен поиск документа УПД на приход с такими данными. Если документ не найден, появится сообщение: 
Если ответить «Да», будет создан процесс для подсчета КИЗ без немедленного контроля, но с сохранением данных об УПД, который должен прийти из системы ЭДО.
При приеме поставки до получения УПД на приход контроль кодов КИЗ в процессе приема невозможен. По результатам приема создается приходная накладная, в которую переносятся данные УПД. Накладная помечается, как ожидающая прихода УПД, что не позволяет поднять ее статус до «Принят полностью» до тех пор, пока не будет завершен документооборот.
При приходе УПД производится поиск соотвествтующей ему приходной накладной, делается автоматическая сверка состава УПД и приходной накладной и немедленно отсылается ответ поставщику. Это может быть подтверждение приема (при совпадении состава) или отказ с перечнем фактически принятых товаров и их КИЗ.
Аналогичные изменения внесены в программу Супермаг Мобайл Андроид.
Для предупреждения смены статуса приходной накладной на «Принят полностью» в случае, если она создана на основании информации об УПД поставщика и УПД еще не получен, создана функция проверки 241 «Контроль наличия УПД при принятии приходной накладной». Функция имеет режим работы «Всегда запрет».
Проверка срабатывает для приходной накладной, созданной процессом подсчета КИЗ ТСД до получения УПД, если в общих основаниях накладной не указан УПД или указан, но этого УПД нет в торговой системе.
В предыдущих версиях протокол «УПД фильтр» с форматами данных XML или JSON предполагал следующую последовательность обмена данными при приеме УПД на приход:
Изменен алгоритм автоматической генерации складского требования. При расчете потребностей мест поставки для текущих РЦ и артикула: \\ Формула расчета доступного количества: \\ \[Доступное кол-во на РЦ\] = \[Остаток РЦ\] - \[Резерв РЦ\] - \[В приемке / в пути РЦ\] - \[Потери РЦ\] – \[Кол-во из заблокированных накладных на перемещение и расходных накладных, в которых РЦ является местом хранения «Из»\] \\ заменена формулой: \\ \[Доступное кол-во на РЦ\] = \[Остаток РЦ\] - \[Резерв РЦ\] - \[В приемке / в пути РЦ\] - \[Потери РЦ\] \\ Упразднена формула коррекции текущего запаса: \\ \[Запас\] = \[Запас\] + \[Кол-во из заблокированных накладных на перемещение из РЦ в текущее МХ\]. \\ |
В разделе «Складские требования» в мастере создания нового документа имеется опция «Автоматическая генерация складских требований». При выборе опции на следующем шаге мастера показывается диалог с опциями процедуры генерации. При выборе опции создания шаблона на перемещение с заполнением спецификации теперь доступна дополнительная опция «Копировать количество»: 
При выборе сочетания опций «Спецификация» и «Копировать количество» после генерации складских требований для каждого созданного документа создается накладная на перемещение со спецификацией из складского требования и с копированием количества из складского требования.
В прошлых версиях в поле количество накладной на перемещение всегда проставлялось нулевое значение, чтобы оператор заполнил его фактическим количеством отгружаемого товара.
При использовании опции «Копировать количество» необходимо учитывать, что реальная поставка может не совпадать с желаемым перемещением и использование опции для упрощения работы возможно при соответствующей дисциплине сотрудников.
В функцию проверки 211 «Соответствие приходной накладной и накладной поставщика / УПД» добавлен контроль соответствия приходной накладной и УДП. В прошлых версиях проверка выполнялась только по отношению к накладной поставщика. Текущее поведение функции описано ниже:
Проверка срабатывает для документа «Приходная накладная» с операцией «Приход» или «Поступление инвентаря», если для поставщика установлен флаг «Приём по накладным поставщика», а в общих основаниях приходной накладной нет ни накладной поставщика, ни УПД.
Если в общих основаниях накладной есть УПД на приход, то все последующие проверки будут выполняться только для УПД на приход. Если в общих основании накладной нет УПД на приход, но есть накладная поставщика, то все последующие проверки будут выполняться для накладной поставщика. Проверка срабатывает для документа «Приходная накладная» с операцией «Приход» или «Поступление инвентаря» при выполнении одного из следующих условий:
Если в настройках административного модуля установлен флаг «Учет кодов КИЗ при приеме и отгрузке товаров», то предполагается, что всякий прием или отгрузка маркированных товаров при операциях с внешними контрагентами требует регистрации КИЗ маркированных товаров для дальнейшей отсылки их в систему ЭДО.
В текущей версии, если флаг установлен, то при сканировании КИЗ маркированных товаров при заполнении спецификации приходной или расходной накладной (с операциями: приход, возврат от покупателя, возврат переданного товара, продажа, возврат поставщику, передача товара) КИЗ используется не только для идентификации товара, но и сохраняется в спецификации накладной. Если флаг не установлен, то сканирование КИЗ приводит к идентификации товара, но в накладной КИЗ не сохраняется.
При успешном сканировании КИЗ в мастере ввода строки не разрешается вводить количество. Сканирование КИЗ приводит к немедленному сохранению в пункте спецификации количества, которое идентифицируется КИЗ.
При сканировании и сохранении КИЗ не разрешается использовать один и тот же КИЗ дважды. В этом случае выдается предупреждение, например: 
КИЗ, сохраненные в спецификации, не редактируются. Если необходимо удалить неверно просканированный КИЗ, необходимо удалить строку спецификации и провести сканирование повторно.
Для маркированных товаров не запрещается редактирование количества в строке спецификации или ввод сканированием EAN кода. Это позволяет проводить доверительный прием маркированного товара. В текущей версии подразумевается, что контроль за правильностью ввода данных ведется административно.
В накладных не выполняется специальная обработка групповых КИЗ и КИЗ с неизвестными EAN кодами. Все EAN коды должны быть определены в системе заранее, а для приема маркированных товаров с групповыми КИЗ надо использовать процессы «Подсчет кодов КИЗ ТСД» или «Прием заказа ТСД».
Внесено изменение в алгоритм функции проверки 10 «Контроль количества КИЗ».
Проверка теперь срабатывает только при включенном системном параметре «Учёт кодов КИЗ при приёмке и отгрузке товаров». Если проверка вызывается для приходной накладной, то она срабатывает только для документов с операциями «Приход», «Возврат от покупателя» и «Возврат переданного товара». Если проверка вызывается для расходной накладной, то она срабатывает только для документов с операциями «Продажа», «Возврат поставщику» и «Передача товара».
Название функции проверки 237 «Контроль совпадения КИЗ приходной накладной и накладной поставщика» заменено названием «Контроль совпадения КИЗ приходной накладной и УПД / накладной поставщика».
Внесено изменение в алгоритм функции проверки: проверка теперь срабатывает только при включенном системном параметре «Учёт кодов КИЗ при приёмке и отгрузке товаров» и только для приходной накладной с операциями «Приход», «Возврат от покупателя» и «Возврат переданного товара». В прошлых версиях функция сверяла КИЗ приходной накладной с КИЗ накладной поставщика из общих оснований приходной накладной. В текущей версии, если в общих основаниях приходной накладной есть УПД на приход, то КИЗ приходной накладной сверяются с КИЗ УПД на приход. Если вместо УПД на приход в основании имеется накладная поставщика - то с КИЗ накладной поставщика.
В файле ответа с результатом приема поставки по УПД на приход (REPLY) выгружается тэг LOCATIONGLN. В теге выводится значение GLN места хранения приема поставки. В предыдущей версии тэг всегда заполнялся значением номера GLN места хранения, который задается на закладке «Общее» раздела «Склады и магазины».
В текущей версии, если для места хранения и собственного контрагента из «УПД на приход» указан собственный GLN места хранения, то выгружается этот GLN. Если такого GLN нет, то берётся GLN с закладки «Общие» места хранения.
Дополнительно реализована выгрузка тэга в протоколе JSON.
Чтобы тэг выгружался, необходимо его описать в файле схемы UICONFIRM.xsd.
В справочник «Доп. характеристики товара» добавлены системные дополнительные характеристики:
Sys.InternetShopOrderQuantum «Минимальное количество заказа в интернет-магазине»
Sys.StorageCondition«Описание условий хранения»
По умолчанию для обеих характеристик не установлен флаг «Активная» и они не отображаются в разделе карточек складского учета.
Дополнительная характеристика «Описание условий хранения» предназначена для записи произвольного описания условий хранения товара, в том числе, в виде инструкции для потребителя, например, «Хранить при температуре от 4 до 10 градусов Цельсия при влажности менее 50%».
Это описание не заменяет атрибут карточки «Условие хранение», которое используется для обозначения способа хранения товара на складе или в торговом зале, например, на полке, в холодильнике или морозильнике.
В предыдущих версиях атрибуты пищевой ценности на закладке «Нормы продукции» можно было задать, если карточке складского учета назначена единица измерения «килограмм», или определена альтернативная единица измерения «килограмм», или альтернативная единица измерения, для которой «килограмм» является базовой. В текущей версии пищевую ценность можно задать для любого артикула.
Прежнее ограничение было связано с использованием атрибутов пищевой ценности для расчета норм при производстве продукции и для защиты от случайных ошибок.
При выгрузке информации по запросу «Актуальная номенклатура продуктов» выгружается, в том числе, тэг measure, например:
measure": {
"value": 1,
"quantum": 1.0,
"unit": "GRM"
В прошлой версии для штучного товара тэг «quantum» получал значение 1, тэг «unit» значение «GRM» и тэг «value» получал следующее значение:
В разделе «Контрагенты» изменен интерфейс вкладки «Поставщик». Из нее убраны опции, связанные с особенностями приема поставки. Эти опции перенесены в новую закладку «Условия поставки»: 
На вкладке «Условия поставки» изменена опция «Проставлять цены в приходную накладную».
В текущей версии добавлен выбор источника цен
\\ Внесено изменение в процедуру генерации заказов по алгоритму «Стандартный» в части поиска количества заказа. \\ В прошлой версии при округлении вычисленного количества заказа до размера упаковки поставки использовалась следующая формула: \\ \[Кол-во заказа\] = \[Размер упаковки\] * округленное по математическим правилам отношение ( \[Кол-во заказа\] / \[Размер упаковки\] ) \[Кол-во заказа\] = 0 и ( (\[Остаток на день ближайшей поставки\] < \[Мин. уровень\] и \[Мин. уровень\] <= 0.6 * \[Размер упаковки\]) \[Кол-во заказа\] = \[Размер упаковки\] да |
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ В текущей версии используется следующая формула: \\ \[Кол-во заказа\] = \[Размер упаковки\] * округленное по математическим правилам отношение ( \[Кол-во заказа\] / \[Размер упаковки\] ) \[Кол-во заказа\] = 0 и ( (\[Остаток на день ближайшей поставки\] < \[Мин. уровень\] и \[Мин. уровень\] <= 0.6 * \[Размер упаковки\]) или \[Остаток на день следующей поставки\] <= 0 ) \[Кол-во заказа\] = \[Размер упаковки\] да |
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ Дополнительное условие: «или \[Остаток на день следующей поставки\] <= 0 )» позволяет избежать ситуации, когда при расчетном количестве заказа меньше половины упаковки из-за округлении до размера упаковки количество заказа обнулится и заказ не состоится, тогда как прогноз остатка на дату следующей поставки показывает, что остаток снизится до нуля раньше, чем наступит поставка. \\ |
В текущей версии внесено изменение в алгоритм расчета цен и сумм в документе «Контракт с поставщиком» для локализации «Беларусь». Изменение коснулось варианта расчета, когда цена контракта без НДС.
В прошлых версиях для цены контракта без НДС использовался тот же алгоритм, что и для накладных с режимом округления «Цена без НДС».
Граф калькулятора выглядел следующим образом:
В текущей версии для контакта с поставщиком используется отдельный алгоритм, граф расчета которого выглядит так: 
Отличие заключается в том, что в новом графе ведущим полем для расчетов являются поля «Цена производителя» и «Оптовая надбавка», а не поля «Цена производителя» и «Цена без налогов». То есть, в прошлой версии поле «Оптовая надбавка» пересчитывалось при изменении любого из полей «Цена производителя» и «Цена без налогов», в текущей версии вместо этого пересчитывается поле «Цена без налогов» при изменении значения любого из полей «Цена производителя» и «Оптовая надбавка». Кроме того поле «Цена без налогов» теперь не округляется до точности валюты.
Изменения функционала в версии 1.048
Интеграция с сервисом «Яндекс.Еда».
ЕГАИС.
Инвентаризация ЕГАИС. Функция «Заполнить журнал марками поштучного учета».
ТТН ЕГАИС. Отсылка документов по почте.
Запрос остатков ЕГАИС по расписанию.
Акт списания / постановки на баланс ЕГАИС. Интерфейс документа.
УПД на отгрузку.
Интерфейс.
Почтовый обмен
УПД на приход.
Поле «УПД. Состояние обмена» в приходных накладных.
Структура данных «УПД на приход».
Использование УКД при приемке товара по УПД.
Интерфейс УПД на приход после коррекции УКД.
Экспорт в накладную поставщика.
Приходная накладная.
Функция «Заполнить документ ценами из УПД на приход»
Экспорт в накладную поставщика.
Накладная поставщика. Редактирование содержания.
Карточки складского учета. Фильтр «Склад».
Генерация документов из процесса ТСД
Заказ в торговом зале ТСД.
Произвольный подсчет ТСД. Расход на производство.
Настройка принтеров для печати из ТСД.
Отгрузка заказа ТСД. Доверительная отгрузка укомплектованного заказа.
Административный модуль. Настройка автоматической печати для процессов отгрузки.
Сервер приложений. Количество запросов для базы данных.
Касса. Функциональная роль «Протокол ФФД 1.2»
Функция проверки «Корректность документов «Обязательство склада»»
Функции экспорта для XML пакетов почтового модуля.
Выгрузка в кассу. Налоги, акцизы, алкоголь.
Ассистент Супермаг.+
Перечень исправленных ошибок и улучшений
\\
В сервер обмена данными добавлен новый формат обмена данных «Яндекс.Еда». Новый формат обмена применим только для адресата типа «Доверительная база». Адресат с таким форматом обмена может быть только один в базе данных. Предполагается, что «Яндекс.Еда» обслуживает заказы всех магазинов базы данных по одному каналу обмена.
\\
Бизнес-процесс, который обслуживает новый протокол обмена, подразумевает, что «Яндекс.Еда» получает от торговой организации перечень мест хранения, для которых покупатели смогут создавать заказы, получает список товаров с их атрибутами, ценами, остатками, изображениями и передает заказы от клиентов.
\\
При работе по протоколу «Яндекс.Еда» сервер обмена данными выступает только в качестве службы. «Яндекс.Еда» выступает в роли клиента и получает или сохраняет информацию по собственной инициативе. В частности, запрос артикулов «Яндекс.Еда» предполагает производить по собственному расписанию.
\\
Для включения формата обмена в работу в базе данных должна быть лицензия на функциональную роль «Сервер обмена данными (API): Яндекс.Еда». Назначать право на работу с функцией какой-либо должности не требуется.
\\
При обмене информацией с клиентом используется протокол авторизации OAuth2. Настройка работы протокола включает задание и передачу клиенту атрибутов «Client ID» и «Client secret». «Client ID» необходимо ввести вручную. Этот атрибут не является секретным. «Client secret» генерируется системой и его необходимо сохранить и передать абоненту конфиденциальным образом. Атрибут показывается один раз в момент генерации и более в интерфейсе не доступен:
\\
!worddav4b46350baa3086e17c7d2ff11c6b8be9.png|height=129,width=186!
\\
Если атрибут потерялся, его необходимо создать заново и передать его значение абоненту.
\\
!worddava355bfa6d5b3ff5272a21f131638ba11.png|height=459,width=540!
\\
В интерфейсе задания атрибутов необходимо указать перечень магазинов, для которых покупатели будут создавать заказы, а Яндекс.Еда будет получать цены и остатки.
\\
В элементе «Товары» необходимо указать группу классификатора категорий товаров, выбранную для привязки доступных для сервиса товаров. В ответах на запросы сервиса будут задействованы только те товары, у которых есть привязка к выбранному узлу классификатора категорий.
\\
Флажок «Передавать старую цену» («Не передавать маркетинговую цену») управляет правилом передачи цены. Если флаг не установлен, то передается текущая цена для кассы, какая бы она не была – регулярная или маркетинговая. Если флаг установлен, то в случае, если текущая цена артикула является маркетинговой, будет передана его ближайшая цена из истории цен, превышающая текущую цену.
\\
Опция «URLссылки и хэш изображения товара» управляет способом генерации хэш-кода для изображения товара. Изображение товара может иметь большой размер, и его передача при каждом запросе информации об артикуле нерациональна. Вычисление хэш-кода картинки позволяет понять, произошло ли изменение картинки, и запрашивать картинку только при изменении.
\\
Переключатель «Формируется автоматически, используя изображение из карточки товара» означает, что хэш-код будет формироваться в Торговой Системе. Переключатель «указывается вручную в карточке товара на изображение на стороннем ресурсе» означает, что скачивание изображения и его анализ будет проводиться третьей стороной.
\\
При начале работы «Яндекс.Еда» выполняет запрос «Аутентификация в системе» по адресу /security/oauth/token, в котором передается client_id и client_secret.
\\
POST /security/oauth/token
\\
После проверки client_id и client_secret в теле сообщения ответа возвращается токен доступа
\\
\{
"access_token": "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
\}
или, при ошибке сравнения,
\[
\{
"code": 100,
"description": "Description of error"
\}
\]
\\
Токен доступа сохраняется в памяти сервера обмена данными с максимальным временем жизни, по истечении которого токен из памяти будет удален.
\\
Далее во всех остальных запросах к сайту сервера обмена данными в заголовке («header») каждого запроса (кроме запроса "Аутентификация в системе") в параметре HTTPS Authorization "Bearer" должен быть передан токен доступа ("ABCDEFGHIJKLMNOPQRSTUVWXYZ"). При отсутствии токена или истечении его срока годности выдается ошибка авторизации 401 «Не пройдена авторизация - истек токен, либо не был передан в запросе»:
\{
"reason": "Access token has been expired. You should request a new one"
\}
\\
Поскольку «ЯндексЕда» не поддерживает запрос «refresh token», то при получении от сервера обмена данными ошибки, адресат должен повторно вызвать запрос "Аутентификация в системе".
\\
Перечень команд.
\\
GET /restaurants- Список мест хранения. Запрос "Выдача списка заведений партнера"
\\
Ответ - список магазинов:
\\
\{
"places": \[
\{
"id": "123",
"title": "Петровский",
"address": "City, str. Street, 1"
\}
\]
\}
\\
где id - это код места хранения в Торговой Системе. Все места хранения Торговой Системы должны общаться с «Яндекс.Еда» через один сайт сервера обмена данными.
\\
Другие команды:
\\
GET /nomenclature/\{placeId\}/composition- Актуальная номенклатура продуктов
\\
Возвращается структура каталогов с вложенными артикулами. В информации об артикуле вместо картинки передается хэш-код и URL-адрес доступа к ней.
\\
GET /nomenclature/\{placeId\}/availability- Список товаров с указанием их остатков
\\
Перечисленным товарам обновляются остатки. В зависимости от значения остатков также обновляется и доступность продукта. Если остаток <= 0, продукт становится недоступным для заказа, если > 0 - доступным для заказа. Отсутствующие в списке продукты будут недоступными для заказа.
\\
POST /order - Создание заказа
\\
GET /order/\{orderId\} - Выдача актуальной информации о заказе
\\
DELETE /order/\{orderId\} - Отмена заказа
\\
PUT /order/\{orderId\} - Обновление заказа
\\
GET /order/\{orderId\}/status - Выдача актуального статуса заказа.
\\
\\
Для передачи изображений категорий товаров в раздел «Классификатор категорий товаров» добавлена возможность сохранять картинки для группы классификатора:
\\
!worddav1c9c44b8abe6dcae6ca1665a64c8d9d5.png|height=275,width=646!
\\ |
В разделе «Инвентаризация ЕГАИС» имеется функция «Обработать - Заполнить журнал марками поштучного учета». Функция позволяет заполнить журнал инвентаризации ЕГАИС марками из таблиц учета с выбранными ограничениями.
При добавлении марок в журнал для них устанавливается флаг «По факту» либо для марок, имеющихся на собственном поштучном учете, либо для марок, находящихся на учете ЕГАИС.
В текущей версии добавлена опция «Отметку «По факту» не устанавливать для добавляемых марок».
Опция может быть использована, когда при частичной инвентаризации сканируются марки всех экземпляров товаров одного вида и это те марки, которые есть по факту. А те марки, которые добавляются в журнал из выбранного журнала учета, фактически отсутствуют. Их добавление в журнал инвентаризации без отметки «по факту» позволяет в дальнейшем произвести их списание.
Диалог функции теперь выглядит следующим образом: 
В разделах «ТТН ЕГАИС на приход» и «ТТН ЕГАИС на отгрузку» в диалоге функции «Разослать по почте» добавлена возможность отсылать отмеченные документы: 
В прошлых версиях можно было отослать либо выделенный курсором документ, либо все документы, имеющиеся в таблице.
В административном модуле в разделе «База данных» на закладке «Задания» можно настроить запрос остатков ЕГАИС по расписанию. В прошлых версиях одно задание можно было настроить для запроса остатков для одного ФСРАР ИД и одного типа остатков – либо остатков склада, либо остатков торгового зала.
При использовании одной базы данных для работы множества магазинов для их обслуживания может быть создано большое количество заданий. В текущей версии в задании на запрос остатков можно указать список ФСРАР ИД и для каждого из них выбрать опцию – «Остатки в торговом зале» и / или «Остатки в складе»: 
При исполнении задания запросы к ЕГАИС запускаются в заданное время для каждого ФСРАР ИД из списка.
Акт постановки на баланс склада, прежде чем быть отправленным, требует заполнения данными или из бумажной справки А, или из справки РФУ1 ТТН ЕГАИС на приход. В предыдущих версиях в спецификации акта постановки на баланс были поля «Справка А», «РФУ1», «РФУ2». Поскольку исторически сложилось так, что термины «Справка А» и «РФУ1» воспринимаются как одно и то же, то есть справка РФУ1, то в текущей версии название поля «Справка А» заменено названием «Бумажная справка А». Аналогичное изменение сделано в прочих диалогах и сообщениях. 
Примечание: Акты постановки на баланс для разных действий имеют разный интерфейс. Здесь идет речь только об акте постановки на баланс регистра склада.
В интерфейс кнопки «Обработать» добавлена функция «Подобрать справки РФУ1 из ТТН» со следующими опциями: 
Функция позволяет найти значение справки РФУ1 в документах ТТН на приход по коду алкогольной продукции. Если в базе данных имеется множество документов с нужным кодом алкогольной продукции, то будет выбран номер справки для самого нового документа.
Кроме того, при отсылке акта в ЕГАИС теперь выполняется запрос содержания справки РФУ1, если она не обнаружена в базе данных. Содержание справки используется для корректного заполнения акта постановки на баланс склада.
Из заголовка документа «УПД на отгрузку» убраны поля Накладная поставщика, Счет-фактура и Дата счет-фактуры. И добавлены поля Номер и Дата расходной накладной и Функция УПД: 
Новые поля заполняются только при создании документа, начиная с текущей версии.
Почтовый модуль при отсылке документа «УПД на отгрузку» по протоколу «УПД фильтр» с форматом «XML» может получать и обрабатывать файлы квитанций «APPERAK» такого же формата, как при приеме документа «УПД на приход».
В текущей версии используется термин «УКД».
УКД – универсальный корректировочный документ, используется для исправления УПД – универсального передаточного документа.
В интерфейсе списка отобранных документов раздела «Приходные накладные» есть возможность вывести информацию о состоянии обмена с провайдером ЭДО. Информация формируется по данным обмена УПД на приход, на основании которого создана приходная накладная.
В текущей версии информация о состоянии обмена расширена информацией провайдера о состоянии прохождении документа в его системе: 
Список возможных детализаций:
В предыдущих версиях была реализована возможность сканировать КИЗ маркированных товаров при вводе данных в спецификацию накладных с одновременным сохранением КИЗ в спецификации документа. Алгоритм обработки КИЗ был рассчитан на идентификацию артикула и его количества по значению штрихового кода EAN, который может быть извлечен из КИЗ. Алгоритм имел ограничение – он не позволял корректно принимать маркированные весовые товары. Для маркированных весовых товаров EAN из КИЗ не определяет реальное количество идентифицируемого товара, а лишь обозначает, что данный экземпляр товара прошел процедуру маркировки.
В текущей версии при разборе КИЗ в накладных для весовых товаров считается, что количество товара определить по КИЗ невозможно и для данного сканирования оно устанавливается в значение 0. То есть при сканировании КИЗ весового товара происходит идентификация товара, сам КИЗ добавляется в спецификацию документа с количеством 0 и количество товара не увеличивается. Его в этом случае надо проставлять вручную, определив вес либо взвешиванием товара, либо из информации на этикетке товара.
Аналогичное изменение внесено в программу Супермаг Мобайл для ОС Андроид, начиная с версии 2.2.123.23, за тем исключением, что в программе Супермаг Мобайл вес необходимо вносить для каждого сканирования, и он фиксируется в журнале программы, как количество, идентифицируемое КИЗ.
При отсылке УПД на отгрузку и при отсылке файла подтверждения приема для товаров с объемно-сортовым учетом формируется код ОСУ. Для штучных артикулов количество кодов КИЗ в ОСУ коде принимается равным количеству отгружаемого / принятого товара.
Для весового товара в текущей версии количество отгружаемых / принимаемых кодов КИЗ определяется по количеству кодов КИЗ в спецификации накладной.
Для корректного формирования документов при отгрузке или приеме весовых товаров с объемно-сортовым учетом необходимо в обязательном порядке сканировать все коды КИЗ отгружаемых или принимаемых товаров. Иного способа узнать, сколько кодов КИЗ отгружается или принимается, кроме как просканировать и зафиксировать все коды КИЗ в накладной, в текущей версии не существует.
В предыдущих версиях функции «Заполнить документ ценами из УПД на приход», «Заполнить документ ценами из накладной поставщика» переносили в приходную накладную полную цену, после чего выполнялся перерасчет цен и сумм в документе в соответствии с его режимом округления.
В текущей версии в накладную переносятся цена без налогов и полная цена, и при расчете принимается во внимание изменение той цены, которая соответствуют режиму округления приходной накладной.
Изменение внесено для того, чтобы исключить расхождения в ценах и суммах документов, которые возникают из-за округления величин до точности валюты.
В случае несовпадения режимов округления в приходной накладной и УПД на приход / накладной поставщика, расхождение все равно может возникнуть, из-за разного алгоритма округления цен и сумм.
В текущей версии внесены следующие изменения в условия автоматического создания УПД на отгрузку при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью».
УПД на отгрузку может быть создана только для расходной накладной с операцией «Продажа», «Возврат поставщику» или «Передача товара» при условии установки опции «Учет кодов КИЗ при приемке и отгрузке товаров» в административном модуле.
Добавлено дополнительное условие формирования УПД на отгрузку: УПД создается, если в накладной есть артикулы, относящиеся к группам классификатора ТН ВЭД с флагом «маркируемый». Это условие позволяет автоматически создавать УПД на отгрузку, когда в расходной накладной нет кодов КИЗ для маркированного товара по причине того, что он относится к товарам с объемно-сортовым учетом.
В функцию проверки 211 «Соответствие приходной накладной и УПД / накладной поставщика» условие
«для накладной поставщика / УПД задан номер документа поставщика (поле "Накладная поставщика" / "Номер УПД"), который отличается от значения поля "Документ поставщика" приходной накладной»
теперь действует и для накладной поставщика и для УПД на приход. В прошлой версии условие действовало только в случае, когда в основании приходной накладной находилась накладная поставщика.
В прошлых версиях была реализована возможность принимать поставку по нескольким заказам одновременно как одну поставку с последующей генерацией приходных накладных по одной на каждый принимаемый заказ. Эта возможность была ограничена условием вхождения одного артикула в один заказ. Если артикул встречался более чем в одном заказе, прием по такой группе заказов не разрешался.
В текущей версии разрешено принимать поставку по группе заказов, в которых встречаются одни и те же артикулы. Чтобы воспользоваться такой возможностью, необходимо использовать программу Супермаг Мобайл, начиная с версии 1.6.2491.24 для ТСД с ОС Windows CE/Mobile, или начиная с версии 2.2.121.24 для ТСД с ОС Андроид.
При генерации приходных накладных в случае приема по нескольким заказам, количество принятого товара распределяется по накладным таким образом, чтобы не превысить количество заказа.
В функцию ArticleByBarcode внесено следующее изменение: если поиск артикула по штриховому коду из спецификации XML-документа не привел к успеху, то из штрихового кода удаляются лидирующие нули и выполняется повторный поиск артикула.
Изменение внесено по той причине, что в качестве EAN кодов могут быть указаны 14 символьные GTIN, то есть коды из КИЗ, которые представляют собой EAN коды, дополненные спереди нулями до 14 символов.
В функцию ArticleByBarcodeUI внесено такое же изменение, как в функцию ArticleByBarcode, а также добавлена возможность распознавать артикул по коду ОСУ. Для этого в перечень параметров функции добавлено поле osuCode: 
В предыдущих версиях была реализована возможность принимать КИЗ, как в теге MARKCODE, так и в тэге PACKAGECODE. Последнее обусловлено тем, что по рекомендациям ЦРПТ в тэг MARKCODE желательно помещать КИЗ минимальной потребительской упаковки, то есть штук товара, а в тэг PACKAGECODE помещать КИЗ упаковок товара.
В связи с тем, что в ранних версиях обмена с ЭДО провайдером тег PACKAGECODE отсутствовал, и при работе по прежней версии протокола данные тэга не обрабатывались, провайдер принял решение о дублировании КИЗ упаковок в обоих тэгах. Это, в свою очередь, привело к невозможности приема УПД по новому протоколу из-за ошибки дублирования кода КИЗ.
В текущей версии почтовый фильтр при приеме УПД перед обработкой XML-файла удаляет дублированные коды КИЗ, если они встречаются в разных тэгах.
В административном модуле в разделе «База данных» на закладку «Конфигурация» добавлена группа данных «Заказы от клиентов». На закладку добавлена опция «Автоматически помечать заказы от клиента закрытыми при смене статуса расхода на «Отпущен со склада». По умолчанию опция не отмечена. 
Изменения функционала в версии 1.049 сервис пак 2.
Вывод из оборота маркированной продукции.
УПД на приход.
Номер и дата исправления.
Определение режима округления.
Приходная накладная. Заполнить документы ценами из УПД на приход.
Почтовый модуль.
Номер версии Супермаг в заголовке XML пакетов.+
УПД фильтр. Опция «Сохранять копию (.bak) при отсылке».
УПД фильтр. Формат данных XML. Содержание файла ответа с результатом приемки.
Заказ от клиента. Поле «Артикул ценника».
Формирование пакета заказов на базе контракта. Остаток собственного поставщика.
Алгоритм автоматической генерации заказа.
Вывод из оборота маркированной продукции подразумевает списание маркированной продукции или переход ее в состояние, когда она более не является маркированной, например, разделка (расфасовка) весовой молочной продукции. То есть, это такое действие, после которого КИЗ маркированной продукции более не числится за организацией и, в более широком смысле, в обороте, не может быть продан через кассу или по документам (УПД).
Вывод из оборота маркированной продукции может быть выполнен на сайте ГИС МТ в личном кабинете в ручном режиме или, там же, загрузкой файлов формата XML со сведениями о выбывающих товарах.
Ниже фрагмент инструкции из документа ЦРПТ «Инструкция по предоставлению сведений о выводе товаров из оборота в государственную информационную систему мониторинга за оборотом товаров (далее – ГИС МТ)» (Vyvod_tovara_iz_oborota.pdf) для вывода из оборота продукции путем передачи сведений файлом формата XML (для нетабачной продукции):
3. Зайти в раздел Документы с помощью соответствующей вкладки в левой части экрана.
4. Нажать на кнопку «Загрузить», выбрать «Вывод из оборота» и выбрать ранее подготовленный файл для загрузки. 
5. Параметры загружаемого документа отобразятся на форме предварительного просмотра. В случае если все параметры заявки указаны верно, необходимо подтвердить загрузку нажатием кнопки «Подписать и отправить», в противном случае нажать на кнопку «Отменить». В появившемся диалоговом окне подтверждения нажать на кнопку «Да», чтобы подписать отправляемый заказ с помощью УКЭП.
В текущей версии Торговой Системы в разделе «Расходные накладные» в режиме открытого документа для документов со статусом «Отпущен со склада» и «Отпущен полностью» доступна функция «Списание маркированной продукции». 
Функция позволяет заполнить атрибуты для формирования файла: 
И 
Функция при заполнении файла использует понятие «Код группы маркированной продукции» честного знака. Для корректного заполнения файл данными в справочник кодов ТН ВЭД добавлено поле «Код ЧЗ»: 
Значение кода выбирается из фиксированного списка: 
Перед началом использования функции «Списание маркированной продукции» необходимо обязательно заполнить справочник значениями кодов Честного знака.
Для товаров из следующих групп ЧЗ создается файл в формате XML: «Антисептики и дезинфицирующие средства», «Биологически активные добавки к пище», «Велосипеды и велосипедные рамы», «Духи и туалетная вода», «Кресла-коляски», «Молочная продукция», «Обувные товары», «Пиво, напитки, изготавливаемые на основе пива, слабоалкогольные напитки», «Предметы одежды, бельё постельное, столовое, туалетное и кухонное», «Упакованная вода», «Фотокамеры (кроме кинокамер), фотовспышки и лампы-вспышки», «Шины и покрышки пневматические резиновые новые».
Для товаров из групп «Табак», «Альтернативная табачная продукция», «Никотиносодержащая продукция» создается файл в формате CSV. Этот файл может быть использован для подготовки данных и вывода марок из оборота в ручном режиме. Для табачной продукции передача сведений файлом формата XML не предусмотрена.
В заголовок документа «УПД на приход» добавлена закладка «Исправления». На закладке показывается номер и дата последнего исправления, если контрагент присылал эти сведения в УКД или в исправительном УПД.
Документы, принятые в прошлых версиях, такой информации не содержат, и для них закладка будет иметь следующий вид: 
Такой же вид будет для документов, принятых первый раз. В случае, если проводилась коррекция в виде исправительного УПД или с помощью УКД и провайдер прислал в этих документах информацию о номере и дате корректировки, закладка будет иметь следующий вид: 
В интерфейс закладки «Главная» для документа «УПД на приход» добавлено поле «Округление». В поле выводится режим округления, который определяется по содержанию документа в момент его получения почтовым модулем. Поставщики и провайдер ЭДО не предоставляют сведений о способе расчета цен и сумм в документе. По этой причине значение режима округления устанавливается на основании анализа соответствия цен и сумм полученного документа. В некоторых случаях цены могут быть такими, что к ценам и суммам документа могут подходить разные режимы округления. В этом случае будет проставлен какой-либо из них, и если он будет отличаться от ожидаемого режима округления, это не будет ошибкой.
В тех случаях, когда соответствие не выявлено, показывается текст «не определено».
Документы, полученные до установки текущей версии, имеют то значения округления, которое было проставлено в документ по умолчанию. Это значение может не соответствовать реальному режиму округления документа.
В диалог старта функции «Заполнить документы ценами из УПД на приход» добавлена опция «Синхронизировать режим округления с УПД на приход». Значение опции запоминается и устанавливается при следующем запуске функции.
Синхронизация режимов округления позволяет избежать расхождения сумм документов из-за разных алгоритмов округления при расчете цен и сумм.
Опцией следует пользоваться только при работе с документами УПД на приход, полученными после установки текущей версии.
В текущей версии, при создании почтовым модулем XML файлов, в тэге PACKAGE дополнительно указывается атрибут SMVersion. В тэге прописывается текущая версия Супермаг+. Например:
<PACKAGE name="220927161028_9725_11" SMVersion="1.049 SP2">
В настройки почтового модуля для УПД фильтра добавлена опция «Сохранять копию (.bak) при отсылке». По умолчанию флаг не отмечен.
Если флаг отметить, то при отсылке пакетов по протоколу «УПД фильтр» копии отсылаемых файлов будут сохраняться в подкаталоге LOG каталога исходящих сообщений с расширением .bak.
Опция может быть полезна в тех случаях, когда провайдер забирает файлы пакетов в автоматическом режиме, но требуется знать точное содержание переданных файлов, например, в случаях разногласий с провайдером или контрагентом в интерпретации содержания отосланных пакетов. При использовании опции необходимо следить за размером дискового пространства и периодически удалять ненужные файлы.
В файл ответа с результатом приемки добавлен тэг CREATEDATWI, который содержит дату приходной накладной. Например:
<CREATEDATWI>2022-09-27</CREATEDATWI>
Дата приходной накладной соответствует понятию «дата приема товара» и может не совпадать с датой УПД на приход.
В файл ответа также добавлен тэг SUPPLIERCORRECTINVOICE. Тэг содержит номер коррекции, на которую сформирован ответ. Например:
<SUPPLIERCORRECTINVOICE>1</SUPPLIERCORRECTINVOICE>
В спецификацию документа «Заказ от клиента» добавлено поле «Артикул ценника». В поле может сохраняться значение артикула упаковки, идентифицированной при комплектации заказа. Информация об упаковке заказа может быть полезной при комплектации маркированного товара. Эта информация может быть использована для корректного формирования кассового чека, когда заказ от клиента используется в качестве пречека.
В разделе «Формирование пакета заказов на базе контракта» в таблицу артикулов для заказа добавлено поле «Остаток собственного поставщика». В поле показывается остаток товара для контрагента – поставщика заказа, если он является собственным контрагентом мест хранения Торговой Системы. Остаток определяется, как сумма оперативно доступных остатков по местам хранения, где поставщик заказа является собственным контрагентом места хранения.
При вычислении остатка собственного поставщика отрицательные оперативно доступные остатки места хранения принимаются равными нулю. Остаток вычисляется при открытии раздела, для обновления значения надо нажать кнопку «Обновить оперативные остатки»: 
В алгоритмах автоматической генерации заказа «Стандартный» и «Fresh» изменен алгоритм округления количества заказа до размера упаковки. Теперь количество упаковок заказа всегда округляется в большую сторону.
Изменения функционала в версии 1.049 сервис пак 3.
Расходные накладные.
Поля «ЭДО. № УПД на отгрузку», «ЭДО. дата УПД на отгрузку».
Функция проверки «Корректность накладной для создания УПД на отгрузку».
Создание и сквозная почтовая рассылка УПД на отгрузку.
УПД на приход.
Количество почтовых приемов.
Причина расхождения с приходной накладной.
Приходная накладная.
Поле «УПД. Причина расхождения».
Поиск подходящего УПД на приход при смене статуса приходной накладной.
Обработка УПД на приход при смене статуса приходной накладной.
Функция проверки «Расхождение в составе приходной накладной и УПД на приход».
Простановка цен и режима округления из УПД на приход в приходную накладную.
Почтовый модуль. Функция импорта «ArticleBySupplierCodeUI».
Прием заказа ТСД. Прием по заказу с несколькими накладными поставщика.
Алкогольная декларация.
В перечень полей, доступных для добавления в таблицу отобранных документов, добавлены поля «ЭДО. № УПД на отгрузку» и «ЭДО. дата УПД на отгрузку»: 
В поле «ЭДО. № УПД на отгрузку» показывается номер документа УПД на отгрузку, созданного на основании расходной накладной.
В поле «ЭДО. дата УПД на отгрузку» показывается дата документа УПД на отгрузку, созданного на основании расходной накладной.
При двойном клике на номере УПД на отгрузку выполняется переход к документу.
Создана функция проверки 242 «Корректность накладной для создания УПД на отгрузку». Функция срабатывает при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью» и имеет режим работы «Всегда запрет».
Проверке подвергается расходная накладная с операцией «Продажа», «Возврат поставщику» или «Передача товара», если установлен системный параметр «Учёт кодов КИЗ при приёмке и отгрузке товаров» и выполняется одно из следующих условий:
Первое изменение позволяет создавать документ УПД на отгрузку в подчиненной базе, где нет обмена с ЭДО провайдером, и пересылать документ в старшую базу стандартным образом, как и все прочие документы. Второе изменение позволяет старшей базе принимать и пересылать провайдеру документы от многих подчиненных баз, предназначенные разным адресатам обмена, например, если каждый магазин имеет собственное юридическое лицо с собственным каналом обмена с провайдером. Также это изменение обеспечивает схему обмена с множеством промежуточных баз данных, например база магазина – база куста – центральная база – провайдер.
В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «Кол-во почтовых приемов»: 
В поле показывается количество записей из истории документа с операцией «Изменение почтой». Это количество соответствует количеству почтовых приемов документа.
В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «Причина расхождения»: 
В поле показывается текст с описанием причины, по которой алгоритм сличения УПД на приход и приходной накладной признал, что содержание документов не совпадает. Расхождение в содержании документов приводит к блокировке документа УПД на приход и отсылке поставщику информации о приеме с расхождением.
В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «УПД. Причина расхождения»: 
Содержание поля аналогично такому же полю в УПД на приход.
В практике использования УПД на приход при приеме товаров могут быть случаи, когда приход оформляется либо до получения УПД на приход, либо без его использования, например, при приеме по заказу и накладной поставщика или при приеме без указания УПД на приход, как основания прихода. В этом случае УПД на приход отсутствует в основании приходной накладной и в прошлых версиях не обрабатывался при смене статуса приходной накладной.
В текущей версии при смене статуса приходной накладной с «Черновик» на «Принят на складе» для приходной накладной выполняется поиск подходящей УПД на приход. Поиск выполняется по значениям атрибутов приходной накладной: «Документ поставщика», «Дата документа поставщика», «Поставщик», «Приход в». Эти атрибуты должны совпадать со значениями атрибутов УПД на приход «Номер УПД», дата документа «УПД на приход», «Поставщик», «Приход в» и УПД на приход должен иметь статус «Принят».
Если документ найден, он добавляется в общие основания приходной накладной и обрабатывается при смене статуса приходной накладной.
Дополнительно, при смене статуса приходной накладной и перед обработкой УПД на приход из основания накладной, проводится сверка номера и даты документа поставщика приходной накладной и данных УПД на приход. Отсутствие или неверные значения этих атрибутов в приходной накладной приводят к неверному заполнению файла подтверждения приема УПД на приход. По этой причине в текущей версии обработка таких УПД производиться не будет. Сам факт несоответствия номера и даты документа поставщика и данных УПД на приход говорит о том, что прием поставки по УПД на приход не производился или производился с нарушением порядка действий и УПД оказался в основании приходной накладной случайным образом.
При смене статуса приходной накладной проводится сличение спецификации приходной накладной и УПД на приход для принятия решения о том, в какой статус необходимо перевести УПД на приход. В статус «Закрыт», что означает фиксацию приема по УПД, или «Заблокирован», что означает необходимость отправки поставщику уведомления о приеме с расхождением и ожидания присылки корректирующего документа.
В процедуру сличения спецификация документов в текущей версии добавлены следующие условия:
В процесс подсчета алкоголя ТСД, созданного на основании ТТН ЕГАИС, добавлена возможность сканирования кода упаковки алкоголя. Если в ТТН ЕГАИС содержится информации об упаковке, то при сканировании кода упаковки в журнал подсчета добавляются все алкогольные марки, содержащиеся в этой упаковке. Ранее эта функциональность уже была реализована в программе Супермаг Мобайл.
При выполнении экспорта в расходную накладную с созданием акта списания ЕГАИС подразумевается, что для маркированного алкоголя посчитанные алкогольные марки и соответствующий им алкогольный товар должны быть списаны с товарного учета: с собственного поштучного учета и с учета ЕГАИС.
В прошлых версиях так происходило, если для сканированных марок не было нарушений в учете. С точки зрения алгоритма экспорта считалось, что списание должно происходить после приведения всех трех измерений учета к единому состоянию, и ни одной из описанных ниже ситуации быть не должно:
Просканированная марка (факт) | Собственный учет | Учет ЕГАИС |
Марка 1 | Нет | Нет |
Марка 2 | Есть | Нет |
Марка 3 | Нет | Есть |
Для приведенного выше примера при создании расходной накладной и при создании акта списания ЕГАИС в прошлой версии учитывались только марки, находящиеся на собственном поштучном учете.
В текущей версии перед созданием документов делается проверка на наличие марок на собственном учете и учете ЕГАИС и показывается предупреждение следующего вида: 
Если выбрать продолжение работы, то в расходную накладную будет помещено количество равное количеству у марок подсчета, находящихся на собственном учете, а в акт списания ЕГАИС будут помещены марки, находящиеся на учете в ЕГАИС.
В документ «Заказ от клиента» добавлена возможность сохранения кодов марок алкогольной продукции наравне с сохранением кодов марок КИЗ. В текущей версии интерфейса документа алкогольные марки не отображаются. Просмотр алкогольных марок в заказе от клиента будет доступен в версии 1.050.
Для процессов «Комплектация заказа ТСД» и «Подсчет товаров ТСД» (для документа Заказ от клиента) добавлена возможность принимать из программы ТСД информацию о сканированных алкогольных марках.
В сервер приложений добавлены функции, которые позволяют программе ТСД при сканировании алкогольных марок в ходе наполнения заказов проверять их наличие на собственном поштучном учете. Опция доступна при наличии связи и при работе с СМ Мобайл, начиная с версии 2.2.163.37.
В административный модуль добавлено функциональное задание «Консолидация заказов поставщикам». Задание позволяет объединять заказы поставщику в один документ и ставить его в очередь на отсылку в подходящий почтовый ящик типа «Контрагент».
Опции для настройки задания:
\\
Описание экземпляра товара по запросу актуальной номенклатуры выглядит следующим образом:
\\
"items": \[
\{
"id": "some-uniq-identifier",
"vendorCode": "string",
"categoryId": "some-uniq-identifier",
"location": "Бакалея. Линия 8",
"name": "Молоко Домик в деревне",
"description": \{
"general": "string",
"composition": "string",
"nutritionalValue": "string",
"purpose": "string",
"storageRequirements": "string",
"expiresIn": "string",
"vendorCountry": "Россия",
"packageInfo": "Тетрапак",
"vendorName": "Буренка"
\},
"price": 1000,
"oldPrice": 1234.56,
"vat": 20,
"barcode": \{
"value": "987654321098",
"values": \[
"987654321098"
\],
"type": "ean13",
"weightEncoding": "ean13-tail-gram-4"
\},
"measure": \{
"value": 1000,
"quantum": 0.5,
"unit": "GRM"
\},
"volume": \{
"value": 100,
"unit": "DMQ"
\},
*"isCatchWeight": false,*
"sortOrder": 0,
"images": \[
\{
"hash": "string",
"url": "string"
\}
\]
\}
\]
\\
Информация о товаре содержит, в том числе, атрибут "isCatchWeight". В прошлых версиях атрибут «isCatchWeight» получал значение true, если базовая единица измерения товара была весовой или если штучному товару была назначена альтернативная весовая единица измерения.
\\
В текущей версии атрибут получает значение true, только если базовая единица измерения является весовой. Во всех прочих случаях она получает значение false.
\\ |
Внесено изменение в поведение функции «Отмена запроса поштучных остатков по РФУ». В предыдущих версиях очистка очереди запросов происходила только для случая запроса по всем справкам РФУ. Если запрос делался по выборочному списку справок, очистки очереди запросов не происходило.
В текущей версии изменен алгоритм формирования очереди, что позволило проводить отмену запросов, в том числе для выборочных справок РФУ.
В интерфейс настройки автоматического задания «Консолидация заказов поставщикам» добавлен выбор перечня мест хранения, для которых будут искаться заказы поставщикам для консолидации: 
При создании приходной накладной может сложиться ситуация, когда УПД на приход в момент приема товара еще не получен и не может быть использован в качестве основания прихода. УПД на приход может быть получен в ходе приемки или после ее завершения. Чтобы автоматически привязать УПД на приход к уже созданной приходной накладной в прошлых версиях была создана функция, которая при смене статуса накладной с «Черновик» на «Принят на складе» выполняла поиск УПД на приход. Поиск велся по значению полей «Документ поставщика» и «Дата документа поставщика» из заголовка приходной накладной, которые сравнивались со значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
В текущей версии в алгоритм поиска добавлен поиск УПД на приход по совпадению значений полей «Счет-фактура» и «Дата счета-фактуры» приходной накладной и значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
Изменение алгоритма связано с тем, что УПД на приход может одновременно являться и счетом-фактурой и передаточным документом одновременно. Соответственно, его «Номер УПД» и дата могут быть занесены, как в поля номер и дата документа поставщика, так и в поля номер и дата счета-фактуры приходной накладной.
В текущей версии изменен алгоритм поиска приходной накладной для УПД на приход, который выполняется, чтобы определить был ли выполнен прием поставки по УПД до получения УПД. В прошлых версиях поиск проводился по условию совпадения атрибута «Номер документа поставщика» в приходной накладной с атрибутом «Номер УПД» документа «УПД на приход» и совпадения даты документа поставщика с датой УПД на приход. В текущей версии поиск расширен поиском приходной накладной по совпадению даты и номера счета фактуры из приходной накладной с датой УПД и атрибутом «Номер УПД» документа «УПД на приход».
Изменение внесено по причине использования УПД на приход одновременно в роли счета-фактуры и транспортной накладной, и, соответственно, использованием номера УПД, как номера счета-фактуры при оформлении приходной накладной.
XSD схема файла APPERAK является частью кода обработки этого типа данных и не представлена в виде файла, как в случае с другими типами данных. Соответственно, изменение схемы не может быть выполнено отдельно от изменения программного модуля.
В прошлой версии тип данных тэга CREATEDAT схемы был заменен с типа «Дата» на тип «Дата – время» и содержание файла должно было выглядеть так:
<APPERAK>
<RESULT>3</RESULT>
<ID>UI0000000055</ID>
<CREATEDAT>2021-07-06T00:00:00</CREATEDAT>
<SENDDATTIM>2021-07-06T12:12:32</SENDDATTIM>
<EDOID>039a4936-d443-42ea-a6e0-65a3914b40fa</EDOID>
<CLIENTGLN>4343463463462</CLIENTGLN>
<ERRORTEXT>Ошибка ЭЦП</ERRORTEXT>
</APPERAK>
В текущей версии в файле можно использовать как тип «Дата», так и тип «Дата – время».
Изменения функционала в версии 1.049.1 сервис пак 1.
Контроль остатков ТСД. Генерация документов из процесса.
Процесс контроля остатков ТСД предполагает подсчет фактически наличествующих товаров по группам товаров с одновременным сличением посчитанного количества с оперативным остатком, то есть таким остатком, который должен быть в месте хранения с учетом всех потерь, обнаружений, незавершенных, с точки зрения оформления документов, поставок и отгрузок, а также оперативной кассовой реализации.
Предполагалось, что процесс может быть использован для коррекции фактических остатков для управленческих целей, в первую очередь для формирования заказов, в промежутке между инвентаризациями. Соответственно, в прошлых версиях результатом работы процесса были документы акт обнаружений и акт потерь.
В текущей версии предполагается, что процесс может быть использован для проведения частичной или полной инвентаризации бригадой из сторонних лиц, для которых важна безошибочность проведения подсчета и, как следствие, нужна справочная информация об ожидаемом фактическом остатке товара.
Для такого случая в текущей версии в административный модуль в раздел «База данных», на закладку «Конфигурация» в группу данных «Генерация документов из процесса» для процесса «Контроль остатков» добавлен выбор возможности генерировать документ «Инвентаризационная опись» со статусом «Черновик» или «Принят в количестве»: 
Документ создается с номером приказа об инвентаризации равным номеру документа, с контрагентом равным собственному контрагенту места хранения и режимом заполнения «Произвольный список товаров». Если для места хранения собственный контрагент не задан, документ создан не будет. Сообщение об ошибке будет показано на экране ТСД.
Документ создается только при создании процесса из ТСД. В интерфейсе процесса показывается факт наличия созданной инвентаризационной описи, но дополнительной функции генерации документа из процесса не существует: 
Изменения функционала в версии 1.049.1 сервис пак 2.
Касса УКМ 4 XML. Загрузка списка товаров для отображения на экране кассы самообслуживания (пик-листа).
Информация о выкладке товара.
Поддержка работы СМ Мобайл. Повторное чтение документов.
\\
В диалог настройки касс типа «УКМ4 XML» добавлена опция «Для просмотра списка товаров использовать классификатор категорий»:
\\
!worddav3c4d1db4531036ae8446953ef74af9d0.png|height=384,width=358!
\\
!worddav1fd42d17532b5cb23d174b923c185516.png|height=422,width=305!
\\
В опции разрешается выбирать только группы классификатора категорий, которые не являются списками товаров. Группы классификатора выступают в роли пакета пик-листов в терминах УКМ4. Список товаров выступает в роли пик-листа.
\\
Опция доступна, как для случая настройки кассы для места хранения, так и для центрального офиса. Если опция заполнена, то при выгрузке данных в кассу выгружается информация о товарах групп классификатора категорий в файл с именем «picklists_\[хх\]_\[F\].xml».
\\
Данные в файл выгружаются всегда полностью и только при полной выгрузке. Содержание файла имеет следующий вид:
\\
<?xml version="1.0" encoding="utf-8"?>
<picklists fullness="F">
<version>1.0</version>
<picklist>
<id>1</id>
<name>Овощи</name>
<isGobal>1</isGobal>
<stores>999</stores>
<items>
<id>Ц000017</id>
<id>Ц000037</id>
</items>
</picklist>
<picklist>
<id>2</id>
<name>Фрукты</name>
<isGobal>1</isGobal>
<stores>999</stores>
<items>
<id>000010</id>
<id>Ц000037</id>
</items>
</picklist>
</picklists>
\\
Тэг <isGobal> всегда заполняется значением 1, тэг <stores> всегда заполняется значением 999. Тэг <id> заполняется номером позиции списка товаров в группе классификатора категорий, выбранной в качестве пакета пик-листов.
\\ |
В раздел «Карточки складского учета» добавлена закладка «Выкладка». Для доступа к информации закладки необходимо иметь право на функциональные роли «Карточки складского учета: Просмотр выкладки товаров» и «Карточки складского учета: Редактирование выкладки товаров». Роли добавлены в текущем сервис паке и для их визуализации в административном модуле требуется обновить лицензию.
На закладке для каждого места хранения можно зафиксировать описание местоположения и особенностей выкладки товара в произвольном виде: 
Информация о выкладке товара используется программой Супермаг Мобайл, начиная с версии 2.2.242.21, при получении справки о товаре.
Для процессов, требующих документ-основание, например, для приема по заказу ТСД, для нужд СМ Мобайл имеется функция, которая определяет, был ли изменен ранее считанный документ. В текущей версии для документа «Заказ поставщику», помимо содержания документа, проверяется, не был ли изменен состав документов «УДП на приход» или «Накладная поставщика», созданных на основании заказа. Если состав документов изменился, программа ТСД перечитывает как заказ поставщику, так и все связанные с ним документы поставщика. Изменение содержания документов «УПД на приход» и «Накладная поставщика» не проверяется, проверяется только факт изменения состава таких документов с учетом их статуса.
Внимание! Контроль изменения документов в СМ Мобайл выполняется, если в настройках программы установлен флаг «Обновление информации. Проверка изменения загруженного документа на сервере, при создании задания на его основании».
Изменения функционала в версии 1.049.1 сервис пак 3.
Задание «Консолидация заказов поставщикам». Фильтр по местам хранения.
Почтовый модуль.
Прием документа «УПД на приход». Поиск подходящей приходной накладной.
Почтовый объект «Выкладка товара».
Сервер обмена данными.
Аналитический объект «Алкогольные марки упаковки». Формат данных.
Прием объектов с указанием имени схемы.
Поддержка работы СМ Мобайл
Обработка лицензий.
Выгрузка информации о количестве ожидаемой поставки.
В интерфейс настройки автоматического задания «Консолидация заказов поставщикам» добавлен выбор перечня мест хранения, для которых будут искаться заказы поставщикам для консолидации:
В текущей версии изменен алгоритм поиска приходной накладной для УПД на приход, который выполняется, чтобы определить был ли выполнен прием поставки по УПД до получения УПД. В прошлых версиях поиск проводился по условию совпадения атрибута «Номер документа поставщика» в приходной накладной с атрибутом «Номер УПД» документа «УПД на приход» и совпадения даты документа поставщика с датой УПД на приход. В текущей версии поиск расширен поиском приходной накладной по совпадению даты и номера счета фактуры из приходной накладной с датой УПД и атрибутом «Номер УПД» документа «УПД на приход».
Изменение внесено по причине использования УПД на приход одновременно в роли счета-фактуры и транспортной накладной, и, соответственно, использованием номера УПД, как номера счета-фактуры при оформлении приходной накладной.
В прошлой версии для артикула был добавлен атрибут «Выкладка товара», но не была реализована его рассылка. В текущей версии добавлен новый почтовый объект «Выкладка товара» (LT). Объект представляет собой строку с информацией о выкладке товара по месту хранения. Объект может рассылаться самостоятельно по факту изменения (при настроенном правиле рассылки) или с артикулом при его ручной рассылке. В последнем случае отсылаются все объекты LT, связанные с артикулом.
\\
Изменен формат данных, возвращаемых аналитическим объектом «Алкогольные марки упаковки» IOSMIOBOXMARKCODES (описание см. Изменение 1.049.1).
\\
В поле «sMarkCode» теперь возвращается код алкогольной марки в формате BASE64.
Например, для списка алкогольных марок
\\
«203200473108451018001A6FU3TLS5PFQRPH3LYQ3MBPNDQPUQT7OQGSPBAWVMO74DNCE6M3TAXD4CS36QVFOTNRDAIPD43BAO65XPERNKOJHTDIROOCDKJNWNXGC2EIUPHPWG2TCDUH76XV6MQ4CA»
\\
«203200441424561018001PNEJF5VLG5OMV6T7YHH62M5VJ46JNSFIYTHYMBMUXZBTIPUHLSQ4JWOX3PTITXTTA5R3ZBC4F43NFPXXQE5S7ODJPBXQZIB3IBR35UBZNQW36RSFYCYNC665C6Z3C4FSI»
\\
«203200570133631018001IHBTEJOQCRYTXROMWZBDYJCSHANHNXVFA42SLFJTEQ6FQAE2B7A3FLG352KKYGKT3DVDUVZ7WCBQKULPRIQWF2F56EO2Z32R2YHMFFPM252GKICYMRDIHYLNHSOX44GJA»
\\
«203200596047061018001NXMUATQBLTAXLKJSC7R2AHOKYII4LE25J6HTR7N5YAKIH7SIFGQV4MKTELG3XVQK7W57NDUQKJ6I4OH4JMTQIHCVH6ZCJUCTNYIWZR2WI7OC36IUPJSQY7WMHDSCNZKXY»
\\
Обращение вернет следующий ответ:
\\
\{
"PACKAGE": \{
"name": "0770efd0-da72-4a18-8c21-b5e9364004ab",
"POSTOBJECT": \[
\{
"description": "Алкогольные марки упаковки",
"action": "normal",
"Id": "IOSMIOBOXMARKCODES",
"IOSMIOBOXMARKCODES": \{
"SMIOBOXMARKCODES": \[
\{
"sMarkCode": "MjAzMjAwNDczMTA4NDUxMDE4MDAxQTZGVTNUTFM1UEZRUlBIM0xZUTNNQlBORFFQVVFUN09RR1NQQkFXVk1PNzRETkNFNk0zVEFYRDRDUzM2UVZGT1ROUkRBSVBENDNCQU82NVhQRVJOS09KSFRESVJPT0NES0pOV05YR0MyRUlVUEhQV0cyVENEVUg3NlhWNk1RNENB"
\},
\{
"sMarkCode": "MjAzMjAwNDQxNDI0NTYxMDE4MDAxUE5FSkY1VkxHNU9NVjZUN1lISDYyTTVWSjQ2Sk5TRklZVEhZTUJNVVhaQlRJUFVITFNRNEpXT1gzUFRJVFhUVEE1UjNaQkM0RjQzTkZQWFhRRTVTN09ESlBCWFFaSUIzSUJSMzVVQlpOUVczNlJTRllDWU5DNjY1QzZaM0M0RlNJ"
\},
\{
"sMarkCode": "MjAzMjAwNTcwMTMzNjMxMDE4MDAxSUhCVEVKT1FDUllUWFJPTVdaQkRZSkNTSEFOSE5YVkZBNDJTTEZKVEVRNkZRQUUyQjdBM0ZMRzM1MktLWUdLVDNEVkRVVlo3V0NCUUtVTFBSSVFXRjJGNTZFTzJaMzJSMllITUZGUE0yNTJHS0lDWU1SRElIWUxOSFNPWDQ0R0pB"
\},
\{
"sMarkCode": "MjAzMjAwNTk2MDQ3MDYxMDE4MDAxTlhNVUFUUUJMVEFYTEtKU0M3UjJBSE9LWUlJNExFMjVKNkhUUjdONVlBS0lIN1NJRkdRVjRNS1RFTEczWFZRSzdXNTdORFVRS0o2STRPSDRKTVRRSUhDVkg2WkNKVUNUTllJV1pSMldJN09DMzZJVVBKU1FZN1dNSERTQ05aS1hZ"
\}
\]
\}
\}
\]
\}
\}
\\ |
В прошлых версиях было декларировано, что в случае, когда разные адресаты используют разные версии схем одного и того же вида объектов, эти схемы могут быть сохранены с разными именами и в дальнейшем могут быть использованы при обращениях со стороны абонента.
До текущей версии это правило не работало. При получении запроса от абонента всегда искалась схема объекта с именем по умолчанию (имя по умолчанию равно коду вида объекта). В текущей версии реализована обработка обращения с указанием имени схемы:
http://IP-адрес:порт/in/db/название БД абонента/формат данных/имя схемы
Пример для curl с анонимным доступом (без указания имени БД арресата):
curl -F "xml_file=@c:\temp\UPD193_OSU.XML" http://192.168.25.163:8085/in/xml/UIIN > Response.xml
В текущей версии реализованы функции, позволяющие программе СМ Мобайл передавать информацию о ключе устройства, используемого для генерации лицензии. Файл с ключом сохраняется в подкаталоге Keys каталога дистрибутива Супермаг Мобайл, который задается в административном модуле в разделе «База данных», на закладке «Конфигурация» в группе данных «Инсталляция». Подкаталог Keys создается автоматически, также как подкаталог Licenses (см. ниже).
Файл с ключом имеет имя, состоящее из двух символьного префикса, символа подчеркивания и строки, совпадающей со строкой ключа.
Символы префикса имеют следующий смысл:
Первый символ может принимать значения «D» - демо режим, или «L» - лицензированный режим. Если в ТСД файл лицензии загружен, но недействителен, например, истек срок действия, первый символ префикса имени файла ключа будет «D».
Второй символ может принимать значение «U» - устройство с неизвестным встроенным сканером или «M» - устройство с распознанным встроенным сканером.
Устройство с неизвестным встроенным сканером, это устройство, у которого либо нет встроенного сканера, например, телефон, либо это ТСД с моделью сканера, для которого не реализована поддержка драйвера сканера.
Если в подкаталог Licenses каталога дистрибутива Супермаг Мобайл поместить файлы лицензии для ТСД, то ТСД при регистрации будет забирать из него свою лицензию.
Для процесса «Заказ в торговом зале ТСД» (режим работы «Создание заказа поставщику» в интерфейсе программы СМ Мобайл Андроид) добавлена возможность получения в ТСД информации о количестве товара, ожидаемого к поставке, то есть количества по заказам поставщику в статусе «Размещен». Дополнительно изменен алгоритм определения количества в последнем заказе («Посл. зак.»). Теперь для определения количества ищется последний заказ среди заказов поставщику со статусом «Завершен». В прошлых версиях документ искался среди заказов со статусом «Завершен» и «Размещен».
Изменения функционала в версии 1.049.1 сервис пак 4.
Остатки ЕГАИС. Поштучный учет.
Функция «Отсылка алкогольных марок в СММарко».
Временный набор.
Подсчет алкоголя ТСД. Функция «Проверить в УТМ и отправить в СММарко».
В раздел «Остатки ЕГАИС» добавлена функция «Отсылка алкогольных марок в СММарко». Функция активна на закладке «Поштучный учет».
В начале работы функция показывает / позволяет выбрать адресат с фильтром «СуперМагМарко»: 
Позволяет выбрать вариант выбора списка марок для отсылки: 
Все марки – означает что будут отосланы все марки, находящиеся как на собственном поштучном учете, так и на учете в ЕГАИС. Вариант «отобранные по условию фильтра означает, что будут отосланы все марки, которые показываются в окне отбора и одновременно находятся на собственном поштучном учете и на учете в ЕГАИС, то есть все марки, выделенные зеленым фоном.
В разделе «Остатки ЕГАИС» на закладке «Поштучный учет» интерфейс разделен на две закладки: «Фильтр» и «Временный набор»: 
На закладке «Временный набор» можно сканировать марки и накапливать в списке только нужные марки.
При сканировании или вводе марки делается проверка, что марка когда либо приходила в организацию или числится на остатках ЕГАИС. Если марка не имеет отношения к организации будет показано сообщение: 
Закладка сделана для быстрой проверки состояния учета марок наличного товара. Для списка марок временного набора действуют все функции раздела, относящиеся к поштучному учету.
В раздел «Подсчет алкоголя ТСД добавлена функция «Проверить в УТМ и отправить в СММарко». Функция позволяет для алкогольных марок из подсчета выполнить проверку на их принадлежность ФСРАР ИД организации, также как это делается в функции «Проверить марки в УТМ», и марки, признанные в УТМ действительными, поставить в очередь на отсылку в СММарко.
В начале работы функция показывает / позволяет выбрать адресат с фильтром «СуперМагМарко»: 
Указать адрес УТМ / проверить его наличие и, при необходимости выполнить тест доступности УТМ: 
Просмотреть список марок и результаты проверки: 
И поставить в очередь на отсылку марки, прошедшие проверку.
Марки, не прошедшие проверку, в СММарко, не отсылаются во избежание конфликтов при продаже по кассе. Марка, не прошедшая проверку, назависимо от причины, будет заблокирована УТМ в момент проверки при продаже товара. Если марки отсутствуют в базе УТМ из-за того, что последние поступления еще не обновили базу УТМ, следует дождаться, когда эти марки появяться в УТМ и, при необходимости, повторить их выгрузку в СММарко.
Изменения функционала в версии 1.049.1 сервис пак 5.
ЕГАИС. Подбор кодов алкогольной продукции для ТТН на отгрузку для мест хранения с учетным регистром «Торговый зал».
УПД на приход.
Поиск подходящего УПД на приход при принятии на склад приходной накладной.
Контроль расхождения сумм при сравнении с приходной накладной.
Почтовый модуль. Настройки и обмен с почтовым ящиком типа «Контрагент» и «Доверительная база».
Контрагенты. Поле «Дополнительный номер».
Для мест хранения с учетным регистром «Торговый зал» списание или отгрузка немаркированной алкогольной продукции приводит к необходимости списания алкогольной продукции с регистра «Торговый зал». Для этого на основании кассового документа или накладной создается ТТН ЕГАИС на отгрузку, в которой необходимо определить код алкогольной продукции для каждого артикула расходного документа, а затем номер справки РФУ2, если продукция должна быть переведена с регистра торгового зала на регистр склада.
При отсылке ТТН на отгрузку или при выполнении функции раздела «Подбор кодов алкогольной продукции» для позиций ТТН с незаполненными кодами алкогольной продукции выполняется подбор подходящих кодов алкогольной продукции и справок РФУ2 по специальному алгоритму. Если ТТН ЕГАИС создана на основании расходной накладной с проставленными основаниями товародвижения, подбор кодов алкогольной продукции выполняется по ТТН на приход, с которыми связаны приходные накладные из оснований товародвижения. Если оснований товародвижения нет, то подбор подходящих кодов алкогольной продукции выполняется по остаткам второго регистра, а справки РФУ2 определяются по актам перемещения в торговый зал с учетом актов возврата и расходов по этим справкам.
В текущей версии внесено следующее изменение в алгоритм, в ту его часть, которая определяет справки РФУ2 для расходуемой алкогольной продукции. Для ТТН на отгрузку с типом (операцией) «Акт списания из торгового зала» подбор справок РФУ2 более не делается. Для передачи акта списания из торгового зала в ЕГАИС указание РФУ2 не требуется. Для прочих ТТН выполнена оптимизация кода подбора справок РФУ2 для убыстрения работы процедуры.
Внесено изменение в алгоритм поиска УПД на приход при смене статуса приходной накладной на «Принят на складе». Поиск УПД на приход выполняется, если прием поставки был выполнен на основании УПД (бумажной копии), но УПД не был помещен в основание приходной накладной, по причине того, что на момент формирования приходной накладной УПД еще не был получен.
В прошлых версиях алгоритм поиска УПД на приход включал проверку наличия в основании документов «УПД на приход» и «Приходная накладная» документа «Заказ поставщику» и его совпадение. В текущей версии, если в основании УПД на приход заказ поставщику не указан, то и в приходной накладной его наличие не проверяется.
В прошлых версиях при изменении статуса приходной накладной, созданной на основании УПД на приход, делалась проверка на совпадение содержания документов для принятия решения о подтверждении приема или о сообщении поставщику факта приема с расхождениями.
При проверке содержания документов, чтобы считать документы идентичными, в том числе, проверялось полное совпадение сумм без налогов, сумм НДС и сумм полных для всех артикулов спецификации. В текущей версии документы считаются идентичными, если имеются расхождения в любой из сумм на одну копейку. Изменение внесено в связи с тем, что некоторые поставщики при создании УКД вычисляют сумму нового документа, как сумму поставки минус сумма не принятого товара, что может привести к расхождению с посчитанной для принятого количества суммой на одну копейку из-за ошибок округления.
В предыдущих версиях существовало ограничение, которое не позволяло назначать одного и того же контрагента разным почтовым ящиком типа «Контрагент». В текущей версии это ограничение снято, что позволяет отсылать одному и тому же контрагенту разные документы с использованием разных форматов обмена.
В текущей версии для почтовых ящиков типа «Контрагент» разрешена настройка обслуживаемых мест хранения для отсылки в них только тех документов, которые относятся к заданным местам хранения. Если для почтового ящика не настроено ни одного обслуживаемого места хранения, то фильтрация документов по месту хранения при постановке в очередь не производится, то есть считается, что контрагенту можно отсылать документы, связанные с любым местом хранения.
Кроме того, для почтовых ящиков типа «Контрагент» разрешено назначать обслуживаемое место хранения уже назначенное другому почтовому ящику. Такое же разрешение дано почтовым ящикам типа «Доверительная база», но не дано ящикам типа «Подчиненная база».
В версии 1.049 из интерфейса раздела «Контрагенты» с закладки «Главная» был удален элемент «Номер». В текущей версии отображение элемента возвращено под названием «Дополнительный номер»:
Изменения функционала в версии 1.049.1 сервис пак 6.
ЕГАИС. Отказ от использования второго регистра («Торговый зал»).
Управление перемещением немаркированной продукции в торговый зал.
Списание пива в ЕГАИС по кассовым документам.
Карточки складского учета. Вкладка «История кодов продукции ЕГАИС».
Весы «Falcon», «DIGI SM-5000 Ethernet». Выгрузка второй цены со скидкой.
ЕГАИС выпустил следующее информационное сообщение:
«В связи с вводом с 1 апреля 2023 года обязательной маркировки пива, пивных напитков, сидра, пуаре и медовухи Росалкогольрегулированием будет осуществляться поэтапный отказ от использования второго регистра (Торговый зал) ЕГАИС для пива, пивных напитков, сидра, пуаре и медовухи.
На первом этапе с 15 мая 2023 года будет введен запрет на возможность фиксации в ЕГАИС «Заявки о фиксации в ЕГАИС сведений о перемещении алкогольной продукции в торговый зал», установленной приказом Росалкогольрегулирования от 17.12.2020 № 397 «Об утверждении форм, порядка заполнения, форматов и сроков представления в электронном виде заявок о фиксации информации в единой государственной автоматизированной системе учета объема производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции».
На втором этапе Росалкогольрегулированием будет введен полный запрет на операции со вторым регистром (Торговый зал) ЕГАИС для организаций, являющихся участниками ЕГАИС и осуществляющих деятельность по розничной реализации пива и пивных напитков.»
То есть, с 15 мая 2023 года любая попытка перемещения алкогольного товара с регистра «Склад» на регистр «Торговый зал» будет невозможна, но прочие операции, такие как, списание, перемещение из торгового зала, некоторое время будут доступны.
Изменение касается только мест хранения с учетным регистром «Торговый зал», то есть магазинов. Для складов, где не ведется розничная реализация алкоголя, и установлен учетный регистр «Склад» правила работы не меняются.
С точки зрения учета движения немаркированной продукции ограничение, вводимое 15 мая, означает, что используемые до сих пор правила работы при продаже по кассе, инвентаризации недостачи, продаже внешним контрагентам или перемещении в другие места хранения формально остаются без изменения. Запрет явным образом касается только перемещения продукции в торговый зал. Но с течением времени продукция, находящаяся на регистре торгового зала будет убывать и для регулярной работы магазина потребуется либо частично выполнять операции с регистром «Торговый зал», частично с регистром «Склад», либо принудительно вернуть продукцию на регистр «Склад» и вести все операции с регистром «Склад». При этом надо принять во внимание, что ЕГАИС не дал методических рекомендация о способе определения партий товаров для списания продаж по кассе. При продаже по кассе в чеке фиксируется только штриховой код (артикул) товара, тогда как для списания с первого регистра требуется знать точное значение кода алкогольной продукции и номер справки РФУ2, по которой пришел проданный товар. По этой причине немедленный возврат всей продукции на первый регистр представляется преждевременным.
В текущей версии в административном модуле в разделе «База данных» для группы данных «Документы» добавлен флаг «Автоматически перемещать в торговый зал немаркированный товар». По умолчанию флаг установлен, что соответствует текущему поведения системы: 
Если флаг снять, то принимаемая на первый регистр немаркированная продукция более не будет автоматически перемещаться на второй регистр. Это флаг необходимо снять не позднее конца дня 14 мая 2023 года.
В разделе «Кассовые документы» имеется функция «Списание пива ЕГАИС», которая позволяет для каждого кассового документа сформировать «Акт о списании из торгового зала» для передачи в ЕГАИС информации о розничной реализации немаркированной продукции.
Функция проверяет наличие в кассовом документе артикулов, входящих в группу алкогольного классификатора с флагом «пиво». Проверка наличия проводится с учетом возвратов по кассе того же дня. Если такие артикулы находятся, то создается документ «ТТН ЕГАИС на отгрузку» с операцией «Акт о списании из торгового зала» и для каждого найденного артикула с положительным количеством продажи (с учетом возвратов) в акте создается строка с привязкой к строке спецификации кассового документа. Если у артикула имеется единственный код алкогольной продукции, он тут же помещается в строку спецификации ТТН ЕГАИС. На этом функция прекращает работу. Дальнейшие действия по формированию акта списания из торгового зала выполняются в разделе ТТН ЕГАИС на отгрузку.
В текущей версии функция «Списание пива ЕГАИС» перед началом формирования акта делает проверку на наличие остатка на регистре торгового зала хотя бы для одного из кодов алкогольной продукции списываемых артикулов. Если остатки есть, она создает «Акт списания из торговго зала», если все остатки исчерпаны, будет создан «Акт списания со склада». В случае создания акта списания из торгового зала алгоритм формирования акта такой же, как в предыдущих версиях.
Принятие решение о том, какой акт надо формировать, не зависит от состояния флага «Автоматически перемещать в торговый зал немаркированный товар».
Следующий шаг подготовки акта списания из торгового зала подразумевает использование функции «Подбор кодов алкогольной продукции» раздела «ТТН ЕГАИС на отгрузку» или аналогичной функции, которая выполняется при нажатии кнопки «Отослать».
В текущей версии поведение этой функции следующее:
При выполнении подбора кодов алкогольной продукции используется информация об остатках по кодам алкогольной продукции на регистре торгового зала, о чем показывается сообщение: 
Если для какого либо артикула из кассового документа при просмотре остатков торгового зала по всем его кодам алкогольной продукции обнаруживается, что нет достаточного количества, то недостающее количество помещается в акт списания со склада, который может быть обработан по правилам отсылки продукции с регистра «Склад».
Флаг «Автоматически перемещать в торговый зал немаркированный товар» на работу функции не влияет.
В раздел карточек складского учета добавлена вкладка «История кодов продукции ЕГАИС»: 
В журнале истории фиксируется факт добавления и удаления кода алкогольной продукции.
Для драйверов весов моделей «Falcon» и «DIGI SM-5000 Ethernet» в диалоге «Настройка электронных весов», на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой: 
Для корректной печати в этикетке либо одной цены, либо двух цен необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat: 
При выгрузке артикулов (PLU) в весы артикулу назначается либо этикетка с одной ценой, либо с двумя ценами. Этикетка с одной ценой назначается всегда, если не выбран вид цены для цены со скидкой. Если вид цены выбран, то артикулу назначается этикетка с двумя ценами, если для него имеется маркетинговая акция по виду цены со скидкой и маркетинговая цена меньше цены для кассы.
По условиям протокола вторая цена выгружается в весы как разница между первой и второй ценой (между ценой для кассы и ценой со скдикой).
Изменения функционала в версии 1.049.1
ЕГАИС.
Остатки ЕГАИС. Функция «Очистка ошибок запросов поштучных остатков по РФУ2».
Отгрузка немаркированного алкоголя со второго регистра без простановки оснований товародвижения.
УПД на отгрузку. Информация о складе разгрузки.
Контрагенты. GLN склада контрагента.
Расходная накладная. GLN адреса разгрузки.
УПД на отгрузку. Транспортный раздел.
УПД на отгрузку. Обмен с провайдером.
Операция «Акт приемки».
Алгоритм создания УПД на отгрузку и реакция на получение акта приемки.
Расходная накладная. УПД. Состояние обмена.
Расходная накладная. Функция «Обработать акт приемки».
Возврат поставщику с формированием УКД для УПД на приход.
Контрагенты. Закладка «ЭДО».
Прием УКД для УПД на приход в статусе «Закрыт» при возврате товара.
Приходная накладная. Поиск подходящего УПД на приход при смене статуса накладной.
Поддержка работы СМ Мобайл.
Контрагенты. Определение цены контракта.
Сервер обмена данными. Аналитический объект «Алкогольные марки упаковки»
Касса Супермаг. Чек для пречека с упаковками маркированного товара.+
Перечень исправленных ошибок и улучшений.
\\ При отсылке запроса кодов марок из регистра №3 ЕГАИС может случиться ошибка отсылки, например, "Проверяемый файл НЕ ВАЛИДЕН. FSRAR_ID документа \[030000394897\] не совпадает с идентификатором абонента в ключе RSA \[030000553302\]". Ошибка показывается на закладке поштучного учета в таблице кодов КИЗ в поле «Состояние обмена с ЕГАИС». Если это сообщение уже не нужно, оно всё равно будет показываться и дальше, если ситуация не может быть изменена. \\ В текущей версии создана функция, которая позволяет очистить сообщения об ошибках, если они больше не нужны. \\ |
Для создания ТТН ЕГАИС на отгрузку по данным расходной накладной используется функция «Формирование и отсылка ТТН в ЕГАИС». Функция создает ТТН ЕГАИС и заполняет ее данными из накладной. Часть данных, которые не могут быть получены из накладной, остаются незаполненными и заполняются при нажатии на кнопку «Отослать» в разделе ТТН ЕГАИС. В этот момент выполняется подбор алкокодов для артикулов (если их не удалось однозначно определить по артикулу) и подбор справок РФУ1 и РФУ2.
Для немаркированных алкогольных товаров, если место хранения связано с ФСРАР ИД с учетным регистром «Торговый зал», функция подбора справок РФУ1 и РФУ2 имела следующее поведение:
Если в расходной накладной проставлены основания товародвижения, функция создает акт возврата продукции с регистра торгового зала на регистр склада и заполняет ТТН на отгрузку, используя информацию о справках РФУ1 и РФУ2 из оснований товародвижения. Если основания товародвижения не проставлены, функция пытается списать товар с регистра склада, используя информацию об остатках регистра склада, которые, в том числе, содержат данные о справках. В этом случае показывалось следующее сообщение: 
В первом случае (при простановке оснований товародвижения) имеется риск неверного выбора основания, когда товар по выбранному основанию с точки зрения ЕГАИС уже продан, возвращен поставщику или списан с регистра склада по документам ЕГАИС (то есть с указанием справки РФУ1 и РФУ2, продажи по кассе не влияют на эти данные) и его количества по ТТН недостаточно для выполнения операции. Во втором случае требуется предварительно вручную перевести товар со второго регистра на первый, поскольку весь немаркированный алкоголь при поступлении автоматически переводится на второй регистр.
В текущей версии изменено поведение функции, когда основание товародвижения не проставлено. Функция выполняет анализ остатков в торговом зале для определения возможности вернуть товар на первый регистр и подбирает подходящие акты перемещения в торговый зал с учетом ранее сделанных возвратов для того, чтобы выполнить возврат товара на склад с указанием корректных справок РФУ1 и РФУ2. Перед началом выполнения функции показывается следующее сообщение: 
Для того количества, которое требуется переместить на регистр склада, подбираются самые давние акты перемещения в торговый зал среди тех, которые покрывают текущий остаток регистра торгового зала.
В разделе контрагентов в таблицу складов контрагента добавлено поле «GLN»: 
Значение GLN склада контрагента используется для заполнения соответствующего поля заголовка расходной накладной. См. ниже.
В заголовок расходной накладной на закладке «Транспортный раздел» для адреса разгрузки добавлено поле «GLN». При создании документа поле автоматически заполняется значением GLN главного склада клиента: 
Также автоматически адрес погрузки заполняется адресом места хранения, а адрес разгрузки - адресом главного склада.
В выпадающем списке адреса разгрузки показывается список складов клиента и его физический и юридический адрес. В прошлых версиях показывались только физический и юридический адреса. Для физического и юридического адресов GLN не задается.
В разделе «УПД на отгрузку» в заголовок документа добавлена закладка «Транспортный раздел», в котором размещены данные адреса погрузки и разгрузки, включая GLN адреса разгрузки: 
Данные заполняются при создании документа из соответствующих полей расходной накладной.
В XSD схему почтового объекта УПД на отгрузку добавлен тэг SMDOCTRANSPORT, содержащий информацию транспортного раздела.
В заголовок документа УПД на отгрузку добавлено поле «Операция». Для документа, созданного на основании расходной накладной, операция имеет значение «Отгрузка получателю». Для документа, созданного на основании ответа контрагента с результатом приемки (см.ниже), операция имеет значение «Акт приемки»: 
В прошлых версиях УПД на отгрузку создавался при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью». В текущей версии принята логика, при которой статус «Отпущен полностью» должен свидетельствовать о том, что документ утвержден обеими сторонами. В связи с этим УПД на отгрузку теперь создается при смене статуса расходной накладной с «Черновик» на «Отпущен со склада». Это поведение требует, чтобы все атрибуты документа, необходимые для формирования УПД на отгрузку, были заполнены до смены статуса на «Отпущен со склада».
Файл ответа от контрагента с результатом приемки (описывается схемой UDCONFIRM.xsd) в дальнейшем будет называться «Акт приемки».
При получении от провайдера файла с актом приемки с кодом ответа 1 (поставка принята), происходит изменение статуса УПД на отгрузку со «Сформирован» на «Обработан» и, одновременно, меняется статус расходной накладной с «Отпущен со склада» на «Отпущен полностью».
При получении акта приемки с кодом 3 (в приеме поставки отказано) статус УПД на отгрузку устанавливается в значение «Заблокирован», статус расходной накладной не меняется и остается «Отпущен со склада». Решение о смене статуса расходной накладной должен принимать персонал после выяснения обстоятельств отказа. Если это действительно полный отказ от поставки, то статус расходной накладной надо установить в «Заблокирован» после возврата товара на склад. Если речь идет об ошибках оформления УПД, то документ может быть исправлен и заново отослан контрагенту.
При получении акта приемки с кодом 2 (прием с расхождением) на основании акта приемки создается новый документ «УПД на отгрузку» с операцией «Акт приемки», статусом «Сформирован» и спецификацией из полученного от контрагента акта приемки. В основание этого документа ставится расходная накладная. Исходный документ «УПД на отгрузку» с операцией «Отгрузка получателю» получает статус «Заблокирован». Расходная накладная не меняет своего статуса. В дальнейшем персонал должен принять решение о согласии или несогласии с актом контрагента и отослать ему свой ответ. См. ниже «Расходная накладная. Функция «Обработать акт приемки»».
В разделе расходных накладных добавлена возможность выводить колонку «УПД. Состояние обмена» в таблице отобранных документов (см. опции кнопки «Поля…»): 
В поле показывается информация о состоянии УПД на отгрузку, связанного с расходной накладной, включая информацию из квитанций провайдера в случае ошибок обмена, а также информацию о факте приема с расхождениями, если от контрагента пришел акт приемки с расхождением.
В раздел расходных накладных добавлена функция «Обработать акт приемки». Функция доступна для документов со статусом «Отпущен со склада» в режиме редактирования. Функция работает, если от контрагента получен акт приемки с расхождением.
В диалоге старта функции имеется возможность посмотреть расхождение и принять или отклонить расхождение: 
При нажатии на кнопку «Показать расхождение» выводится детальная информация о расхождении: 
При сравнении расходной накладной и акта приемки по каждому артикулу расходной накладной сверяется количество, затем совпадение КИЗ, если они есть, затем сравниваются суммы без налогов, суммы НДС и суммы полные.
Нажатие кнопки «Признать расхождение» приводит к замене спецификации расходной накладной на содержание акта приемки, созданию и отсылке нового УПД на отсылку. Перед выполнением действия показывается сообщение: 
Для вновь отосланного УПД на отгрузку будет ожидаться новый акт приемки, чтобы завершить регистрацию отгрузки.
Кнопка «Аннулировать отгрузку» вызывает блокировку УПД с операцией «Акт приемки». Статус расходной накладной остается без изменения. Отсылка информации контрагенту не производится.
При возврате товара ФНС разрешает вместо УПД на отгрузку возвращаемого товара оформлять возврат в виде корректировки УПД на поставку возвращаемого товара, то есть с помощью УКД к УПД на приход.
Выбор варианта возврата с помощью УПД на отгрузку или с помощью УКД для УПД на приход должен быть заранее согласован с поставщиком и неукоснительно соблюдаться.
В раздел контрагентов добавлена закладка «ЭДО», на которую помещены атрибуты «Идентификатор участника обмена УПД» и «ЭДО при приеме с расхождением». В прошлых версиях эта информация показывалась на закладке «Описание» в одноименных системных дополнительных характеристиках контрагента. На эту же закладку добавлен атрибут «ЭДО при возврате поставщику» с возможными значениями «УПД на отгрузку» и «УКД для документа поставки»: 
Если для контрагента выбран вариант «УКД для документа поставки», то при смене статуса расходной накладной с операцией «Возврат поставщику» УПД на отгрузку не создается. В этом случае никаких документов поставщику не отсылается. Считается, что поставщик по результату приемки возврата сам оформит и пришлет УКД для коррекции того документа поставки, по которому делается возврат. При получении УКД оператор может согласиться или не согласиться с результатом оформления возврата.
Когда УПД на приход получает статус «Закрыт», прием документов, влияющих на его содержание, прекращается, в том числе запрещается принимать УКД для его коррекции.
Если для контрагента опция «ЭДО при возврате поставщику» установлена в значение «УКД для документа поставки», то теперь разрешается принимать УКД для УПД в статусе «Закрыт» при условии, что дата УКД больше или равна дате УПД. В этом случае считается, что УКД пришел, как подтверждение поставщиком возврата товара.
Внимание! В текущей версии нет контроля того, что УКД для возврата товара действительно пришел, как ответ на формирования расходной накладной на возврат товара. Также нет автомата сличения состава возвращаемого товара и содержания корректирующего документа. Это связано с тем, что на одну расходную накладную на возврат товара может прийти множество УКД для разных приходов, в том числе один и тот же артикул может присутствовать в нескольких УКД.
При получении УКД для закрытого УПД создается новый УПД на приход. Содержание нового УПД формируется на основании предыдущего УПД на приход и корректирующей информации из УКД. Статус нового УПД устанавливается в «Принят», операция - «Коррекция уже принятой поставки». Статус прежнего УПД не меняется.
Оператор может вручную поменять статус нового УПД на приход, то есть согласиться или не согласиться с результатом приема возврата поставщиком. При смене статуса УПД на приход с операцией «Коррекция уже принятой поставки» сличение УПД с приходной накладной не происходит, поскольку приходная накладная не меняется. Ответ для нового УПД отсылается с результатом приемки 1 (УКД принят) или 3 (УКД отвергнут) и без спецификации. Статус прежнего УПД меняется на «Заблокирован», если новый УПД получает статус «Закрыт». Это позволяет принимать последовательно УКД для нескольких возвратов.
При создании приходной накладной может сложиться ситуация, когда УПД на приход в момент приема товара еще не получен и не может быть использован в качестве основания прихода. УПД на приход может быть получен в ходе приемки или после ее завершения. Чтобы автоматически привязать УПД на приход к уже созданной приходной накладной в прошлых версиях была создана функция, которая при смене статуса накладной с «Черновик» на «Принят на складе» выполняла поиск УПД на приход. Поиск велся по значению полей «Документ поставщика» и «Дата документа поставщика» из заголовка приходной накладной, которые сравнивались со значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
В текущей версии в алгоритм поиска добавлен поиск УПД на приход по совпадению значений полей «Счет-фактура» и «Дата счета-фактуры» приходной накладной и значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
Изменение алгоритма связано с тем, что УПД на приход может одновременно являться и счетом-фактурой и передаточным документом одновременно. Соответственно, его «Номер УПД» и дата могут быть занесены, как в поля номер и дата документа поставщика, так и в поля номер и дата счета-фактуры приходной накладной.
В текущей версии внесены следующие изменения в функции, обеспечивающие работу программы СМ Мобайл:
\\
В сервер обмена данных добавлен аналитический объект IOSMIOBOXMARKCODES для получения списка алкогольных марок, содержащихся в упаковке алкоголя. Аргументом функции является код упаковки алкоголя, нанесенный на коробку с алкоголем, ответом является список марок алкогольной продукции, содержащейся в упаковке.
\\
Пример команды:
GET [<span style="color: #0000ff"><span style="text-decoration: underline; "><span class="nobr"><a href="http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=" class="external-link" rel="nofollow">http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>"03000009996110518000000002</span></span>|http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=%2203000009996110518000000002]"
\\
Где localhost:8085 – ip адрес сервера обмена данных
03000009996110518000000002 – код упаковки.
\\
Пример выполнения запроса с помощью curl:
\\
curl.exe -s -X GET [<span style="color: #0000ff"><span style="text-decoration: underline; "><span class="nobr"><a href="http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=" class="external-link" rel="nofollow">http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>"03000009996110518000000002</span></span>|http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber=%2203000009996110518000000002]"
\\
Ответ:
\\
\{
"PACKAGE": \{
"name": "a585380c-6e27-4360-80b3-e10dd2930bfc",
"POSTOBJECT": \[
\{
"description": "Алкогольные марки упаковки",
"action": "normal",
"Id": "IOSMIOBOXMARKCODES",
"IOSMIOBOXMARKCODES": \{
"SMIOBOXMARKCODES": \[
\{
"sMarkCode": "203200440290891018001TDUDFPG72ZVRLX26KFXGWGKEWAPS6I3KETE4KMQ27KNZYK5BZ55AL2YQBYAX64E6ZGV6EWAGOQLGB3LN23GVRADBCMUWJQKOSVIF5MP4Q37ZD3LFWRTOZLENXJYT7XNYA"
\},
\{
"sMarkCode": "203200441445631018001QDPHWDIZYDCGO5BLRSYAQ24WUM2RO3W7WIQOPLBHPFUVNLEJOMFJ6SBW5XD2DWTACK2K37DXO7KVMHAIPDJAB7PDRRI5XRV556PJPBIHMPOVHBSPEVIARJB4Y3EN6U5WA"
\},
\{
"sMarkCode": "2032005721293710180017FAO7IRYXT5IL6JBLBEL3QTNGIJ6YI4AO4RSDVLZLMTBEQPG5KAYWPXRNG3RPHXVLYD6ZEZY4CPCOMV2WZ5COU3QKVKXYLHPP5CCDQNTP6TT4ZCQMNXE7CDRQIU3AXTRI"
\},
\{
"sMarkCode": "203200572167291018001ZKIC7T7YKZI3UPNICE4SLSKC7UGGLBQUBJF25LPCX3OJU55FUUF3VA4WA7J3KSMXKSNRMDXSQ5366JDAIKF34FHON3SZGXVKWX4ALPVAOBHO6JZUEZ2VW4VVCL46X3VGI"
\}
\]
\}
\}
\]
\}
\}
\\
\\
Ответ, когда марок нет:
\\
\{
"PACKAGE": \{
"name": "0e99d351-d167-4cc6-8ece-9998f5e5e76e",
"POSTOBJECT": \[
\{
"description": "Алкогольные марки упаковки",
"action": "normal",
"Id": "IOSMIOBOXMARKCODES",
"IOSMIOBOXMARKCODES": \{\}
\}
\]
\}
\}
\\
Формальное описание структуры JSON:
\\
\{
"$schema": "[<span style="color: #0000ff">{+}<span class="nobr"><a href="http://json-schema.org/schema#+" class="external-link" rel="nofollow">http://json-schema.org/schema#+<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span></span>|http://json-schema.org/schema]",
"title": "IOSMIOBOXMARKCODES, Export",
"description": "Алкогольные марки упаковки",
"type": "object",
"additionalProperties": false,
"properties": \{
"PACKAGE": \{
"type": "object",
"additionalProperties": false,
"properties": \{
"name": \{
"type": "string"
\},
"POSTOBJECT": \{
"type": "array",
"items": \{
"type": "object",
"additionalProperties": false,
"properties": \{
"description": \{
"type": "string"
\},
"action": \{
"type": "string"
\},
"Id": \{
"type": "string"
\},
"IOSMIOBOXMARKCODES": \{
"type": "object",
"additionalProperties": false,
"properties": \{
"SMIOBOXMARKCODES": \{
"type": "array",
"items": \{
"type": "object",
"additionalProperties": false,
"properties": \{
"sMarkCode": \{
"anyOf": \[
\{
"type": "string"
\},
\{
"type": "null"
\}
\]
\}
\}
\}
\}
\}
\}
\}
\}
\}
\}
\}
\}
\}
\\
Для использования объекта надо в интерфейсе сервера обмена данных поместить объект в перечень разрешенных для запроса и объявить его доступным:
\\
!worddav9998d0f0a22322a5250c1b8dba3e4244.png|height=377,width=646!
\\
Сервер обмена данных может вернуть содержание упаковки алкогольной продукции только в случае, когда в базе данных имеется ТТН на приход с соответствующей информацией. Если организация имеет распределенную структуру баз данных и весь обмен с ЕГАИС ведется только в старшей базе, то для получения информации об упаковках алкогольной продукции в подчиненных местах хранения необходимо настраивать их обмен с сервером обмена данных старшей базы данных.
\\ |
Объемно-сортовой учет маркируемого товара позволяет в документах передачи товара регистрировать вместо списка кодов КИЗ маркированного товара код, содержащий информацию о количестве кодов КИЗ, то есть код объемно-сортового учета в формате «01<14 символов GTIN>37<количество марок>».
В таблицу справочника «Коды ТН ВЭД» добавлена колонка «Объемно-сортовой учет»: 
Поле используется для указания того, что код ТНВЭД указывает на маркированные товары, относящиеся к объемно-сортовому учету. Для кодов ТН ВЭД без флага «Маркируемый» флаг «Объемно-сортовой учет» смысла не имеет.
В спецификацию документов «УПД на приход», «УПД на отгрузку», «Накладные поставщика» добавлена возможность сохранять коды объемно-сортового учета и отображать их к поле «КИЗ / Коды ОСУ»: 
В спецификации документа коды КИЗ и коды ОСУ показываются в одном и том же поле, но в структуре документов эти данные хранятся в разных таблицах.
Для приема УПД на приход по протоколу XML в XSD-схему «UI.XSD» надо добавить следующий тэг, соответствующий таблице документа для хранения кодов ОСУ:
<xs:element name="SMSPECOSUCODEWE" msdata:Locale="ru">
<xs:complexType>
<xs:sequence>
<xs:element smimport:Function="GenerateDocNoUIDatebyINN2(SMWAYBILLSEXT.CONSIGNECLIENTINN, SMDOCUMENTS.LOCATIONKPP, SMDOCUMENTS.CLIENTINN, SMDOCUMENTS.CLIENTKPP, SMWAYBILLSEXT.SUPPLIERDOC, SMDOCUMENTS.CREATEDAT)" name="DOCID" type="xs:string" />
<xs:element default="UI" name="DOCTYPE" type="xs:string" />
<xs:element name="SPECITEM" type="xs:decimal" />
<xs:element name="OSUCODE" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
И ограничение:
<xs:unique msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true" name="SMSPECOSUCODEWE_Constraint1">
<xs:selector xpath=".//SMSPECOSUCODEWE" />
<xs:field xpath="DOCID" />
<xs:field xpath="DOCTYPE" />
<xs:field xpath="SPECITEM" />
<xs:field xpath="OSUCODE" />
</xs:unique>
В приведенном примере для генерации номера документа Торговой системы по содержанию XML-файла используется функция «GenerateDocNoUIDatebyINN2». Вместо нее может быть использована другая функция.
В XML-файле этому элементу схемы будет соответствовать, например, такая запись:
<SMSPECOSUCODEWE>
<SPECITEM>2</SPECITEM>
<OSUCODE>01046070253984243711</OSUCODE>
</SMSPECOSUCODEWE>
Прием товара, для которого разрешен объемно-сортовой учет, проводится также, как прием немаркированного товара, за исключением того, что на таком товаре присутствуют марки с кодами КИЗ и они могут быть использованы для идентификации товара.
При сканировании кодов КИЗ товаров с ОСУ сам код сохраняется в приходной накладной, но в дальнейшем используется только для контроля уникальности кода КИЗ. Сравнение с кодами КИЗ в УПД на приход не выполняется. Если сплошное сканирование кодов КИЗ не предполагается, можно сканировать EAN коды или вводить количество вручную.
Прием товаров с ОСУ можно выполнять программой «СМ Мобайл Андроид», начиная с версии 2.1. 999.30, и «СМ Мобайл», начиная с версии 1.6.2470.34 (только в режиме «Подсчет кодов КИЗ»), а также непосредственно в разделе приходной накладной «Супермаг+». В разделе приходных накладных внесены изменения в систему цветовых предупреждений о расхождении состава КИЗ накладной и УПД на приход. Для товаров с ОСУ проверка расхождения не делается. Кроме того, внесены изменения в функции проверки, чтобы избежать проверки состава КИЗ в приходной накладной.
При смене статуса приходной накладной на «Принят складом» выполняется сличение документов «Приходная накладная» и «УПД на приход». Для маркированных товаров с ОСУ сличение выполняется без проверки совпадения КИЗ, независимо от их наличия или отсутствия в УПД и приходной накладной. При расхождении количества товаров с ОСУ в файл подтверждения приема заносится информация о фактически принятом товаре в виде кода ОСУ, который формируется на основании кода EAN с флагом «Обмен с EDI» и фактически принятого количества.
Например:
<ITEM>
<BARCODE>4811269007176</BARCODE>
<QUANTITY>1</QUANTITY>
<ARTICLE>000072</ARTICLE>
<SPECITEM>2</SPECITEM>
<DISPLAYITEM>2</DISPLAYITEM>
<BARCODEEXTERNAL>4811269007176</BARCODEEXTERNAL>
<ITEMPRICE>143</ITEMPRICE>
<ITEMPRICENOTAX>119.17</ITEMPRICENOTAX>
<CARDFULLNAME>Молоко Домик в деревне. 2,5% 1л..</CARDFULLNAME>
<CARDMEASUREMENTCODE>796</CARDMEASUREMENTCODE>
<VATRATE>20</VATRATE>
<VATSUM>23.83</VATSUM>
<TOTALPRICE>143</TOTALPRICE>
<TOTALPRICENOTAX>119.17</TOTALPRICENOTAX>
<MARKS />
<OSUCODES>
<OSUCODE>0104607025398424371</OSUCODE>
</OSUCODES>
</ITEM>
При приеме исправительного УПД контроль кодов ОСУ или кодов КИЗ для артикулов с ОСУ не производится. Сравнивается количество, цены и суммы.
При создании расходной накладной с маркированными товарами для товаров с ОСУ разрешается не сканировать коды КИЗ и фиксировать только количество товара. Если коды КИЗ будут просканированы, они будут сохранены в накладной, но не будут использоваться для формирования УПД на отгрузку. 
При смене статуса расходной накладной на «Отпущен со склада» для накладных с маркированным товаром автоматически создается «УПД на отгрузку». При создании УПД на отгрузку для строк с артикулами с ОСУ генерируются коды ОСУ на основании штрихового кода артикула с флагом «Обмен с EDI» и количества из строки спецификации. Коды КИЗ из расходной накладной для таких артикулов не переносятся. 
Для корректной отсылки УПД на отгрузку с кодами ОСУ необходимо, чтобы в файле описания схемы UD.XSD был описан тэг:
<xs:element msdata:Locale="ru" name="SMSPECOSUCODEUD">
<xs:complexType>
<xs:sequence>
<xs:element name="DOCID" type="xs:string" />
<xs:element name="DOCTYPE" type="xs:string" />
<xs:element name="SPECITEM" type="xs:decimal" />
<xs:element name="OSUCODE" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
И ограничение:
<xs:unique msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true" name="SMSPECOSUCODEUD_Constraint1">
<xs:selector xpath=".//SMSPECOSUCODEUD" />
<xs:field xpath="DOCID" />
<xs:field xpath="DOCTYPE" />
<xs:field xpath="SPECITEM" />
<xs:field xpath="OSUCODE" />
</xs:unique>
В схему для УПД фильтра внесено изменение, которое позволяет принимать коды КИЗ маркированных товаров как прежде, в тэге MARKCODE, так и раздельно: коды КИЗ для единиц товара - в теге MARKCODE, коды КИЗ для упаковок - в тэге PACKAGECODE. Для этого внесено следующее изменение в XSD-схему UI.XSD:
<xs:element msdata:Locale="ru" name="SMSPECTOBACCOWE">
<xs:complexType>
<xs:sequence>
<xs:element smimport:Function="GenerateDocNoUIDatebyINN2(SMWAYBILLSEXT.CONSIGNECLIENTINN, SMDOCUMENTS.LOCATIONKPP, SMDOCUMENTS.CLIENTINN, SMDOCUMENTS.CLIENTKPP, SMWAYBILLSEXT.SUPPLIERDOC, SMDOCUMENTS.CREATEDAT)" name="DOCID" type="xs:string" />
<xs:element default="UI" name="DOCTYPE" type="xs:string" />
<xs:element name="SPECITEM" type="xs:decimal" />
<xs:element name="MARKCODE" type="xs:string" />
<xs:element name="PACKAGECODE" type="xs:string" />
<xs:element smimport:Function="BarcodeKey(MARKCODE)" name="BARCODE" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
В приведенном примере для генерации номера документа Торговой системы по содержанию XML-файла используется функция «GenerateDocNoUIDatebyINN2». Вместо нее может быть использована другая функция.
В XML-файле этому описанию будет соответствовать, например, такой текст:
<SMSPECTOBACCOWE>
<SPECITEM>1</SPECITEM>
<MARKCODE>00000046200020QEv?c"TAQB3ya15</MARKCODE>
</SMSPECTOBACCOWE>
<SMSPECTOBACCOWE>
<SPECITEM>1</SPECITEM>
<PACKAGECODE>010460143993125621pz>,!A:</ PACKAGECODE >
</SMSPECTOBACCOWE>
<SMSPECTOBACCOWE>
<SPECITEM>1</SPECITEM>
<PACKAGECODE>010460143993125621nNc3bUI8005122000</ PACKAGECODE >
</SMSPECTOBACCOWE>
При приеме данных из XML коды КИЗ (как единиц товара, так и упаковок) будут помещены в одну таблицу кодов КИЗ документа. При приеме УПД на приход из XML-файла можно принимать как файлы, в которых все коды КИЗ будут перечислены в тэге MARKCODE, так и файлы с новой структурой данных.
Для отсылки подтверждения приема необходимо внести изменение в схему UICONFIRM.xsd. Описание тэга MARKS должно быть следующее:
<xs:element name="MARKS" minOccurs="1" maxOccurs="1" >
<xs:complexType>
<xs:sequence>
<xs:element name="MARKCODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
<xs:element name="PACKAGECODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
</xs:sequence>
</xs:complexType>
</xs:element>
При формировании файла ответа с результатом приема коды КИЗ из приходной накладной будут распределены по тэгам MARKCODE и PACKAGECODE в зависимости от того, идентифицируют они единицу товара или упаковку.
Для отсылки УПД на отгрузку с разделением кодов КИЗ по тегам MARKCODE и PACKAGECODE необходимо изменить XSD-схему UD.xsd. Вместо тэга SVSPECTOBACCOUD, необходимо описать следующий тэг:
<xs:element msdata:Locale="ru" name="SMSPECTOBACCOUD">
<xs:complexType>
<xs:sequence>
<xs:element name="DOCID" type="xs:string" />
<xs:element name="DOCTYPE" type="xs:string" />
<xs:element name="SPECITEM" type="xs:decimal" />
<xs:element name="BARCODE" type="xs:string" />
<xs:element name="MARKCODE" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
И добавить его ограничение:
<xs:unique msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true" name="SMSPECTOBACCOUD_Constraint1">
<xs:selector xpath=".//SMSPECTOBACCOUD" />
<xs:field xpath="DOCID" />
<xs:field xpath="DOCTYPE" />
<xs:field xpath="SPECITEM" />
<xs:field xpath="MARKCODE" />
</xs:unique>
При выгрузке УПД на отгрузку соответствующая часть XML-файла будет выглядеть, например, так:
<SMSPECTOBACCOUD>
<DOCID>0000000004</DOCID>
<DOCTYPE>UD</DOCTYPE>
<SPECITEM>1</SPECITEM>
<PACKAGECODE>010460143993125621nNc3bUI8005122000</PACKAGECODE>
</SMSPECTOBACCOUD>
<SMSPECTOBACCOUD>
<DOCID>0000000004</DOCID>
<DOCTYPE>UD</DOCTYPE>
<SPECITEM>1</SPECITEM>
<PACKAGECODE>010460143993125621pz>,!A:</PACKAGECODE>
</SMSPECTOBACCOUD>
В прошлых версиях изменение статуса документа «УПД на отгрузку» предварялась проверкой его состояния. Если состояние обмена документа было «Отправлен», «Принят» или «Принят с расхождениями», смена статуса документа запрещалась.
В текущей версии создана функция 22 «Контроль состояния обмена УПД на отгрузку», которая проверяет возможность смены статуса. Функция управляется по должностям. По умолчанию, режим проверки установлен в «Предупреждение».
В текущей версии документ «Справка к ГТД/ТТН» получил название «ГТД». Из документа удалены упоминания о справках к ТТН, которые использовались для сопровождения алкогольных товаров до введения ЕГАИС.
Соответственно, изменен мастер создания документа, в котором теперь имеется только форматированный ввод номера ГТД: 
В прошлых версиях позволялось выбрать либо форматированный ввод номера ГТД, либо ввод произвольной строки для справки к ТТН.
В диалог редактирования номера ГТД и сертификата соответствия в ячейку поля «ГТД» добавлена кнопка, вызывающая диалог для форматированного ввода номера ГТД и РНПТ: 
Введенное значение проверяется на соответствие правилам формирования номера ГТД: 
Для описания артикула в разделе карточек складского учета используется 31 вкладка. Для навигации по вкладкам в раздел добавлен диалог, который вызывается кнопкой в виде папки: 
При нажатии на кнопку показывается следующий диалог со сгруппированными названиями вкладок: 
Щелчок по названию вкладки приводит к переходу к соответствующей вкладке.
\\ В прошлых версиях для протоколов обмена «Внешний \[XML\]» и «Внешний \[JSON\]» для тех случаев, когда сервер обмена данных выступал в роли клиента, можно было выбрать алгоритм «Basic без шифрования» для аутентификации при запросе данных у внешнего сервера. \\ В текущей версии реализована аутентификация для случая, когда сервер обмена данных выступает в роли сервера: \\ !worddav5600314be03b75c7a2addbca12da7b10.png|height=376,width=442! \\ Для протокола «Внешний \[JSON\]» и «Внешний \[XML\]» реализована команда постраничного запроса данных вида: \\ /?Page=2&PageSize=10 \\ Где Page – номер запрашиваемой страницы, PageSize – количество записей / объектов данных, содержащихся на странице. \\ Внимание! При формировании обращения специальный символ & должен быть заменен на %26 \\ |
В почтовый модуль добавлен новый протокол обмена «Октопус – сервер заказов» и транспорт с таким же названием. Протокол и транспорт должны использоваться совместно: 
В сервер Октопус передаются заказы от клиентов. Предполагается, что передаваться будут заказы, полученные от интернет-магазинов и требующие комплектации.
Добавлен новый процесс «Предзаказ от клиента ТСД» для создания нового заказа от клиента и его размещения, то есть получения заказа от клиента в статусе «Размещен». Данные для заказа формируются в программе «Супермаг Мобайл Андроид» на основании обращения клиента либо сканированием товаров, либо сканированием штриховых кодов прайс-листа, либо вводом артикулов товара, либо вводом части названия товара и выбором товара из предложенного списка.
Если при создании процесса было указано, что заказ надо перенаправить поставщику, то одновременно с заказом от клиента будет создан заказ поставщику или несколько заказов поставщику или, если для товара не найдется ни одного соглашения о поставке, складское требование. Содержание создаваемых документов может быть полностью скопировано из заказа от клиента или уменьшено на количество товара, имеющегося в месте хранения. Это зависит от опции «Учитывать остатки места хранения».
Изменения функционала в версии 1.050 сервис пак 1.
ЕГАИС. Отказ от использования второго регистра («Торговый зал»).
Управление перемещением немаркированной продукции в торговый зал.
Списание пива в ЕГАИС по кассовым документам.
Карточки складского учета. Вкладка «История кодов продукции ЕГАИС».
Весы «Falcon», «DIGI SM-5000 Ethernet». Выгрузка второй цены со скидкой.
ЕГАИС выпустил следующее информационное сообщение:
«В связи с вводом с 1 апреля 2023 года обязательной маркировки пива, пивных напитков, сидра, пуаре и медовухи Росалкогольрегулированием будет осуществляться поэтапный отказ от использования второго регистра (Торговый зал) ЕГАИС для пива, пивных напитков, сидра, пуаре и медовухи.
На первом этапе с 15 мая 2023 года будет введен запрет на возможность фиксации в ЕГАИС «Заявки о фиксации в ЕГАИС сведений о перемещении алкогольной продукции в торговый зал», установленной приказом Росалкогольрегулирования от 17.12.2020 № 397 «Об утверждении форм, порядка заполнения, форматов и сроков представления в электронном виде заявок о фиксации информации в единой государственной автоматизированной системе учета объема производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции».
На втором этапе Росалкогольрегулированием будет введен полный запрет на операции со вторым регистром (Торговый зал) ЕГАИС для организаций, являющихся участниками ЕГАИС и осуществляющих деятельность по розничной реализации пива и пивных напитков.»
То есть, с 15 мая 2023 года любая попытка перемещения алкогольного товара с регистра «Склад» на регистр «Торговый зал» будет невозможна, но прочие операции, такие как, списание, перемещение из торгового зала, некоторое время будут доступны.
Изменение касается только мест хранения с учетным регистром «Торговый зал», то есть магазинов. Для складов, где не ведется розничная реализация алкоголя, и установлен учетный регистр «Склад» правила работы не меняются.
С точки зрения учета движения немаркированной продукции ограничение, вводимое 15 мая, означает, что используемые до сих пор правила работы при продаже по кассе, инвентаризации недостачи, продаже внешним контрагентам или перемещении в другие места хранения формально остаются без изменения. Запрет явным образом касается только перемещения продукции в торговый зал. Но с течением времени продукция, находящаяся на регистре торгового зала будет убывать и для регулярной работы магазина потребуется либо частично выполнять операции с регистром «Торговый зал», частично с регистром «Склад», либо принудительно вернуть продукцию на регистр «Склад» и вести все операции с регистром «Склад». При этом надо принять во внимание, что ЕГАИС не дал методических рекомендация о способе определения партий товаров для списания продаж по кассе. При продаже по кассе в чеке фиксируется только штриховой код (артикул) товара, тогда как для списания с первого регистра требуется знать точное значение кода алкогольной продукции и номер справки РФУ2, по которой пришел проданный товар. По этой причине немедленный возврат всей продукции на первый регистр представляется преждевременным.
В текущей версии в административном модуле в разделе «База данных» для группы данных «Документы» добавлен флаг «Автоматически перемещать в торговый зал немаркированный товар». По умолчанию флаг установлен, что соответствует текущему поведения системы:
Если флаг снять, то принимаемая на первый регистр немаркированная продукция более не будет автоматически перемещаться на второй регистр. Это флаг необходимо снять не позднее конца дня 14 мая 2023 года.
В разделе «Кассовые документы» имеется функция «Списание пива ЕГАИС», которая позволяет для каждого кассового документа сформировать «Акт о списании из торгового зала» для передачи в ЕГАИС информации о розничной реализации немаркированной продукции.
Функция проверяет наличие в кассовом документе артикулов, входящих в группу алкогольного классификатора с флагом «пиво». Проверка наличия проводится с учетом возвратов по кассе того же дня. Если такие артикулы находятся, то создается документ «ТТН ЕГАИС на отгрузку» с операцией «Акт о списании из торгового зала» и для каждого найденного артикула с положительным количеством продажи (с учетом возвратов) в акте создается строка с привязкой к строке спецификации кассового документа. Если у артикула имеется единственный код алкогольной продукции, он тут же помещается в строку спецификации ТТН ЕГАИС. На этом функция прекращает работу. Дальнейшие действия по формированию акта списания из торгового зала выполняются в разделе ТТН ЕГАИС на отгрузку.
В текущей версии функция «Списание пива ЕГАИС» перед началом формирования акта делает проверку на наличие остатка на регистре торгового зала хотя бы для одного из кодов алкогольной продукции списываемых артикулов. Если остатки есть, она создает «Акт списания из торговго зала», если все остатки исчерпаны, будет создан «Акт списания со склада». В случае создания акта списания из торгового зала алгоритм формирования акта такой же, как в предыдущих версиях.
Принятие решение о том, какой акт надо формировать, не зависит от состояния флага «Автоматически перемещать в торговый зал немаркированный товар».
Следующий шаг подготовки акта списания из торгового зала подразумевает использование функции «Подбор кодов алкогольной продукции» раздела «ТТН ЕГАИС на отгрузку» или аналогичной функции, которая выполняется при нажатии кнопки «Отослать».
В текущей версии поведение этой функции следующее:
При выполнении подбора кодов алкогольной продукции используется информация об остатках по кодам алкогольной продукции на регистре торгового зала, о чем показывается сообщение:
Если для какого либо артикула из кассового документа при просмотре остатков торгового зала по всем его кодам алкогольной продукции обнаруживается, что нет достаточного количества, то недостающее количество помещается в акт списания со склада, который может быть обработан по правилам отсылки продукции с регистра «Склад».
Флаг «Автоматически перемещать в торговый зал немаркированный товар» на работу функции не влияет.
В раздел карточек складского учета добавлена вкладка «История кодов продукции ЕГАИС»:
В журнале истории фиксируется факт добавления и удаления кода алкогольной продукции.
Для драйверов весов моделей «Falcon» и «DIGI SM-5000 Ethernet» в диалоге «Настройка электронных весов», на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой:
Для корректной печати в этикетке либо одной цены, либо двух цен необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat:
При выгрузке артикулов (PLU) в весы артикулу назначается либо этикетка с одной ценой, либо с двумя ценами. Этикетка с одной ценой назначается всегда, если не выбран вид цены для цены со скидкой. Если вид цены выбран, то артикулу назначается этикетка с двумя ценами, если для него имеется маркетинговая акция по виду цены со скидкой и маркетинговая цена меньше цены для кассы.
По условиям протокола вторая цена выгружается в весы как разница между первой и второй ценой (между ценой для кассы и ценой со скдикой).
В разделах документов, где в спецификации имеются колонки со значением суммы НДС, добавлена возможность просматривать суммы по документу (кнопка «Сумма» и выбор полей заголовка по кнопке «Поля») соответствующие ставке НДС 12%, если такое значение ставки будет определено в перечне ставок НДС раздела «Редактор налогов».
Изменения функционала в версии 1.050 сервис пак 2.
ЕГАИС. Отказ от использования второго регистра («Торговый зал»).
Списание кассовой реализации немаркированной продукции.
Функция «Формирование и отсылка ТТН в ЕГАИС» для расходных накладных и накладных на перемещение.
Инвентаризация немаркированной продукции для мест хранения с учетным регистром «Торговый зал».
ТТН ЕГАИС на отгрузку. Выбор кода алкогольной продукции.
Заказ в торговом зале ТСД. Округление количества заказа до упаковки заказа.
Почтовый модуль. Сервер обмена данными. Правила рассылки для доверительных баз с УПД фильтром.
Модель весов DP Wasp.
В текущей версии внесены изменения для поддержки работы со вторым регистром (регистром торгового зала), когда при расходе немаркированной алкогольной продукции необходимо приоритетно списывать продукцию с регистра торгового зала, а если остатков торгового зала недостаточно, то выполнять расход с регистра склада.
В текущей версии уточнен алгоритм списания немаркированной продукции при продаже по кассовым документам. Он выглядит следующим образом:
Добавлена возможность удалять строки Акта списания со склада, проставляя нулевое количество.
В процессе «Подсчет алкоголя ТСД» имеется функция экспорта в расходную накладную с отправкой кассового чека в ЕГАИС. Отправка кассового чека происходит без создания документа в Торговой системе. По правилам ЕГАИС форма кассового чека требует обязательного заполнения поля EAN, тогда как в процессе подсчета алкоголя возможны случаи, когда EAN код может быть не заполнен.
В алгоритм отсылки кассового чека ЕГАИС внесено следующее изменение: если поле «штрихкод» в строке таблицы не заполнено, то в кассовом чеке оно заполняется штриховым кодом артикула типа EAN (то есть, содержащий 8, 12 или 13 чисел). Преимущество отдается внешним штриховым кодам.
\\
Ответ на команду GET /nomenclature/\{placeId\}/composition (актуальная информация о товарах) дополнен тэгом «exciseValue» с информацией о принадлежности товара к категории акцизных товаров.
\\
Описание тэга в документации «ЯндексЕда»:
\\
"exciseValue": \{
"type": "string",
"description": "Тип акциза. Пример, ССН (кириллица - сахаросодержащие напитки)",
"example": "ССН"
\}
\\
Пример:
\\
\{
"id": "000018",
"vendorCode": "000018",
"categoryId": "6.",
"location": "",
"name": "СИГАРЕТЫ \"СОЮЗ АПОЛЛОН\" ОСОБЫЕ ШТ",
"description": \{
"general": "asdf",
"composition": "aeda",
"nutritionalValue": "",
"purpose": "",
"storageRequirements": "asdf",
"expiresIn": "",
"vendorCountry": "РОССИЯ",
"packageInfo": null,
"vendorName": ""
\},
"price": 1200.0,
"oldPrice": null,
"vat": 20,
"barcode": \{
"value": "4601439931256",
"type": "ean13",
"weightEncoding": "none"
\},
"measure": \{
"value": 1,
"quantum": 12.0,
"unit": "GRM"
\},
"volume": null,
"isCatchWeight": false,
*"exciseValue": "ССН",*
"sortOrder": null,
"images": null
\},
\\
\\
Ответ на команду GET /order/\{orderId\} (выдача актуальной информации о заказе) дополнен тэгом «marking» с информацией о содержании КИЗ маркированных товаров, собранных при комплектации заказа от клиента.
\\
Описание тэга в документации «ЯндексЕда»:
\\
"marking": \{
"type": "array",
"description": "Объект с информацией о маркировке товара",
"items": \{
"type": "object",
"properties": \{
"datamatrix": \{
"type": "string",
"description": "Маркировка в виде строки"
\},
"quantity": \{
"type": "number",
"example": 0.5,
"description": "Вес товарной единицы"
\}
\},
"required": \[
"datamatrix"
\]
\}
\},
\\
Пример ответа на запрос заказа, содержащего КИЗ маркированной продукции:
\\
\{
"discriminator": "yandex",
"eatsId": "SOI2-0612142142",
"restaurantId": "4",
"deliveryInfo": \{
"clientName": "",
"phoneNumber": "",
"courierArrivementDate": "2022-12-06T00:00:00.000000+03:00"
\},
"paymentInfo": \{
"itemsCost": 199.25,
"paymentType": "CASH"
\},
"items": \[
\{
"id": "Ц022567",
"name": "СИГАРЕТЫ \"СОЮЗ АПОЛЛОН\" ОСОБЫЕ",
"quantity": 20.0,
"price": 9.21,
*"marking": \[*
*\{*
*"datamatrix": "010460143993125621nNc3bUI\u001d800512200093+YHz\u001d240FA068050.68",*
*"quantity": 10.0*
*\},*
*\{*
*"datamatrix": "010460143993125621pz>,!A:\u001d910001\u001d92RR26AQ==\u001d24014240647",*
*"quantity": 10.0*
*\}*
*\],*
"modifications": \[\],
"promos": \[\]
\},
\{
"id": "Ц023687",
"name": "СИГАРЕТЫ \"BLEND KING SIZE\" light",
"quantity": 1.0,
"price": 15.05,
*"marking": \[*
*\{*
*"datamatrix": "010460720309891021nNc3bUI\u001d800512200093+YHz\u001d240FA068050.68",*
*"quantity": 1.0*
*\}*
*\],*
"modifications": \[\],
"promos": \[\]
\}
\],
"comment": "",
"promos": \[\]
\}
\\ |
Изменения функционала в версии 1.050
WEB сервер лицензирования.
Интервал постановки в почтовую очередь запросов остатков по маркам ЕГАИС.
Правила создания УПД на отгрузку для контрагентов, освобожденных от ЭДО.
Вывод из оборота маркированной продукции.
Проверка КИЗ на выбытие и загрузка в Супермаг Марко.
Подбор накладной поставщика при приеме по заказу поставщику.
Акты переоценки начала и завершения Маркетинговой акции. История изменения цен.
Разбор штрихового кода «маркировка GS1». Определение веса и объема.
Почтовый модуль.
XML протокол. Пересылка КИЗ в спецификации документов.
Функция импорта из XML ArticleByAnyCodeUI.
Алкогольная декларация.
Перечень исправленных ошибок и улучшений.
В сервер приложений Супермаг+ добавлена возможность получать лицензионную информацию от WEB сервера лицензирования. В этом случае не требуется получать файл лицензии и не требуется аппаратный ключ.
WEB сервер лицензирования размещен в облачном пространстве и обслуживается силами компании производителя. В комплект поставки Торговой системы сервер лицензирования не входит.
Для работы с WEB сервером лицензирования на компьютере, где работает сервер приложений, исполняющий функцию сервера лицензий Торговой системы, необходимо создать специальную запись в системном реестре с URL сервера лицензирования. При установке или обновлении Торговой системы эта запись не создается и может быть выдана по запросу. При наличии такой записи в интерфейсе администратора сервера приложений в диалоге, доступном при нажатии кнопки «Лицензия БД», появляется кнопка «Лицензирование без ключа через веб-сервер»: 
При нажатии на кнопку появляется возможность ввести номер лицензии и пароль, которые выдаются организации при заключении соглашения с компанией производителем: 
Номер лицензии соответствует понятию «номер ключа» в случае использования физического ключа. Номер лицензии может быть один для всех баз данных, независимо от того обслуживаются они одним сервером приложений или несколькими.
В случае успешного доступа к серверу лицензирования и наличия в ней лицензии для указанной базы данных, лицензию можно загрузить: 
Лицензия, загруженная с веб-сервера, представляет собой зашифрованные данные. Чтобы сервер приложений получил информацию о том, разрешена ли для использования та или иная функция, ему необходимо обратиться к веб-серверу. При получении ответа, ответ кешируется и одновременно сохраняется специальным образом. При рестарте сервера приложений все данные кеша при наличии связи перезагружаются с веб-сервера. Сохраненные ответы при отсутствии соединения могут использоваться до 72 часов.
При старте сервера приложений он будет работать с лицензией, то есть будет выполнять функцию сервера лицензий, только в том случае, если лицензия загружалась с его помощью. При переносе сервера приложений на другой компьютер надо заново загрузить лицензию.
Для защиты от несанкционированного доступа к лицензионной информации обмен данными с веб-сервером происходит по защищенному протоколу, с использованием протокола авторизации OAuth2 и с подтверждением доступа к аутентичной службе.
В административный модуль в раздел «База данных» на закладку «Конфигурация» в группу данных «Документы» добавлен атрибут «Интервал (в минутах) постановки в почтовую очередь запросов остатков по маркам ЕГАИС» со значением по умолчанию 35 минут: 
Атрибут действует на интервал времени между последовательной отсылкой запросов функцией «Запрос поштучных остатков по РФУ2» в разделе «Остатки ЕГАИС»: 
При смене статуса расходной накладной процедура смены статуса может автоматически на основании расходной накладной создать документ «УПД на отгрузку». Для принятия решения о создании УПД на отгрузку используется следующий алгоритм:
УПД на отгрузку не создается:
Изменения функционала в версии 1.051 сервис пак 1.
ЕГАИС.
Акт списания / постановки на баланс ЕГАИС
ТТН ЕГАИС на отгрузку. Функция «Подбор кодов алкогольной продукции» для операций списания со склада.
Отправка кассового чека ЕГАИС. Простановка EAN кода.
Почтовый модуль. Экспорт в XML. Функция LocationGLNCross.
Формат обмена «Яндекс. Еда» сервера обмена данными. Изменения в протоколе обмена.
Добавлена возможность удалять строки Акта списания со склада, проставляя нулевое количество.
При подборе кодов алкогольной продукции для строк спецификации ТТН, связанных со строками спецификации накладных, проводится анализ остатков склада для кодов алкогольной продукции артикула. Остатки кодов алкогольной продукции на регистре склада распределены по справкам РФУ2. Анализ остатков проводится для выбора кода алкогольной продукции и справки РФУ2, для которых на складе есть остатки, чтобы при передачи ТТН в ЕГАИС избежать ошибки ЕГАИС вида «необеспеченный расход». Поскольку остатки склада (см. раздел «Остатки ЕГАИС», закладка «Склад») являются актуальными только на момент получения их из ЕГАИС, а запрос остатков разрешен не чаще раза в сутки, то алгоритм подбора кодов алкогольной продукции и справок РФУ2 в прошлых версиях учитывал количества приходов и расходов, которые отображаются в таблице остатков ЕГАИС в колонках «Приход по документам» и «Расход по документам» и образуются при получении из ЕГАИС квитанций о фиксации документов ЕГАИС.
В текущей версии в алгоритм добавлен учет расходов и приходов (акт постановки на баланс) по не зафиксированным документам ЕГАИС, то есть поставленным в очередь на отсылку, но с не полученным ответом из ЕГАИС.
Изменение внесено в связи с тем, что продажа немаркированной продукции разрешается при наличии одного идентификатора ФСРАР ИД для множества магазинов юридического лица. Соответственно, списание кассовой реализации выполняется в коротком диапазоне времени для многих магазинов, что приводит к тому, что подбор кодов алкогольной продукции и справок для одних и тех же артикулов разных магазинов происходит с использованием одних и тех же остатков и без ожидания фиксации в ЕГАИС других актов списания. Что, в свою очередь, приводит к ошибкам передачи документов в ЕГАИС.
Внесенные изменения не исключают вероятности того, что два или более документа будут одновременно выполнять подбор кодов алкогольной продукции и справок РФУ2. Если при отсылке ТТН в ЕГАИС, ЕГАИС вернет ошибку вида «необеспеченный расход», надо перевести ТТН в черновик, повторно выполнить функцию «Подбор кодов алкогольной продукции» и снова отослать ТТН в ЕГАИС.
В процессе «Подсчет алкоголя ТСД» имеется функция экспорта в расходную накладную с отправкой кассового чека в ЕГАИС. Отправка кассового чека происходит без создания документа в Торговой системе. По правилам ЕГАИС форма кассового чека требует обязательного заполнения поля EAN, тогда как в процессе подсчета алкоголя возможны случаи, когда EAN код может быть не заполнен.
В алгоритм отсылки кассового чека ЕГАИС внесено следующее изменение: если поле «штрихкод» в строке таблицы не заполнено, то в кассовом чеке оно заполняется штриховым кодом артикула типа EAN (то есть, содержащий 8, 12 или 13 чисел). Преимущество отдается внешним штриховым кодам.
В перечень функций, доступных при формировании XML-файла, отсылаемого почтовым модулем добавлена функция «LocationGLNCross»: 
Функция работает для приходных накладных и возвращает номер GLN места хранения документа заказа поставщику из общего основания накладной, если место хранения кросс-докинга заказа совпадает с местом хранения приходной накладной, а при отсутствии места хранения кросс-докинга возвращает GLN места хранения приходной накладной.
Функция предназначена для корректного формирования ответа поставщику при приеме поставки товара, когда заказ делается для магазина, а поставка на склад кросс-докинга.
\\
Ответ на команду GET /nomenclature/\{placeId\}/composition (актуальная информация о товарах) дополнен тэгом «exciseValue» с информацией о принадлежности товара к категории акцизных товаров.
\\
Описание тэга в документации «ЯндексЕда»:
\\
"exciseValue": \{
"type": "string",
"description": "Тип акциза. Пример, ССН (кириллица - сахаросодержащие напитки)",
"example": "ССН"
\}
\\
Пример:
\\
\{
"id": "000018",
"vendorCode": "000018",
"categoryId": "6.",
"location": "",
"name": "СИГАРЕТЫ \"СОЮЗ АПОЛЛОН\" ОСОБЫЕ ШТ",
"description": \{
"general": "asdf",
"composition": "aeda",
"nutritionalValue": "",
"purpose": "",
"storageRequirements": "asdf",
"expiresIn": "",
"vendorCountry": "РОССИЯ",
"packageInfo": null,
"vendorName": ""
\},
"price": 1200.0,
"oldPrice": null,
"vat": 20,
"barcode": \{
"value": "4601439931256",
"type": "ean13",
"weightEncoding": "none"
\},
"measure": \{
"value": 1,
"quantum": 12.0,
"unit": "GRM"
\},
"volume": null,
"isCatchWeight": false,
*"exciseValue": "ССН",*
"sortOrder": null,
"images": null
\},
\\
\\
Ответ на команду GET /order/\{orderId\} (выдача актуальной информации о заказе) дополнен тэгом «marking» с информацией о содержании КИЗ маркированных товаров, собранных при комплектации заказа от клиента.
\\
Описание тэга в документации «ЯндексЕда»:
\\
"marking": \{
"type": "array",
"description": "Объект с информацией о маркировке товара",
"items": \{
"type": "object",
"properties": \{
"datamatrix": \{
"type": "string",
"description": "Маркировка в виде строки"
\},
"quantity": \{
"type": "number",
"example": 0.5,
"description": "Вес товарной единицы"
\}
\},
"required": \[
"datamatrix"
\]
\}
\},
\\
Пример ответа на запрос заказа, содержащего КИЗ маркированной продукции:
\\
\{
"discriminator": "yandex",
"eatsId": "SOI2-0612142142",
"restaurantId": "4",
"deliveryInfo": \{
"clientName": "",
"phoneNumber": "",
"courierArrivementDate": "2022-12-06T00:00:00.000000+03:00"
\},
"paymentInfo": \{
"itemsCost": 199.25,
"paymentType": "CASH"
\},
"items": \[
\{
"id": "Ц022567",
"name": "СИГАРЕТЫ \"СОЮЗ АПОЛЛОН\" ОСОБЫЕ",
"quantity": 20.0,
"price": 9.21,
*"marking": \[*
*\{*
*"datamatrix": "010460143993125621nNc3bUI\u001d800512200093+YHz\u001d240FA068050.68",*
*"quantity": 10.0*
*\},*
*\{*
*"datamatrix": "010460143993125621pz>,!A:\u001d910001\u001d92RR26AQ==\u001d24014240647",*
*"quantity": 10.0*
*\}*
*\],*
"modifications": \[\],
"promos": \[\]
\},
\{
"id": "Ц023687",
"name": "СИГАРЕТЫ \"BLEND KING SIZE\" light",
"quantity": 1.0,
"price": 15.05,
*"marking": \[*
*\{*
*"datamatrix": "010460720309891021nNc3bUI\u001d800512200093+YHz\u001d240FA068050.68",*
*"quantity": 1.0*
*\}*
*\],*
"modifications": \[\],
"promos": \[\]
\}
\],
"comment": "",
"promos": \[\]
\}
\\
\\
\\
\\
Изменения функционала в версии 1.051 сервис пак 2.
\\
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ЕГАИС.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592457]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Остатки ЕГАИС. Склад. Приход по документам, расход по документам.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592458]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Функция «Подбор кодов алкогольной продукции».</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592459]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Функция удаления строки ТТН.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592460]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Удаление ТТН с операцией «акт списания из торгового зала».</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592461]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Отсылка ТТН на отгрузку по почте с подбором кодов алкогольной продукции.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592462]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Расходная накладная. Условия работы функции «Сформировать электронный УПД».</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592463]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Почтовый модуль. УПД фильтр. Прием файла подтверждения для УПД на отгрузку.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592464]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Почтовый модуль. УПД фильтр. Сквозная рассылка провайдерам.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592465]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Контрагенты. Доп. характеристика «Пакет документов поставщика для приёмки по заказу».</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592466]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Сервер обмена данными. «ЯндексЕда». Передача комментария заказа.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592467]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Сервер лицензий. Время офлайн работы WEB лицензии.</span></span> |C:\TEMP\4\4\Изменения1051 сп2.doc#_Toc143592468] |
В предыдущих версиях на закладке «Склад» в колонках «Приход по документам» и «Расход по документам» не отображалось количество по документам, которые были зафиксированы в ЕГАИС после получения информации об остатках склада, как это было для остатков торгового зала. В текущей версии при получении квитанции о фиксации документа в ЕГАИС его количество отражается в соответствующей колонке. Для получения корректных значений в колонках необходимо после обновления версии произвести запрос остатков склада в ЕГАИС.
В предыдущих версиях функция «Подбор кодов алкогольной продукции» в ТТН на отгрузку в случае отгрузки с регистра склада была разрешена только для ТТН, созданных на основании кассовых документов (списание по кассовым документам). Это ограничение было обусловлено тем, что подбор кодов алкогольной продукции и справок РФУ имеет смысл только для немаркированной продукции. Списание по кассовому документу выполняет именно эту задачу. На основании кассового документа выполняется списание только немаркированной продукции, тогда как маркированная продукция при продаже по кассе списывается непосредственно в момент продажи кассовым чеком ЕГАИС.
При создании ТТН на основании расходной накладной в ТТН может присутствовать, как немаркированная, так и маркированная продукция вместе с кодами марок ЕГАИС. Выполнение функции «Подбор кодов алкогольной продукции» может привести к ошибочным ситуациям при обработке строк с маркированной продукцией.
В текущей версии разрешено использование функции «Подбор кодов алкогольной продукции» для ТТН на отгрузку, созданных на основании любых документов при условии, что в ТТН отсутствуют коды марок ЕГАИС.
Дополнительно в мастер запуска функции «Подбор кодов алкогольной продукции» добавлен диалог: 
В прошлых версиях функция обрабатывала только строки с пустыми значениями поля «Алк. код».
Опция позволяет полностью пересчитать все привязки к алкокодам и справкам РФУ, если в течении времени остатки склада изменились так, что прежний подбор стал недействительным, например, в промежутке времени с прошлого выполнения функции был полностью израсходован товар по конкретной справке РФУ или даже по коду алкогольной продукции.
В интерфейс ТТН на отгрузку добавлена кнопка «Уд. строку»: 
Нажатие кнопки вызывает функцию, которая позволяет удалить из ТТН выделенные строки. Перед удалением строк функция проверяет, что в строках нет подобранных справок РФУ2: 
Функция может использоваться для удаления строк ТТН, для которых не удалось подобрать справку РФУ2 при списании или отгрузке товара со склада. В тех случаях, когда по какой-то причине, товар не числится на остатках склада в ЕГАИС, списание или отгрузка товара невозможна и отсуствтие остатка на складе отдельной позиции из ТТН останавливает отгрузку прочей продукции из спецификации ТТН.
В предыдущих версиях существовало правило, что ТТН на отгрузку с операциями «акт списания из торгового зала» и «акт списания со склада», созданные на основании одного товарного документа могли быть удалены только парой.
При генерации ТТН на отгрузку может сложиться ситуация, когда в торговом зале не будет остатков ни для одного из списываемых товаров. В этом случае текущий алгоритм создает акт списания для торгового зала, а затем все количество переносит в акт списания со склада и акт списания из торгового зала остается с пустой спецификацией.
В текущей версии функция удаления ТТН проверяет, что спецификация ТТН пустая и в этом случае позволяет удалить ее без проверки наличия парного документа.
При отсылке ТТН на отгрузку по почте, если ТТН имеет операцию регистра склада, делается проверка на заполнение в ТТН полей РФУ и если выясняется, что не все поля заполнены, для позиций без справок выполняется подбор кодов алкогольной продукции и справок.
В прошлой версии, если функция подбора кодов алкогольной продукции не могла заполнить требуемые данные, возникала ошибки отсылки, которая отражалась в интерфейсе почтового модуля. В текущей версии запись об ошибке дополнительно помещается в журнал обмена ЕГАИС ТТН на отгрузку и в поле "Состояние обмена с ЕГАИС" ТТН на отгрузку помещается статус "Ошибка", что позволяет перевести ТТН в черновик, внести в него изменение и повторно отослать после исправления.
В версии 1.049.1 была изменена логика соответствия статусов расходной накладной и соответствующей ей УПД на отгрузку. УПД на отгрузку стала создаваться при смене статуса расходной накладной с «Черновик» на «Отпущен со склада», а статус «Отпущен полностью» стал соответствовать факту получения подтверждения приема поставки от контрагента по этому УПД.
Помимо автоматических процедур создания УПД и приема файла подтверждения в разделе расходных накладных имеется функция «Сформировать электронный УПД», которая позволяет выполнить действие вручную. В текущей версии поведение функции приведено в соответствие с логикой соответствия статусов. Функция может выполняться для расходной накладной со статусом «Отпущен со склада». Прежнее поведение, которое позволяло выполнять функцию для накладных со статусом «Отпущен полностью» также сохранено.
Внесены следующие изменения в протокол приема файла подтверждения (Reply) для отосланного документа «УПД на отгрузку»:
Внесено изменение в схему для приема подтверждения (UDCONFIRM.xsd). Изменение в схеме касается спецификации поставки, принятой контрагентом получателем. В прежнем варианте допускался только прием информации об артикуле, количестве принятого товара, а также о принятых кодах марок КИЗ и кодов ОСУ. Информация об артикуле допускалась только в виде артикула поставщика (SUPPLIERARTICLE):
<xs:complexType name="SpecPositionType">
<xs:sequence>
<xs:element name="SUPPLIERARTICLE" type="xs:string" />
<xs:element name="QUANTITY" type="xs:decimal" />
<xs:element name="MARKS" minOccurs="1" maxOccurs="1" >
<xs:complexType>
<xs:sequence>
<xs:element name="MARKCODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="OSUCODES" minOccurs="1" maxOccurs="1" >
<xs:complexType>
<xs:sequence>
<xs:element name="OSUCODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
В текущем варианте артикул можно определять следующим образом: это может быть либо тэг с артикулом, либо тэг со штрихкодом, либо тэг с артикулом поставщика, либо тег с любым из ключевых значений артикула (артикул поставщика, артикул, штрихкод)
<xs:choice>
<xs:element name="ARTICLE" type="xs:string" nillable="false" />
<xs:element name="BARCODE" type="xs:string" nillable="false" />
<xs:element name="SUPPLIERARTICLE" type="xs:string" nillable="false" />
<xs:element name="ARTICLEKEY" type="xs:string" nillable="false" />
</xs:choice>
Предпочтительным является использование тэга ARTICLEKEY. Это позволит использовать одну и ту же схему для работы с разными контрагентами, которые могут отвечать разным образом.
Важно, чтобы в одном файле подтверждения приема для разных строк спецификации использовалась одна и та же нотация. Нельзя одну строку определять через штриховой код, а другую через артикул поставщика.
Дополнительно, в схему добавлены теги для передачи цен, сумм и значения ставки НДС, зафиксированные в документе приема поставки. А также тэг для передачи кодов КИЗ упаковок товаров (PACKAGECODE):
<xs:complexType name="SpecPositionType">
<xs:sequence>
<xs:choice>
<xs:element name="ARTICLE" type="xs:string" nillable="false" />
<xs:element name="BARCODE" type="xs:string" nillable="false" />
<xs:element name="SUPPLIERARTICLE" type="xs:string" nillable="false" />
<xs:element name="ARTICLEKEY" type="xs:string" nillable="false" />
</xs:choice>
<xs:element name="QUANTITY" type="xs:decimal" />
<xs:element name="ITEMPRICE" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="ITEMPRICENOTAX" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="VATRATE" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="VATSUM" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="TOTALPRICE" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="TOTALPRICENOTAX" type="xs:decimal" minOccurs="0" maxOccurs="1" nillable="true" />
<xs:element name="MARKS" minOccurs="1" maxOccurs="1" >
<xs:complexType>
<xs:sequence>
<xs:element name="MARKCODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
<xs:element name="PACKAGECODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="OSUCODES" minOccurs="0" maxOccurs="1" >
<xs:complexType>
<xs:sequence>
<xs:element name="OSUCODE" type="xs:string" minOccurs="0" maxOccurs="unbounded" nillable="false" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Соответственно, доработан алгоритм создания УПД с операцией «акт приема» для использования информации из перечисленных тэгов.
В текущей версии при сквозной рассылке документов УПД из подчиненных баз в базы провадеров ЭДО выбор базы для рассылки осуществляется по совпадению значения поля «Ид. Уч. ЭДО» документа УПД и атрибута «Собственный идентификатор участника документооборота» УПД фильтра.
Для контрагентов добавлена системная дополнительная характеристика «Пакет документов поставщика для приёмки по заказу»: 
Доп. характеристика используется при работе Супермаг Мобайл Андроид, начиная с версии 2.4.71.23.
Если для контрагента документа «Заказ поставщику» заполнено значение дополнительной характеристики её содержание показывается перед началом приема по заказу. Текст характеристики показывается в окне «Проверка присутствтия документов поставщика». Предполагается, что оператор перед началом приемки должен удостовериться, что поставщик предоставил описанный перечень документов или выполнил иные требования, предваряющие прием поставки.
В текущей версии при получении запроса командой «Получение актуальной информации о заказе в системе партнера» сервер обмена данных при формировании ответа заполняет тэг «"comment"» информацией из поля «Комментарий» закладки «Доставка» заголовка документа «Заказ от клиента».
Время работы сервера лицензии в офлайн режиме увеличено до 10 суток.
Изменения функционала в версии 1.051 сервис пак 3.
Карточки складского учета. Выкладка.
Административный модуль. Поведение опции «Запрещать редактировать документы товародвижения с даты инвентаризации».
Весы DIGI SM-Ethernet. Выгрузка второй цены со скидкой.
В текущей версии в разделе карточек складского учета в таблице описания выкладки товара поле для описания сделано многострочным:
В разделе «Склады и магазины» на закладке «Общие» имеется опция «Редактирование док-тов товародвиж. только с датой после». Такая же опция имеется в административном модуле, в разделе «База данных», на закладке «Конфигурация», в группе данных «Документы». Там же есть опция «Запрещать редактировать документы товародвижения с даты инвентаризации».
Опция «Редактирование док-тов товародвиж. только с датой после» позволяет установить дату запрета редактирования документов товародвижения, то есть дату, по которую включительно нельзя редактировать документы товародвижения. Опция для места хранения действует на документы товародвижения, связанные с этим местом хранения. Значение опции административного модуля используются, если для места хранения опция не определена.
Опция «Запрещать редактировать документы товародвижения с даты инвентаризации» указывает системе, что при смене статуса документа «Сличительная ведомость» на «Принят в количестве и ценах» для места хранения ведомости необходимо установить дату запрета редактирования документов товародвижения равной дате начала проведения инвентаризации из сличительной ведомости. Действие выполняется, если новая дата запрета редактирования больше старой даты, или атрибут «Редактирование документов товародвижения только с датой после» для места хранения не был установлен ранее.
В текущей версии изменено поведение системы при установленной опции «Запрещать редактировать документы товародвижения с даты инвентаризации». Теперь при смене статуса документа «Сличительная ведомость» на «Принят в количестве и ценах» устанавливается дата запрета редактирования документов товародвижения равной дате начала проведения инвентаризации со ссылкой на текущую ведомость. А также сохраняются прежние значения даты запрета и номера ведомости. При обратной смене статуса «Сличительная ведомость» с «Принят в количестве и ценах» на «Принят в количестве» восстанавливаются прежние значения даты и номера ведомости. Также прежние значения восстанавливаются при создании актов потерь и обнаружений функцией «Создать накладные» в разделе «Сличительные ведомости».
При ручном редактировании опции «Редактирование документов товародвижения только с датой после» ссылка на ведомость будет удалена.
Новое поведение позволяет решить проблему, когда на основании сличительной ведомости, уже получившей статус «Принят в количестве и ценах», создаются не приходные и расходные накладные, которые приводят остатки товаров к их фактическим значениям, а акты потерь и обнаружений, которые влияют не на текущие остатки, а на значение колонки «Потери» таблицы остатков.
Новое поведение опции сохраняет историю ее установки на один шаг назад. Это означает, что автоматически восстанавливается прежнее значение опции только для последнего действия. Если будет произведена отмена статуса сличительной ведомости предшествующей последней, то никакого изменения значения опции не произойдет. Если произвести последовательно отмену статусов двух или более сличительных ведомостей, то значение опции будет очищено.
В диалог «Настройка электронных весов», для весов «DIGI SM-Ethernet» на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой: 
При печати этикетки весы могут выполнять печать для товаров, у которых есть скидка и у которых нет скидки. Дизайн этикеток в таких случаях, как правило, разный. В одном дизайне печатается только одна цена, в другом цена со скидкой и цена без скидки. Чтобы использовались разные дизайны для печати этикетки для разных товаров, необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat: 
Этикетка с двумя ценами назначается товару, если выбран вид цены для цены со скидкой, а также, если товар участвует в маркетинговой акции. Кроме того, цена со скидкой должна быть меньше цены для кассы.
По условиям протокола вторая цена выгружается в весы как разница между первой и второй ценой (между ценой для кассы и ценой со скдикой). Для корректной работы необходимо, чтобы весы были настроены так, чтобы загруженная вторая цена воспринималась, как размер скидки от базовой цены, а не как абсолютное значение.
Изменения функционала в версии 1.051 сервис пак 4.
Сервер приложений. Работа с WEB лицензией.
Выход из производства ГИС Меркурий. Функция «Проставить признак «Скоропортящийся»».
Процесс «Отгрузка по заказу ТСД». Генерация расходной накладной.
Процесс «Отгрузка перемещения ТСД». Генерация накладной на перемещение.
УПД на приход, УПД на отгузку. ИНН и имя подписанта ЭДО.
Административный модуль.
Подписант ЭДО.
Задание «Генерация заказов».
Почтовый модуль. УПД фильтр. Перечень данных при отправке подтверждения приема и УПД на расход.
Раздел «Электронные весы». Флаг «Только локальные».
В прошлых версиях кэш с WEB лицензией очищался при перезагрузке службы и восстанавливался только при наличии интернет соединения с WEB сервером лицензирования. В текущей версии кэш при старте службы восстанавливается из локальных ресурсов, что позволяет продолжать работу в разрешенном промежутке времени при отсутствии соединения с WEB сервером лицензирования.
Дополнительно реализовано сообщение при начале работы с Супермаг+ об отсутствии соединения с WEB сервером лицензирования и об оставшемся времени автономной работы.
В интерфейс документа «Выход из производства ГИС «Меркурий»» добавлена функция «Проставить признак «Скоропортящийся»». Функция позволяет установить или снять признак «Скоропортящийся» для строк спецификации документа: 
При генерации расходной накладной из процесса «Отгрузка по заказу ТСД» в спецификации расходной накладной теперь заполняются поля «Страна» и «Производитель/импортер» данными из карточки складского учета. Поле «Производитель/импортер» заполняется значением с флагом «По умолчанию».
При генерации накладной на перемещение из процесса «Отгрузка перемещения ТСД» в спецификации расходной накладной теперь заполняются поле «Производитель/импортер» данными из карточки складского учета. Поле заполняется значением с флагом «По умолчанию».
В документы «УПД на приход» и «УПД на отгрузку» на закладку «Грузораспорядители» добавлены атрибуты «Подписант» и «ИНН»: 
Атрибуты заполняются именем и ИНН подписанта ЭДО – сотрудника подтверждающего УПД на приход, или отправляющего УПД на отгрузку.
В административный модуль в разделе «Права доступа», в закладке «Сотрудники» в диалог настройки атрибутов сотрудника добавлен флаг «Подписант ЭДО»: 
Если атрибут установлен, то ИНН и имя (логин) сотрудника будут проставляться в соответствующие поля УПД на отгрузку при смене им статуса УПД на приход или при создании УПД на отгрузку.
В административном модуле, в разделе «База данных» на закладке «Задания» в диалоге настройки задания «Генерация заказов» при выборе алгоритма «Fresh» теперь скрывается флаг «С учётом маркетинговых акций (кроме алгоритма Fresh)», т.к. данная опция не учитывается в этом алгоритме: 
В структуру файла подтверждения приема УПД и файла УПД на отгрузку добавлены тэги INNSIGNATORY и NAMESIGNATORY – ИНН подписанта и имя подписанта.
Например, при отсылке подтверждения приема:
<?xml version="1.0" encoding="UTF-8"?>
<PACKAGE name="dd92f026-75cc-49bd-a6f9-0ce123915184" SMVersion="1.051 SP4">
<REPLY description="Результат приемки">
<ID>UI0000000126</ID>
<CREATEDAT>2023-10-12</CREATEDAT>
<RESULT>3</RESULT>
<EDOID>3897523747</EDOID>
<SUPPLIERDOC>190-18</SUPPLIERDOC>
<SUPPLIERINVOICE>193.777_18</SUPPLIERINVOICE>
<SUPPLINVOICECREATE>2023-10-12</SUPPLINVOICECREATE>
<SUPPLIERCORRECTINVOICE />
<CLIENTINN>7730107662</CLIENTINN>
<CLIENTKPP>772901001</CLIENTKPP>
<CLIENTGLN>0987341</CLIENTGLN>
<OURCLIENTINN>7724308434</OURCLIENTINN>
<OURCLIENTKPP>772401001</OURCLIENTKPP>
<OURCLIENTGLN>55456231</OURCLIENTGLN>
<LOCATIONGLN>65436345623</LOCATIONGLN>
<COMMENTARY>Не соответствует заказу</COMMENTARY>
<INNSIGNATORY>7712345656</INNSIGNATORY>
<NAMESIGNATORY>ПЕТРОВ</NAMESIGNATORY>
</REPLY>
</PACKAGE>
Для отсылки информации о подписанте в УПД на отгрузку, необходимо в файл описания структуры XML пакета (UD.xsd) в тэг ="SMDOCUD" добавить тэги:
<xs:element name="SMDOCUD" msdata:Locale="ru">
<xs:complexType>
<xs:sequence>
….
<xs:element name="INNSIGNATORY" type="xs:string" minOccurs="0" />
<xs:element name="NAMESIGNATORY" type="xs:string" minOccurs="0" />
….
В интерфейс раздела «Электронные весы» добавлен флаг «Только локальные»:
Если флаг отмечен, то при обращении к выпадающему спискдля выбора места хранения, в выпадающем списке показываются только локальные места хранений.
Изменения функционала в версии 1.051 сп5
WEB лицензирование. Автоматическая загрузка лицензий новых версий.
Выгрузка в кассу по протоколу УКМ4 XML.
В сервер приложений Супермаг+ добавлен механизм автоматического обращения к серверу лицензирования при несоответствии версии базы данных и версии WEB лицензии или при истечении срока действия временной лицензии. Если на сервере лицензирования будет обнаружена подходящая лицензия, она автоматически будет загружена в сервер приложений. Интервал опроса сервера лицензирования составляет 60 секунд.
Для поддержки протокола работы ККТ при передаче данных о комиссионных и агентских продажах в алгоритм формирования файла suppliers внесено следующее изменение: при выгрузке тэга <SupplierTel> строка с информацией о телефоне юридического адреса комиссионера обрабатывается для выделения единственного номера телефона и преобразования его к формату, допустимому в ККТ:
При использовании WEB лицензии допускается работа Супермаг+, когда связь с WEB сервером лицензирования прерывается. В текущей версии время автономной работы Супермаг+ в отсутствии связи с сервером лицензирования увеличено до 30 суток.
Примечание. Для работы в автономном режиме необходимо, чтобы настройка сервера приложений на работу с WEB лицензией проводилась при наличии соединения с WEB сервером лицензирования и все лицензионные права были бы хотя бы один раз подтверждены WEB сервером.
По результатам инвентаризации ЕГАИС для немаркированного алкоголя могут быть созданы акты списания со второго и/или первого регистра на недостачу товара и акт постановки на баланс на первый регистр для излишков товара. В прошлых версиях акт постановки на баланс создавался с операцией «Излишки» и выбор других операций был недоступен.
В текущей версии при редактировании ТТН помимо операции «Излишки» разрешен выбор операций «Пересортица» и «Продукция, полученная до 01.01.2016»:. 
При выборе операции «Пересортица» предоставлять возможность выбора акта списания с регистра склада с операцией «Пересортица». Акт списания со склада может быть, как документом Акт списания, так и ТТН ЕГАИС на отгрузку:
Отсылка акта постановки на баланс с операцией «Пересортица» возможна только после отсылки и фиксации в ЕГАИС связанного с ним акта списания с операцией «Пересортица».
В прошлых версиях при создании ТТН ЕГАИС на основании накладной на перемещение контрагенты отправителя и получателя определялись по ИНН и КПП собственных контрагентов мест хранения "Из" и "В" перемещения. То есть по атрибутам контрагентов, заданным в разделе «Контрагенты» на закладке «Общие».
Если собственные контрагенты мест хранения перемещения совпадали, отсылка ТТН ЕГАИС была невозможна.
В текущей версии, когда собственные контрагенты обоих мест хранения перемещения одинаковые, ИНН контрагента берется из данных закладки «Общие», а КПП контрагента - из таблицы мест хранения собственного контрагента закладки «Собств. контрагент»: 
В текущей версии в спецификации ТТН на приход фон строк, у которых поле «Недостача» имеет положительное значение, окрашивается в красный цвет. 
В прошлых версиях при создании приходной накладной на основании заказа поставщику и УПД на приход в приходную накладную переносился номер счета-фактуры из УПД, но не переносилась дата счета-фактуры. В текущей версии, если приходная накладная создается на основании УПД на приход, у которого поле «функция УПД» имеет значение «СЧФДОП», то есть, когда УПД на приход одновременно является счетом-фактурой, в приходную накладную в поле «дата счета-фактуры» копируется дата документа «УПД на приход».
Примечание. В структуре XML-файла почтового объекта «UI» (УПД на приход) в таблице «SMWAYBILLSEXT» имеются тэги «SUPPLIERINVOICE» и «SUPPLINVOICECREATE» (номер и дата счета-фактуры). Эти тэги присутствуют в структуре почтового объекта по той причине, что таблица «SMWAYBILLSEXT» является общей с объектом «WE» (Накладная поставщика) и в объекте «UI» не используются.
В перечень полей для отображения отобранных документов «Акт потерь» и «Акт обнаружений» добавлено поле «Комментарий»: 
В интерфейс настройки формата обмена «Яндекс.Еда» добавлен выбор вида цены для выгрузки цен товаров: 
Виды цен для кассы и для интернет-магазина настраиваются в разделе «Склады и магазины» на закладке «Цены»: 
Если месту хранения вид цены для интернет-магазина не назначен, то товар будет выгружаться с ценой для кассы. Если вид цены для интернет-магазина назначен, но для конкретного товара цена не установлена, то товар будет выгружен с ценой для кассы.
Изменения функционала в версии 1.051
Справочник «Банкнотный ряд»
Главная касса.
Документы главной кассы.
Перерасчет баланса главной кассы.
ТТН ЕГАИС на отгрузку.
Отсылка ТТН ЕГАИС почтовым модулем, подбор кодов алкогольной продукции.
Контроль соответствия ТТН ЕГАИС с операциями актов списания и кассового документа.
Выбор кода алкогольной продукции.
УПД на приход.
Исправления и расхождения.
Отказ в приеме.
Контрагенты. Доверительный прием поставки.
Генерация документов из процесса «Отгрузка перемещения ТСД».
Поддержка СМ Мобайл. Выгрузка справочника единиц измерения.
Перечень исправленных ошибок и улучшений.
Создан справочник «Банкнотный ряд» в группе справочников «Ценообразование». Для редактирования справочника необходимо иметь право на функцию «Редактирование банкнотного ряда» модуля «Справочники». 
По умолчанию справочник не заполнен. Справочник используется для создания документа «Расходный кассовый ордер» (см. ниже).
В группу разделов Супермаг+ «Платежи» добавлен раздел «Главная касса». Раздел позволяет работать с документами главной кассы: «Приходный кассовый ордер», «Расходный кассовый ордер», «Изъятие из ККТ», «Внесение в ККТ», «Ревизия главной кассы». Для работы с разделом и его документами необходимо обладать правами: 
Раздел «Главная касса» предназначен для регистрации движения наличных денежных средств в главной кассе места хранения торгового предприятия. Для одного места хранения может быть только одна главная касса. Под главной кассой понимается совокупность всех мест в месте хранения (как правило, сейфа или сейфов), в которых хранятся денежные средства, исключая денежные ящики ККТ. Под денежными средствами подразумеваются денежные знаки основной валюты. Учет множества валют не поддерживается. Учет иных денежных средств (суррогатов) не поддерживается.
Для ведения корректного учета в главной кассе не допускается движение денег между кассовыми ящиками ККТ, минуя главную кассу, и прямая инкассация из денежных ящиков ККТ.
Документы «Платеж» и «Получение платежа» к документам главной кассы не относятся, даже если в документе указан «наличный расчет». В случае расчета с контрагентами наличными средствами следует вначале выдать наличные средства подотчетному лицу из главной кассы, затем оформить платеж.
При начале работы с разделом первый раз необходимо указать место хранения, в котором ведется главная касса. Место хранение запоминается и в дальнейшем автоматически подставляется в фильтр документов главной кассы: 
При необходимости можно преключиться на другое место хранение, нажав кнопку «Фильтр»: 
В фильтре можно задать только одно место хранения. Это ограничение позволяет работать с одной выбранной главной кассой.
\\ В разделе «Главная касса» все документы главной кассы показываются одним списком, которым можно управлять с помощью фильтра, то есть выбирать нужные типы документов, их статусы, даты и номера. \\ Каждый документ главной кассы создается с внутренним номером по правилам генерации номеров документа Супермаг+ (см. справочник «Параметры создания документов») и с номером для печати, который формируется по правилам, описанным ниже, и выводится при печати документа. \\ В разделе можно создать приходные и расходные кассовые ордера с операциями: «Выдача наличных» и «Внесение наличных» (то есть операции с физическими лицами), «Получение размена» и «Инкассация» (то есть операции с банковскими организациями), а также документ «Ревизия» - документ проверки наличия денежных средств в главной кассе. Информация об операциях обмена с денежными ящиками ККТ может быть получена только от ККТ и вручную не регистрируется. \\ Для получения данных о внесении и изъятии денег из денежного ящика ККТ модифицирован протокол обмена с кассой типа «УКМ4 XML». В протокол добавлена обработка файлов вида cashbox_\[X\]_\[XXX\]_\[X\]_\[X\]_\[X\].xml, которые содержат информацию о событии внесения или изъятия денежных средств. Файлы cashbox… создаются кассой в момент регистрации внесения или изъятия и немедленно выкладываются в каталог обмена. Файлы забираются кассовым модулем Супермаг+ при приеме по расписанию, ручном приеме, а также при приеме оперативной сводки. \\ На основании каждого принятого файла создается документ с номером для печати вида: \\ 4.111.2.3 \\ В приведенном примере: \\ 4 – номер места хранения 111 – номер кассы 2 – номер кассовой смены, в ходе которой было внесение или изъятие 3 – номер документа в кассе \\ В случае повторной выгрузки кассой квитанций о внесении или изъятии, полученные данные замещают ранее принятые. \\ Интерфейс просмотра информации документа внесения в ККТ и изъятия из ККТ имеет следующий вид: \\ !worddav95bbe31b13c7909da0ebd9b318dbeb0f.png|height=234,width=609! \\ Приходный / расходный кассовый ордер имеет следующий интерфейс работы с документом: \\ !worddav7d35b43bafa7e46e45e8f3cac5d39bdd.png|height=365,width=579! \\ Номер для печати автоматически генерируется по следующим правилам: \\ |
Изменения функционала в версии 1.052 сп1
WEB лицензирование. Время автономной работы.
ЕГАИС.
ТТН на расход. Ручное проставление справок РФУ при возврате без указания основания.
Акт постановки на баланс по результатам инвентаризации. Операция «Пересортица».
ТТН ЕГАИС на отгрузку на основании накладной на перемещение. Определение атрибутов контрагентов при отсылке ТТН в ЕГАИС.
ТТН на приход. Цветовая индикация недостачи.
Приходная накладная. Создание на основании УПД на приход. Копирование даты счета-фактуры.
Акты потерь, Акты обнаружений. Поле «Комментарий».
Сервер обмена данными. Формат «Яндекс.Еда». Изменение в протоколе обмена.
При использовании WEB лицензии допускается работа Супермаг+, когда связь с WEB сервером лицензирования прерывается. В текущей версии время автономной работы Супермаг+ в отсутствии связи с сервером лицензирования увеличено до 30 суток.
Примечание. Для работы в автономном режиме необходимо, чтобы настройка сервера приложений на работу с WEB лицензией проводилась при наличии соединения с WEB сервером лицензирования и все лицензионные права были бы хотя бы один раз подтверждены WEB сервером.
В прошлых версиях при создании ТТН на расход для немаркированных товаров на основании расходной накладной с операцией «Возврат поставщику» и без оснований товародвижения, ТТН создавалась для первого регистра с подбором справок РФУ по актам постановки на баланс. Это связано с тем, что сопоставление контрагента поставщика расходной накладной и контрагента ЕГАИС не является однозначным и точный подбор справок РФУ для возврата невозможен. По этой причине для возврата используется механизм простановки оснований товародвижения в расходной накладной, который позволяет через соответствующие приходные накладные сослаться на справки РФУ из ТТН на приход с соответствующим контрагентом. В противном случае допустимо ссылаться на акты постановки на баланс, поскольку они не связаны ни с какими конкретными поставщиками.
В текущей версии для тех случаев, когда простановка оснований в расходной накладной невозможна, но известно, по каким ТТН приходил товар, реализован механизм ручной простановки справок РФУ для строк ТТН на возврат.
В диалог создания ТТН на отгрузку из расходной накладной на возврат без указания оснований товародвижения добавлена опция «Справки РФУ определять по ТТН на приход №»: 
В качества номера ТТН на приход можно ввести GLID из ТТН Супермаг+, номер ТТН, как её пронумеровал поставщик, или идентификатор ТТН, сгенерированный ЕГАИС.
При создании ТТН на отгрузку в ней будут подобраны коды алкогольной продукции и справки РФУ из указанной ТТН на приход. Подбор выполняется с учетом остатков склада и с учётом всех недообработанных документов ЕГАИС. Для позиций и количеств, для которых остатка не хватило, значения кодов алкогольной продукции и справок РФУ будут пустыми.
Созданную ТТН на возврат можно открыть и подобрать недостающие позиции по другим ТТН на приход, используя функцию «Подбор кодов алкогольной продукции»: 
По результатам инвентаризации ЕГАИС для немаркированного алкоголя могут быть созданы акты списания со второго и/или первого регистра на недостачу товара и акт постановки на баланс на первый регистр для излишков товара. В прошлых версиях акт постановки на баланс создавался с операцией «Излишки» и выбор других операций был недоступен.
В текущей версии при редактировании ТТН помимо операции «Излишки» разрешен выбор операций «Пересортица» и «Продукция, полученная до 01.01.2016»:.
При выборе операции «Пересортица» предоставлять возможность выбора акта списания с регистра склада с операцией «Пересортица». Акт списания со склада может быть, как документом Акт списания, так и ТТН ЕГАИС на отгрузку:
Отсылка акта постановки на баланс с операцией «Пересортица» возможна только после отсылки и фиксации в ЕГАИС связанного с ним акта списания с операцией «Пересортица».
В прошлых версиях при создании ТТН ЕГАИС на основании накладной на перемещение контрагенты отправителя и получателя определялись по ИНН и КПП собственных контрагентов мест хранения "Из" и "В" перемещения. То есть по атрибутам контрагентов, заданным в разделе «Контрагенты» на закладке «Общие».
Если собственные контрагенты мест хранения перемещения совпадали, отсылка ТТН ЕГАИС была невозможна.
В текущей версии, когда собственные контрагенты обоих мест хранения перемещения одинаковые, ИНН контрагента берется из данных закладки «Общие», а КПП контрагента - из таблицы мест хранения собственного контрагента закладки «Собств. контрагент»:
В текущей версии в спецификации ТТН на приход фон строк, у которых поле «Недостача» имеет положительное значение, окрашивается в красный цвет.
В прошлых версиях при создании приходной накладной на основании заказа поставщику и УПД на приход в приходную накладную переносился номер счета-фактуры из УПД, но не переносилась дата счета-фактуры. В текущей версии, если приходная накладная создается на основании УПД на приход, у которого поле «функция УПД» имеет значение «СЧФДОП», то есть, когда УПД на приход одновременно является счетом-фактурой, в приходную накладную в поле «дата счета-фактуры» копируется дата документа «УПД на приход».
Примечание. В структуре XML-файла почтового объекта «UI» (УПД на приход) в таблице «SMWAYBILLSEXT» имеются тэги «SUPPLIERINVOICE» и «SUPPLINVOICECREATE» (номер и дата счета-фактуры). Эти тэги присутствуют в структуре почтового объекта по той причине, что таблица «SMWAYBILLSEXT» является общей с объектом «WE» (Накладная поставщика) и в объекте «UI» не используются.
В перечень полей для отображения отобранных документов «Акт потерь» и «Акт обнаружений» добавлено поле «Комментарий»:
В интерфейс настройки формата обмена «Яндекс.Еда» добавлен выбор вида цены для выгрузки цен товаров:
Виды цен для кассы и для интернет-магазина настраиваются в разделе «Склады и магазины» на закладке «Цены»:
Если месту хранения вид цены для интернет-магазина не назначен, то товар будет выгружаться с ценой для кассы. Если вид цены для интернет-магазина назначен, но для конкретного товара цена не установлена, то товар будет выгружен с ценой для кассы.
Изменения функционала в версии 1.052 сп2
Расходные накладные. Функция «Списание маркированной продукции».
Проверка 73 «Превышение максимально разрешенного изменения цены прихода отн. последней поставки данного поставщика». Условия выполнения.
УПД на приход. Проверка 244 (Корректность документов "УПД на приход").
УКМ4 XML. Выгрузка признака товара «разливное пиво».
Процессы ТСД. Контроль атрибутов КИЗ.
Прием заказа ТСД. Контроль превышения количества заказа.
Почтовый обмен. Прием документа «Заказ поставщику» из подчиненной базы.
В прошлых версиях функция была доступна только в режиме открытого документа. В текущей версии функция доступна в режиме редактирования, если для документа установлен статус «Отпущен со склада» или «Отпущен полностью». Перед выполнением функции, при необходимости, выполняется сохранение документа.
В функции проверки приходной накладной 73 «Превышение максимально разрешенного изменения цены прихода отн. последней поставки данного поставщика» добавлено условие выполнения «при смене статуса с 1 на 2», то есть со статуса «Черновик» на статус «Принят на складе»: 
В детализацию функции проверки добавлена возможность раздельного выбора режима работы функции при смене статуса до «Принят на складе» и до «Принят полностью». 
В проверке 244 «Корректность документов "УПД на приход"» убрано условие срабатывания при смене статуса с «Черновик» на «Заблокирован».
Условие препятствовало отказу от приема УПД, если был установлен системный параметр «Неизвестный артикул при приеме товара» и в спецификации документа были позиции с таким артикулом.
\\
В протокол выгрузки данных УКМ4 XML внесено следующее изменение:
\\
При выгрузке данных об артикуле в файл updateItems_\[ххх\]_\[F/I\].xml при полной или инкрементальной выгрузке в тэге <item> теперь выгружается тэг <crptNotUnique> со значением 1, если артикул относится к маркированным артикулам, которые могут продаваться множество раз с одним и тем же КИЗ. Сейчас к таким артикулам относится разливное пиво, где по правилам ЦРПТ КИЗ, нанесенный на товарную упаковку (кэг), должен указываться каждый раз при продаже в разлив порции пива из этой упаковки. Признак <crptNotUnique> позволяет кассе с одной стороны требовать обязательное указание КИЗ маркированного товара, с другой стороны не контролировать уникальность КИЗ для таких товаров.
\\
Пример:
\\
<?xml version="1.0" encoding="utf-8"?>
<updateItems fullness="I">
<version>1.0</version>
<item>
<article>1001035</article>
<name>Разливное пиво в литрах XML</name>
<measure>л</measure>
<measprec>0.001</measprec>
<groupId>FFD12</groupId>
<SubExcise>1</SubExcise>
<egaisType>3</egaisType>
*<crptNotUnique>1</crptNotUnique>*
<taxgroupId>2</taxgroupId>
<barcode>
<id>4604048023029</id>
<quantity>1</quantity>
</barcode>
</item>
</updateItems>
\\
Артикул считается маркированным с неуникальным КИЗ, если артикул имеет единицу измерения «литр» и входит в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки». Также тэг выгружается для карточек типа «набор», если один из компонентов набора имеет единицу измерения «литр» и входит в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки». Для остальных случаев тэг в файл не помещается.
\\ |
В администраторе сервера приложений в диалог настройки общих параметров добавлен элемент для ввода URL сервера проверки КИЗ. 
URL передается в программу Супермаг Мобайл для обращения к серверу в тех случаях, когда программа сканирует КИЗ и когда требуется предупреждать оператора о тех или иных несоответствиях в параметрах КИЗ. Например, об истекшем сроке годности товара или о факте его продажи.
Контроль КИЗ реализован в программе Супермаг Мобайл Андроид в версии 2.4.228.32
В текущей версии в протокол обмена с ТСД добавлен запрос права оператора на проведение приема поставки без строгого запрета превышения количества принимаемого товара над количеством заказа и с возможностью приема товара, отсутствующего в заказе.
Право оператора определяется назначенным ему режимом работы детализации 2 «Товар отсутствует или кол-во товара превышает кол-во в заказе - основании данного прихода» функции проверки 7 «Наличие товара в основании документа». Если функция проверки (детализация 2) не установлена в «Запрет», то при приеме поставки проверяется только превышение над количеством в УПД / накладной поставщика, если такой документ будет загружен вместе с заказом, а превышение над количеством заказа поставщику не запрещается. В программе ТСД для индикации режима приемки в окне подтверждения начала работы выводится текст «контроль превышения заказа не ведется».
Реакция на права оператора реализована в программе Супермаг Мобайл Андроид в версии 2.4.218.32
В текущей версии разрешен прием в старшей базе документа «Заказ поставщику» из подчиненной базы с понижением статуса, если принимаемый документ имеет статус «Заблокирован».
Изменение связано с поддержкой процесса, когда при создании заказов в подчиненной базе используется автоматическая процедура консолидации заказов и на основании множества первичных заказов создаются новые с блокированием ранее созданных.
Изменения функционала в версии 1.052 сп3
УКМ4 XML. Выгрузка признака товара «разливное пиво».
Инвентаризация ТСД. Ограничение по типам артикула при выгрузке данных в документы.
\\ В прошлой версии в протокол выгрузки данных УКМ4 XML было внесено изменение для выгрузки тэга <crptNotUnique> в файле updateItems_\[ххх\]_\[F/I\].xml. Признак <crptNotUnique> позволяет кассе одновременно требовать обязательное указание КИЗ маркированного товара и не контролировать уникальность КИЗ для таких товаров. \\ В прошлой версии артикул считался маркированным с неуникальным КИЗ, если артикул имел единицу измерения «литр» и входил в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки». Или артикул имел типа «набор» и один из компонентов набора имел единицу измерения «литр» и входил в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки». \\ В текущей версии тэг выгружается по описанному выше условию не только для карточек с единицей измерения «литр», но и для всех карточек, которые имеют единицу измерения, производную от единицы измерения «литр». То есть единицу измерения, у которой в поле «Базовая единица измерения» установлено значение «литр». Например, это может быть «декалитр» или «дал». \\ |
Для реализации маркетинговых программ или программ лояльности торговое предприятие может использовать подарочные сертификаты в качестве денежных суррогатов. Для продажи сертификатов могут использоваться физические носители, например, бумажные карточки, которые хранятся на территории магазина. В Торговой системе такие объекты регистрируются, как артикулы типа «Деньги» и используются для обмена с кассой информацией о продаже и гашении сертификатов. При этом количественный учет сертификатов не ведется и в товарные документы их включать не разрешается, поскольку до момента продажи и активации они денежной функции не несут и, по сути, являются малоценным материалом.
При проведении инвентаризации материальных ценностей персонал может не учитывать особенностей оборота сертификатов. При работе непосредственно с документами такие артикулы не будут добавляться в спецификацию, при использовании ТСД такие артикулы можно внести в подсчет товаров. В этом случае в прошлых версиях возникала ошибка при экспорте из процесса Инвентаризации ТСД в документы. В текущей версии в процедуру экспорта добавлено ограничение, которое позволяет игнорировать артикулы типа «Деньги» и «Услуга» при переносе данных из журнала подсчета в инвентаризационные документы. При обнаружении таких артикулов перед выполнением процедуры экспорта показывается следующее предупреждение: 
Изменения функционала в версии 1.052
WEB лицензирование. Автоматическая загрузка лицензий новых версий.
Управление заданиями Супермаг Мобайл 3.
Закладка «Справочники».
Закладка «Типы заданий».
Закладка «Задания».
УПД на приход. Прием УПД с неизвестными артикулами.
Расходная накладная, Накладная на перемещение. Функция «Проставить основания…». Учет КИЗ.
Раздел «Коррекция заказов поставщикам».
Настройка автоматической генерации заказов поставщику.
Экспорт. Формат поля типа «Дата».
Передача уведомлений в Супермаг Мобайл 2.4.
Меркурий. Прямой обмен с сервисами ГИС Меркурий.
Справочник «Единицы измерения ГИС Меркурий».
Справочник «Площадки ГИС Меркурий».
Выгрузка в кассу по протоколу УКМ4 XML.
Перечень исправлений.
В сервер приложений Супермаг+ добавлен механизм автоматического обращения к серверу лицензирования при несоответствии версии базы данных и версии WEB лицензии или при истечении срока действия временной лицензии. Если на сервере лицензирования будет обнаружена подходящая лицензия, она автоматически будет загружена в сервер приложений. Интервал опроса сервера лицензирования составляет 60 секунд.
Создан новый раздел «Управление заданиями Супермаг Мобайл 3». Раздел помещен в группу «Процессы и потоки работ». Раздел предназначен для создания заданий операторам СМ Мобайл 3 и получения результатов выполнения заданий.
Раздел взаимодействует с сервисом СМ Мобайл 3 по протоколу REST API, предоставляемого сервисом. Обмен данными происходит по защищенному протоколу https и с использованием аутентификации по протоколу OAuth2. В связи с этим при первом старте раздела предлагается ввести URL сервера СМ Мобайл 3 и ключ организации для доступа к данным организации.
При необходимости, данные для обращения к сервису можно изменить с помощью функции «Параметры раздела»: 
Эта закладка позволяет передать службе СМ Мобайл 3 справочные данные, необходимые для выполнения заданий: 
При передаче в СМ Мобайл 3 классификатора товаров карточки товаров, принадлежащие группам, отсутствующим в новом справочнике, будут удалены. Аналогично при передаче мест хранения данные (задания, остатки, цены), связанные с местами хранения, отсутствующими в новом справочнике, будут удалены. Миниатюры карточек товаров замещают существующие на сервере изображения товаров. Перед экспортом всех прочих типов данных на сервере СМ Мобайл 3 происходит их полная очистка.
На этой закладке отображаются типы заданий, которые импортируются из СМ Мобайл 3. Здесь же можно сопоставить типы заданий с процессами ТСД Супермаг+: 
Для сопоставления в текущей версии доступны следующие процессы: 
Сопоставление типа задания СМ Мобайл 3 и процесса Супермаг+ означает, что результат выполнения задания соответствующего типа приведет к созданию указанного процесса в Супермаг+.
На этой закладке можно видеть список заданий, загруженных в СМ Мобайл 3 с текущим статусом выполнения, можно создать новое задание и импортировать журналы исполненных заданий: 
При создании задания указывается тип задания и атрибуты, необходимые для работы оператора. Например: 
При сохранении задания оно немедленно передается в СМ Мобайл 3 и становится доступным оператору для работы: 
При создании задания указывается тип задания СМ Мобайл 3, а не процесс Супермаг+ по той причине, что одному процессу Супермаг+ может соответствовать несколько типов заданий. Тип задания СМ Мобайл 3 может отражать варианты исполнения процесса с дополнительными уточнениями для оператора. Например, инвентаризация может производиться по произвольному списку товаров или по строгому списку. В Супермаг+ это опция процесса «Инвентаризация ТСД», а в СМ Мобайл 3 это разные типы заданий.
После завершения задания оператором можно получить результаты его выполнения, нажав кнопку «Скачать»: 
Факт скачивания задания отражается в журнале событий. Само задание при этом из списка заданий СМ Мобайл 3 удаляется: 
Одновременно создается процесс Супермаг+. Например: 
В текущей версии процессы в Супермаг+ создаются в статусе «Не завершен» и требуют вмешательства оператора для завершения.
Электронный УПД поставщика товаров, как правило, не содержит артикулов Супермаг+. Поставщик передает информацию о товарах либо через собственные артикулы, либо через штриховые коды (GTIN), либо через КИЗ или ОСУ коды, которые внутри себя содержат GTIN.
При приеме электронного УПД и создании УПД на приход происходит опознание артикулов Супермаг+ по данным электронного УПД. В некоторых случаях опознать артикул Супермаг+ не удается и тогда, в прошлых версиях, такой документ не принимался с ошибкой «…нарушено ограничение целостности (SUPERMAG.SMCSPECWE_ARTICLE) - исходный ключ не найден …».
В текущей версии в административный модуль в разделе «База данных» на закладке «Конфигурация» в группу данных «Документы» добавлен атрибут «Неизвестный артикул при приеме товара». Атрибут можно заполнить артикулом, который будет выбран для обозначения неизвестного артикула при приеме электронного УПД. 
Дополнительно в УПД на приход добавлены поля «Ключ товара из УПД» и «Название из УПД», которые заполняются значениями из электронного УПД. Ключ товара может быть либо штриховым кодом (GTIN), либо артикулом поставщика, в зависимости от того, что встретится в электронном УПД.
При приеме электронного УПД созданный УПД на приход, в котором будет содержаться «неизвестный артикул», будет оставлен в статусе «Черновик» и не будет переведен в статус «Принят». В поле «Состояние обмена» помещается запись «Получен с ошибкой: Артикул не найден»: 
Дополнительно в интерфейс УПД на приход добавлена кнопка «Определить артикулы». Кнопка позволяет вызвать функцию для замещения «неизвестного артикула» артикулами Супермаг+ по значению поля «Ключ товара из УПД». Для выполнения функции необходимо иметь новое право «УПД на приход: Редактирование черновика». 
Если все артикулы определены, становится возможным сменить статус документа на «Принят»: 
Для контроля смены статуса создана функция проверки 244 «Корректность документов "УПД на приход"» с режимом работы «Всегда запрет». Проверка срабатывает при смене статуса УПД на приход с «Черновик» на другой статус, если установлен системный параметр «Неизвестный артикул при приеме товара» и в спецификации документа есть позиции, артикул которых совпадает со значением этого параметра.
В документах «Расходная накладная» и «Накладная на перемещение» в функцию «Проставить основания» внесены изменения для сохранения кодов КИЗ в спецификации документа после простановки оснований товародвижения. Если строка исходной спецификации разделяется на несколько с разными основаниями, коды КИЗ могут быть перенесены без соблюдения равенства количества в строке спецификации и в КИЗ (например, если код КИЗ является групповым, а расход или перемещение сослалось на части разных приходов, каждая из которых меньше групповой упаковки).
В группу разделов «Контракты и заказы» добавлен новый раздел «Коррекция заказов поставщикам». Раздел предназначен для верификации и коррекции заказов поставщикам, созданных алгоритмами автоматической генерации заказов.
Раздел позволяет рассмотреть совокупно множество заказов в виде перечня товаров с дополнительной аналитической информацией. Спецификация раздела содержит совокупную спецификацию соглашений о поставках, на основании которых были созданы заказы поставщикам и включает, в том числе строки, для которых алгоритм генерации заказа товар не заказал. Раздел позволяет удостовериться в корректности предложения заказа, либо принять решение о коррекции количества заказа и изменить его: 
Перечень заказов для верификации задается списком соглашений о поставках. Список должен быть предварительно сформирован с использованием классификатора списка документов. В интерфейсе раздела выбирается группа классификатора списка документов, из которого, в свою очередь, берется перечень соглашений о поставках и для этих соглашений отбираются заказы в статусе «Черновик», созданные процедурой автоматической генерации заказов. Статус соглашений о поставках не анализируется. Считается, что список документов всегда актуальный.
В разделе поддерживается управление перечнем полей таблицы (см. картинку выше) и функции обработки количества заказа:
администратором хозяйствующего субъекта. 
