Бюллетени изменений 1.045 сп1 - 1.052 сп3

Изменения функционала в версии 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 файла.
Калькулятор цен для РБ.

Прием немаркированного товара по УПД.

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

УПД на отгрузку. Интерфейс.

В интерфейсе заголовка документа «УПД на отгрузку» название элемента «Поставщик» заменено на «Клиент».

Почтовый модуль. Функция импорта артикула 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-м формате.

В разделе «Подсчет алкоголя ТСД» в функции «в расходную накладную с отсылкой кассового чека в ЕГАИС» кассовый чек ЕГАИС теперь формируется и отсылается в 3-м формате. Интерфейс для ввода параметров заголовка чека остался прежним:

УПД. Повторный прием УПД по протоколу «УПД фильтр». Проверка наличия приходной накладной.

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

Контрагенты. Собственный контрагент, поля "Номер GLN" и "КПП".

В разделе «Склады и магазины» можно описать GLN и КПП места хранения. Эта информация представлена на закладке «Общие»:

В тех случаях, когда место хранение разделяется между несколькими собственными контрагентами, место хранения для каждого контрагента будет иметь свой собственный GLN и КПП.
Чтобы описать перечень значений GLN и КПП одного и того же места хранения для разных контрагентов в разделе «Контрагенты» в таблицу на закладке «Собственный контрагент» добавлены колонки «Номер GLN» и «КПП»:

Почтовый модуль. Функция экспорта GLN места хранения и импорта места хранения по GLN и КПП.

При назначении нескольких контрагентов одному месту хранения считается, что GLN места хранения контрагента обладает уникальностью. Таким образом не может быть двух одинаковых GLN у разных мест хранения или разных контрагентов. Также не может быть одинаковых КПП у разных контрагентов в отношении одного места хранения, но могут быть одинаковые КПП в отношении разных мест хранения.
В функции экспорта и импорта данных XML фильтра почтового модуля внесены следующие изменения:
К функциям экспорта добавлена функция LocationGLN2. Функция имеет два аргумента – код контрагента и код места хранения. Функция возвращает номер GLN (Global Location Number) собственного контрагента в привязке к месту хранения. Если для места хранения собственный контрагент не задан или у него отсутствует GLN, то экспортируется GLN места хранения.
В функции импорта LocationByGLN место хранения теперь ищется вначале по значениям GLN в таблице мест хранения собственных контрагентов, затем, если данные не будут найдены, по значениям GLN мест хранений. Если данных не будет найдено, или будет найдено несколько мест хранения, будет сгенерирована ошибка.
В функции импорта LocationByKPP (Возвращает код места хранения по его КПП)
вначале ищется место хранения по значению КПП мест хранения и, если такого не найдется, то по КПП в таблице мест хранений собственных контрагентов. Если будет найдено несколько мест хранения, будет сгенерирована ошибка.
В функции импорта LocationByINNKPP (Возвращает код места хранения по его КПП и по наличию контрагента с заданным ИНН среди собственных контрагентов места хранения) алгоритм изменен так, что вначале место хранения ищется по сочетанию КПП и собственного контрагента, который определяется по ИНН в таблице мест хранения собственных контрагентов. Если ничего не найдено, то место хранения ищется по его КПП, а если таких будет найдено несколько - по наличию контрагента с заданным ИНН среди собственных контрагентов места хранения (собственный контрагент может быть назначен месту хранения без указания собственного значения КПП).

Касса Супермаг+. ККТ СП801-Ф. ФФД 1.2.

В кассовую программу Супермаг+ внесены изменения для поддержки протокола ФФД 1.2 при работе с ККТ СП-801Ф.
Кассовая программа автоматически определяет текущую версию протокола ФФД, с которым работает ФН в ККТ, и взаимодействует с ККТ либо по протоколу для ФФД 1.05, либо по протоколу для ФФД 1.2.

Наценивание. Алгоритм «Средневзвешенная розничная цена».

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

Значение атрибута распространяется на все артикулы группы и артикулы подчиненных групп, если для них это значение не переопределено. Определить атрибут для отдельного артикула нельзя.
Если флажок отмечен, то при выполнении процедуры наценивания прихода (кнопка «Наценить и принять» в приходной накладной или функция «Генерация актов изменения цены ...» приходной накладной) для не комплексных артикулов отмеченных групп будет выполняться алгоритм наценивания «Средневзвешенная розничная цена» вместо стандартного алгоритма наценивания. Алгоритм выполняется только для вида цены для кассы места хранения прихода. Для прочих видов цен действует стандартный алгоритм наценивания.
В алгоритме «Средневзвешенная розничная цена» новая цена считается стандартным образом, округляется, а затем корректируется по следующей формуле:
[Новая цена] = ([Новая цена по стандартному алгоритму] * [Количество прихода] + [Текущая цена] * [Логистический остаток]) / ([Количество прихода] + [Логистический остаток]),
Где [Логистический остаток] – это текущий остаток (без учета количества текущей поставки) за вычетом потерь и оперативных продаж, отрицательное значение обнуляется.
Дальше происходит округление цены по стандартному алгоритму.
Новый алгоритм применим только к прямым поставкам в место хранение и предназначен для сглаживания колебаний цены товаров с высоким удельным оборотом.

Административный модуль. Настройка печати комплекта документов из процессов.

В административный модуль в раздел «База данных» на закладку «Конфигурация» добавлена группа данных «Печать из процессов ТСД»:

Для процессов «Прием по заказу ТСД» и «Произвольный подсчет ТСД» можно задать перечень и количество копий печатных форм, которые будут печататься автоматически по факту формирования документа с указанной операцией:

Протокол загрузки весов Check Way. Выгрузка даты производства.

Производитель весов Check Way расширил протокол весов в части загрузки дат возможностью загрузки прошлых дат. Это позволило модифицировать протокол загрузки весов и добавить в него загрузку даты производства. Для загрузки в весы даты производства надо отметить флажок в диалоге «Параметры загрузки весов» процедуры загрузки:

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




Изменения функционала в версии 1.046 сервис пак 2.
ЕГАИС. Отсылка акта постановки на баланс с причиной «Пересортица».
Калькуляция. Функция «Заполнить документ ценами последнего прихода».
Заказ в торговом зале ТСД. Нормирование количества заказа
Административный модуль. Печать из процессов ТСД
Поведение элемента выбора мест хранений при запрете просмотра мест хранений.

ЕГАИС. Отсылка акта постановки на баланс с причиной «Пересортица».

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

Калькуляция. Функция «Заполнить документ ценами последнего прихода».

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

Заказ в торговом зале ТСД. Нормирование количества заказа

В процессе «Заказ в торговом заде ТСД» при получении журнала подсчета потребности в товаре из программы Супермаг Мобайл может быть создан документ «Заказ поставщику». При создании заказа поставщику в него помещается количество потребности товара. В прошлых версиях это количество всегда равнялось той величине, которая приходила из программы ТСД. В текущей версии количество заказа нормируется по условиям соглашения о поставках для артикула заказа. Под нормированием понимается округление количества заказа до размера упаковки заказа. Округление производится в ближайшую строну, за исключением случая, когда после округления получается ноль упаковок. В этом случае заказывается одна упаковка заказа.

Административный модуль. Печать из процессов ТСД

В предыдущей версии в административный модуль было добавлено управление перечнем печатных форм и количеством копий для печати по факту генерации документа в процессе ТСД. В текущей версии в настройку перечня форм внесены следующие изменения:
Для приходной накладной добавлен выбор формы «форма внутреннего учета».

Для расходной накладной убран выбор формы «акт на списание товара»:

Поведение элемента выбора мест хранений при запрете просмотра мест хранений.

Возвращено прежнее поведение элемента выбора места хранения: в нем будут отображаться все места хранения, т.е. не будут учитываться права должности на просмотр мест хранения.

Изменения функционала в версии 1.046 сервис пак 3.
ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.
Формирование пакета заказов на базе контракта. Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.
Весы самообслуживания. Загрузка групп PLU.
Заказ в торговом зале ТСД. Передача данных об упаковке заказа.

ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.

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

Формирование пакета заказов на базе контракта. Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.

В версии Супермаг+ 1.042 при создании процесса «Формирование пакета заказов на базе контракта» в случае, когда процесс создается на базе маркетингового соглашения о поставке, из спецификации процесса перестали исключаться артикулы, не входящие в номенклатуру места хранения. Это было сделано для того, чтобы была возможность включать в заказ для маркетинговых поставок новые, пробные артикулы.
В текущей версии исключение артикулов управляется настройкой (Административный модуль - База данных – Конфигурация - Заказы поставщикам):

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

Весы самообслуживания. Загрузка групп PLU.

Для весов самообслуживания с сенсорными экранами для выбора товара реализована возможность использования групп ассортиментов в дополнение к группам номенклатур для загрузки в весы групп 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).
Если для контрагента задано значение характеристики, то в расходной накладной необязательно заполнять поле «Собственный идентификатор участника обмена УПД» и/или «Идентификатор контрагента - участника обмена УПД». Эти данные будут автоматически подставлены в документ УПД на отгрузку, в случае его автоматического создания при смене статуса расходной накладной на «Отпущен полностью». Условия автоматического создания УПД на отгрузку см. раздел «УПД на отгрузку. Обмен с провайдером».

Экспорт. Выгрузка кода и названия грузораспорядителей.

В разделе «Экспорт» в объект выгрузки «Документы/проводки» добавлены колонки для выгрузки кодов и наименований грузоотправителя и грузополучателя.

УПД на отгрузку. Обмен с провайдером.

Реализован обмен с провайдером ЭДО при отгрузке маркированного и немаркированного товара. Общая схема формирования отгрузки и документооборота с контрагентом выглядит следующим образом:

• Создается расходная накладная с операцией отгрузки товара контрагенту. При отгрузке маркированного товара накладная формируется в выбранном для этих целей процессе ТСД с одновременным подсчетом КИЗ, либо отдельно делается подсчет кодов КИЗ ТСД и отдельно – накладная, после чего результат подсчета КИЗ помещается в накладную. Для немаркированного товара накладная создается любым подходящим способом. Расходная накладная переводится пользователем в статус «Отпущен полностью».
• Если накладная содержит КИЗ, то есть маркированный товар, то при смене статуса расходной накладной на «Отпущен полностью» для нее автоматически будет создан УПД на отгрузку со статусом «Сформирован».
• Если в расходной накладной для внешнего контрагента задан идентификатор контрагента – участника обмена УПД или этот идентификатор задан в дополнительной характеристике контрагента «Идентификатор участника обмена УПД», то при смене статуса расходной накладной на «Отпущен полностью» будет создан УПД на отгрузку, независимо от того отгружается маркированный или немаркированный товар.
• По факту смены статуса УПД на отгрузку на «Сформирован» происходит отсылка его по протоколу, который выбран в фильтре УПД (XML/JSON, ФНС XML). Затем происходит ожидание ответа контрагента. Если контрагент прислал согласие, статус УПД на отгрузку меняется на «Обработан», если отказал или принял с расхождением, статус УПД на отгрузку меняется на "Заблокирован". Работа с расходной накладной в случае отказа / неполного приема выполняется вручную.
  Если в документе УПД на отгрузку заполнено поле «Собственный идентификатор участника обмена УПД», то при отсылке УПД на отгрузку это значение будет использовано для выбора адресата обмена (почтового ящика) по равенству значения с атрибутом «Собственный идентификатор участника документооборота» адресата обмена в настройках почтового модуля / сервера обмена данных. Если поле не заполнено и не может быть заполнено значением справочника, то отсылка возможна, если имеется единственный адресат обмена с фильтром «УПД фильтр».
  XSD схема файла ответа для протокола «УПД фильтр XML» приведена ниже:
  <?xml version="1.0" encoding="utf-8"?>
  <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="PACKAGE">
  <xs:complexType>
  <xs:sequence>
  <xs:element name="REPLY">
  <xs:complexType>
  <xs:sequence>
  <xs:element name="ID" type="xs:string" minOccurs="1" maxOccurs="1" nillable="false" />
  <xs:element name="RESULT" type="xs:int" minOccurs="1" maxOccurs="1" nillable="false" />
  <xs:element name ="ACCEPTED" minOccurs="0" maxOccurs="1">
  <xs:complexType>
  <xs:sequence>
  <xs:element name = "ITEM" type="SpecPositionType" minOccurs="0" maxOccurs="unbounded" />
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  </xs:sequence>
  <xs:attribute name="description" type="xs:string" use="required" />
  </xs:complexType>
  </xs:element>
  </xs:sequence>
  <xs:attribute name="name" type="xs:string" use="required" />
  </xs:complexType>
  </xs:element>
  <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:sequence>
  </xs:complexType>
  </xs:schema>
  Пример файла ответа с расхождением:
  <?xml version="1.0" encoding="UTF-8"?>
  <PACKAGE name="f679f7a5-eaba-40d3-bbee-c163be0e240e">
  <REPLY description="Результат приемки">
  <ID>UD0000000003</ID>
  <RESULT>2</RESULT>
  <ACCEPTED>
  <ITEM>
  <SUPPLIERARTICLE>Ц001677</SUPPLIERARTICLE>
  <QUANTITY>5</QUANTITY>
  <MARKS>
  <MARKCODE>04606203086627V?r6=LCAC68lgsz</MARKCODE>
  </MARKS>
  </ITEM>
  </ACCEPTED>
  </REPLY>
  </PACKAGE>
  Для протокола «УПД фильтр ФНС XML» прием ответа с расхождением не предусмотрен.
  

  УПД на приход. Содержание файла ответа.

  
  В текущей версии расширено содержание файла ответа на полученный УПД. В файл схемы ответа - UICONFIRM.XML добавлены следующие поля:
  Для заголовка документа прихода:
  OURCLIENTINN ИНН покупателя
  OURCLIENTKPP КПП покупателя
  OURCLIENTGLN GLN покупателя
  LOCATIONGLN GLN места хранения
  Для спецификации:
  ARTICLE Артикул товара
  SPECITEM Номер строки в спецификации
  DISPLAYITEM Номер строки, отображаемый в интерфейсе накладной.
  BARCODEEXTERNAL Штрихкод поставщика
  ITEMPRICE Цена с НДС
  ITEMPRICENOTAX Цена без НДС
  CARDFULLNAME Полное наименование товара
  CARDMEASUREMENTCODEКод ОКЕИ
  VATRATE Ставка НДС
  VATSUM Сумма НДС по позиции
  TOTALPRICE Итоговая сумма по позиции с НДС
  TOTALPRICENOTAX Итоговая сумма по позиции без НДС
  Полная схема UICONFIRM.xsd приобрела вид:
  <?xml version="1.0" encoding="utf-8"?>
  <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="PACKAGE">
  <xs:complexType>
  <xs:sequence>
  <xs:element name="REPLY">
  <xs:complexType>
  <xs:sequence>
  <xs:element name="ID" type="xs:string" />
  <xs:element name="EDOID" type="xs:string" />
  <xs:element name="CREATEDAT" type="xs:dateTime" />
  <xs:element name="RESULT" type="xs:int" minOccurs="1" maxOccurs="1" nillable="false" />
  <xs:element name="SUPPLIERDOC" type="xs:string" />
  <xs:element name="SUPPLIERINVOICE" type="xs:string" />
  <xs:element name="SUPPLINVOICECREATE" type="xs:dateTime" />
  <xs:element name="CLIENTINN" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="CLIENTKPP" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="CLIENTGLN" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="OURCLIENTINN" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="OURCLIENTKPP" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="OURCLIENTGLN" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name="LOCATIONGLN" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <xs:element name ="ACCEPTED" minOccurs="0" maxOccurs="1">
  <xs:complexType>
  <xs:sequence>
  <xs:element name = "ITEM" type="SpecPositionType" minOccurs="0" maxOccurs="unbounded" />
  </xs:sequence>
  <xs:attribute name="docWI" type="xs:string" use="required" />
  </xs:complexType>
  </xs:element>
  </xs:sequence>
  <xs:attribute name="description" type="xs:string" use="required" />
  </xs:complexType>
  </xs:element>
  </xs:sequence>
  <xs:attribute name="name" type="xs:string" use="required" />
  </xs:complexType>
  </xs:element>
  <xs:complexType name="SpecPositionType">
  <xs:sequence>
  <xs:element name="SUPPLIERARTICLE" type="xs:string" />
  <xs:element name="QUANTITY" type="xs:decimal" />
  <xs:element name="ARTICLE" type="xs:string" minOccurs="0" maxOccurs="1" nillable="false" />
  <xs:element name="SPECITEM" type="xs:int" minOccurs="0" maxOccurs="1" nillable="false" />
  <xs:element name="DISPLAYITEM" type="xs:int" minOccurs="0" maxOccurs="1" nillable="false" />
  <xs:element name="BARCODEEXTERNAL" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" />
  <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="CARDFULLNAME" type="xs:string" minOccurs="0" maxOccurs="1" nillable="false" />
  <xs:element name="CARDMEASUREMENTCODE" type="xs:string" 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:sequence>
  </xs:complexType>
  </xs:element>
  </xs:sequence>
  </xs:complexType>
  </xs:schema>
  Схему можно редактировать. Если из схемы удалить поля, которые не требуется пересылать, файл ответа будет формироваться в соответствии с отредактированной схемой.
  В связи с тем, что файл ответа теперь может содержать полный набор данных, необходимых для идентификации товара и этими данными можно управлять, файлы UICONFIRM.A.xsd и UICONFIRM.B.xsd более не используются. В прошлых версиях управление содержанием файла ответа осуществлялось выкладыванием в каталог схем одного из этих файлов. Теперь в каталог схем надо выкладывать файл UICONFIRM.xsd того содержания, которое требуется для ответа.
  Также изменено содержание ответа, в зависимости от результата приемки. В прошлых версиях спецификация документа прихода выгружалась только при наличии расхождения между содержанием УПД и результатом приемки. В текущей версии спецификация выгружается всегда, кроме случая полного отказа от приемки поставки, когда приходная накладная отсутствует.
  Для обмена УПД с провайдером, помимо почтового модуля, можно использовать сервер обмена данными. Схемы объектов обмена для сервера обмена данных хранятся непосредственно в таблицах сервера, а не в каталоге, как это принято в почтовом модуле. Их содержание может быть загружено из файла, либо отредактировано в интерфейсе администратора. Например:
  
  
  
  Схемы для ответа на УПД на приход доступны в интерфейсе администратора сервера обмена данных в диалоге «Схемы объектов обмена» на закладке «Отсылаемые из Супермага». Диалог вызывается нажатием кнопки «Объекты обмена».
  
  
  В этом интерфейсе схема файла ответа на УПД на приход имеет идентификатор «UI», то есть такой же, как идентификатор схемы принимаемого объекта на закладке «Передаваемые в Супермаг».
  Для редактирования схемы надо нажать кнопку «Изменить»:
  
  
  Для редактирования доступен выбор одного из ключей спецификации, то есть поля, по которому будет определяться товар (артикул / артикул поставщика / штриховой код), и перечень полей – атрибутов заголовка и спецификации, которые можно выгружать или не выгружать в файле ответа.
  

  УПД. Заголовок документа.

  
  В разделах «УПД на приход» и «УПД на отгрузку» в интерфейс заголовка документа добавлено поле «Функция УПД», поле «Накладная поставщика» получила название «Номер УПД», а поля номер и дата счета-фактуры удалены.
  В поле «Функция УПД» проставляется значение соответствующего тэга электронного УПД, то есть «СЧФДОП», «СЧФ» или «ДОП». В нотации ФНС эти термины имеют следующий смысл:
  СЧФ – счет-фактура, применяемый при расчетах по налогу на добавленную стоимость.
  СЧФДОП – счет-фактура, применяемый при расчетах по налогу на добавленную стоимость, и документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг).
  ДОП – документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг).
  
  
  

  КИЗ в процессах и документах.

  Добавление КИЗ в спецификацию документов.

  
  В прошлых версиях была реализована возможность использования КИЗ в спецификациях приходных, расходных накладных, а также в упаковочном листе. Добавление КИЗ в документы выполнялось с помощью функций раздела «Подсчет кодов КИЗ ТСД». Функции раздела позволяют либо создать документ по результатам подсчета, либо дополнить документ результатами подсчета, либо добавить КИЗ из подсчета в уже созданный документ.
  В текущей версии внесены изменения для упрощения работы с КИЗ в документах. Изменения коснулись процессов ТСД, которые связаны с приемом, отгрузкой товаров или подготовки к приему или отгрузке. Это «Прием заказа ТСД», «Отгрузка заказа ТСД», «Произвольный подсчет», «Комплектация заказа», «Комплектация требования». В журналы этих процессов добавлена возможность принимать информацию о КИЗ, считанных в процессе подсчета. Одновременно проведены изменения в программе Супермаг Мобайл Андроид для использования КИЗ вместо EAN при подсчете товара и для сохранения считанных в ходе работы КИЗ в журнале подсчета.
  При создании документов на основании журналов подсчета КИЗ из журнала подсчета помещаются в спецификацию документов. Это позволяет отказаться от дополнительного использования процесса «Подсчет кодов КИЗ» в бизнес-процессах приема / отгрузки товара и упростить процессы работы с маркированным товаром, в том числе, в случае оформления движения смешанных партий из маркированных и немаркированных товаров.
  В разделах документов добавлять КИЗ в спецификацию документа по-прежнему нет возможности, за исключением случая добавления данных из упаковочного листа.
  

  Упаковочные листы с КИЗ.

  
  Реализован перенос КИЗ из упаковочных листов в приходные, расходные накладные и в требование на отбор при добавлении содержания упаковочного листа в документ.
  Аналогичная возможность реализована в программе Супермаг Мобайл Андроид в процессах приема / отгрузки товаров и комплектации требования.
  

  Произвольный подсчет ТСД. Упаковочный лист.

  
  В процесс «Произвольный подсчет» добавлена возможность принимать из программы Супермаг Мобайл журнал подсчета для создания документа «Упаковочный лист». Для этого в процесс добавлен выбор операции «Упаковка».
  В программу Супермаг Мобайл Андроид добавлено условие, по которому при подсчете маркированного товара требуется обязательно сканировать его КИЗ. КИЗ сохраняются в журнале и в дальнейшем помещаются в спецификацию документа «Упаковочный лист».
  Подсчет товара для упаковочного листа реализован в программе Супермаг Мобайл Андроид версии 2.1.643.34.
  

  Касса Супермаг+.

  Чек ЕГАИС. Формат 3.

  
  В кассовую программу внесено изменение для отсылки в ЕГАИС данных о продажах и возвратах маркированной алкогольной продукции в соответствии с схемой ChequeV3.xsd. Прежняя схема Cheque.xsd более не поддерживается. К настоящему времени все УТМ должны поддерживать формат ChequeV3. Если окажется, что это не так, необходимо обновить прошивку УТМ.
  В связи с тем, что новая схема не требует заполнения данных о контрагенте продавце, из интерфейса «Параметры раздела», с закладки «ЕГАИС» убрана опция «контрагент магазина».
  Из интерфейса также убран флаг «Проверять возможность продажи акцизной марки». В прошлых версиях, если флаг был отмечен, то делалось обращение к базе данных Oracle, при наличии связи с ней, для проверки того, не была ли марка продана другими кассами. По текущему протоколу такая проверка делается в УТМ и не требует дополнительных действий.
  

  ККТ СП802-Ф. ФФД 1.2

  
  В кассовую программу Супермаг+ внесены изменения для поддержки протокола ФФД 1.2 при работе с семейством ККТ, работающих по протоколу СП-802Ф: СП101-Ф, СП402-Ф, СП802-Ф, ЧекВей77-Ф.
  Кассовая программа автоматически определяет текущую версию протокола ФФД, с которым работает ФН в ККТ, и взаимодействует с ККТ либо по протоколу для ФФД 1.05, либо по протоколу для ФФД 1.2.
  Протокол ФФД 1.2 вносит следующие особенности в работу кассовой программы:
• ФН должен иметь и периодически обновлять ключи проверки. Это действие происходит при открытии каждой пятнадцатой смены или, если при открытии смены выяснится, что от предыдущего обновления прошло более 15 дней. Обновление ключей может занимать до 30 секунд. Это означает, что время от времени открытие смены может выглядеть как зависание программы.
• При сканировании КИЗ маркированного товара контрольный знак должен проходить двойную проверку, вначале в ФН, на корректность структуры КИЗ, затем в ОИСМ, на доступность к обороту. Общее время, которое отводится на проверку, занимает до 3-х секунд. Соответственно, добавление в чек строки спецификации с кодом КИЗ выглядит как торможение работы программы.
• При продаже или возврате маркированного товара необходимо учитывать, что в чеке может присутствовать не более 128 позиций с маркированным товаром. При необходимости зафиксировать большую партию необходимо пользоваться кодами КИЗ транспортных упаковок (блоков, коробок).
  В строке чека выводится пиктограмма, информирующая о результате проверки кода КИЗ в ККТ. Если КИЗ не прошел проверку в ФН или ОИСМ, то пиктограмма выводится красным цветом. Во всплывающей подсказке к ячейке таблицы выводится разъяснение, где именно КИЗ не прошел проверку.
  При получении отрицательного результата проверки надо учитывать, что отрицательный результат может быть получен, в том числе, для корректного КИЗ. В частности, если ОИСМ не успевает ответить за отведенное время, то корректный КИЗ будет считаться не прошедшим проверку на наличие в обороте. Если ФН не смог обновить ключи проверки, то КИЗ с корректной структурой будет считаться не прошедшим проверку.
  Наибольшее внимание надо обращать на ошибки структуры КИЗ, которые проводятся ФН. ФН проводит вычисление кода проверки для тех КИЗ, которые их содержат, и эти коды достаточно надежно свидетельствуют о подлинности КИЗ. Если проверка ФН покажет ошибку, на такой КИЗ следует обратить внимание.
  

  Проверка права продажи акцизного товара в ФН.

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

  Контракты с поставщиками. Функция «Создать маркетинговый контракт».

  
  В раздел «Контракты с поставщиками» добавлена функция «Создать маркетинговый контракт». Функция создает маркетинговый контракт на основании списка отобранных контрактов. Заголовок маркетингового контракта формируется мастером функции и не требует одинаковости атрибутов в заголовках отобранных контрактов. Спецификация маркетингового контракта заполняется по заданным условиям:
  
  
  Если флаг «Заполнять спецификацию артикулами из спецификации исходных контрактов» не отмечен, то маркетинговый контракт будет создан с пустой спецификацией, если отмечен, то со спецификацией, созданной путем объединения спецификаций исходных контактов. Поля спецификации исходных контрактов копируются полностью, кроме цены. Если исходные контракты содержат одни и те же артикулы, то при создании маркетингового контракта будут использоваться данные только одного из них. То есть, если атрибуты контракта, такие как, упаковка поставки и т.д., в разных контрактах будут обличаться, то в маркетинговый контракт они попадут из одного из них.
  В общие основания маркетингового контракта помещаются все исходные контракты, на основании которых он сделан.
  

  Накладные. Диалог «Справка к ГТД/ТТН, Сертификат соответствия».

  
  В приходных, расходных накладных и накладных на перемещение можно отредактировать поля спецификации «Справка к ГТД/ТТН» и «Сертификат» через диалог «Справка к ГТД/ТТН, Сертификат соответствия». В прошлых версиях этот диалог позволял ввести перечень номеров акцизных марок, поступивших с товаром. Это поведение было актуальным до появления ЕГАИС. В текущей версии эта возможность удалена.
  
  
  Функция проверки 15 «Значения "Справка к ГТД/ТТН", "Сертификат" или "Акциз" не заполнены» переименована в «Значения "Справка к ГТД" или "Сертификат" не заполнены». Из неё исключен контроль соответствия флага «Акцизный товар» у артикула и содержания строки спецификации.
  

  Подсчет товаров ТСД. Отгрузка заказа ТСД. Отгрузка перемещения ТСД. Управление статусом создаваемых документов.

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

  Отгрузка заказа ТСД. Отгрузка перемещения ТСД. Смена статуса документа основания отгрузки.

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

  Карточки. Контрагенты. Места хранения. Поиск в таблице данных.

  
  В разделах «Карточки складского учета», «Контрагенты», «Склады и магазины» внесено изменение в способ поиска строки в списке отобранных строк таблицы данных.
  В предыдущих версиях поиск производился среди значений заданной колонки таблицы. Для поиска необходимо было выбрать колонку, ввести строку для поиска и нажать «Enter». В случае успеха курсор устанавливался на первой строке с подходящим контекстом. Последовательное нажатие «Enter» приводило к перемещению курсора на следующую строку с подходящим контекстом.
  В текущей версии поиск производится сразу по всем значимым колонкам таблицы, если таковые выбраны для показа в таблице данных:
• в разделе «Контрагенты»: Ид., Название, Короткое название, ИНН, КПП, ОКПО, Комментарий, Паспорт, GLN, Телефон, Факс, E-mail;
• в разделе «Склады и магазины»: Ид., Название, Короткое название, КПП, Комментарий, GLN, Адрес, Телефон, Факс;
• в разделе «Карточки складского учета»: Артикул, Название, Короткое название, Артикул ЦС.
  Результат поиска формируется не путем позиционирования курсора на искомой строке, а путем показа в таблице подходящих строк:
  
  
  Поиск осуществляется при нажатии на кнопку с лупой или «Enter» и непустой строке поиска. Отмена поиска выполняется нажатием кнопки с крестиком или «Escape», либо удалением строки поиска и нажатием «Enter». Ввод строки поиска можно начать, если фокус находится, как на элементе для ввода строки, так и на любом поле таблицы.
  При смене группы классификатора, когда установлено условие поиска, автоматического применения условия к новым данным не происходит. Для возобновления поиска необходимо нажать на кнопку с лупой или кнопку «Enter» при установленном фокусе на строке поиска.
  В текущей версии также изменен интерфейс отображения условий фильтра карточек и управление результатом работы фильтра карточек. Элемент с содержанием условий фильтра показывается только при заданном условии (см. картинку выше), если условие фильтра не задано, элемент на экране отсутствует. Кнопка «Фильтр», которая использовалась для отмены и восстановления результата фильтрации, заменена кнопкой с крестиком, а кнопка «Задать фильтр» получила название «Фильтр».
  

  Сервер обмена данными. Пользовательские аналитические данные.

  
  В предыдущих версиях сервер обмена данными позволял запрашивать у него объекты Супермаг+ (документы, карточки и т.д.) и ограниченное количество аналитических объектов, созданных для служебных нужд.
  Перечень объектов доступных для получения, можно посмотреть в администраторе сервера обмена данными, если нажать кнопку «Объекты обмена» и в диалоге «Схемы объектов обмена» нажать кнопку «Добавить» на закладке «Отсылаемые из Супермага»:
  
  
  В текущей версии перечень стандартных объектов Супермаг+ можно дополнить собственными аналитическими объектами.
  Под аналитическим объектом понимается результат выборки из базы данных, представленный в виде одной таблицы.
  Для создания или редактирования аналитических объектов необходимо иметь право «Сервер обмена данными (API): редактирование пользовательских аналитических данных».
  Создание и редактирование аналитических объектов выполняется в диалоге «Схемы объектов обмена». Диалог вызывается кнопкой «Объекты обмена» в интерфейсе администратора сервера обмена данных. Для работы надо перейти на закладку «Пользовательские аналитические данные». На закладке есть кнопка «?» для вызова файла помощи, в котором описан процесс создания аналитического объекта и дается пример такого объекта.
  Внимание! Для создания аналитического объекта требуются навыки написания скриптов на языке PL/SQL и знание структуры базы данных Супермаг+.
  Создание объекта выполняется в два этапа. На первом этапе создается функция PL/SQL с условием, что ее имя начинается с символов «USIO». Это требуется, чтобы избежать конфликтов с именами процедур и функций Супермаг+, в том числе с именами функций для аналитических объектов.
  Например, требуется получить из сервера обмена данных информацию обо всех активных артикулах заданного места хранения с текущими остатками и текущими ценами для кассы. Тогда функция, которая предоставит такие данные, может, например, иметь имя «USIOARTICLEINFO» и ее содержание будет следующим:
  create or replace function USIOARTICLEINFO
  (
  pLocID in varchar2
  ) return DummyTypeHolder.TRefCursor
  is
  vSQL varchar2(4000);
  vResult DummyTypeHolder.TRefCursor;
  begin
  vSQL :=
  'select a.Article'||
  ',a.Name'||
  ',g.Quantity'||
  ',(select p.Price from SMPrices p, SMPriceTypes pt, SMLocPrices lp'||
  ' where p.Article = a.Article'||
  ' and p.StoreLoc = g.StoreLoc'||
  ' and p.PriceType = pt.ID'||
  ' and lp.PriceType = pt.ID'||
  ' and bitand(lp.Flags, 2) <> 0'||
  ' and lp.LocID = p.StoreLoc'||
  ') Price'||
  ' from SMCard a, SMGoods g'||
  ' where g.StoreLoc = '||pLocID||
  ' and g.Article = a.Article'||
  ' and a.Accepted=1';
  open vResult for vSQL;
  return vResult;
  end;
  /
  Функция имеет один входной параметр – pLocID (код места хранения) и в качестве результата выдает курсор с полями: Article, Name, Quantity, Price (артикул, название, остаток, цена). Скрипт создания функции необходимо выполнять от имени пользователя «supermag».
  На втором этапе объект необходимо описать в интерфейсе сервера обмена данных:
  
  
  Имена полей виртуальной таблицы данных должны совпадать с именами полей, которые возвращаются функцией (регистр не имеет значения).
  После описания аналитического объекта его можно добавить в перечень разрешенных для запроса. Для этого на закладке «Отсылаемые из Супермага» надо нажать кнопку «Добавить» и в диалоге выбрать информационный объект:
  
  
  Обратите внимание, что имя информационного объекта отличается от имени функции. Имя информационного объекта начинается с префикса IO и продолжается именем функции:
  
  
  Проверить работоспособность информационного объекта можно в браузере, задав следующий URL:
  {+}http://localhost:8095/out/xml/IOUSIOARTICLEINFO/*/pLocId=3+
  locationhost:8095 – ip-адрес и порт компьютера сервера обмена данных;
  out – запрос информации;
  xml – формат представления данных;
  IOUSIOARTICLEINFO – имя информационного объекта;

• - дополнительные условия, которые в случае аналитических объектов отсутствуют;
  pLocId – имя входного параметра функции;
  =3 - значение входного параметра, в нашем случае - код места хранения, для которого запрашиваются данные.
  Если параметров будет несколько, они перечисляются с разделителем «/».
  Фрагмент ответа сервера обмена данных представлен ниже:
  
  
  При использовании аналитических бизнес-объектов необходимо учитывать, что объект формируется в ходе выполнения функции базы данных и выдается СУБД после завершения обработки данных и формирования результата. Этот процесс при большом объеме обрабатываемых данных или при неоптимальном построении программного кода может быть долгим. При использовании протокола text/plain (используется большинством программ), при котором ответ помещается в тело отклика WEB-сервера, это время может превысить таймаут отклика, что приведет к ошибке обмена. В таких случаях необходимо использовать протокол multipart/form-data, при котором WEB-сервер дает служебный ответ немедленно при получении запроса, а данные передает в виде файла по дополнительному запросу клиента спустя то время, которое требуется на его формирование.
  При настройке адресата обмена можно увидеть выбор протокола. Чтобы не запутаться, надо учитывать, что этот интерфейс предназначен только для настройки протокола обмена, когда сервер обмена данными выступает в роли клиента. То есть, HTTP-адрес, тип контента и аутентификация – это атрибуты сервера, по отношению к которому сервер обмена данными выступает в роли клиента:
  
  
  В том случае, когда сервер обмена данными выступает в роли сервера, он не требует настроек типа контента и определяет протокол обмена автоматически. В этом случае важно, чтобы клиент, который запрашивает аналитический объект, мог работать по желательному протоколу, например, по протоколу «multipart/form-data».
  

  Драйвер касс «УКМ4 XML». Выгрузка в кассу признака подакцизного товара.

  
  В протокол УКМ4 XML в выгрузку информации о товаре внесено следующее изменение:
  в файле updateItems в тэг <item> добавлен тэг <SubExcise> - признак того, является ли товар подакцизным. Тэг может принимать значения «0» или «1», где 0 - не подакцизный, 1 – подакцизный товар, например:
  <item>
      <article>000002</article>
      <name>Протвино-Ветчина Для завтрака </name>
      <measure>килограмм</measure>
      <measprec>0.001</measprec>
      <SubExcise>0</SubExcise>
      <groupId>286</groupId>
      <taxgroupId>2</taxgroupId>
      <barcode>
         <id>2200002</id>
         <quantity>0</quantity>
      </barcode>
  </item>
  Для отнесения товара к подакцизным в разделе «Карточки складского учета» на закладке «Карточка» надо установить флажок «Акцизный товар». Флажок можно установить или снять для перечня карточек функцией «Изменение карточки» кнопки «Обработать».
  Атрибут передается в кассу для корректного заполнения тэга 1212 при отправке чека в налоговые органы.
  

  Почтовый модуль. Функция экспорта в XML-пакет.

  
  В редактор XML-схем для экспорта данных добавлены функции: VatRate и VatRateCurrent.
  Обе функции предназначены для выгрузки значения ставки налога НДС из карточки товара.
  Функция VatRate имеет четыре аргумента:

• Артикул товара
• Контрагент - для определения того, следует ли замещать ставку НДС на ноль, если контрагент документа не является плательщиком НДС.
• Дата операции - для случая, когда выгружается старый документ, в момент действия которого ставка НДС была иной.
• Место хранения - для определения региона действия ставки налога.
  Функция VatRateCurrent имеет один аргумент - Артикул товара.
  Для определения ставки НДС артикула в этой функции принимается, что замещать ставку НДС на ноль не следует, дата действия налога – текущая и НДС определяется для региона по умолчанию (код региона = -1).
  

  Административный модуль. Утилита «Исчерпание диапазона номеров документов».

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

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

• Выполнена оптимизация алгоритма генерации номера документа во избежание длительного ожидания блокировки таблицы SADocDefaults. Блокировка устанавливается функцией генерации номера документа для обеспечения уникальности генерируемого номера при одновременном обращении множества пользователей.
  1) В сборку мусора добавлено удаление из таблицы SSDocGen записей, не отвечающих текущим стандартным правилам генерации номера. Эта таблица участвует в работе функции генерации номеров документов, и большой размер таблицы отрицательно сказывается на быстродействии функции.
  2) Создана статистическая таблица SSDocLastID, в которой хранится максимальный сгенерированный номер для текущих правил генерации номера документа.
  3) Изменен механизм блокировок для выстраивания в очередь обращений за новыми номерами. Вместо блокирования таблицы SADocDefaults устанавливается блокировка на генерацию номера для указанного типа документов.
  
  Изменения функционала в версии 1.047 сервис пак 1.
  УПД на приход. Содержание файла ответа.
  Подсчет кодов КИЗ ТСД. Сохранение в карточке нового штрихкода из КИЗ.
  Прием по заказу ТСД. Данные накладной поставщика.
  Контроль остатков. Печать спецификации из процесса и из программы ТСД.
  Заказ в торговом зале ТСД. Предложение заказа.

УПД на приход. Содержание файла ответа.

В файл ответа с результатом приема по УПД на приход (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.

Приходная накладная. Мастер создания.

В прошлых версиях в мастере создания приходной накладной (страница «[на основании заказа]») значение опции «Заполнять спецификацию товарами из заказа / накладной поставщика» запоминалось и предлагалось при следующем обращении к мастеру:

В текущей версии значение опции не запоминается и при создании документа всегда устанавливается в положение «не отмечено».
Название опции дополнено словом «… / УПД», что означает, что при создании приходной накладной на основании заказа могут использоваться не только накладные поставщика, но и УПД, созданные на основании заказа.
УПД при создании приходной накладной используются также, как и накладные поставщика.
УПД на приход предлагается использовать, если на основании заказа поставщику нет ни одной накладной поставщика в статусе «Принят». Если накладная поставщика имеется, у нее будет приоритет использования по отношению к УПД. Это позволяет сохранять преемственность работы с данными, оставшимися от предыдущих версий, когда при приходе УПД автоматически создавалась накладная поставщика. Если будет обнаружено несколько УПД, например, когда заказ поставляется частями, будет предложен диалог с возможностью выбора УПД по номеру и дате документа поставщика:

При использовании УПД на приход, также как в случае использования накладной поставщика, КИЗ из УПД в приходную накладную не переносятся.
При использовании опции «Заполнить поле «Цена»» необходимо учитывать, что УПД принимается в том виде, в котором ее заполнил поставщик и, если он допустил грубые ошибки в расчете сумм, создание приходной накладной может быть заблокировано с показом соответствующей ошибки.

Контракт с поставщиком. Информация о соглашениях о поставках.

В интерфейс заголовка документа «Контракт с поставщиком» на закладке «Соглашения о поставках» в таблицу соглашений о поставках добавлены колонки «Количество мест поставки» и «Количество позиций»:

Дополнительно разрешена сортировка строк по значению статуса.

Изменения функционала в версии 1.047 сервис пак 4.
Алкогольная декларация. Изменение XSD схемы файлов 7 и 8.
Контрагент по умолчанию для операций с розничным клиентом.
Подсчет товаров ТСД. Создание документа «Заказ от клиента».
Прием заказа ТСД. Изменение интерфейса для работы с УПД.
Подсчет кодов КИЗ ТСД. Функция экспорта данных «в приходную накладную». Простановка цен.
Сервер приложений. Журнализация процесса регистрации начала работы с ТСД.

Алкогольная декларация. Изменение XSD схемы файлов 7 и 8.

В XSD схемах деклараций 7 «Декларация об объемах закупки этилового спирта, алкогольной и спиртосодержащей продукции» и 8 «Декларация о перевозках этилового спирта, алкогольной и спиртосодержащей продукции» для типа данных "П000000000003" «Код вида продукции» изменилось ограничение на длину кода с 3 до 5 символов. Соответствующее изменение внесено в процедуру генерации деклараций.

Контрагент по умолчанию для операций с розничным клиентом.

В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Документы» название атрибута «Контрагент по умолчанию для возврата от покупателя» заменено названием «Контрагент по умолчанию для розничного клиента»:

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

Подсчет товаров ТСД. Создание документа «Заказ от клиента».

В процессе «Подсчет товаров ТСД» изменен бизнес процесс работы с документом «Заказ от клиента». В прошлых версиях при получении от ТСД журнала с операцией «Заказ от клиента» создавался документ «Заказ от клиента» со статусом «Черновик».
В текущей версии название операции «Заказ от клиента» заменено названием «Сбор заказа клиента / пречек». Процесс «Подсчет товаров ТСД» подразумевает, что оператор видит, сканирует и регистрирует реальный наличествующий товар или товар представленный в виде образцов, и результат его работы может быть использован для формирования платежа и передачи клиенту партии товара.
В текущей версии ожидается, что программа ТСД передаст в экземпляр процесса данные, как о товарах и их количестве, так и о КИЗ маркированных товаров, чтобы созданный в процессе документ «Заказ от клиента» можно было бы передать кассовой программе для формирования чека.
Документ «Заказ от клиента» теперь создается в статусе «Согласован», в него проставляется клиент «Контрагент по умолчанию для розничного клиента» из настроек административного модуля (База данных->Конфигурация->Документы), вид платежа устанавливается в значение «Наличный / банковская карта», затребованное количество устанавливается равным собранному количеству.

Прием заказа ТСД. Изменение интерфейса для работы с УПД.

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

Подсчет кодов КИЗ ТСД. Функция экспорта данных «в приходную накладную». Простановка цен.

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

Сервер приложений. Журнализация процесса регистрации начала работы с ТСД.

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

Изменения функционала в версии 1.047 сервис пак 5.
Накладные. Диалог редактирования ГТД / ТТН и сертификатов.
Функция нормирования количества заказа.

Накладные. Диалог редактирования ГТД / ТТН и сертификатов.

В версии 1.046 в приходных, расходных накладных и накладных на перемещение было внесено изменение в диалог «Справка к ГТД/ТТН, Сертификат соответствия». До изменения диалог использовался для редактирования полей спецификации «Справка к ГТД / ТТН», «Сертификат» и «Акциз». Из диалога был убран флаг «Акциз», который позволял ввести множество строк с перечнем акцизных марок. Как следствие, диалог стал однострочным, то есть стало можно ввести одно значение справки ГТД / ТТН и одно значение сертификата.
В текущей версии диалог изменен, чтобы поддержать ввод множества строк с номерами справок к ГТД / ТТН и сертификатами:

Колонка с кнопкой «Выбор Сертификата» позволяет обратиться к функции выбора подходящего документа «Сертификат/Декларация соответствия», чтобы выбрать номер сертификата и добавить его в выбранную строку таблицы.

Функция нормирования количества заказа.

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



Изменения функционала в версии 1.047
Справочник «Классификатор ОКПД2».
Карточки складского учета. Группа классификатора ОКПД2.
ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.
Прием УПД. Режим приема УПД.
Функция проверки «Контроль наличия УПД при принятии приходной накладной»
Почтовый модуль. Протокол «УПД фильтр». Квитанция провайдера ЭДО.
Приходная накладная. Индикация состояния обмена УПД. Фильтр документов по состоянию обмена.
Накладная на перемещение. Регистрация КИЗ при перемещении товара.
Функция проверки «Контроль наличия КИЗ для маркированных товаров».
Функция проверки «Контроль статуса УПД / накладной поставщика при разоприходовании приходной накладной».
Подсчет кодов КИЗ ТСД. Экспорт данных в накладную на перемещение.
Резервирование товара документом «Заказ от клиента» в статусе «Согласован».
Документы. Функция «Упорядочить №№»
Формирование пакета заказов на базе контракта.
Цены маркетинговых контрактов.
Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.
Весы самообслуживания. Загрузка групп PLU.
Контроль остатков ТСД. Автоматическая генерация документов.
Контроль зала ТСД.
Отгрузка заказа ТСД.
Административный модуль.
Маркировка. Опция «Учет кодов КИЗ при приемке и отгрузке товаров».
Периоды. Интерфейс страницы.
Процедура обрезки базы данных.
Перечень исправленных ошибок и улучшений.

Справочник «Классификатор ОКПД2».

В раздел «Справочники» в группу справочников «Карточки» добавлен справочник «Классификатор ОКПД2».

Справочник требуется заполнить самостоятельно теми данными, которые предполагается использовать. Группы классификатора, которые использовать не предполагается, например, слишком общие, как 10.5 в примере выше, или неприменимые к торгуемой продукции, заносить в справочник не следует. Это может привести к ошибкам в назначении групп классификатора товарам.
Для работы со справочником необходимо иметь функциональное право «Редактирование классификатора ОКПД2».

Карточки складского учета. Группа классификатора ОКПД2.

В разделе «Карточки складского учета» на закладку «Классификация» добавлено назначение артикулу группы классификатора ОКПД2:

Назначить группу классификатора списку артикулов можно в функции «Изменение классификации» кнопки «Обработать»:

Для поиска арткулов по значению группы классификатора ОКПД2 добавлен элемент «ОКПД2» в закладку «Прочее» фильтра карточек:

Для отображения кода классификатора ОКПД2 в таблице отобранных карточек в диалог кнопки «Поля» добавлен флаг «Код ОКПД2»:

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

ЕГАИС. Отсылка ТТН ЕГАИС на отгрузку с немаркированным алкоголем.

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

Прием УПД. Режим приема УПД.

В предыдущих версиях было поддержано три варианта работы с УПД на приход, которые задавались режимами приема УПД: «С предварительным приемом накладной поставщика», «С созданием накладной поставщика по УПД» и «Без накладной поставщика».
Вариант «С предварительным приемом накладной поставщика» предполагает, что поставщик присылает накладную поставщика, как уведомление об отгрузке, по ней производится прием поставки, результат приема (приходная накладная Супермаг+) отсылается поставщику, который в ответ (при согласии) присылает УПД, как документ, согласованный двумя сторонами и требующий только подтверждения со стороны получателя.
Вариант «С созданием накладной поставщика по УПД» предполагает, что поставщик присылает УПД, как уведомление об отгрузке, при приеме УПД создается накладная поставщика (для унификации процессов приема), по накладной поставщика делается прием поставки, результат отсылается поставщику, после чего, в случае приема с расхождениями, от него ожидается повторный исправленный УПД.
Вариант «Без накладной поставщика» предполагает, что поставщик не присылает никаких документов перед поставкой, поставка принимается на основании заказа, после чего результат приемки отсылается поставщику для формирования им УПД. При приеме УПД происходит автоматическое сличение состава УПД с ранее созданной приходной накладной и, при успешном сличении, подтверждение приема.
При работе с поставками выяснилось, что поставщик не всегда может обеспечить однозначную последовательность присылки УПД и прибытия поставки. То есть, могут быть случаи, когда УПД приходит раньше поставки и, тогда выставленный режим приема УПД «С созданием накладной поставщика по УПД» позволяет выполнить, как прием с контролем КИЗ, так и обмен документами с поставщиком в запланированной последовательности. Могут быть случаи, когда поставка прибывает до получения электронного УПД, и тогда, для поддержания корректного процесса, прием поставки откладывается.
В текущей версии выполнено объединение режимов приема «С созданием накладной поставщика по УПД» и «Без накладной поставщика» в один режим приема «Без накладной поставщика». Это обеспечило возможность приема поставки от одного и того же поставщика, как при наличии УПД к моменту прибытия поставки, так и в случае, когда она еще не пришла.
В новой трактовке режима приема «Без накладной поставщика», УПД от поставщика принимается без создания накладной поставщика, даже в том случае, когда УПД приходит до начала приема товара. Чтобы обеспечить возможность приема поставки с контролем КИЗ при отсутствии накладной поставщика были внесены изменения в процесс «Подсчет кодов КИЗ ТСД».
Для приема поставки в режиме «Без накладной поставщика» в диалог создания процесса «Подсчет кодов КИЗ ТСД» добавлен элемент «по УПД»:

Если УПД уже принят, он может быть найден либо по заданному сочетанию номера документа поставщика, его даты и контрагента, либо поиском с помощью стандартного диалога выбора документа.
Когда УПД на приход выбран, прием ведется также, как в случае приема на основании накладной поставщика, то есть с проверкой сканируемых КИЗ на их наличие в УПД на приход.
После завершения подсчета выполняется экспорт данных в приходную накладную. Накладная создается в статусе «Черновик», в её основание помещаются УПД на приход и заказ поставщику, который берется из УПД. При смене статуса приходной накладной с «Черновик» на «Принят на складе» производится контроль полноты приема поставки по УПД. Затем поставщику отсылается либо подтверждение приема, либо отказ с описанием перечня принятых артикулов и их КИЗ. Во втором случае УПД на прием блокируется, и ожидается ответ от поставщика в виде исправительного УПД.
Если поставка прибыла до получения электронного УПД от поставщика, подсчет кодов КИЗ можно выполнить, указав контрагента, номер и дату документа поставщика из сопроводительных документов. Под номером документа поставщика понимается тот номер документа, который в УПД на приход показывается в поле «Номер УПД», в XML-схеме находится в поле <SUPPLIERDOC>, а в схеме ФНС XML - в поле <НомерСчФ>.

Если задать эти параметры и нажать «Далее», будет призведен поиск документа УПД на приход с такими данными. Если документ не найден, появится сообщение:

Если ответить «Да», будет создан процесс для подсчета КИЗ без немедленного контроля, но с сохранением данных об УПД, который должен прийти из системы ЭДО.
При приеме поставки до получения УПД на приход контроль кодов КИЗ в процессе приема невозможен. По результатам приема создается приходная накладная, в которую переносятся данные УПД. Накладная помечается, как ожидающая прихода УПД, что не позволяет поднять ее статус до «Принят полностью» до тех пор, пока не будет завершен документооборот.
При приходе УПД производится поиск соотвествтующей ему приходной накладной, делается автоматическая сверка состава УПД и приходной накладной и немедленно отсылается ответ поставщику. Это может быть подтверждение приема (при совпадении состава) или отказ с перечнем фактически принятых товаров и их КИЗ.
Аналогичные изменения внесены в программу Супермаг Мобайл Андроид.

Функция проверки «Контроль наличия УПД при принятии приходной накладной»

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

Почтовый модуль. Протокол «УПД фильтр». Квитанция провайдера ЭДО.

В предыдущих версиях протокол «УПД фильтр» с форматами данных XML или JSON предполагал следующую последовательность обмена данными при приеме УПД на приход:

• получение УПД в формате XML или JSON;
• отсылка файла подтверждения приема с результатом приема 1 или 3 и с полной спецификацией принятого товара (если что-то принято);
• получение исправленного УПД, если результат приема 3 и файл ответа содержит спецификацию приема;
• отсылка файла подтверждения с результатом приема 1 при совпадении исправленного УПД с результатом приема.
  В текущей версии протокол обмена дополнен получением технической квитанции в ответ на отсылку файла с результатом приемки. Квитанция имеет смысл подтверждения успешности обработки и пересылки провайдером ЭДО файла подтверждения. Квитанция имеет вид:
  <APPERAK>
  <RESULT>3</RESULT>
  <ID>WE762be5ac-03ae-4457-b9af-81b08caeb389</ID>
  <CREATEDAT>2021-07-06</CREATEDAT>
  <SENDDATTIM>2021-07-06T12:12:32/SENDDATTIM>
  <EDOID>039a4936-d443-42ea-a6e0-65a3914b40fa</EDOID>
  <CLIENTGLN>4343463463462</CLIENTGLN>
  < ERRORTEXT >Ошибка ЭЦП</ ERRORTEXT >
  </APPERAK>
  Если после отсылки файла подтверждения будет получена квитанция со значением RESULT = 3, что означает ошибку при прохождении в системе ЭДО, то файл подтверждения можно будет отослать повторно из открытого на просмотр документа:
  
  Если RESULT = 1 (при отсылке файла подтверждения с флагом приема) или 2 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно.
  
  

  Приходная накладная. Индикация состояния обмена УПД. Фильтр документов по состоянию обмена.

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

  Накладная на перемещение. Регистрация КИЗ при перемещении товара.

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

  Функция проверки «Контроль наличия КИЗ для маркированных товаров».

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

  Функция проверки «Контроль статуса УПД / накладной поставщика при разоприходовании приходной накладной».

  
  Создана новая функция проверки 240 «Контроль статуса УПД / накладной поставщика при разоприходовании приходной накладной». По умолчанию функция имеет режим работы «Предупреждение».
  Функция выполняется при понижении статуса приходной накладной с «Принят на складе» до «Черновик».
  Проверка срабатывает при выполнении одного из следующих условий:
• в основании приходной накладной имеется УПД в статусе «Сформирован» или «Обработан» или накладная поставщика в статусе «Принят» или «Закрыт»;
• имеется УПД в статусе «Сформирован» или «Обработан», в основании которого указана приходная накладная.
  Последнее условие связано с процессом приема поставки до получения электронного УПД (см. выше), когда поставка принимается на основании сведений, предоставленных в сопроводительных документах. В этом случае приходная накладная формируется до получения УПД на приход и прописывается в его основание при приёме УПД, а не наоборот, как в случае, когда УПД приходит до начала приема товара.
  

  Подсчет кодов КИЗ ТСД. Экспорт данных в накладную на перемещение.

  
  В предыдущих версиях процесс «Подсчет кодов КИЗ ТСД» позволял экспортировать результаты подсчета в накладную на перемещение, перенося в нее данные о посчитанных артикулах и их количестве. Коды КИЗ в накладную на перемещение не переносились.
  В текущей версии в процессе подсчета кодов КИЗ ТСД реализовано два сценария работы с накладной на перемещение с переносом в нее кодов КИЗ. Первый сценарий подразумевает, что накладная на перемещение формируется для отгрузки товара, второй – подсчет используется для приема товара по имеющейся накладной на перемещение.
  В первом случае в диалоге создания нового процесса надо пропустить выбор документа основания подсчета:
  
  При приеме перемещения с контролем КИЗ надо указать документ, по которому будет проводиться прием:
  
  При подсчете кодов КИЗ, когда основание подсчета отсутствует, функция экспорта данных «в накладную на перемещение» предлагает два варианта работы:
  
  При выборе опции «Создать новую накладную» создается накладная на перемещение в статусе «Черновик» с заполнением поля «Количество», заполнением таблицы КИЗ и с нулевыми значениями в поле «Фактическое количество».
  При выборе опции «Принять поставку по существующей накладной» дальше в мастере функции необходимо указать накладную на перемещение, по которой производится прием товара (накладная должна иметь статус «Отправлен»). Далее в этой накладной будет заполнена колонка «Фактическое количество» и для принятых кодов КИЗ будет установлен флаг «Принят». Если при работе функции будут обнаружены КИЗ, которые присутствуют в подсчете, но отсутствуют в накладной на перемещение, работа функции будет прекращена с сообщением об ошибке.
  Прием накладной на перемещение не предполагает коррекции накладной при обнаружении новых кодов КИЗ, то есть кодов, не зафиксированных при отгрузке. Ошибочно доставленные товары или вся партия должны быть возвращены отправителю для дальнейшего выяснения причины ошибки.
  Если подсчет кодов КИЗ выполняется сразу на основании накладной на перемещение, то при сканировании кода КИЗ проводится немедленная проверка на его наличие в накладной. Если выяснится, что просканированный код не был отгружен, то есть отсутствует в накладной на перемещение, прием товара с таким КИЗ будет запрещен.
  При экспорте данных подсчета, созданных на основании накладной на перемещение, разрешается переносить данные только в ту накладную, которая была основанием подсчета.
  Принимать товар на основании накладной на перемещение можно несколькими подсчетами. При экспорте данных в накладную на перемещение в ней происходит суммирование информации от каждого выгруженного в нее подсчета.
  

  Резервирование товара документом «Заказ от клиента» в статусе «Согласован».

  
  В прошлых версиях существовала неявная возможность определить количество товара, готового к отгрузке, но еще не отгруженного. Это делалось за счет рассмотрения документов расходная накладная, накладная на перемещение и расход на производство в статусе «Заблокирован» / «Подготовлен», как документов, фиксирующих факт готовности партии товара к отгрузке. Использовать такую нотацию было можно за счет включения функций проверки, в названии которых присутствовали слова «с учетом заблокированных», кроме того, эта нотация использовалась в алгоритме генерации складских требований и для заполнения поля «Готово к отгрузке» в разделах «Остатки» и «Бизнес-анализ».
  В текущей версии неявное определение товаров, готовых к отгрузке, отменено. Статус «Заблокированный» для указанных выше документов теперь используется в единственном смысле, как указание на блокировку документа.
  Для определения подготовленной к отгрузке партии товара в текущей версии используется документ «Заказ от клиента». Изменение статуса заказа от клиента теперь виляет на изменение количества зарезервированного товара.
  В связи с этим внесены следующие изменения:
• Удалены функция проверки 22 «Запрет принятия док., приводящего к отр. остаткам с учетом заблокированных (подготовленных) док.» и функция проверки 60 «Запрет принятия док., приводящего к отр. остаткам с учетом опер. продаж и заблокированных (подготовленных) док.»
• В функции проверки 70 «Контроль отрицательных остатков при простановке оснований» удалена проверка на остатки с учетом заблокированных документов.
• Изменено название функции проверки 44. Вместо «Запрет принятия док., прив. к отр. остаткам на дату док. и с учетом заблокированных (подготовленных) док.» функция получила название «Запрет принятия док., приводящего к отрицательным остаткам на дату док.». Из проверки удален учет количества артикула в документах типа «Расходная накладная», «Накладная на перемещение» и «Расход на производство» в статусе «Заблокирован» / «Подготовлен», как изымающих товар из места хранения.

• Изменен алгоритм автоматической генерации складского требования. При расчете потребностей мест поставки для текущих РЦ и артикула:
  Формула расчета доступного количества:
  [Доступное кол-во на РЦ] = [Остаток РЦ] - [Резерв РЦ] - [В приемке / в пути РЦ] - [Потери РЦ] – [Кол-во из заблокированных накладных на перемещение и расходных накладных, в которых РЦ является местом хранения «Из»]
  заменена формулой:
  [Доступное кол-во на РЦ] = [Остаток РЦ] - [Резерв РЦ] - [В приемке / в пути РЦ] - [Потери РЦ]
  Упразднена формула коррекции текущего запаса:
  [Запас] = [Запас] + [Кол-во из заблокированных накладных на перемещение из РЦ в текущее МХ].
  

• В разделе «Бизнес-анализ» из группы полей «Текущие остатки» удалено поле «Готово к отгрузке».
• Из таблицы раздела «Остатки» удалено поле «Готово к отгрузке».
• Из таблицы окна свойств артикула «Остатки» удалено поле «Готово к отгрузке».
• В накладной на перемещение статус «Подготовлен» получил название «Заблокирован».
• При смене статуса документа «Заказ от клиента» с «Размещен» на «Согласован» или с «Закрыт» на «Согласован» происходит увеличение количества зарезервированного товара на количество артикула в документе. При смене статуса с «Согласован» на «Размещен» или с «Согласован» на «Закрыт» количество зарезервированного количества уменьшается на количество артикула в документе. Влияние документа «Расходная накладная», в основании которой имеется заказ от клиента, не учитывается. Считается, что заказ от клиента закрывается сразу после отгрузки товара.
  В связи с тем, что документ «Заказ от клиента» начал влиять на таблицу остатков, после установки версии требуется запустить полный перерасчет остатков (Административный модуль – База данных – Утилиты – Перерасчет остатков).
  

  Документы. Функция «Упорядочить №№»

  
  В разделах документов с товарной спецификацией есть кнопка «Упорядочить №№», доступная в режиме редактирования в статусе «Черновик». В документах, у которых есть несколько режимов работы, например, в приходной накладной, кнопка «Упорядочить №№» доступна в режиме «Спецификация».
  Функция кнопки позволяет изменить нумерацию строк спецификации. В прошлых версиях было доступно упорядочение нумерации за счет удаления пропусков и повторов. В текущей версии добавлена возможность нумерации строк по их текущему положению:
  
  Текущее положение строк на экране можно менять с помощью сортировки строк по колонкам, например, по названию товара или по артикулу.
  

  Формирование пакета заказов на базе контракта.

  Цены маркетинговых контрактов.

  
  В процессе «Формирование пакета заказов на базе контакта» в случае, когда процесс создан на основании базового контракта, поле спецификации процесса «Маркетинговый контракт» заполняется номером маркетингового контракта и ценой из него, если для артикула спецификации имеется действующий маркетинговый контракт. В предыдущих версиях маркетинговый контракт подбирался по следующему условию – маркетинговый контракт содержит в основании основной контракт и действует на дату поставки из заголовка процесса.
  В текущей версии алгоритм поиска маркетингового контракта учитывает настройку поставщика «цены из контракта на дату ...». Если для поставщика выбрано условие «цены из контракта на дату «Заказа»», то ведется поиск маркетинговых контрактов, действующих на дату заказа из заголовка процесса, если выбрано условие «цены из контракта на дату «Поставки»», то ищутся маркетинговые контракты, действующие на дату поставки.
  

  Исключение из спецификации артикулов, не входящих в номенклатуру места хранения.

  
  В версии Супермаг+ 1.042 при создании процесса «Формирование пакета заказов на базе контракта» в случае, когда процесс создается на базе маркетингового соглашения о поставке, из спецификации процесса перестали исключаться артикулы, не входящие в номенклатуру места хранения. Это было сделано для того, чтобы была возможность включать в заказ для маркетинговых поставок новые, пробные артикулы.
  В текущей версии исключение артикулов управляется настройкой (Административный модуль - База данных – Конфигурация - Заказы поставщикам):
  
  По умолчанию флаг «Для процесса на базе маркетингового контракта не исключать артикулы, не входящие в номенклатуру места хранения» не установлен.
  

  Весы самообслуживания. Загрузка групп PLU.

  
  Для весов самообслуживания с сенсорными экранами для выбора товара реализована возможность использования групп ассортиментов в дополнение к группам номенклатур для загрузки в весы групп PLU. Выбор группы номенклатуры или ассортимента осуществляется в настройках весов на закладке «Свойства модели»:
  
  
  Тип выбранной группы индицируется префиксом: «ном.» - группа номенклатуры, «асс.» - группа ассортимента.
  

  Контроль остатков ТСД. Автоматическая генерация документов.

  
  В предыдущих версиях экземпляр процесса «Контроль остатков ТСД» создавался по инициативе программы ТСД со статусом «не завершен», а завершение процесса и генерация актов потерь и актов обнаружения выполнялись функциями раздела.
  В текущей версии в административный модуль в раздел «База данных» на закладку «Конфигурация» в группу данных «Генерация документов из процесса» добавлен выбор условия генерации актов потерь и обнаружений при создании экземпляра процесса «Контроль остатков ТДС»:
  
  Для процесса можно выбрать условия «Не создавать», «Черновик» и «Принят». По умолчанию установлено условие «Не создавать».
  При выборе условия «Черновик» или «Принят» экземпляр процесса создается с одновременной генерацией актов потерь и обнаружений с указанным статусом. Экземпляр процесса в этом случае получит статус «Завершен».
  

  Контроль зала ТСД.

  
  В перечень модульных ролей добавлена роль «Контроль зала ТСД». Право на роль дает возможность доступа к режиму работы «Контроль в зале» программы «Супермаг Мобайл» в версии для ОС Андроид.
  В Супермаг+ для роли «Контроль зала ТСД» никакого раздела не создано, так как этот режим работы сохраняет результаты в уже имеющиеся разделы «Заказ в торговом зале ТСД» и «Контроль ценников ТСД».
  

  Отгрузка заказа ТСД.

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

  Административный модуль.

  Маркировка. Опция «Учет кодов КИЗ при приемке и отгрузке товаров».

  
  В административном модуле в разделе «База данных» на закладку «Конфигурация» добавлена новая группа данных «Маркировка». В эту группу данных помещен флаг «Учет кодов КИЗ при приемке и отгрузке товаров». По умолчанию флаг установлен.
  
  В текущей версии флаг действует только на работу программы ТСД Супермаг Мобайл Андроид. Если флаг установлен, то в тех режимах работы, в которых происходит подсчет товаров для целей приема или отгрузки, сканирование кода EAN маркируемых артикулов, то есть тех, у которых установлена группа классификатора «Коды ТН ВЭД» с флагом «Маркируемый», будет приводить к запросу сканирования КИЗ каждого экземпляра товара или упаковки товара. КИЗ будут сохраняться в журнале сканирования с контролем его уникальности.
  Если флаг не установлен, то все артикулы обрабатываются, как немаркированные. Их можно идентифицировать, как с помощью EAN кодов, так и с помощью КИЗ, при этом КИЗ не запоминаются и не сохраняются, и разрешается вводить количество товара после его идентификации.
  

  Периоды. Интерфейс страницы.

  
  В предыдущих версиях на закладке «Периоды» раздела «Аналитика» административного модуля выводился журнал закрытий периодов. На каждое закрытие периода могло приходиться несколько записей, если закрытие осуществлялось несколькими процессами. Если на одну дату были закрыты периоды на складе и в производстве, то в журнале также показывались отдельные записи на каждый тип закрытия.
  В текущей версии интерфейс журнала разделен на две закладки «Периоды» и «Журнал». На закладке «Периоды» показывается список закрытий периодов, на закладке «Журнал» - полный журнал событий закрытия периода:
  
  
  В списке периодов отдельным цветом выделяются периоды, которые находятся в процессе работы, то есть закрытия, открытия или обрезки, периоды, которые можно обрезать, и обрезанный период.
  

  Процедура обрезки базы данных.

  
  В процедуру обрезки базы данных добавлено безусловное удаление всех платежных документов и процессов, которые были начаты в обрезаемом периоде.
  В код процедуры добавлено управление количеством объектов, удаляемых одной командой (в одной транзакции). В прошлых версиях удаление выполнялось по одному объекту. Количество объектов, удаляемых одной командой, можно задать в диалоге «Обрезка базы данных», который показывается при нажатии кнопки «Обрезать базу» в административном модуле в разделе «Аналитика» на закладке «Периоды»:
  
  Опция может влиять на скорость выполнения процедуры, в зависимости от конфигурации оборудования и базы данных.
  

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

• Проведена оптимизация процедуры закрытия периода для ускорения ее работы. Оптимизация распространяется на все виды закрытия периода.
• Проведена оптимизация функции простановки оснований товародвижения для ускорения ее работы.
• В разделах документов «Маркетинговые акции», «Обязательства склада», «Акты уценки», «Накладные на перемещение», «Упаковочные листы», «Акты о сортировке» из мастера ввода строки спецификации убрано поле для ввода артикула поставщика. В этих документах нет поставщика и использование артикула поставщика для определения артикула невозможно.
• Ошибка смены статуса Акта производства из-за нулевого количества ингредиента. Ошибка возникает при автоматической генерации актов производства при малой доле ингредиента в продукции, когда расчетное количество ингредиентов меньше тысячной доли единицы изменения (меньше единицы точности). Внесено изменение в проверки, запрещающие нулевое количество в документе со статусом «Принят».
• Экспорт из открытого документа. В прошлых версиях экспортировалась как спецификация, так и часть полей заголовка. В текущей версии экспортируется только спецификация.
  
  Изменения функционала в версии 1.048 сервис пак 1.
  Автоматическая генерация складских требований. Копирование количества в накладные на перемещение.
  Функция проверки «Соответствие приходной накладной и накладной поставщика / УПД»
  Администратор сервера приложений. Информация о сессии. Версия СМ Мобайл.

Автоматическая генерация складских требований. Копирование количества в накладные на перемещение.

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

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

Функция проверки «Соответствие приходной накладной и накладной поставщика / УПД»

В функцию проверки 211 «Соответствие приходной накладной и накладной поставщика / УПД» добавлен контроль соответствия приходной накладной и УДП. В прошлых версиях проверка выполнялась только по отношению к накладной поставщика. Текущее поведение функции описано ниже:
Проверка срабатывает для документа «Приходная накладная» с операцией «Приход» или «Поступление инвентаря», если для поставщика установлен флаг «Приём по накладным поставщика», а в общих основаниях приходной накладной нет ни накладной поставщика, ни УПД.
Если в общих основаниях накладной есть УПД на приход, то все последующие проверки будут выполняться только для УПД на приход. Если в общих основании накладной нет УПД на приход, но есть накладная поставщика, то все последующие проверки будут выполняться для накладной поставщика. Проверка срабатывает для документа «Приходная накладная» с операцией «Приход» или «Поступление инвентаря» при выполнении одного из следующих условий:

• в общих основаниях приходной накладной указано несколько накладных поставщика / УПД;
• накладная поставщика / УПД отсутствует в торговой системе;
• накладная поставщика / УПД находится в общих основаниях других приходных накладных в статусах, отличных от «Черновик»;
• полная сумма накладной поставщика / УПД отличается от значения поля «Сумма по документу поставщика» приходной накладной;
• не совпадают поставщики приходной накладной и накладной поставщика / УПД;
• дата накладной поставщика / УПД не совпадает с датой накладной поставщика из приходной накладной;
• только для накладной поставщика: значение поля «Накладная поставщика» накладной поставщика указано и отличается от значения аналогичного поля приходной накладной;
• только для накладной поставщика: значение поля «Счет-фактура» накладной поставщика указано и отличается от значения аналогичного поля приходной накладной;
• только для накладной поставщика: значение поля «Дата счета-фактуры» накладной поставщика указано и отличается от значения аналогичного поля приходной накладной;
• приходная накладная содержит артикул, отсутствующий в накладной поставщика / УПД, или суммарное количество артикула в приходной накладной больше суммарного количества этого артикула в накладной поставщика / УПД;
• накладная поставщика / УПД содержит артикул, отсутствующий в приходной накладной, или суммарное количество артикула в накладной поставщика / УПД не совпадает с суммарным значением поля «Кол-во по док.» этого артикула в приходной накладной.
  

  Администратор сервера приложений. Информация о сессии. Версия СМ Мобайл.

  
  В интерфейсе администратора сервера приложений на закладке «Сессии» в колонке «Приложение» для программы «Супермаг Мобайл» теперь показывается номер версии программы «Супермаг Мобайл»:
  
  Информация о версии показывается при работе с программами Супермаг Мобайл, начиная с версии 1.6.2389.29 и при работе с программой Супермаг Мобайл Андроид, начиная с версии 2.1.917.23.
  
  
  Изменения функционала в версии 1.048 сервис пак 2.
  Приходные и расходные накладные. Сохранение КИЗ маркированного товара при заполнении спецификации.
  Функция проверки «Контроль количества КИЗ».
  Функция проверки «Контроль совпадения КИЗ приходной накладной и накладной поставщика»
  Почтовый модуль. Фильтр УПД XML/JSON. Файл ответа на прием поставки.
  Системные дополнительные характеристики товара.
  Карточки складского учета. Пищевая ценность.
  Формат «Яндекс. Еда» сервера обмена данными. Изменение в протоколе обмена.

Приходные и расходные накладные. Сохранение КИЗ маркированного товара при заполнении спецификации.

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

КИЗ, сохраненные в спецификации, не редактируются. Если необходимо удалить неверно просканированный КИЗ, необходимо удалить строку спецификации и провести сканирование повторно.
Для маркированных товаров не запрещается редактирование количества в строке спецификации или ввод сканированием EAN кода. Это позволяет проводить доверительный прием маркированного товара. В текущей версии подразумевается, что контроль за правильностью ввода данных ведется административно.
В накладных не выполняется специальная обработка групповых КИЗ и КИЗ с неизвестными EAN кодами. Все EAN коды должны быть определены в системе заранее, а для приема маркированных товаров с групповыми КИЗ надо использовать процессы «Подсчет кодов КИЗ ТСД» или «Прием заказа ТСД».

Функция проверки «Контроль количества КИЗ».

Внесено изменение в алгоритм функции проверки 10 «Контроль количества КИЗ».
Проверка теперь срабатывает только при включенном системном параметре «Учёт кодов КИЗ при приёмке и отгрузке товаров». Если проверка вызывается для приходной накладной, то она срабатывает только для документов с операциями «Приход», «Возврат от покупателя» и «Возврат переданного товара». Если проверка вызывается для расходной накладной, то она срабатывает только для документов с операциями «Продажа», «Возврат поставщику» и «Передача товара».

Функция проверки «Контроль совпадения КИЗ приходной накладной и накладной поставщика»

Название функции проверки 237 «Контроль совпадения КИЗ приходной накладной и накладной поставщика» заменено названием «Контроль совпадения КИЗ приходной накладной и УПД / накладной поставщика».
Внесено изменение в алгоритм функции проверки: проверка теперь срабатывает только при включенном системном параметре «Учёт кодов КИЗ при приёмке и отгрузке товаров» и только для приходной накладной с операциями «Приход», «Возврат от покупателя» и «Возврат переданного товара». В прошлых версиях функция сверяла КИЗ приходной накладной с КИЗ накладной поставщика из общих оснований приходной накладной. В текущей версии, если в общих основаниях приходной накладной есть УПД на приход, то КИЗ приходной накладной сверяются с КИЗ УПД на приход. Если вместо УПД на приход в основании имеется накладная поставщика - то с КИЗ накладной поставщика.

Почтовый модуль. Фильтр УПД XML/JSON. Файл ответа на прием поставки.

В файле ответа с результатом приема поставки по УПД на приход (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» получал следующее значение:

• коэффициент пересчета в альтернативную единицу измерения «килограмм», умноженный на 1000 (то есть, вес в граммах),
• или коэффициент пересчета в альтернативную единицу измерения, для которой «килограмм» является базовой, с пересчетом в килограммы и умножением на 1000 (то есть, вес в граммах),
• в противном случае, значение 1.
  В текущей версии тэг «quantum» заполняется значением дополнительной характеристики карточки «Минимальное количество заказа в интернет-магазине». Если значение характеристики для артикула не задано, то тэг заполняется значением «1».
  Тэг «unit» заполняется значением «MLT», если карточке товара назначена единица измерения «литр» (или производная от нее единица измерения) или альтернативная единица измерения «литр» (или производная от нее единица измерения). В противном случае тэг «unit» заполняется значением «GRM».
  Тэг «value» получает:
• значение коэффициента пересчета в альтернативную единицу измерения «килограмм» умноженное на 1000 (то есть, вес в граммах),
• или значение коэффициента пересчета в альтернативную единицу измерения, для которой «килограмм» является базовой, с пересчетом в килограммы и умножением на 1000 (то есть, вес в граммах),
• значение коэффициента пересчета в альтернативную единицу измерения «литр», умноженное на 1000 (то есть, объем в миллилитрах),
• или значение коэффициента пересчета в альтернативную единицу измерения, для которой «литр» является базовой, с пересчетом в литры и умножением на 1000 (то есть, объем в миллилитрах),
• в противном случае, значение«1».
  При выгрузке информации по запросу «Список продуктов с указанием их остатков» оперативно доступные остатки артикула для указанного места хранения берутся либо из таблицы текущих остатков, либо из таблицы статистики остатков. Объект «Статистика по текущим остаткам» содержит данные об остатках мест хранения, обслуживаемых в других базах данных. Эта информация приходит в базу данных по почте.
  Выбор источника данных выполняется следующим образом. Если место хранение локальное в текущей базе данных и у него не отключен перерасчет остатков, то остатки берутся из таблицы текущих остатков, в противном случае - из таблицы статистики остатков.
  
  Изменения функционала в версии 1.048 сервис пак 3.
  Контрагенты. Опция «Проставлять цены в приходные накладные».
  Условие доверительного приема маркированного товара при сравнении цен с УПД на приход.
  Функция проверки «Доверительный приём без подсчёта КИЗ». Описание функции.
  Отсылка подтверждения приема маркированного товара при расхождении в ценах.
  Приходные накладные.
  Мастер создания нового документа. Выбор документов поставщика.
  Проверка прав пользователя при заполнении спецификации данными из УПД на приход или накладной поставщика.
  Сервер приложений. Внутренний TCP-порт службы «Сервер приложений Супермага».
  Административный модуль. Алгоритм поиска последнего прихода.
  Алгоритм автоматической генерации заказа «Стандартный», «Fresh».
  Контракты с поставщиком. Беларусь. Алгоритм калькулятора для цен без налогов.

Контрагенты. Опция «Проставлять цены в приходные накладные».

В разделе «Контрагенты» изменен интерфейс вкладки «Поставщик». Из нее убраны опции, связанные с особенностями приема поставки. Эти опции перенесены в новую закладку «Условия поставки»:


На вкладке «Условия поставки» изменена опция «Проставлять цены в приходную накладную».
В текущей версии добавлен выбор источника цен

• из контракта с поставщиком
• из УПД на приход / накладной поставщика
  При выборе условия «из УПД на приход / накладной поставщика» доступен дополнительный флаг: При отклонении цены документа поставщика от условий контракта проставлять цену из контракта.
  В предыдущих версиях было предусмотрено проставлять цены автоматически только из контракта с поставщиком. При выборе опции «Проставлять цены в приходную накладную - из УПД на приход / накладной поставщика» цены берутся из УПД на приход из основания приходной накладной или, при отсутствии УПД на приход, из накладной поставщика из основания приходной накладной. Если в основании приходной накладной нет ни УПД на приход, ни накладной поставщика или в этих документах отсутствует артикул из спецификации приходной накладной, цена такого артикула будет нулевой.
  После простановки цен выполняется их пересчет калькулятором для согласования с выбранным режимом округления.
  Если дополнительно выбрана опция «При отклонении цены документа поставщика от условий контракта проставлять цену из контракта», то проставляемая цена сверяется с ценой из подходящего контракта с поставщиком. Если обнаруживается расхождение с условиями контракта, то вместо цены из УПД на приход / накладной поставщика проставляется цена из контракта. Обязательным условием поиска расхождения с ценой контракта является заполнение полей занижения / завышения эталонной цены. Если эти поля пустые, то считается, что цена контракта является необязательной.
  В случае отсутствия артикула в УПД на приход / накладной поставщика его цена принимается равной нулю и дальше проводятся те же действия по сравнению с ценой контракта, как если бы этот артикул был в спецификации УПД на приход / накладной поставщика.
  

  Условие доверительного приема маркированного товара при сравнении цен с УПД на приход.

  
  Под доверительным приемом маркированного товара понимается прием без подсчета кодов КИЗ, когда предполагается, что данные поставщика, указанные в УПД на приход, верны. Для того чтобы можно было принять товар доверительно, перечень принятого товара и его количество должны совпадать с данными УПД. Если имеются расхождения, то поставщику необходимо передать полную информацию о принятом товаре, для чего необходимо провести подсчет всех принятых кодов КИЗ.
  В текущей версии перечень условий, когда возможен доверительный прием, дополнен проверкой цены товара. Это означает, что в случае, если количественные параметры принятой поставки совпадают с данными документа поставщика, но цены не совпадают, поставщику должна быть отправлена информации о расхождениях в данных принятой поставки и УПД на приход.
  

  Функция проверки «Доверительный приём без подсчёта КИЗ». Описание функции.

  
  Описание функции проверки 236 «Доверительный приём без подсчёта КИЗ» приведено в соответствие с ее алгоритмом.
  Из описания убраны следующие условия срабатывания
• «приходная накладная не является результатом процесса «Подсчёт кодов КИЗ ТСД»».
• «в основании приходной накладной есть накладная поставщика в статусе «Принят» с заполненным полем «Собственный идентификатор участника обмена УПД» (т.е. накладная поставщика является УПД)».
  В описание добавлено условие срабатывания для случая, когда в общих основаниях накладной есть УПД на приход в статусе «Принят»:
• «ценовые параметры (цена / сумма полная, цена / сумма без налогов, ставка НДС, сумма НДС) каждого артикула в приходной накладной и УПД на приход совпадают».
  

  Отсылка подтверждения приема маркированного товара при расхождении в ценах.

  
  В прошлых версиях приходная накладная с маркированным товаром могла не содержать КИЗ только в случае доверительного приема, когда весь товар принимается полностью и когда подсчет кодов КИЗ пропускается по причине доверия данным поставщика. Результатом является отсылка файла подтверждения приема с кодом 1 – поставка принята полностью.
  В текущей версии попытка доверительного приема может завершиться отказом из-за несовпадения цен приходной накладной с ценами УПД на приход. В этом случае файл подтверждения должен содержать всю спецификацию принятого товара, включая полный перечень КИЗ.
  В алгоритм отсылки подтверждения приема поставки на основании УПД на приход внесено следующее изменение: при заполнении спецификации принятого артикула в файле ответа коды КИЗ берутся из приходной накладной, если они там есть. Если в приходной накладной кодов КИЗ для артикула нет, а количество артикула в приходной накладной и УПД на приход совпадает, то коды КИЗ берутся из УПД на приход, если они там есть.
  Если в УПД на приход или приходной накладной одному артикулу соответствует несколько строк, коды КИЗ могут быть размещены в строках подтверждения приема произвольно.
  

  Приходные накладные.

  Мастер создания нового документа. Выбор документов поставщика.

  
  В текущей версии диалог выбора заказа поставщику – основания накладной заменен на диалог с возможностью просмотра спецификации заказа внизу диалогового окна:
  
  Диалог для выбора накладной поставщика или УПД на приход, имеющих в основании выбранный заказ поставщику, также заменен на диалог с возможностью просмотра спецификации заказа внизу диалогового окна:
  
  

  Проверка прав пользователя при заполнении спецификации данными из УПД на приход или накладной поставщика.

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

  Сервер приложений. Внутренний TCP-порт службы «Сервер приложений Супермага».

  
  В предыдущих версиях сервер приложений Супермаг+ использовал для внутренних нужд межпоточного взаимодействия TCP-порт и соответствующие механизмы. В текущей версии для межпоточного взаимодействия используется механизм .Net Remoting и внутренний TCP-порт более не используется. Соответствующая строка убрана из диалога «Настройка TCP портов всех служб» администратора служб Супермага:
  
  

  Административный модуль. Алгоритм поиска последнего прихода.

  
  В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Документы» можно задать условие поиска последнего прихода для простановки цен в документы инвентаризации и прочие документы:
  
  В текущей версии перечень вариантов поиска последнего прихода дополнен условием:
  «Искать приход в место хранения документа, его старшее место хранения и подчиненные старшему месту хранения локальные склады. Если приход не найден - искать приход в любое место хранения.»:
  
  Условие влияет на поведение функций «Заполнить документ ценами последнего прихода» / «Проставить цены».
  

  Алгоритм автоматической генерации заказа «Стандартный», «Fresh».

  
  Внесено изменение в процедуру генерации заказов по алгоритму «Стандартный» в части поиска количества заказа.
  В прошлой версии при округлении вычисленного количества заказа до размера упаковки поставки использовалась следующая формула:
  [Кол-во заказа] = [Размер упаковки] * округленное по математическим правилам отношение ( [Кол-во заказа] / [Размер упаковки] )
  [Кол-во заказа] = 0
  и ( ([Остаток на день ближайшей поставки] < [Мин. уровень] и [Мин. уровень] <= 0.6 * [Размер упаковки])
  [Кол-во заказа] = [Размер упаковки]
  да

В текущей версии используется следующая формула:
[Кол-во заказа] = [Размер упаковки] * округленное по математическим правилам отношение ( [Кол-во заказа] / [Размер упаковки] )
[Кол-во заказа] = 0
и ( ([Остаток на день ближайшей поставки] < [Мин. уровень] и [Мин. уровень] <= 0.6 * [Размер упаковки])
или [Остаток на день следующей поставки] <= 0 )
[Кол-во заказа] = [Размер упаковки]
да

Дополнительное условие: «или [Остаток на день следующей поставки] <= 0 )» позволяет избежать ситуации, когда при расчетном количестве заказа меньше половины упаковки из-за округлении до размера упаковки количество заказа обнулится и заказ не состоится, тогда как прогноз остатка на дату следующей поставки показывает, что остаток снизится до нуля раньше, чем наступит поставка.

Контракты с поставщиком. Беларусь. Алгоритм калькулятора для цен без налогов.

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


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

Отличие заключается в том, что в новом графе ведущим полем для расчетов являются поля «Цена производителя» и «Оптовая надбавка», а не поля «Цена производителя» и «Цена без налогов». То есть, в прошлой версии поле «Оптовая надбавка» пересчитывалось при изменении любого из полей «Цена производителя» и «Цена без налогов», в текущей версии вместо этого пересчитывается поле «Цена без налогов» при изменении значения любого из полей «Цена производителя» и «Оптовая надбавка». Кроме того поле «Цена без налогов» теперь не округляется до точности валюты.


Изменения функционала в версии 1.048
Интеграция с сервисом «Яндекс.Еда».
ЕГАИС.
Инвентаризация ЕГАИС. Функция «Заполнить журнал марками поштучного учета».
ТТН ЕГАИС. Отсылка документов по почте.
Запрос остатков ЕГАИС по расписанию.
Акт списания / постановки на баланс ЕГАИС. Интерфейс документа.
УПД на отгрузку.
Интерфейс.
Почтовый обмен
УПД на приход.
Поле «УПД. Состояние обмена» в приходных накладных.
Структура данных «УПД на приход».
Использование УКД при приемке товара по УПД.
Интерфейс УПД на приход после коррекции УКД.
Экспорт в накладную поставщика.
Приходная накладная.
Функция «Заполнить документ ценами из УПД на приход»
Экспорт в накладную поставщика.
Накладная поставщика. Редактирование содержания.
Карточки складского учета. Фильтр «Склад».
Генерация документов из процесса ТСД
Заказ в торговом зале ТСД.
Произвольный подсчет ТСД. Расход на производство.
Настройка принтеров для печати из ТСД.
Отгрузка заказа ТСД. Доверительная отгрузка укомплектованного заказа.
Административный модуль. Настройка автоматической печати для процессов отгрузки.
Сервер приложений. Количество запросов для базы данных.
Касса. Функциональная роль «Протокол ФФД 1.2»
Функция проверки «Корректность документов «Обязательство склада»»
Функции экспорта для XML пакетов почтового модуля.
Выгрузка в кассу. Налоги, акцизы, алкоголь.
Ассистент Супермаг.+
Перечень исправленных ошибок и улучшений

Интеграция с сервисом «Яндекс.Еда».

В сервер обмена данными добавлен новый формат обмена данных «Яндекс.Еда». Новый формат обмена применим только для адресата типа «Доверительная база». Адресат с таким форматом обмена может быть только один в базе данных. Предполагается, что «Яндекс.Еда» обслуживает заказы всех магазинов базы данных по одному каналу обмена.
Бизнес-процесс, который обслуживает новый протокол обмена, подразумевает, что «Яндекс.Еда» получает от торговой организации перечень мест хранения, для которых покупатели смогут создавать заказы, получает список товаров с их атрибутами, ценами, остатками, изображениями и передает заказы от клиентов.
При работе по протоколу «Яндекс.Еда» сервер обмена данными выступает только в качестве службы. «Яндекс.Еда» выступает в роли клиента и получает или сохраняет информацию по собственной инициативе. В частности, запрос артикулов «Яндекс.Еда» предполагает производить по собственному расписанию.
Для включения формата обмена в работу в базе данных должна быть лицензия на функциональную роль «Сервер обмена данными (API): Яндекс.Еда». Назначать право на работу с функцией какой-либо должности не требуется.
При обмене информацией с клиентом используется протокол авторизации OAuth2. Настройка работы протокола включает задание и передачу клиенту атрибутов «Client ID» и «Client secret». «Client ID» необходимо ввести вручную. Этот атрибут не является секретным. «Client secret» генерируется системой и его необходимо сохранить и передать абоненту конфиденциальным образом. Атрибут показывается один раз в момент генерации и более в интерфейсе не доступен:

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

В интерфейсе задания атрибутов необходимо указать перечень магазинов, для которых покупатели будут создавать заказы, а Яндекс.Еда будет получать цены и остатки.
В элементе «Товары» необходимо указать группу классификатора категорий товаров, выбранную для привязки доступных для сервиса товаров. В ответах на запросы сервиса будут задействованы только те товары, у которых есть привязка к выбранному узлу классификатора категорий.
Флажок «Передавать старую цену» («Не передавать маркетинговую цену») управляет правилом передачи цены. Если флаг не установлен, то передается текущая цена для кассы, какая бы она не была – регулярная или маркетинговая. Если флаг установлен, то в случае, если текущая цена артикула является маркетинговой, будет передана его ближайшая цена из истории цен, превышающая текущую цену.
Опция «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 - Выдача актуального статуса заказа.

Для передачи изображений категорий товаров в раздел «Классификатор категорий товаров» добавлена возможность сохранять картинки для группы классификатора:

ЕГАИС.

Инвентаризация ЕГАИС. Функция «Заполнить журнал марками поштучного учета».

В разделе «Инвентаризация ЕГАИС» имеется функция «Обработать - Заполнить журнал марками поштучного учета». Функция позволяет заполнить журнал инвентаризации ЕГАИС марками из таблиц учета с выбранными ограничениями.
При добавлении марок в журнал для них устанавливается флаг «По факту» либо для марок, имеющихся на собственном поштучном учете, либо для марок, находящихся на учете ЕГАИС.
В текущей версии добавлена опция «Отметку «По факту» не устанавливать для добавляемых марок».
Опция может быть использована, когда при частичной инвентаризации сканируются марки всех экземпляров товаров одного вида и это те марки, которые есть по факту. А те марки, которые добавляются в журнал из выбранного журнала учета, фактически отсутствуют. Их добавление в журнал инвентаризации без отметки «по факту» позволяет в дальнейшем произвести их списание.
Диалог функции теперь выглядит следующим образом:

ТТН ЕГАИС. Отсылка документов по почте.

В разделах «ТТН ЕГАИС на приход» и «ТТН ЕГАИС на отгрузку» в диалоге функции «Разослать по почте» добавлена возможность отсылать отмеченные документы:


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

Запрос остатков ЕГАИС по расписанию.

В административном модуле в разделе «База данных» на закладке «Задания» можно настроить запрос остатков ЕГАИС по расписанию. В прошлых версиях одно задание можно было настроить для запроса остатков для одного ФСРАР ИД и одного типа остатков – либо остатков склада, либо остатков торгового зала.
При использовании одной базы данных для работы множества магазинов для их обслуживания может быть создано большое количество заданий. В текущей версии в задании на запрос остатков можно указать список ФСРАР ИД и для каждого из них выбрать опцию – «Остатки в торговом зале» и / или «Остатки в складе»:

При исполнении задания запросы к ЕГАИС запускаются в заданное время для каждого ФСРАР ИД из списка.

Акт списания / постановки на баланс ЕГАИС. Интерфейс документа.

Акт постановки на баланс склада, прежде чем быть отправленным, требует заполнения данными или из бумажной справки А, или из справки РФУ1 ТТН ЕГАИС на приход. В предыдущих версиях в спецификации акта постановки на баланс были поля «Справка А», «РФУ1», «РФУ2». Поскольку исторически сложилось так, что термины «Справка А» и «РФУ1» воспринимаются как одно и то же, то есть справка РФУ1, то в текущей версии название поля «Справка А» заменено названием «Бумажная справка А». Аналогичное изменение сделано в прочих диалогах и сообщениях.


Примечание: Акты постановки на баланс для разных действий имеют разный интерфейс. Здесь идет речь только об акте постановки на баланс регистра склада.
В интерфейс кнопки «Обработать» добавлена функция «Подобрать справки РФУ1 из ТТН» со следующими опциями:

Функция позволяет найти значение справки РФУ1 в документах ТТН на приход по коду алкогольной продукции. Если в базе данных имеется множество документов с нужным кодом алкогольной продукции, то будет выбран номер справки для самого нового документа.
Кроме того, при отсылке акта в ЕГАИС теперь выполняется запрос содержания справки РФУ1, если она не обнаружена в базе данных. Содержание справки используется для корректного заполнения акта постановки на баланс склада.

УПД на отгрузку.

Интерфейс.

Из заголовка документа «УПД на отгрузку» убраны поля Накладная поставщика, Счет-фактура и Дата счет-фактуры. И добавлены поля Номер и Дата расходной накладной и Функция УПД:

Новые поля заполняются только при создании документа, начиная с текущей версии.

Почтовый обмен

Почтовый модуль при отсылке документа «УПД на отгрузку» по протоколу «УПД фильтр» с форматом «XML» может получать и обрабатывать файлы квитанций «APPERAK» такого же формата, как при приеме документа «УПД на приход».

УПД на приход.

В текущей версии используется термин «УКД».
УКД – универсальный корректировочный документ, используется для исправления УПД – универсального передаточного документа.

Поле «УПД. Состояние обмена» в приходных накладных.

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

Список возможных детализаций:

• ответ отослан, ждет подписания
• ответ отослан, Ошибка ЭЦП
• ответ подписан, ждет исправительный УПД.
• ответ подписан, ожидание УКД
  

  Структура данных «УПД на приход».

  
  В текущей версии документ УПД на приход может формироваться, как прежде, то есть в результате приема по почте электронного УПД, а также может создаваться, как результат коррекции ранее принятого УПД на приход при приеме по почте электронного УКД. Для поддержки процесса создания документа в результате коррекции в таблицу расширения заголовка «SMWayBillsExt» добавлены новые поля:
  UtdSuppDoc SMSupplierDoc null - номер УПД (SupplierDoc), на который ссылается УКД (только для документов типа UI с операцией 65 – корректировка).
  UtdDate SMDate null - дата УПД, на который ссылается УКД (только для документов типа UI с операцией 65 – корректировка).
  Поля не имеют отражения в интерфейсе.
  В таблицу спецификации документа SMSpecWE добавлены поля:
  SpecItemUI SMSpecID null, внутренний пункт спецификации из УПД
  DisplayItemUI SMSpecID null,№ п/п из УПД
  QuantityUI SMQuantity null, количество из УПД
  Поля показываются в интерфейсе в том случае, когда документ создан в результате корректировки УПД с номером поставщика «UtdSuppDoc».
  

  Использование УКД при приемке товара по УПД.

  
  В предыдущих версиях была поддержана технология приема товара на основании электронных УПД. Прием поставки мог происходить с предварительным приемом накладной поставщика, которая в этом случае выступает в роли уведомления об отгрузке, и без предварительного приема накладной поставщика, то есть на основании УПД на приход.
  В случае приема на основании накладных поставщика, поставщик формирует УПД по данным переданной ему приходной накладной, то есть по фактическому результату приемки (в случае его согласия). УПД на приход при этом сценарии всегда совпадает с результатом приемки и никогда не требует коррекции.
  При приеме по УПД без предварительного приема накладной поставщика может возникнуть три ситуации: результаты приема полностью соответствуют содержанию УПД, поставка отклоняется и поставка принимается с расхождением. В последнем случае УПД поставщика не соответствует результату приемки и требует коррекции. В прошлых версиях, для получения корректного УПД, использовалась следующая технология: УПД поставщика отклоняется, и поставщику отсылается результат приемки для формирования нового УПД с содержанием, соответствующим фактически принятому товару. После получения корректного УПД он подписывается обеими сторонами и становится юридически действующим документом.
  В этом сценарии полученный товар становится доступен для реализации только после получения и подписания согласованного УПД. Для маркированного товара это условие является обязательным. Его нельзя реализовывать до того, как его поступление не будет зафиксировано в ЦРПТ.
  В текущей версии реализована технология приема по УПД, позволяющая начинать реализацию товара до окончательного согласования состава УПД. Эта технология применима при следующих условиях:
• Фактически принятый товар полностью и корректно описан в УПД. То есть, принята часть содержания УПД и не предполагается, что принят товар, который в УПД не описан. Последнее возможно, когда в УПД указаны неверные КИЗ, то есть, товар соответствует номенклатуре и количеству заказу, но их фактический КИЗ не соответствует перечню, указанному в УПД.
• Поставщик согласен в случае расхождения признать корректность результата приема.
  Последнее условие важно для того, чтобы избежать случая, когда поставщик решит отозвать поставку, тогда как товар уже будет реализован.
  Для того чтобы сценарий можно было реализовать, необходимо подписать УПД поставщика, несмотря на наличие расхождения, тогда его состав будет отражен в ЦРПТ. Далее, необходимо известить поставщика о необходимости присылке УКД для коррекции содержания УПД. В УКД описывается весь список изменений УПД, и после его подписания эти изменения фиксируются в ЦРПТ.
  Перечисленные выше действия можно выполнить, если при расхождении отсылать в ответе о результате приемке код приема «2» и список отклонений.
  Для управления работой сценарием с приемом исправительного УПД или УКД для контрагентов создана системная дополнительная характеристика «ЭДО при приеме с расхождением», которая может принимать значения «Исправительный УПД» или «УКД»:
  
  
  Для выбора сценария работы с УКД при работе с конкретным контрагентом надо задать для него значение характеристики «ЭДО при приеме с расхождением» равным «УКД»:
  
  Если значение характеристики не задано, то считается, что работа с контрагентом ведется по сценарию «Исправительный УПД».
  Схема работы по сценарию «УКД» включает почтовый обмен и функциональное поведение при работе с Торговой системой. Сценарий почтового обмена для работы с УКД реализован в протоколе «УПД фильтр» с форматом «XML» и «JSON». Для формата «ФНС XML» сценарий не реализован.
  Схема работы по сценарию работы с УПД следующая:
• Прием УПД на приход из XML или JSON файла по протоколу «УПД фильтр» с режимом приема «Без накладной поставщика» (при приеме с предварительным приемом накладной поставщика сценарий работы с УКД смысла не имеет). Выполняется так же, как в случае приема по сценарию «Исправительный УПД».
• Прием поставки на основании УПД и создание приходной накладной выполняется так же, как в случае сценария «Исправительный УПД».
• При смене статуса приходной накладной с «Черновик» на «Принят на складе» и при наличии расхождения УПД на приход меняет статус на «Заблокирован» и ставится в очередь отсылки поставщику. В отличие от сценария «Исправительный УПД» в поле «Состояние обмена» УПД на приход будет значение «Расхождение, использование УКД»:
  
• Почтовый модуль при отсылке УПД на приход поставщику формирует файл REPLY результата приемки со значением тэга «RESULT» равным «2» и значение тэга «ANSWERTYPE» равным «УКД». Остальное содержание файла ответа такое же, как в случае сценария «Исправительный УПД». То есть, файл содержит атрибуты УПД на приход и полную спецификацию принятого товара.
• Провайдер пересылает информацию о расхождении поставщику и одновременно подписывает УПД и отправляет его в ЦРПТ, в отличие от сценария «Исправительный УПД», где УПД не подписывается, а отменяется.
• Приходная накладная получает право на смену статуса на «Принят полностью», товар может поступать в продажу.
• Поставщик присылает УКД. Структура документа УКД такая же, как у УПД за исключением следующих изменений:
  Заголовок документа УКД в тэге SMDOCUMENTS должен обязательно содержать тэг
  OPCODE со значением 65. В УПД тэг может быть пропущен, значение операции 64 в этом случае будет проставлено по умолчанию, если оно прописано в XSD-схеме объекта. Код операции - это то, что позволяет отличить УКД от УПД.
  Либо вместо тэга OPCODE можно использовать предметный тэг:
  KNDTYPE со значением 1115133.
  В этом случае в XSD-схеме в тэге OPCODE должно быть выражение:
  <xs:element smimport:Function="Decode(KNDTYPE,1115133,65,64)" name="OPCODE" type="xs:decimal" />
  В тэг SMWAYBILLSEXT заголовка документ в дополнении к данным, которые есть в УПД, надо добавить следующие тэги:
  UTDSUPPDOC – номер УПД, для которого сделан УКД
  UTDDATE – дата УПД, для которого сделан УКД
  UTDFUNCTION – код функции документа, должен быть «КСЧФ»
  Эти тэги должны быть прописаны в XSD-схеме документа UI.
  В таблице спецификации УКД тэг SPECITEM должен содержать номер пункта спецификации УПД, который меняется текущим документом, либо этот тэг может содержать внутренний порядковый номер пункта спецификации УКД, но тогда в спецификации должен быть специальный тэг
  SPECITEMUI – номер корректируемого пункта спецификации УПД.
  Если пункт спецификации полностью не принят, количество в нем должно быть равно нулю. В спецификации УКД перечисляются только те пункты спецификации, которые были изменены. Измененный пункт спецификации передается полностью.
  Все перечисленные выше тэги должны быть определены в XSD-схеме документа UI.
• Почтовый модуль принимает УКД в документ «УПД на приход» с операцией «Коррекция при приемке». При приеме УКД создается новый документ УПД на приход, спецификация которого формируется, как спецификация первичного УПД с коррекцией по данным УКД.
• Содержание вновь созданного документа УПД на приход сверяется с содержанием приходной накладной. В случае расхождения, УПД на приход блокируется, в случае совпадения - получает статус «Закрыт».
• Поставщику отсылается уведомление о подтверждении приема.
• Если приходная накладная имела статус «Принят на складе», то ее статус автоматически меняется на «Принят полностью».
  

  Интерфейс УПД на приход после коррекции УКД.

  
  Если документ УПД на приход имеет операцию «Коррекция при приемке», то в таблице спецификации показываются дополнительные колонки «№ в УПД» - номер пункта спецификации в исходном УПД на приход и «Количество в УПД» - количество по данному пункту в исходном УПД:
  
  

  Экспорт в накладную поставщика.

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

  Приходная накладная.

  Функция «Заполнить документ ценами из УПД на приход»

  
  В приходную накладную в режиме работы «Ценовой» в кнопку «Цены» добавлена функция «Заполнить документ ценами из УПД на приход».
  
  УПД на приход берется из общих оснований приходной накладной.
  

  Экспорт в накладную поставщика.

  
  В разделе документов «Приходная накладная» в функцию «Экспорт документов» кнопки «Обработать» добавлен тип документа «Накладная поставщика».
  При экспорте в накладную поставщика из приходной накладной копируются, в том числе, КИЗ. В другие типы документов спецификация приходно накладной копируется без КИЗ. КИЗ копируется «как есть», без преобразования в нормализованный вид по правилам ЦРПТ.
  

  Накладная поставщика. Редактирование содержания.

  
  В прошлых версиях документ «Накладная поставщика» можно было получить по почте, изменить его статус и удалить. В текущей версии разрешено редактировать документ в статусе «Черновик».
  Создание документа вручную, по-прежнему, не разрешено.
  В перечень информационных полей накладной поставщика добавлены следующие атрибуты:
  
  Контракт с поставщиком ищется по общим правилам поиска подходящего контракта для каждой строки спецификации. Приходная накладная берется из общих оснований накладной поставщика. Если основание найдено не будет, то ищется приходная накладная, в основании которой есть накладная поставщика.
  
  Если в административном модуле параметр «База данных – Конфигурация - Клиент» установлен в значение «7» (параметр «Customer» в таблице SSSysInfo), то для накладной поставщика в режиме просмотра в статусе «Черновик» доступна кнопка «Рассчитать и применить цены»:
  
  Функция «Рассчитать и применить цены» переносит цены из накладной поставщика в приходную накладную, которая является основанием накладной поставщика. Приходная накладная должна быть в статусе «Черновик» или «Принят на склад». Цены переносятся из накладной поставщика, если они не превышают цену контракта, в противном случае в приходную накладную переносятся цены контракта. Приходная накладная после переноса цен переводится в статус «Принят полностью», накладная поставщика переводится в статус «Закрыт». Функция требует права «Прих. накл.: Заполнение спецификации ценами».
  

  Карточки складского учета. Фильтр «Склад».

  
  В разделе карточек складского учета в интерфейсе фильтра на закладке «Склад» название группы атрибутов «Товарный запас» заменено названием «Товарный запас в количестве», что точнее отражает назначение атрибутов.
  Для атрибута «Товарный запас – Максимум» добавлен переключатель «Максимум не установлен». В прошлых версиях при выборе условия поиска карточек с товарным запасом от заданной величины максимума, но без задания конечной величины максимума, в отбор попадали, в том числе, все карточки, у которых максимум товарного запаса не задан.
  В текущей версии если выбрать переключатель «Максимум», но не задавать его значение «до», то будут отбираться карточки с любым установленным значением максимума, превышающим его значение «от». Если выбрать переключатель «Максимум не установлен», то отберутся карточки с неустановленным значением максимума.
  
  

  Генерация документов из процесса ТСД

  Заказ в торговом зале ТСД.

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

  Произвольный подсчет ТСД. Расход на производство.

  
  Для процесса «Произвольный подсчет ТСД» добавлена возможность выбора статуса создаваемого документа с операцией «Расход на производство»:
  
  Можно выбрать статус «Черновик», «Принят в количестве» или «Принят в количестве и ценах». В прошлых версиях документ создавался только в статусе «Черновик».
  При выборе статусов, отличных от «Черновик», необходимо убедиться, что для документов «Расход на производство» настроена автоматическая простановка цен:
  
  В противном случае создание документа завершится ошибкой, и процесс останется незавершенным. После исправления настроек документ можно создать из процесса кнопкой «Генерация документа».
  

  Настройка принтеров для печати из ТСД.

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

  Отгрузка заказа ТСД. Доверительная отгрузка укомплектованного заказа.

  
  В предыдущих версиях процесс «Отгрузка заказа ТСД» был предназначен для приема данных от ТСД о факте формирования поставки, отгружаемой на основании заказа от клиента. Результатом работы процесса является создание расходной накладной. Основное применение заключалось в сборке и немедленной отгрузке партии товаров со склада предприятия оптовым покупателям по заранее сформированному заказу от клиента. Основанием отгрузки являлся документ «Заказ от клиента» в статусе «Размещен».
  В текущей версии процесс, помимо сбора и отгрузки размещенного заказа, позволяет выполнять отгрузку уже укомплектованного заказа в статусе «Согласован». В этом случае программа ТСД возвращает не результат сбора заказа, а факт отгрузки уже собранного заказа.
  В текущей версии процесс «Отгрузка заказа ТСД» позволяет принимать от программы ТСД информацию об отгрузке ранее собранного заказа, создает расходную накладную со статусом, заданным в административном модуле, и переводит заказ от клиента в статус «Закрыт».
  

  Административный модуль. Настройка автоматической печати для процессов отгрузки.

  
  В административный модуль добавлена настройка автоматической печати расходной накладной из процесса «Отгрузка заказа ТСД» для операции «продажа»:
  
  Аналогичное изменение сделано для процесса «Отгрузка перемещения ТСД».
  
  

  Сервер приложений. Количество запросов для базы данных.

  
  В администраторе сервера приложений в параметрах базы данных можно настроить величину максимального количества одновременно исполняющихся запросов. Этот параметр ограничивает количество одновременных запросов к базе данных. Под каждый запрос сервер приложений выделяет память, в том числе для хранения данных запроса. В случае использования 32-х битного сервера приложений большое количество одновременно выполняемых запросов может занять память, превышающую допустимый для приложения размер. Ограничение позволяет обеспечить стабильную работу сервера приложений, но может привести к задержкам в работе ТСД, если их количество превысит установленное ограничение.
  
  В случае использования 64-х битного сервера приложений ограничение на память снимается. Соответственно, параметр теряет свой смысл и может лишь служить причиной неожиданного замедления работы ТСД.
  В текущей версии для 64-х битного исполнения сервера приложений этот параметр упразднен, а количество одновременно исполняемых запросов не ограничено:
  
  

  Касса. Функциональная роль «Протокол ФФД 1.2»

  
  Для раздела «Касса» добавлена функциональная роль «Протокол ФФД1.2»:
  
  Право на роль позволяет работать с ККТ по протоколу ФФД 1.2.
  

  Функция проверки «Корректность документов «Обязательство склада»»

  
  Внесено изменение в функцию проверки 194 «Корректность документов «Обязательство склада»».
  Условие проверки:
  «для локального склада и артикула из спецификации рассматриваемого документа уже имеется другое действующее в то же время обязательство склада в статусе "Принят", среди мест поставки которого есть места поставки рассматриваемого документа.»
  Заменено следующим условием:
  «для артикула из спецификации рассматриваемого документа уже имеется другое действующее в то же время обязательство склада в статусе "Принят", среди мест поставки которого есть места поставки рассматриваемого документа.»
  Изменение внесено для соблюдения следующего требования, декларированного в версии 1.028.1:
  «при автоматическом заказе или расчете складского требования каждый магазин может иметь только один локальный склад в качестве поставщика заданного артикула в каждый момент времени. Или, другими словами: несколько локальных складов могут поставлять один и тот же товар, но в разные магазины, или иметь поставки в один и тот же магазин, но разных товаров»
  

  Функции экспорта для XML пакетов почтового модуля.

  
  В редактор XML схем почтовых объектов добавлены следующие функции для экспорта данных:
  CardMeasurementAbbreviation- Возвращает краткое название единицы измерения по артикулу
  Атрибуты функции: Артикул.
  DocDate - Возвращает дату документа торговой системы
  Атрибуты функции: Тип документа, Идентификатор документа.
  Последняя функция может быть использована для получения даты документа, находящегося в общих основаниях пересылаемого документа.
  

  Выгрузка в кассу. Налоги, акцизы, алкоголь.

  
  В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Касса» имеется возможность управлять выгрузкой налогов в кассу.
  В прошлых версиях атрибут «Налоги для артикулов» мог принимать значения «Ставка налогов», «Налоговая группа» и «Не выгружать». Первые два значения управляли видом выгрузки налогов – по Российскому законодательству с передачей ставок налогов или по Украинскому законодательству с передачей буквенных кодов налоговой группы артикула. Эти значения атрибута использовались, в том числе, для управления интерфейсом раздела «Редактор налогов».
  В текущей версии добавлен новый атрибут «Законодательство для кассы», который может принимать значения «Россия / Беларусь» или «Украина». Этот атрибут теперь управляет правилами выгрузки, зависящими от законодательства, и интерфейсом раздела «Редактор налогов». Атрибут «Налоги для артикула» принял вид флажка и теперь управляет необходимостью выгрузки налогов. Если флажок снят, то налоги в кассу не выгружаются:
  
  
  В драйвер касс УКМ4 XML внесено следующее изменение при выгрузке данных в кассу:
  Если атрибут «Законодательство для кассы» имеет значение «Украина», то в файле «updateItems»:
• Тэг «SubExcise» всегда заполняется значением «0», независимо от значения флага «Акцизный товар» в карточке товара.
• Тэг «egaisType» устанавливается в значение «5», если для артикула установлен флаг «Акцизный товар», или «0», если не установлен.
  

  Ассистент Супермаг+.

  
  В административный модуль для модуля «Сервер обмена данными» добавлено новое функциональное право «Сервер обмена данными (API): SmAssistant».
  Право позволяет использовать мобильное приложение «SMAssistant» для получения оперативной информации о работе магазина:
• Выручка (текущая + детализация по часам, за вчерашний день, за неделю назад).
• Средний чек (текущий, за вчерашний день, за неделю назад).
• Количество чеков продаж (текущее + детализация по часам, за вчерашний день, за неделю назад).
• Количество ожидаемых и принятых поставок + детализация по количеству позиций и количеству товаров в поставке.
  Информация запрашивается и получается из сервера обмена данными по протоколам REST API с авторизацией по протоколу OAuth2 с типом авторизации «Password».
  Сервер обмена данными не требует предварительной настройки для работы с приложением SMAssistant. Для работы достаточно, чтобы пользователю, который хочет авторизоваться в приложении, были даны права на использование функциональной роли «Сервер обмена данными (API): SmAssistant».
  

  Перечень исправленных ошибок и улучшений

• Оптимизирована процедура генерации кассовых документов. Процедура работала не оптимально, когда в кассовых чеках имелся значительный объем информации об алкогольных марках, КИЗ или продавцах-консультантах.
• Сервер обмена данными. Не выполнялось повторное соединение с базой данных после рестарта БД.
• Работа с программой ТСД. Добавлена функция для проверки активности базы данных и места хранения ТСД. Функция позволяет убыстрить старт работы с ТСД при большом числе локальных мест хранения и медленной работы БД.
• Для получения картинок из программы ТСД от пользователя требовались права на модуль «Администратор сервера приложений».
• В разделе карточек складского учета, если при первом старте раздела зайти в фильтр на закладке Склад и нажать «Применить», то выполнялся отбор артикулов с неустановленными флагами «Маркировка товара» EAC, CTM, KVI.
  
  Изменения функционала в версии 1.049 сервис пак 1.
  Обработка КИЗ весового маркированного товара в накладных.
  Формирование кода ОСУ для весового товара.
  Приходная накладная. Функции «Заполнить документ ценами из УПД на приход», «Заполнить документ ценами из накладной поставщика».
  Условия автоматической генерации УПД на отгрузку.
  Функция проверки «Соответствие приходной накладной и УПД / накладной поставщика»
  Прием по заказу ТСД. Прием по нескольким заказам с одинаковыми артикулами.
  Почтовый фильтр УПД XML.
  Функция ArticleByBarcode.
  Функция ArticleByBarcodeUI.
  Прием КИЗ в тэгах MARKCODE и PACKAGECODE.
  Закрытие заказа от клиента при смене статуса расходной накладной.

Обработка КИЗ весового маркированного товара в накладных.

В предыдущих версиях была реализована возможность сканировать КИЗ маркированных товаров при вводе данных в спецификацию накладных с одновременным сохранением КИЗ в спецификации документа. Алгоритм обработки КИЗ был рассчитан на идентификацию артикула и его количества по значению штрихового кода EAN, который может быть извлечен из КИЗ. Алгоритм имел ограничение – он не позволял корректно принимать маркированные весовые товары. Для маркированных весовых товаров EAN из КИЗ не определяет реальное количество идентифицируемого товара, а лишь обозначает, что данный экземпляр товара прошел процедуру маркировки.
В текущей версии при разборе КИЗ в накладных для весовых товаров считается, что количество товара определить по КИЗ невозможно и для данного сканирования оно устанавливается в значение 0. То есть при сканировании КИЗ весового товара происходит идентификация товара, сам КИЗ добавляется в спецификацию документа с количеством 0 и количество товара не увеличивается. Его в этом случае надо проставлять вручную, определив вес либо взвешиванием товара, либо из информации на этикетке товара.
Аналогичное изменение внесено в программу Супермаг Мобайл для ОС Андроид, начиная с версии 2.2.123.23, за тем исключением, что в программе Супермаг Мобайл вес необходимо вносить для каждого сканирования, и он фиксируется в журнале программы, как количество, идентифицируемое КИЗ.

Формирование кода ОСУ для весового товара.

При отсылке УПД на отгрузку и при отсылке файла подтверждения приема для товаров с объемно-сортовым учетом формируется код ОСУ. Для штучных артикулов количество кодов КИЗ в ОСУ коде принимается равным количеству отгружаемого / принятого товара.
Для весового товара в текущей версии количество отгружаемых / принимаемых кодов КИЗ определяется по количеству кодов КИЗ в спецификации накладной.
Для корректного формирования документов при отгрузке или приеме весовых товаров с объемно-сортовым учетом необходимо в обязательном порядке сканировать все коды КИЗ отгружаемых или принимаемых товаров. Иного способа узнать, сколько кодов КИЗ отгружается или принимается, кроме как просканировать и зафиксировать все коды КИЗ в накладной, в текущей версии не существует.

Приходная накладная. Функции «Заполнить документ ценами из УПД на приход», «Заполнить документ ценами из накладной поставщика».

В предыдущих версиях функции «Заполнить документ ценами из УПД на приход», «Заполнить документ ценами из накладной поставщика» переносили в приходную накладную полную цену, после чего выполнялся перерасчет цен и сумм в документе в соответствии с его режимом округления.
В текущей версии в накладную переносятся цена без налогов и полная цена, и при расчете принимается во внимание изменение той цены, которая соответствуют режиму округления приходной накладной.
Изменение внесено для того, чтобы исключить расхождения в ценах и суммах документов, которые возникают из-за округления величин до точности валюты.
В случае несовпадения режимов округления в приходной накладной и УПД на приход / накладной поставщика, расхождение все равно может возникнуть, из-за разного алгоритма округления цен и сумм.

Условия автоматической генерации УПД на отгрузку.

В текущей версии внесены следующие изменения в условия автоматического создания УПД на отгрузку при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью».
УПД на отгрузку может быть создана только для расходной накладной с операцией «Продажа», «Возврат поставщику» или «Передача товара» при условии установки опции «Учет кодов КИЗ при приемке и отгрузке товаров» в административном модуле.
Добавлено дополнительное условие формирования УПД на отгрузку: УПД создается, если в накладной есть артикулы, относящиеся к группам классификатора ТН ВЭД с флагом «маркируемый». Это условие позволяет автоматически создавать УПД на отгрузку, когда в расходной накладной нет кодов КИЗ для маркированного товара по причине того, что он относится к товарам с объемно-сортовым учетом.

Функция проверки «Соответствие приходной накладной и УПД / накладной поставщика»

В функцию проверки 211 «Соответствие приходной накладной и УПД / накладной поставщика» условие
«для накладной поставщика / УПД задан номер документа поставщика (поле "Накладная поставщика" / "Номер УПД"), который отличается от значения поля "Документ поставщика" приходной накладной»
теперь действует и для накладной поставщика и для УПД на приход. В прошлой версии условие действовало только в случае, когда в основании приходной накладной находилась накладная поставщика.

Прием по заказу ТСД. Прием по нескольким заказам с одинаковыми артикулами.

В прошлых версиях была реализована возможность принимать поставку по нескольким заказам одновременно как одну поставку с последующей генерацией приходных накладных по одной на каждый принимаемый заказ. Эта возможность была ограничена условием вхождения одного артикула в один заказ. Если артикул встречался более чем в одном заказе, прием по такой группе заказов не разрешался.
В текущей версии разрешено принимать поставку по группе заказов, в которых встречаются одни и те же артикулы. Чтобы воспользоваться такой возможностью, необходимо использовать программу Супермаг Мобайл, начиная с версии 1.6.2491.24 для ТСД с ОС Windows CE/Mobile, или начиная с версии 2.2.121.24 для ТСД с ОС Андроид.
При генерации приходных накладных в случае приема по нескольким заказам, количество принятого товара распределяется по накладным таким образом, чтобы не превысить количество заказа.

Почтовый фильтр УПД XML.

Функция ArticleByBarcode.

В функцию ArticleByBarcode внесено следующее изменение: если поиск артикула по штриховому коду из спецификации XML-документа не привел к успеху, то из штрихового кода удаляются лидирующие нули и выполняется повторный поиск артикула.
Изменение внесено по той причине, что в качестве EAN кодов могут быть указаны 14 символьные GTIN, то есть коды из КИЗ, которые представляют собой EAN коды, дополненные спереди нулями до 14 символов.

Функция ArticleByBarcodeUI.

В функцию ArticleByBarcodeUI внесено такое же изменение, как в функцию ArticleByBarcode, а также добавлена возможность распознавать артикул по коду ОСУ. Для этого в перечень параметров функции добавлено поле osuCode:

Прием КИЗ в тэгах MARKCODE и PACKAGECODE.

В предыдущих версиях была реализована возможность принимать КИЗ, как в теге 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 пакетов.

В текущей версии, при создании почтовым модулем XML файлов, в тэге PACKAGE дополнительно указывается атрибут SMVersion. В тэге прописывается текущая версия Супермаг+. Например:
<PACKAGE name="220927161028_9725_11" SMVersion="1.049 SP2">

УПД фильтр. Опция «Сохранять копию (.bak) при отсылке».

В настройки почтового модуля для УПД фильтра добавлена опция «Сохранять копию (.bak) при отсылке». По умолчанию флаг не отмечен.
Если флаг отметить, то при отсылке пакетов по протоколу «УПД фильтр» копии отсылаемых файлов будут сохраняться в подкаталоге LOG каталога исходящих сообщений с расширением .bak.
Опция может быть полезна в тех случаях, когда провайдер забирает файлы пакетов в автоматическом режиме, но требуется знать точное содержание переданных файлов, например, в случаях разногласий с провайдером или контрагентом в интерпретации содержания отосланных пакетов. При использовании опции необходимо следить за размером дискового пространства и периодически удалять ненужные файлы.

УПД фильтр. Формат данных XML. Содержание файла ответа с результатом приемки.

В файл ответа с результатом приемки добавлен тэг CREATEDATWI, который содержит дату приходной накладной. Например:
<CREATEDATWI>2022-09-27</CREATEDATWI>
Дата приходной накладной соответствует понятию «дата приема товара» и может не совпадать с датой УПД на приход.
В файл ответа также добавлен тэг SUPPLIERCORRECTINVOICE. Тэг содержит номер коррекции, на которую сформирован ответ. Например:
<SUPPLIERCORRECTINVOICE>1</SUPPLIERCORRECTINVOICE>

Заказ от клиента. Поле «Артикул ценника».

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

Формирование пакета заказов на базе контракта. Остаток собственного поставщика.

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

Алгоритм автоматической генерации заказа.

В алгоритмах автоматической генерации заказа «Стандартный» и «Fresh» изменен алгоритм округления количества заказа до размера упаковки. Теперь количество упаковок заказа всегда округляется в большую сторону.

Изменения функционала в версии 1.049 сервис пак 3.
Расходные накладные.
Поля «ЭДО. № УПД на отгрузку», «ЭДО. дата УПД на отгрузку».
Функция проверки «Корректность накладной для создания УПД на отгрузку».
Создание и сквозная почтовая рассылка УПД на отгрузку.
УПД на приход.
Количество почтовых приемов.
Причина расхождения с приходной накладной.
Приходная накладная.
Поле «УПД. Причина расхождения».
Поиск подходящего УПД на приход при смене статуса приходной накладной.
Обработка УПД на приход при смене статуса приходной накладной.
Функция проверки «Расхождение в составе приходной накладной и УПД на приход».
Простановка цен и режима округления из УПД на приход в приходную накладную.
Почтовый модуль. Функция импорта «ArticleBySupplierCodeUI».
Прием заказа ТСД. Прием по заказу с несколькими накладными поставщика.
Алкогольная декларация.

Расходные накладные.

Поля «ЭДО. № УПД на отгрузку», «ЭДО. дата УПД на отгрузку».

В перечень полей, доступных для добавления в таблицу отобранных документов, добавлены поля «ЭДО. № УПД на отгрузку» и «ЭДО. дата УПД на отгрузку»:

В поле «ЭДО. № УПД на отгрузку» показывается номер документа УПД на отгрузку, созданного на основании расходной накладной.
В поле «ЭДО. дата УПД на отгрузку» показывается дата документа УПД на отгрузку, созданного на основании расходной накладной.
При двойном клике на номере УПД на отгрузку выполняется переход к документу.

Функция проверки «Корректность накладной для создания УПД на отгрузку».

Создана функция проверки 242 «Корректность накладной для создания УПД на отгрузку». Функция срабатывает при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью» и имеет режим работы «Всегда запрет».
Проверке подвергается расходная накладная с операцией «Продажа», «Возврат поставщику» или «Передача товара», если установлен системный параметр «Учёт кодов КИЗ при приёмке и отгрузке товаров» и выполняется одно из следующих условий:

• внешнему контрагенту накладной назначено значение дополнительной характеристики «Идентификатор участника обмена УПД»;
• в спецификации накладной есть хотя бы один код КИЗ;
• в спецификации накладной есть хотя бы один артикул, относящийся к группе классификатора «Коды ТН ВЭД» с признаком «Маркируемый».
  Проверка срабатывает при выполнении одного из следующих условий:
• в спецификации накладной есть позиция с нулевым или неустановленным значением цены без налогов;
• в спецификации накладной есть позиция с неустановленным значением поля «Страна»;
• в спецификации накладной есть позиция с неустановленным значением поля «ГТД», если для страны из этой позиции в справочнике «Страны» установлен признак «ГТД».
  Функция проверки создана для того, чтобы не происходило создание таких документов «УПД на отгрузку», которые не могут быть приняты системой ЭДО.
  

  Создание и сквозная почтовая рассылка УПД на отгрузку.

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

1. При смене статуса расходной накладной из условия создания документа «УПД на отгрузку» исключена проверка наличия в настройках почтового модуля. В предыдущих версиях при отсутствии УПД фильтра почтового модуля, УПД не создавался.

1. В алгоритм сквозной пересылки УПД на отгрузку добавлено ограничение, по которому пересылка в доверительную базу с УПД фильтром осуществляется только, если совпадают значения атрибута документа УПД на отгрузку «Собственный идентификатор участника обмена УПД» и атрибута УПД фильтра почтового модуля «Собственный идентификатор участника документооборота». Если в доверительной базе нет УПД фильтра, а есть иные фильтры, то пересылка документа в них подчиняется обычным правилам.

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

УПД на приход.

Количество почтовых приемов.

В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «Кол-во почтовых приемов»:

В поле показывается количество записей из истории документа с операцией «Изменение почтой». Это количество соответствует количеству почтовых приемов документа.

Причина расхождения с приходной накладной.

В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «Причина расхождения»:

В поле показывается текст с описанием причины, по которой алгоритм сличения УПД на приход и приходной накладной признал, что содержание документов не совпадает. Расхождение в содержании документов приводит к блокировке документа УПД на приход и отсылке поставщику информации о приеме с расхождением.

Приходная накладная.

Поле «УПД. Причина расхождения».

В перечень полей, доступных для добавления в таблицу отобранных документов, добавлено поле «УПД. Причина расхождения»:


Содержание поля аналогично такому же полю в УПД на приход.

Поиск подходящего УПД на приход при смене статуса приходной накладной.

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

Обработка УПД на приход при смене статуса приходной накладной.

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

• если собственный контрагент является неплательщиком НДС, то после агрегации данных по артикулу сверяются только полные суммы
• если собственный контрагент плательщик НДС, то сверяются суммы без НДС, суммы НДС, полные суммы. Цены и ставки НДС не сверяются.
  

  Функция проверки «Расхождение в составе приходной накладной и УПД на приход».

  
  Создана функция проверки 60 «Расхождение в составе приходной накладной и УПД на приход» по умолчанию функция имеет режим работы «отключена». Функция срабатывает при смене статуса приходной накладной с «Черновик» на «Принят на складе».
  Функция проверки предупреждает о ситуации, при которой смена статуса приходной накладной повлечет обработку УПД на приход с ответом поставщику о наличии расхождения.
  Проверке подвергается приходная накладная с операцией «Приход», в общих основаниях которой находится УПД на приход в статусе «Принят». Для сравнения позиции накладной и УПД на приход предварительно группируются по артикулам. Проверка срабатывает при выполнении одного из следующих условий:
• в приходной накладной есть артикул, отсутствующий в УПД на приход;
• в УПД на приход есть артикул, отсутствующий в приходной накладной;
• количество артикула приходной накладной не совпадает с количеством этого артикула в УПД на приход;
• количество артикула в УПД на приход больше нуля и его полная сумма не совпадает с полной суммой этого артикула в приходной накладной;
• если поставщик и собственный контрагент накладной являются плательщиками НДС: количество артикула в УПД на приход больше нуля и его сумма без налогов не совпадает с суммой без налогов этого артикула в приходной накладной;
• если поставщик и собственный контрагент накладной являются плательщиками НДС: количество артикула в УПД на приход больше нуля и его сумма НДС не совпадает с суммой НДС этого артикула в приходной накладной;
• в приходной накладной и УПД на приход есть артикул, не относящийся к группе классификатора ТН ВЭД с признаком "Объемно-сортовой учет", и КИЗ этого артикула из приходной накладной отсутствует в УПД на приход или КИЗ этого артикула из УПД на приход отсутствует в приходной накладной.
  Приме сообщения функции проверки:
  
  Функция проверки может быть полезна в ситуации, когда оператор считает, что прием выполнен полностью и ожидает отсылки подтверждения приема УПД, тогда как спецификации документов не совпадают и будет отослан признак приема с расхождением.
  

  Простановка цен и режима округления из УПД на приход в приходную накладную.

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

  Почтовый модуль. Функция импорта «ArticleBySupplierCodeUI».

  
  В перечень функций для импорта документов из XML файлов добавлена функция ArticleBySupplierCodeUI. Функция определяет артикул товара Супермаг+ по его значению, которое может быть либо артикулом Супермаг+, либо артикулом контрагента, либо штриховым кодом артикула, а в случае, если артикул найден не будет, то также полям с КИЗ или ОСУ кодами товара.
  Аргументами функции являются поля со следующими данными:
  cardCode- Произвольный код товара (артикул Супермага, артикул контрагента или штрихкод)
  inn - ИНН поставщика
  kpp - КПП поставщика (параметр КПП может быть не задан, если в БД есть только один контрагент с указанным ИНН и произвольным КПП)
  markCodes- Список КИЗ
  osuCodes- Список кодов ОСУ
  Названия полей могут быть произвольными. Например, для задания кода товара (cardCode) можно использовать поля прежних схем, такие как BARCODE, SUPPLIERARTICLE. Разные поставщики могут помещать в это поле те данные, которыми они располагают. Функция будет искать артикул последовательно исследуя данные в разных контекстах.
  

  Прием заказа ТСД. Прием по заказу с несколькими накладными поставщика.

  
  В процесс «Прием заказа ТСД» добавлена возможность выполнять прием по одному заказу и по нескольким накладными поставщика этого заказа. Прием выполняется по совокупному списку артикулов и на основании приема создается столько приходных накладных, сколько было принято накладных поставщика и с распределением количества принятого товара в соответствии с количеством в накладных поставщика. Если для какой-либо накладной поставщика не будет принято ни одного экземпляра товара, то для такой накладной поставщика будет создана приходная накладная без спецификации и в статусе «Заблокирован». Это можно использовать для контроля полноты приема товара.
  

  Алкогольная декларация.

  
  Для алкогольной декларации изменилась схема документа 08.xsd. Для типа данных "П000000000003" – «Код вида продукции», в схему были добавлены новые коды продукции. Изменения схемы были добавлены в функцию генерации файлов алкогольной декларации.
  
  
  Изменения функционала в версии 1.049 сервис пак 4.
  ЕГАИС. Подсчет алкоголя ТСД.
  Подсчет упаковок с маркированным алкоголем.
  Экспорт данных в расходную накладную с созданием акта списания ЕГАИС.
  Заказ от клиента. Сохранение марок алкогольной продукции.
  Административный модуль. Периодическое задание «Консолидация заказов поставщикам».
  Почтовый модуль. УПД фильтр.
  Прием УПД на приход. Определение режима округления.
  Прием УПД на приход. Обработка номера документа.
  Прием исправительного УПД на приход или УКД. Управление автоматической сменой статуса приходной накладной.
  Схема файла подтверждения обработки отосланных данных (APPERAK).
  Содержание файла подтверждения приема поставки (UICONFIRM).
  Выгрузка тэгов без значения.
  Сервер обмена данными. Формат «Яндекс. Еда». Изменение в протоколе обмена.
  Сервер приложений. Обмен с программой Супермаг Мобайл.

ЕГАИС. Подсчет алкоголя ТСД.

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

В процесс подсчета алкоголя ТСД, созданного на основании ТТН ЕГАИС, добавлена возможность сканирования кода упаковки алкоголя. Если в ТТН ЕГАИС содержится информации об упаковке, то при сканировании кода упаковки в журнал подсчета добавляются все алкогольные марки, содержащиеся в этой упаковке. Ранее эта функциональность уже была реализована в программе Супермаг Мобайл.

Экспорт данных в расходную накладную с созданием акта списания ЕГАИС.

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

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

Если выбрать продолжение работы, то в расходную накладную будет помещено количество равное количеству у марок подсчета, находящихся на собственном учете, а в акт списания ЕГАИС будут помещены марки, находящиеся на учете в ЕГАИС.

Заказ от клиента. Сохранение марок алкогольной продукции.

В документ «Заказ от клиента» добавлена возможность сохранения кодов марок алкогольной продукции наравне с сохранением кодов марок КИЗ. В текущей версии интерфейса документа алкогольные марки не отображаются. Просмотр алкогольных марок в заказе от клиента будет доступен в версии 1.050.
Для процессов «Комплектация заказа ТСД» и «Подсчет товаров ТСД» (для документа Заказ от клиента) добавлена возможность принимать из программы ТСД информацию о сканированных алкогольных марках.
В сервер приложений добавлены функции, которые позволяют программе ТСД при сканировании алкогольных марок в ходе наполнения заказов проверять их наличие на собственном поштучном учете. Опция доступна при наличии связи и при работе с СМ Мобайл, начиная с версии 2.2.163.37.

Административный модуль. Периодическое задание «Консолидация заказов поставщикам».

В административный модуль добавлено функциональное задание «Консолидация заказов поставщикам». Задание позволяет объединять заказы поставщику в один документ и ставить его в очередь на отсылку в подходящий почтовый ящик типа «Контрагент».
Опции для настройки задания:

• выбор поставщиков, для которых будут обрабатываться заказы,
• флаг постановки консолидированного заказа в очередь на отсылку поставщику.
  
  Задание при своем выполнении отбирает документы «Заказ поставщику» со статусом «Размещен» с датой равной текущей дате. Для каждого контрагента из настроек задания формируются списки с совпадающими значениями следующих атрибутов:
  -Дата заказа.
  -Дата поставки.
  -Место хранения.
  -Заказчик.
  Для каждого списка документов создается новый заказ с совокупной спецификацией обрабатываемых документов. Время поставки нового документа устанавливается в значение «с 00:00 по 23:59», флаг «Учитывать при автогенерации заказа» - в значение «Да», документ переводится в статус «Размещен». Обработанные заказы помещаются в общие основания нового заказа и переводятся в статус «Заблокирован».
  Если в настройках задания установлен флаг «Ставить созданные заказы в очередь на отсылку контрагентам», то для каждого созданного документа ищется почтовый ящик типа «Контрагент», который обслуживает поставщика, и, если такой ящик находится, то документ ставится в очередь на отсылку.
  Задание может быть полезным в случае, когда для одного и того же поставщика создается множество заказов, например, в разных магазинах, но с поставкой на склад (центральный склад), и для удобства работы, как поставщика, так и приемщика, требуется объединить эти заказы в один. Задание позволяет автоматизировать процедуру объединения заказов при условии, что первичные заказы не отправляются поставщику сразу же, как они получают статус «Размещен», и при условии, что первичные заказы принимаются для обработки до указанного момента времени, а созданные после административно аннулируются.
  

  Почтовый модуль. УПД фильтр.

  Прием УПД на приход. Определение режима округления.

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

  Прием УПД на приход. Обработка номера документа.

  
  В код приема данных от поставщика добавлена специальная обработка содержания тэгов Id, SUPPLIERDOC, SUPPLIERINVOICE, в которые помещается значение номера документа. Из строки номера документа удаляются лидирующие и финишные пробелы. Как выяснилось, некоторые контрагенты непреднамеренно искажают содержание строки с номером документа, например:
  <Id>UI249629 </Id>
  <SUPPLIERDOC>249629 </SUPPLIERDOC>
  <SUPPLIERINVOICE>249629 </SUPPLIERINVOICE>
  

  Прием исправительного УПД на приход или УКД. Управление автоматической сменой статуса приходной накладной.

  
  В прошлых версиях при приеме исправительного УПД на приход или УКД , если пришедший документ подтверждал содержание связанной с этими документами приходной накладной, то статус приходной накладной автоматически менялся с «Принят на складе» на «Принят полностью».
  В текущей версии в административном модуле в разделе «База данных» на закладку «Конфигурация» в группу данных «Маркировка» добавлен флаг «Автоматически переводить статус приходной накладной в «Принят полностью» при приеме исправительного УПД / УКД, подтверждающего результат приемки». По умолчанию флаг установлен. Если флаг снять, то при приеме исправительного УПД или УКД, подтверждающих результаты приемки, статус приходной накладной меняться не будет.
  

  Схема файла подтверждения обработки отосланных данных (APPERAK).

  
  XSD-схема файла APPERAK является частью кода обработки этого типа данных и не представлена в виде файла, как в случае с другими типами данных. Соответственно, изменение схемы не может быть выполнено отдельно от изменения программного модуля.
  В прошлых версиях тип данных тэга CREATEDAT схемы был описан, как «Дата» и содержание файла должно было выглядеть, например, так:
  <APPERAK>
  <RESULT>3</RESULT>
  <ID>UI0000000055</ID>
  <CREATEDAT>2021-07-06</CREATEDAT>
  <SENDDATTIM>2021-07-06T12:12:32</SENDDATTIM>
  <EDOID>039a4936-d443-42ea-a6e0-65a3914b40fa</EDOID>
  <CLIENTGLN>4343463463462</CLIENTGLN>
  <ERRORTEXT>Ошибка ЭЦП</ERRORTEXT>
  </APPERAK>
  В текущей версии тип данных заменен на тип «Дата – время» и содержание файла должно выглядеть так:
  <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>
  

  Содержание файла подтверждения приема поставки (UICONFIRM).

  
  В схему файла UICONFIRM.xsd (подтверждения приема поставки по УПД на приход), добавлен тэг COMMENTARY.
  В тэг выгружается значение поля «Комментарий» документа «УПД на приход», которое в процессе приемки заполняется информацией о причине расхождения между результатом приемки и содержанием УПД на приход.
  

  Выгрузка тэгов без значения.

  
  В прошлых версиях тэги без значения могли выгружаться в виде:
  <SHIPPERCLIENTINN>
  </SHIPPERCLIENTINN>
  В текущей версии тэги без данных выгружаются в следующем виде:
  <SHIPPERCLIENTINN />
  

  Сервер обмена данными. Формат «Яндекс. Еда». Изменение в протоколе обмена.

  
  Описание экземпляра товара по запросу актуальной номенклатуры выглядит следующим образом:
  "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.
  

  Сервер приложений. Обмен с программой Супермаг Мобайл.

  
  В сервер приложений добавлен код для поддержки повторных запросов документов со стороны Супермаг Мобайл, когда документы были изменены после их последней загрузки. Поддерживается в программе Супермаг Мобайл с версии 2.2.176.29.
  Для включения этой возможности необходимо в настройках программы СМ Мобайл установить флаг «Обновление информации»:
  
  
  По умолчанию флаг не установлен. При ненадежном соединении в месте проведения работы включать опцию не рекомендуется из-за возможных ошибок обращения к серверу.
  
  Изменения функционала в версии 1.049 сервис пак 5.
  Остатки ЕГАИС. Функция «Отмена запроса поштучных остатков по РФУ».
  Задание «Консолидация заказов поставщикам». Фильтр по местам хранения.
  Приходная накладная. Поиск подходящего УПД на приход при смене статуса накладной.
  Почтовый модуль.
  Прием документа «УПД на приход». Поиск подходящей приходной накладной.
  Схема файла подтверждения обработки отосланных данных (APPERAK).

Остатки ЕГАИС. Функция «Отмена запроса поштучных остатков по РФУ».

Внесено изменение в поведение функции «Отмена запроса поштучных остатков по РФУ». В предыдущих версиях очистка очереди запросов происходила только для случая запроса по всем справкам РФУ. Если запрос делался по выборочному списку справок, очистки очереди запросов не происходило.
В текущей версии изменен алгоритм формирования очереди, что позволило проводить отмену запросов, в том числе для выборочных справок РФУ.

Задание «Консолидация заказов поставщикам». Фильтр по местам хранения.

В интерфейс настройки автоматического задания «Консолидация заказов поставщикам» добавлен выбор перечня мест хранения, для которых будут искаться заказы поставщикам для консолидации:

Приходная накладная. Поиск подходящего УПД на приход при смене статуса накладной.

При создании приходной накладной может сложиться ситуация, когда УПД на приход в момент приема товара еще не получен и не может быть использован в качестве основания прихода. УПД на приход может быть получен в ходе приемки или после ее завершения. Чтобы автоматически привязать УПД на приход к уже созданной приходной накладной в прошлых версиях была создана функция, которая при смене статуса накладной с «Черновик» на «Принят на складе» выполняла поиск УПД на приход. Поиск велся по значению полей «Документ поставщика» и «Дата документа поставщика» из заголовка приходной накладной, которые сравнивались со значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
В текущей версии в алгоритм поиска добавлен поиск УПД на приход по совпадению значений полей «Счет-фактура» и «Дата счета-фактуры» приходной накладной и значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
Изменение алгоритма связано с тем, что УПД на приход может одновременно являться и счетом-фактурой и передаточным документом одновременно. Соответственно, его «Номер УПД» и дата могут быть занесены, как в поля номер и дата документа поставщика, так и в поля номер и дата счета-фактуры приходной накладной.

Почтовый модуль.

Прием документа «УПД на приход». Поиск подходящей приходной накладной.

В текущей версии изменен алгоритм поиска приходной накладной для УПД на приход, который выполняется, чтобы определить был ли выполнен прием поставки по УПД до получения УПД. В прошлых версиях поиск проводился по условию совпадения атрибута «Номер документа поставщика» в приходной накладной с атрибутом «Номер УПД» документа «УПД на приход» и совпадения даты документа поставщика с датой УПД на приход. В текущей версии поиск расширен поиском приходной накладной по совпадению даты и номера счета фактуры из приходной накладной с датой УПД и атрибутом «Номер УПД» документа «УПД на приход».
Изменение внесено по причине использования УПД на приход одновременно в роли счета-фактуры и транспортной накладной, и, соответственно, использованием номера УПД, как номера счета-фактуры при оформлении приходной накладной.

Схема файла подтверждения обработки отосланных данных (APPERAK).

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. Загрузка списка товаров для отображения на экране кассы самообслуживания (пик-листа).

В диалог настройки касс типа «УКМ4 XML» добавлена опция «Для просмотра списка товаров использовать классификатор категорий»:


В опции разрешается выбирать только группы классификатора категорий, которые не являются списками товаров. Группы классификатора выступают в роли пакета пик-листов в терминах УКМ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». Выгрузка второй цены со скидкой.

Для драйверов весов моделей «Falcon» и «DIGI SM-5000 Ethernet» в диалоге «Настройка электронных весов», на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой:



Для корректной печати в этикетке либо одной цены, либо двух цен необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat:

При выгрузке артикулов (PLU) в весы артикулу назначается либо этикетка с одной ценой, либо с двумя ценами. Этикетка с одной ценой назначается всегда, если не выбран вид цены для цены со скидкой. Если вид цены выбран, то артикулу назначается этикетка с двумя ценами, если для него имеется маркетинговая акция по виду цены со скидкой и маркетинговая цена меньше цены для кассы.
По условиям протокола вторая цена выгружается в весы как разница между первой и второй ценой (между ценой для кассы и ценой со скдикой).

Изменения функционала в версии 1.049.1
ЕГАИС.
Остатки ЕГАИС. Функция «Очистка ошибок запросов поштучных остатков по РФУ2».
Отгрузка немаркированного алкоголя со второго регистра без простановки оснований товародвижения.
УПД на отгрузку. Информация о складе разгрузки.
Контрагенты. GLN склада контрагента.
Расходная накладная. GLN адреса разгрузки.
УПД на отгрузку. Транспортный раздел.
УПД на отгрузку. Обмен с провайдером.
Операция «Акт приемки».
Алгоритм создания УПД на отгрузку и реакция на получение акта приемки.
Расходная накладная. УПД. Состояние обмена.
Расходная накладная. Функция «Обработать акт приемки».
Возврат поставщику с формированием УКД для УПД на приход.
Контрагенты. Закладка «ЭДО».
Прием УКД для УПД на приход в статусе «Закрыт» при возврате товара.
Приходная накладная. Поиск подходящего УПД на приход при смене статуса накладной.
Поддержка работы СМ Мобайл.
Контрагенты. Определение цены контракта.
Сервер обмена данными. Аналитический объект «Алкогольные марки упаковки»
Касса Супермаг. Чек для пречека с упаковками маркированного товара.+
Перечень исправленных ошибок и улучшений.

ЕГАИС.

Остатки ЕГАИС. Функция «Очистка ошибок запросов поштучных остатков по РФУ2».

При отсылке запроса кодов марок из регистра №3 ЕГАИС может случиться ошибка отсылки, например, "Проверяемый файл НЕ ВАЛИДЕН. FSRAR_ID документа [030000394897] не совпадает с идентификатором абонента в ключе RSA [030000553302]". Ошибка показывается на закладке поштучного учета в таблице кодов КИЗ в поле «Состояние обмена с ЕГАИС». Если это сообщение уже не нужно, оно всё равно будет показываться и дальше, если ситуация не может быть изменена.
В текущей версии создана функция, которая позволяет очистить сообщения об ошибках, если они больше не нужны.

Отгрузка немаркированного алкоголя со второго регистра без простановки оснований товародвижения.

Для создания ТТН ЕГАИС на отгрузку по данным расходной накладной используется функция «Формирование и отсылка ТТН в ЕГАИС». Функция создает ТТН ЕГАИС и заполняет ее данными из накладной. Часть данных, которые не могут быть получены из накладной, остаются незаполненными и заполняются при нажатии на кнопку «Отослать» в разделе ТТН ЕГАИС. В этот момент выполняется подбор алкокодов для артикулов (если их не удалось однозначно определить по артикулу) и подбор справок РФУ1 и РФУ2.
Для немаркированных алкогольных товаров, если место хранения связано с ФСРАР ИД с учетным регистром «Торговый зал», функция подбора справок РФУ1 и РФУ2 имела следующее поведение:
Если в расходной накладной проставлены основания товародвижения, функция создает акт возврата продукции с регистра торгового зала на регистр склада и заполняет ТТН на отгрузку, используя информацию о справках РФУ1 и РФУ2 из оснований товародвижения. Если основания товародвижения не проставлены, функция пытается списать товар с регистра склада, используя информацию об остатках регистра склада, которые, в том числе, содержат данные о справках. В этом случае показывалось следующее сообщение:

В первом случае (при простановке оснований товародвижения) имеется риск неверного выбора основания, когда товар по выбранному основанию с точки зрения ЕГАИС уже продан, возвращен поставщику или списан с регистра склада по документам ЕГАИС (то есть с указанием справки РФУ1 и РФУ2, продажи по кассе не влияют на эти данные) и его количества по ТТН недостаточно для выполнения операции. Во втором случае требуется предварительно вручную перевести товар со второго регистра на первый, поскольку весь немаркированный алкоголь при поступлении автоматически переводится на второй регистр.
В текущей версии изменено поведение функции, когда основание товародвижения не проставлено. Функция выполняет анализ остатков в торговом зале для определения возможности вернуть товар на первый регистр и подбирает подходящие акты перемещения в торговый зал с учетом ранее сделанных возвратов для того, чтобы выполнить возврат товара на склад с указанием корректных справок РФУ1 и РФУ2. Перед началом выполнения функции показывается следующее сообщение:

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

УПД на отгрузку. Информация о складе разгрузки.

Контрагенты. GLN склада контрагента.

В разделе контрагентов в таблицу складов контрагента добавлено поле «GLN»:

Значение GLN склада контрагента используется для заполнения соответствующего поля заголовка расходной накладной. См. ниже.

Расходная накладная. GLN адреса разгрузки.

В заголовок расходной накладной на закладке «Транспортный раздел» для адреса разгрузки добавлено поле «GLN». При создании документа поле автоматически заполняется значением GLN главного склада клиента:

Также автоматически адрес погрузки заполняется адресом места хранения, а адрес разгрузки - адресом главного склада.
В выпадающем списке адреса разгрузки показывается список складов клиента и его физический и юридический адрес. В прошлых версиях показывались только физический и юридический адреса. Для физического и юридического адресов GLN не задается.

УПД на отгрузку. Транспортный раздел.

В разделе «УПД на отгрузку» в заголовок документа добавлена закладка «Транспортный раздел», в котором размещены данные адреса погрузки и разгрузки, включая GLN адреса разгрузки:


Данные заполняются при создании документа из соответствующих полей расходной накладной.
В XSD схему почтового объекта УПД на отгрузку добавлен тэг SMDOCTRANSPORT, содержащий информацию транспортного раздела.

УПД на отгрузку. Обмен с провайдером.

Операция «Акт приемки».

В заголовок документа УПД на отгрузку добавлено поле «Операция». Для документа, созданного на основании расходной накладной, операция имеет значение «Отгрузка получателю». Для документа, созданного на основании ответа контрагента с результатом приемки (см.ниже), операция имеет значение «Акт приемки»:

Алгоритм создания УПД на отгрузку и реакция на получение акта приемки.

В прошлых версиях УПД на отгрузку создавался при смене статуса расходной накладной с «Отпущен со склада» на «Отпущен полностью». В текущей версии принята логика, при которой статус «Отпущен полностью» должен свидетельствовать о том, что документ утвержден обеими сторонами. В связи с этим УПД на отгрузку теперь создается при смене статуса расходной накладной с «Черновик» на «Отпущен со склада». Это поведение требует, чтобы все атрибуты документа, необходимые для формирования УПД на отгрузку, были заполнены до смены статуса на «Отпущен со склада».
Файл ответа от контрагента с результатом приемки (описывается схемой UDCONFIRM.xsd) в дальнейшем будет называться «Акт приемки».
При получении от провайдера файла с актом приемки с кодом ответа 1 (поставка принята), происходит изменение статуса УПД на отгрузку со «Сформирован» на «Обработан» и, одновременно, меняется статус расходной накладной с «Отпущен со склада» на «Отпущен полностью».
При получении акта приемки с кодом 3 (в приеме поставки отказано) статус УПД на отгрузку устанавливается в значение «Заблокирован», статус расходной накладной не меняется и остается «Отпущен со склада». Решение о смене статуса расходной накладной должен принимать персонал после выяснения обстоятельств отказа. Если это действительно полный отказ от поставки, то статус расходной накладной надо установить в «Заблокирован» после возврата товара на склад. Если речь идет об ошибках оформления УПД, то документ может быть исправлен и заново отослан контрагенту.

При получении акта приемки с кодом 2 (прием с расхождением) на основании акта приемки создается новый документ «УПД на отгрузку» с операцией «Акт приемки», статусом «Сформирован» и спецификацией из полученного от контрагента акта приемки. В основание этого документа ставится расходная накладная. Исходный документ «УПД на отгрузку» с операцией «Отгрузка получателю» получает статус «Заблокирован». Расходная накладная не меняет своего статуса. В дальнейшем персонал должен принять решение о согласии или несогласии с актом контрагента и отослать ему свой ответ. См. ниже «Расходная накладная. Функция «Обработать акт приемки»».

Расходная накладная. УПД. Состояние обмена.

В разделе расходных накладных добавлена возможность выводить колонку «УПД. Состояние обмена» в таблице отобранных документов (см. опции кнопки «Поля…»):

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

Расходная накладная. Функция «Обработать акт приемки».

В раздел расходных накладных добавлена функция «Обработать акт приемки». Функция доступна для документов со статусом «Отпущен со склада» в режиме редактирования. Функция работает, если от контрагента получен акт приемки с расхождением.
В диалоге старта функции имеется возможность посмотреть расхождение и принять или отклонить расхождение:


При нажатии на кнопку «Показать расхождение» выводится детальная информация о расхождении:

При сравнении расходной накладной и акта приемки по каждому артикулу расходной накладной сверяется количество, затем совпадение КИЗ, если они есть, затем сравниваются суммы без налогов, суммы НДС и суммы полные.

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

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

Возврат поставщику с формированием УКД для УПД на приход.

При возврате товара ФНС разрешает вместо УПД на отгрузку возвращаемого товара оформлять возврат в виде корректировки УПД на поставку возвращаемого товара, то есть с помощью УКД к УПД на приход.
Выбор варианта возврата с помощью УПД на отгрузку или с помощью УКД для УПД на приход должен быть заранее согласован с поставщиком и неукоснительно соблюдаться.

Контрагенты. Закладка «ЭДО».

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

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

Прием УКД для УПД на приход в статусе «Закрыт» при возврате товара.

Когда УПД на приход получает статус «Закрыт», прием документов, влияющих на его содержание, прекращается, в том числе запрещается принимать УКД для его коррекции.
Если для контрагента опция «ЭДО при возврате поставщику» установлена в значение «УКД для документа поставки», то теперь разрешается принимать УКД для УПД в статусе «Закрыт» при условии, что дата УКД больше или равна дате УПД. В этом случае считается, что УКД пришел, как подтверждение поставщиком возврата товара.
Внимание! В текущей версии нет контроля того, что УКД для возврата товара действительно пришел, как ответ на формирования расходной накладной на возврат товара. Также нет автомата сличения состава возвращаемого товара и содержания корректирующего документа. Это связано с тем, что на одну расходную накладную на возврат товара может прийти множество УКД для разных приходов, в том числе один и тот же артикул может присутствовать в нескольких УКД.
При получении УКД для закрытого УПД создается новый УПД на приход. Содержание нового УПД формируется на основании предыдущего УПД на приход и корректирующей информации из УКД. Статус нового УПД устанавливается в «Принят», операция - «Коррекция уже принятой поставки». Статус прежнего УПД не меняется.
Оператор может вручную поменять статус нового УПД на приход, то есть согласиться или не согласиться с результатом приема возврата поставщиком. При смене статуса УПД на приход с операцией «Коррекция уже принятой поставки» сличение УПД с приходной накладной не происходит, поскольку приходная накладная не меняется. Ответ для нового УПД отсылается с результатом приемки 1 (УКД принят) или 3 (УКД отвергнут) и без спецификации. Статус прежнего УПД меняется на «Заблокирован», если новый УПД получает статус «Закрыт». Это позволяет принимать последовательно УКД для нескольких возвратов.

Приходная накладная. Поиск подходящего УПД на приход при смене статуса накладной.

При создании приходной накладной может сложиться ситуация, когда УПД на приход в момент приема товара еще не получен и не может быть использован в качестве основания прихода. УПД на приход может быть получен в ходе приемки или после ее завершения. Чтобы автоматически привязать УПД на приход к уже созданной приходной накладной в прошлых версиях была создана функция, которая при смене статуса накладной с «Черновик» на «Принят на складе» выполняла поиск УПД на приход. Поиск велся по значению полей «Документ поставщика» и «Дата документа поставщика» из заголовка приходной накладной, которые сравнивались со значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
В текущей версии в алгоритм поиска добавлен поиск УПД на приход по совпадению значений полей «Счет-фактура» и «Дата счета-фактуры» приходной накладной и значением поля «Номер УПД» из заголовка документа УПД на приход и датой этого документа.
Изменение алгоритма связано с тем, что УПД на приход может одновременно являться и счетом-фактурой и передаточным документом одновременно. Соответственно, его «Номер УПД» и дата могут быть занесены, как в поля номер и дата документа поставщика, так и в поля номер и дата счета-фактуры приходной накладной.

Поддержка работы СМ Мобайл.

В текущей версии внесены следующие изменения в функции, обеспечивающие работу программы СМ Мобайл:

• Запрос текущих остатков теперь возвращает данные из таблицы статистики остатков, если для места хранения, в котором работает ТСД, установлен флаг «Отключить перерасчет остатков».
  Примечание. Содержание статистики по остаткам можно увидеть в разделе «Остатки» при выборе опции фильтра «Статистика». Статистика по остаткам заполняется при приеме почтового объекта «SG». Используется для получения информации об остатках из внешних источников в тех случаях, когда учет остатков по некоторому месту хранения в текущей базе данных не ведется. Информации об оперативных остатках (с учетом оперативных продаж) не содержит.
• Для модуля «Контроль остатков ТСД» Добавлено функциональное право «Контроль остатков ТСД: Просмотр остатков»:
  
  Если право отсутствует, то программа ТСД при работе в режиме «Контроль остатков» не должна показывать остатки проверяемых товаров. Функциональность поддерживается в СМ Мобайл Андроид с версии 2.2.197.29. Право определяется программой в момент начала работы программы, а не соответствующего раздела.
• В Административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Генерация документов из процесса» для процесса «Комплектация требования на отбор ТСД» и документов «Накладная на перемещение» и «Расходная накладная» добавлен выбор статуса «Отправлен» и «Отпущен со склада», соответственно:
  
  При выгрузке результатов подбора товара из ТСД процесс меняет содержание требования на отбор, проставляя в него количество фактически собранного товара и, в соотвествии с настройками административного модуля, может дополнительно создать накладную по содержанию требования на отбор и перевести ее в указанный статус.
• В Административном модуле в разделе «База данных» на закладке «Конфигурация» в группу данных «Маркировка» добавлен флаг «Учет кодов КИЗ при перемещении товаров». По умолчанию флаг не установлен:
  
  Если флаг установлен, то в процессе «Подсчет товаров ТСД» для операции «Перемещение» и в процессе «Отгрузка перемещения ТСД» при генерации накладной на перемещение в него помещаются КИЗ, просканированные в ходе подсчета товаров.
  Программа ТСД при установленном флаге требует обязательного поштучного сканирования КИЗ маркированного товара, не относящегося к ОСУ.
  В процессе «Прием перемещения ТСД» программа ТСД при установленном флаге также требует обязательного поштучного сканирования КИЗ маркированного товара, не относящегося к ОСУ, и дополнительно, при сканировании КИЗ проверяется, что сканируемый КИЗ присутствует в накладной на перемещение (добавлен в нее при отгрузке перемещения).
  При завершении процесса «Прием перемещения ТСД» в документ добавляется отметка для тех КИЗ, которые были приняты.
  

  Контрагенты. Определение цены контракта.

  
  В разделе «Контрагенты» на закладке «Условия поставки» имеется опция «Цены из контракта на дату»:
  
  Опция используется для определения значения цены контракта с учетом истории цен контракта в следующих случаях:
• в функции «Заполнить документ ценами из контракта» приходной накладной,
• в функции проверки 128 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят полностью"»,
• в функции проверки 185 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят на складе"».
  Внимание! Функция «Заполнить документ ценами из контракта с поставщиком» документа «Заказ поставщику» всегда проставляет текущие цены контракта. В документе «Накладная поставщика» в колонках «Цена контракта полная» и «Цена контракта без НДС» и в процессе «Формирование пакета заказов на базе контракта» в колонке «Цена в контракте» также показывается текущая цена контракта.
  В прошлых версиях опция могла принимать значения «Цены из контракта на дату» «заказа» и «поставки». Под датой заказа понималось значение поля «Дата заказа» документа «Заказ поставщику». Если это поле в документе не было заполнено, то датой заказа считалась дата документа «Заказ поставщику». Под датой поставки понималась дата приходной накладной.
  В текущей версии набор опций расширен за счет опций «Цены из контракта на дату» «планируемой поставки» и «отгрузки». Под датой планируемой поставки понимается значение поля «Дата поставки» документа «Заказ поставщику», под датой отгрузки понимается дата УПД на приход из основания приходной накладной или дата накладной поставщика из основания приходной накладной. Основания приходной накладной должны иметь статус отличный от «Заблокирован» или «Черновик».
  Чтобы можно было ориентироваться в этих понятиях в интерфейс раздела контрагентов добавлена краткая помощь, доступная при нажатии кнопки «?»:
  
  
  

  Сервер обмена данными. Аналитический объект «Алкогольные марки упаковки»

  
  В сервер обмена данных добавлен аналитический объект 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=^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>"03000009996110518000000002</span></span>"
  Где 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=^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>"03000009996110518000000002</span></span>"
  Ответ:
  {
    "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#+^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span></span>",
    "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"
                              }
                            ]
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
  Для использования объекта надо в интерфейсе сервера обмена данных поместить объект в перечень разрешенных для запроса и объявить его доступным:
  
  Сервер обмена данных может вернуть содержание упаковки алкогольной продукции только в случае, когда в базе данных имеется ТТН на приход с соответствующей информацией. Если организация имеет распределенную структуру баз данных и весь обмен с ЕГАИС ведется только в старшей базе, то для получения информации об упаковках алкогольной продукции в подчиненных местах хранения необходимо настраивать их обмен с сервером обмена данных старшей базы данных.
  

  Касса Супермаг+. Чек для пречека с упаковками маркированного товара.

  
  Касса Супермаг+ может быть использована для формирования чека по содержанию документа «Заказ от клиента». Для использования заказа от клиента в качестве пречека он должен иметь статус «Согласован». То есть должен соответствовать собранному заказу, готовому для передачи клиенту.
  В прошлых версиях было реализовано добавление в заказ от клиента КИЗ маркированных товаров (см. процессы «Комплектация заказа ТСД» и «Подсчет товаров ТСД» с операцией «Сбор заказа клиента / пречек»), соответственно, в кассе Супермаг+ было реализовано помещение КИЗ в чек при создании чека на основании заказа клиента.
  В прошлой версии в процессах ТСД при создании документа «Заказ от клиента» было дополнительно реализовано сохранение в документе информации об артикуле упаковки, если в ходе комплектации заказа был просканирован КИЗ упаковки.
  Внимание! При продаже по кассе упаковок маркированного товара штрихкод упаковки обязательно должен указывать на артикул упаковки. В противном случае корректное оформление чека невозможно. По правилам ЦРПТ одной единице товара в чеке должен соответствовать один КИЗ.
  Ниже приведен пример документа «Заказ от клиента» с упаковками маркированного товара:
  
  В спецификации документа представлены только базовые артикулы, а артикул упаковки сохранен в поле «Артикул ценника».
  При использовании заказа от клиента, как пречека, касса формирует следующий чек:
  
  
  То есть в строках чека представлены артикулы упаковки и количество строк соответствует количеству КИЗ.
  Цена упаковки вычисляется, как произведение цены из заказа клиента и количества в упаковке. Это обеспечивает совпадение суммы чека и суммы заказа.
  

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

• При создании приходной накладной процессом «Подсчет кодов КИЗ ТСД», если процесс был создан на основании УПД, в накладную не переносился режим округления из УПД на приход.
• При выполнении функции «Обработать – Экспорт» из УПД на приход в накладные (приходные, расходные, перемещение) не копировался собственный контрагент.
• При экспорте из УПД на расход в расходную накладную, накладную на перемещение не копировалась спецификация.
• При экспорте из УПД на расход в приходную накладную возникала ошибка: "ORA-00904: "MANUFACTURERSPRICE": invalid identifier ORA-06512: at "SUPERMAG.DOCREMOTE"
• Исправлена ошибка, которая проявлялась в невозможности ввода в ячейку таблицы больше символов, чем можно было разместить по ширине ячейки. Ошибка проявлялась случайным образом.
• В прошлых версиях при указании в качестве основания товародвижения того же документа, в которое и проставляют основание, показывалась ошибка "check constraint (SUPERMAG.SMCSPECSELFCAUSE) violated". В текущей версии показывается сообщение:
  
• Комплектация требования ТСД. Исправлена ошибка, которая появлялась при попытке добавить в спецификацию комплексный артикул.
  
  Изменения функционала в версии 1.049
  Объемно-сортовой учет.
  Справочник «Коды ТН ВЭД».
  УПД на приход, УПД на отгрузку. Накладные поставщика. Коды объемно-сортового учета.
  Почтовый прием УПД на приход с кодами ОСУ.
  Прием поставки маркированного товара с объемно-сортовым учетом.
  Почтовая отсылка УПД на отгрузку с кодами ОСУ.
  УПД фильтр. Прием и отсылка кодов КИЗ для единиц и упаковок в разных тэгах.
  УПД на отгрузку. Изменение статуса документа.
  Документ «ГТД».
  Накладные. Ввод номера ГТД.
  Интерфейс раздела «Карточки складского учета».
  Сервер обмена данными. Постраничная навигация при запросе данных. Аутентификация.
  Почтовый модуль. Протокол и транспорт «Октопус – сервер заказов».
  Предзаказ от клиента ТСД.

Объемно-сортовой учет.

Объемно-сортовой учет маркируемого товара позволяет в документах передачи товара регистрировать вместо списка кодов КИЗ маркированного товара код, содержащий информацию о количестве кодов КИЗ, то есть код объемно-сортового учета в формате «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 без шифрования» для аутентификации при запросе данных у внешнего сервера.
В текущей версии реализована аутентификация для случая, когда сервер обмена данных выступает в роли сервера:

Для протокола «Внешний [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». Выгрузка второй цены со скидкой.

Для драйверов весов моделей «Falcon» и «DIGI SM-5000 Ethernet» в диалоге «Настройка электронных весов», на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой:



Для корректной печати в этикетке либо одной цены, либо двух цен необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat:

При выгрузке артикулов (PLU) в весы артикулу назначается либо этикетка с одной ценой, либо с двумя ценами. Этикетка с одной ценой назначается всегда, если не выбран вид цены для цены со скидкой. Если вид цены выбран, то артикулу назначается этикетка с двумя ценами, если для него имеется маркетинговая акция по виду цены со скидкой и маркетинговая цена меньше цены для кассы.
По условиям протокола вторая цена выгружается в весы как разница между первой и второй ценой (между ценой для кассы и ценой со скдикой).

НДС 12% в разделах документов (Казахстан).

В разделах документов, где в спецификации имеются колонки со значением суммы НДС, добавлена возможность просматривать суммы по документу (кнопка «Сумма» и выбор полей заголовка по кнопке «Поля») соответствующие ставке НДС 12%, если такое значение ставки будет определено в перечне ставок НДС раздела «Редактор налогов».

Изменения функционала в версии 1.050 сервис пак 2.
ЕГАИС. Отказ от использования второго регистра («Торговый зал»).
Списание кассовой реализации немаркированной продукции.
Функция «Формирование и отсылка ТТН в ЕГАИС» для расходных накладных и накладных на перемещение.
Инвентаризация немаркированной продукции для мест хранения с учетным регистром «Торговый зал».
ТТН ЕГАИС на отгрузку. Выбор кода алкогольной продукции.
Заказ в торговом зале ТСД. Округление количества заказа до упаковки заказа.
Почтовый модуль. Сервер обмена данными. Правила рассылки для доверительных баз с УПД фильтром.
Модель весов DP Wasp.

ЕГАИС. Отказ от использования второго регистра («Торговый зал»).

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

Списание кассовой реализации немаркированной продукции.

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

• Для кассового документа выполняется функция «Списание пива ЕГАИС». Функция создает ТТН ЕГАИС на отгрузку с операцией «Акт списания из торгового зала» для артикулов немаркированной алкогольной продукции. Для артикулов с единственными кодами алкогольной продукции коды сразу проставляются в спецификацию ТТН. Если для всех артикулов будут проставлены коды алкогольной продукции и для всех кодов не будет остатка в торговом зале, то будет создана ТТН с операцией «Акт списания со склада».
  Остаток в торговом зале определяется по колонке «Итого» таблицы остатков ЕГАИС в торговом зале (Остаток – Расход по документам + приход по документам).
• Для ТТН ЕГАИС на отгрузку с операцией «Акт списания из торгового зала» выполняется функция «Подбор кодов алкогольной продукции». Функция определяет коды алкогольной продукции с учетом остатков в торговом зале и для той продукции, для которой остатков не хватает, создает ТТН ЕГАИС на отгрузку с операцией «Акт списания со склада». При создании ТТН в нее переносятся ссылки на артикулы кассового документа с количеством, которое не удалось списать из торгового зала. Коды алкогольной продукции при этом не подбираются и справки РФУ не определяются (для списания со склада необходимо сослаться на справку РФУ2). Подготовленный акт списания из торгового зала можно отправлять в ЕГАИС.
• Для ТТН ЕГАИС на отгрузку с операцией «Акт списания со склада» выполняется функция «Подбор кодов алкогольной продукции». Функция подбирает коды алкогольной продукции и справки РФУ по остаткам склада. Подготовленный акт списания со склада можно отправлять в ЕГАИС.
  

  Функция «Формирование и отсылка ТТН в ЕГАИС» для расходных накладных и накладных на перемещение.

  
  В алгоритм функции «Формирование и отсылка ТТН в ЕГАИС» в разделах расходной накладной и накладной на перемещение, внесено следующее изменение: для немаркированной продукции функция создает перемещение из торгового зала на количество, не превышающее остаток торгового зала. Оставшееся количество не перемещается из торгового и справки РФУ для него определяется по остаткам склада.
  

  Инвентаризация немаркированной продукции для мест хранения с учетным регистром «Торговый зал».

  
  В процессе «Инвентаризации ЕГАИС» для немаркированной продукции для мест хранений с учетным регистром «Торговый зал» значение поля «Остаток по ЕГАИС» теперь определяется, как сумма остатков торгового зала и склада. В прошлой версии в этом поле показывался остаток торгового зала. Изменение связано с текущим положением, когда часть продукции может еще числиться на регистре торгового зала, а вновь приходящая продукция остается на учете регистра склада.
  Соответственно, определение недостачи или излишков теперь производится по соотношению посчитанного количества и совокупного количества остатков регистра торгового зала и регистра склада.
  При недостаче продукции алгоритм генерации актов списания создает акт списания из торгового зала в разделе «Акты списания / постановки на баланс ЕГАИС» в количестве, не превышающем остаток торгового зала, и для всей продукции, для которой недостаточно остатка в торговом зале, создает новый для этого раздела документ «акт списания со склада».
  В разделе «Акты списания / постановки на баланс ЕГАИС» внесены изменения в интерфейс для работы с актами списания со склада, реализована функция отсылки в ЕГАИС и функция «Подбор кодов алкогольной продукции» для подбора кодов продукции и справок РФУ2 аналогичная такой же функции в разделе ТТН ЕГАИС на отгрузку.
  

  ТТН ЕГАИС на отгрузку. Выбор кода алкогольной продукции.

  
  В диалог выбора кода алкогольной продукции добавлено отображение текущего остатка для кода алкогольной продукции на регистрах торгового зала и склада:
  
  
  Значение остатка соответствует значению колонки «Итого» таблицы остатков.
  

  Заказ в торговом зале ТСД. Округление количества заказа до упаковки заказа.

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

  Почтовый модуль. Сервер обмена данными. Правила рассылки для доверительных баз с УПД фильтром.

  
  В версии 1.050 из диалога выбора доверительных баз данных при настройке правил рассылки были исключены доверительные базы с протоколами обмена, которые не подразумевают выбор произвольного объекта для рассылки.
  В текущей версии возвращена возможность настраивать рассылку для доверительных баз с протоколом «УПД фильтр», но только для объектов «UI» «УПД на приход» и «UD» «УПД на отгрузку».
  

  Модель весов DP Wasp.

  
  Модель весов «CheckWay» переименована в «DP Wasp». В настройку весов добавлен атрибут «Максимальная длина строки поля состава»:
  
  
  В весах DP Wasp содержание дополнительной характеристики артикула «Состав» выгружается в поля, которые могут содержать до трех строк. При печати этикетки форматирование строк весами не выполняется и максимальная ширина поля для печати строки ограничена 45-55 символами. Всего в поле в трех строках может поместиться 130-150 символов (256 байт для текста UTF-8).
  Для равномерного заполнения полей (может быть до 7 полей с текстом) содержание поля «состав» разбивается на строки указанной длины и размещается последовательно по три строки в каждом поле. Переносы выполняются побуквенно.
  Для корректного отображения текста следует подобрать максимальную длину строки опытным путем.
  
  Изменения функционала в версии 1.050 сервис пак 4.
  ЕГАИС.
  Акт списания / постановки на баланс ЕГАИС
  Отправка кассового чека ЕГАИС. Простановка EAN кода.
  Формат обмена «Яндекс. Еда» сервера обмена данными. Изменения в протоколе обмена.
  Изменения, не попавшие в описание 3-го сервис пака версии 1.050.

ЕГАИС.

Акт списания / постановки на баланс ЕГАИС

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

Отправка кассового чека ЕГАИС. Простановка EAN кода.

В процессе «Подсчет алкоголя ТСД» имеется функция экспорта в расходную накладную с отправкой кассового чека в ЕГАИС. Отправка кассового чека происходит без создания документа в Торговой системе. По правилам ЕГАИС форма кассового чека требует обязательного заполнения поля 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": []
}

Изменения, не попавшие в описание 3-го сервис пака версии 1.050.

• ЕГАИС. Функция подбора алкокода для отгрузки немаркированной продукции со второго регистра более не выполняет приоритетное списание алкокодов с самыми давними поставками. Изменение внесено для повышения производительности функции и в связи с запретом перемещения новых партий немаркированной продукции на второй регистр.
• Сервер обмена данными. Для протоколов XML и JSON реализована обработка атрибута REST API запроса для получения количества записей: /?GetRowsCount=1.

Изменения функционала в версии 1.050
WEB сервер лицензирования.
Интервал постановки в почтовую очередь запросов остатков по маркам ЕГАИС.
Правила создания УПД на отгрузку для контрагентов, освобожденных от ЭДО.
Вывод из оборота маркированной продукции.
Проверка КИЗ на выбытие и загрузка в Супермаг Марко.
Подбор накладной поставщика при приеме по заказу поставщику.
Акты переоценки начала и завершения Маркетинговой акции. История изменения цен.
Разбор штрихового кода «маркировка GS1». Определение веса и объема.
Почтовый модуль.
XML протокол. Пересылка КИЗ в спецификации документов.
Функция импорта из XML ArticleByAnyCodeUI.
Алкогольная декларация.
Перечень исправленных ошибок и улучшений.

WEB сервер лицензирования.

В сервер приложений Супермаг+ добавлена возможность получать лицензионную информацию от WEB сервера лицензирования. В этом случае не требуется получать файл лицензии и не требуется аппаратный ключ.
WEB сервер лицензирования размещен в облачном пространстве и обслуживается силами компании производителя. В комплект поставки Торговой системы сервер лицензирования не входит.
Для работы с WEB сервером лицензирования на компьютере, где работает сервер приложений, исполняющий функцию сервера лицензий Торговой системы, необходимо создать специальную запись в системном реестре с URL сервера лицензирования. При установке или обновлении Торговой системы эта запись не создается и может быть выдана по запросу. При наличии такой записи в интерфейсе администратора сервера приложений в диалоге, доступном при нажатии кнопки «Лицензия БД», появляется кнопка «Лицензирование без ключа через веб-сервер»:

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

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

Лицензия, загруженная с веб-сервера, представляет собой зашифрованные данные. Чтобы сервер приложений получил информацию о том, разрешена ли для использования та или иная функция, ему необходимо обратиться к веб-серверу. При получении ответа, ответ кешируется и одновременно сохраняется специальным образом. При рестарте сервера приложений все данные кеша при наличии связи перезагружаются с веб-сервера. Сохраненные ответы при отсутствии соединения могут использоваться до 72 часов.
При старте сервера приложений он будет работать с лицензией, то есть будет выполнять функцию сервера лицензий, только в том случае, если лицензия загружалась с его помощью. При переносе сервера приложений на другой компьютер надо заново загрузить лицензию.
Для защиты от несанкционированного доступа к лицензионной информации обмен данными с веб-сервером происходит по защищенному протоколу, с использованием протокола авторизации OAuth2 и с подтверждением доступа к аутентичной службе.

Интервал постановки в почтовую очередь запросов остатков по маркам ЕГАИС.

В административный модуль в раздел «База данных» на закладку «Конфигурация» в группу данных «Документы» добавлен атрибут «Интервал (в минутах) постановки в почтовую очередь запросов остатков по маркам ЕГАИС» со значением по умолчанию 35 минут:

Атрибут действует на интервал времени между последовательной отсылкой запросов функцией «Запрос поштучных остатков по РФУ2» в разделе «Остатки ЕГАИС»:

Правила создания УПД на отгрузку для контрагентов, освобожденных от ЭДО.

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

• Если не установлен параметр «Учёт кодов КИЗ при приёмке и отгрузке товаров». То есть если принято решение управлять документооборотом УПД вне торговой системы.
• Если операция расходной накладной не «Продажа», «Возврат поставщику» или «Передача товара». То есть операция не подразумевает смену собственника товара.
• Если операция «Возврат поставщику», то для нее УПД на отгрузку не создается, если атрибут контрагента «ЭДО при возврате поставщику» имеет значение «УКД для документа поставки». В этом случае ожидается получение от поставщика УКД для коррекции уже принятой поставки.
   
  Если ни одно из этих условий не выполнено, то УПД на отгрузку создается, если
   
• у контрагента заполнена доп. характеристика «Идентификатор участника обмена УПД»,
  или
• есть марки в накладной,
  или
• в накладной есть маркированные товары.
  В текущей версии для контрагента добавлен атрибут «Освобожден от обязанности использовать ЭДО»:
  
  По умолчанию флаг не установлен. Атрибут позволяет явным образом исключить создание УПД на отгрузку для отдельных контрагентов, независимо от выполнения других условий генерации УПД.
  Аналогичное изменение внесено в функцию проверки расходной накладной 242 «Корректность накладной для создания УПД на отгрузку»: для накладных с контрагентом, освобожденным от использования ЭДО, проверка не выполняется.
  Изменение внесено для поддержки следующего исключения из правил ведения электронного документооборота маркированной продукции: «муниципальные учреждения не обязаны подключаться к ЭДО до 01.12.2023».
  

  Вывод из оборота маркированной продукции.

  
  В версии 1.049 сп2 для расходной накладной была создана функция «Списание маркированной продукции» для создания файла с данными о выбытии маркированной продукции, который может быть загружен в ЦРПТ на сайте ГИС МТ. С момента выхода версии ЦРПТ изменил правила формирования файла: ввел новые причины выбытия, отменил ряд прежних причин выбытия и добавил новые условия для выгрузки данных.
  В текущей версии алгоритм формирования файла, предлагаемые варианты выбора причины вывода из оборота и соответствующего вида первичного документа приведены в соответствие с актуальными правилами, добавлен ввод идентификатора ФИАС:
  
  

  Проверка КИЗ на выбытие и загрузка в Супермаг Марко.

  
  В раздел «Подсчет кодов КИЗ» добавлена функция «Проверить выбытие и передать в СММарко».
  Функция обрабатывает КИЗ, выбранные из журнала подсчета:
  
  Или все КИЗ, если выбрана другая закладка:
  
  Функция проверяет каждый КИЗ на наличие в спецификации кассовых документов с операцией «Продажа» и «Возврат от покупателя», в спецификации приходных накладных с операцией «Возврат от покупателей» и в спецификации расходных накладных. Если количество расходов КИЗ превысит количество поступлений (возвратов), то КИЗ считается выбывшим. Документы рассматриваются со статусом «Принят в количестве» и «Принят полностью» («розовый» и «зеленый»).
  Если КИЗ не выбыл, он ставится в очередь на отсылку в СММарко. Поскольку в процессе подсчета КИЗ все коды марок хранятся в том виде, в котором они были считаны сканером, то есть со всеми спецсимволами и дополнительными полями, то при отсылке КИЗ в СММарко, они предварительно приводятся к виду, рекомендованному ЦРПТ для их передачи в составе УПД.
  

  Подбор накладной поставщика при приеме по заказу поставщику.

  
  В мастере создания приходной накладной при указании заказа поставщику в качестве основания поставки производится поиск накладной поставщика или УПД на приход, созданной на основании этого заказа.
  В некоторых случаях поставщики используют процедуру подтверждения заказа и присылают подтверждение заказа с измененным содержанием. В процедуре приема изменений создается новый заказ поставщику с содержанием, соответствующим предложению поставщика. В основании этого заказа указывается первичный заказ поставщику. Новый заказ отсылается поставщику.
  В то же время некоторые поставщики формируют поставку и отсылают накладную поставщика / УПД на приход, указывая в ее основании первичный заказ поставщику, который уже признан недействительным и получил статус «Заблокирован». Соответственно, в прежних версиях при приеме поставки с указанием в качестве основания действующего заказа поставщику накладная поставщика не подбиралась, поскольку в ее основании указан другой заказ.
  В текущей версии в мастере создания приходной накладной изменен алгоритм поиска накладной поставщика / УПД на приход для указанного заказа поставщику. Если документы, в основании которых стоит указанный заказ поставщику, не обнаружены, то дополнительно ищутся накладные поставщика или УПД на приход, созданные на основании заказа поставщику, который указан в основании текущего заказа поставщику.
  

  Акты переоценки начала и завершения Маркетинговой акции. История изменения цен.

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

  Разбор штрихового кода «маркировка GS1». Определение веса и объема.

  
  В предыдущих версиях при сканировании штрихового кода и опознании его в качестве кода «маркировка GS1» из кода извлекалась информация о GTIN товара, его серийном номере, цене и т.д. В текущей версии в разбор кода добавлено распознавание кодов применения 310 и 315 – вес нетто товара в килограммах и объем в литрах.
  В формате GS1 идентификатор применения 31 описывается как «Торговая величина» и служит для описания массогабаритных характеристик. Формат идентификатора выглядит как 31XYVVVVVV, где X – тип величины, в частности 0 – вес в килограммах, 5 – объем в литрах, Y - место десятичной точки в числе VVVVVV. Число состоит из 6 знаков.
  Например:
  3103003140
  Означает, что товар имеет вес 3,140 кг.
  Примечание. Идентификатор применения 31 имеет фиксированную длину – 10 символов, и при размещении его к коде GS1 после поля торговой величины может отсутствовать символ «разделитель полей».
  При сканировании штриховых кодов GS1, если GTIN не указывает на штрихкод с количеством и артикул имеет единицу изменения «кг» и в GS1 имеется код применения 310, то артикул будет идентифицирован с весом из GS1. Такое же правило относится к артикулам с единицей измерения «литр» и кодом применения 315.
  Примечание. Штриховой код из GTIN не содержит количества, если он зафиксирован в системе, как код «Весовой ШК18».
  

  Почтовый модуль.

  XML протокол. Пересылка КИЗ в спецификации документов.

  
  В предыдущих версиях при формировании XML файла документов содержание поля с КИЗ передавались в виде строк с экранированием нечитаемых символов. Для экранирования использовался синтаксис вида: &#x<код символа>, например, символ 1D «разделитель полей» экранировался следующим образом: &#x1D. Этот синтаксис не является общеупотребительным и некоторые XML парсеры его не поддерживают.
  В текущей версии строки с КИЗ передаются в формате BASE64. Исключение сделано для документов «УПД на приход», «УПД на отгрузку» и «Накладная поставщика», где КИЗ представлен по правилам ЦРПТ в виде строк без специальных символов.
  Данное изменение надо учесть всем, кто получает или передает документы с использованием третьих систем.
  

  Функция импорта из XML ArticleByAnyCodeUI.

  
  В перечень функций импорта данных из XML файлов добавлена функция ArticleByAnyCodeUI. Функция аналогична функции ArticleBySupplierCodeUI за исключением того, что в качестве аргументов для определения контрагента используются не данные о его ИНН и КПП, а код клиента Супермаг+. Информация о контрагенте в функции нужна для определения артикула по артикулу контрагента, как одной из возможных альтернатив определения артикула.
  В случае использования кода клиента Супермаг+ сам код клиента не обязан быть задан непосредственно в XML файле почтового пакета. Код клиента может определяться функцией.
  Например, в XSD файле могут быть описаны следующие поля, необходимые для работы функции ArticleByAnyCodeUI:
  <xs:element msdata:Locale="ru" name="SMDOCUMENTS">
  <xs:complexType>
  <xs:sequence>
  …
  <xs:element smimport:Function="ClientByGLN(CLIENTGLN)" minOccurs="0" name="CLIENTINDEX" type="xs:string" />
  …
  <xs:element minOccurs="0" name="CLIENTGLN" type="xs:string" />
  …
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  
  <xs:element msdata:Locale="ru" name="SMSPECWE">
  <xs:complexType>
  <xs:sequence>
  …
  <xs:element smimport:Function="ArticleByAnyCodeUI(SMSPECWE.ARTICLECODE, SMDOCUMENTS.CLIENTINDEX, SMSPECTOBACCOWE.MARKCODE, SMSPECOSUCODEWE.OSUCODE)" name="ARTICLE" type="xs:string" />
  …
  <xs:element minOccurs="0" name="ARTICLECODE" type="xs:string" />
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  
  <xs:element msdata:Locale="ru" name="SMSPECTOBACCOWE">
  <xs:complexType>
  <xs:sequence>
  …
  <xs:element name="MARKCODE" type="xs:string" />
  …
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  
  <xs:element msdata:Locale="ru" name="SMSPECOSUCODEWE">
  <xs:complexType>
  <xs:sequence>
  …
  <xs:element name="OSUCODE" type="xs:string" />
  </xs:sequence>
  </xs:complexType>
  </xs:element>
  
  Замечание: в тэге ARTICLECODE может быть либо артикул Торговой системы, либо артикул поставщика, либо штриховой код товара.
  Для схемы, фрагмент которой описан выше, содержание XML файла может быть следующим:
  <SMDOCUMENTS>
  <CREATEDAT>2023-04-14T00:00:00</CREATEDAT>
  <TOTALSUM>6913.20</TOTALSUM>
  <CLIENTGLN>81309835</CLIENTGLN>
  <LOCATIONGLN>sem_4</LOCATIONGLN>
  </SMDOCUMENTS>
  <SMWAYBILLSEXT>
  <EDOID>3897523747</EDOID>
  <SUPPLIERDOC>410</SUPPLIERDOC>
  <OURSELFGLN>543234121</OURSELFGLN>
  <UTDFUNCTION>СЧФДОП</UTDFUNCTION>
  </SMWAYBILLSEXT>
  <SMSPECWE>
  <SPECITEM>1</SPECITEM>
  <DISPLAYITEM>1</DISPLAYITEM>
  <ITEMPRICE>254.40</ITEMPRICE>
  <ITEMPRICENOTAX>212.00</ITEMPRICENOTAX>
  <QUANTITY>21.00</QUANTITY>
  <VATRATE>20</VATRATE>
  <TOTALPRICE>5342.40</TOTALPRICE>
  <TOTALPRICENOTAX>4452.00</TOTALPRICENOTAX>
  <VATSUM>890.4</VATSUM>
  <COUNTRYOKCM>643</COUNTRYOKCM>
  < ARTICLECODE >00000046200020</ ARTICLECODE >
  </SMSPECWE>
  …
  
  В приведенном выше фрагменте XML файла нет тэга CLIENTINDEX, но есть тэг CLIENTGLN, который обрабатывается функцией ClientByGLN. Функция ClientByGLN, в свою очередь, подставляет в XML файл тэг CLIENTINDEX, заполнив его соответствующим значением. Значение CLIENTINDEX может быть получено и другими функциями с другими аргументами, для работы функции ArticleByAnyCodeUI это значения не имеет, важно, чтобы значение поля было определено тем или иным способом.
  

  Алкогольная декларация.

  
  В описание структурного подразделения декларанта добавлено поле «Включать в форму 7». По умолчанию флаг установлен. Если флаг снять, то при формировании формы 7 данные этого структурного подразделения учитываться не будут. Изменение внесено для поддержки пункта закона, который говорит о том, что форму 7 обязаны формировать «организации, осуществляющие розничную продажу алкогольной продукции при оказании услуг общественного питания, розничную продажу алкогольной продукции, осуществляемую в населенных пунктах, в которых отсутствует доступ к информационно-телекоммуникационной сети "Интернет"….». Результаты работы прочих подразделений в форму 7 не помещаются.
  Для приходной, расходной накладной и накладной на перемещение добавлено функциональное право – «Редактирование поля "Производитель / импортёр"». При отсутствии этого права редактировать это поле не разрешается. Изменение внесено для защиты содержания декларации от изменения.
  При расчете данных декларации в том случае, когда данные производителя импортера берутся из ТТН ЕГАИС, связанной с накладной, теперь всегда берутся данные производителя, если в соответствующей строке спецификации ТТН поле ProducerOrgType имеет значение "TS" - таможенный союз.
  Данные поставщика (название, ИНН, КПП) теперь берутся не из данных контрагента накладной, а из данных связанной с ней ТТН (грузоотправителя ТТН).
  

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

• Администратор почтового модуля. Исправлена ошибка: не сохранялись настройки почтового ящика, если после задания значения параметра перейти на другой почтовый ящик и снова вернуться к тому, параметры которого были изменены, и после этого нажать кнопку "Сохранить".
• Сервер обмена данных. Из диалога выбора доверительной базы данных в настройке правил рассылки исключена возможность выбора адресата, чей протокол обмена не подразумевает возможности отсылки произвольного почтового объекта. Аналогичное изменение внесено в диалоги отсылки объектов в разделах Супермаг+.

Изменения функционала в версии 1.051 сервис пак 1.
ЕГАИС.
Акт списания / постановки на баланс ЕГАИС
ТТН ЕГАИС на отгрузку. Функция «Подбор кодов алкогольной продукции» для операций списания со склада.
Отправка кассового чека ЕГАИС. Простановка EAN кода.
Почтовый модуль. Экспорт в XML. Функция LocationGLNCross.
Формат обмена «Яндекс. Еда» сервера обмена данными. Изменения в протоколе обмена.

ЕГАИС.

Акт списания / постановки на баланс ЕГАИС

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

ТТН ЕГАИС на отгрузку. Функция «Подбор кодов алкогольной продукции» для операций списания со склада.

При подборе кодов алкогольной продукции для строк спецификации ТТН, связанных со строками спецификации накладных, проводится анализ остатков склада для кодов алкогольной продукции артикула. Остатки кодов алкогольной продукции на регистре склада распределены по справкам РФУ2. Анализ остатков проводится для выбора кода алкогольной продукции и справки РФУ2, для которых на складе есть остатки, чтобы при передачи ТТН в ЕГАИС избежать ошибки ЕГАИС вида «необеспеченный расход». Поскольку остатки склада (см. раздел «Остатки ЕГАИС», закладка «Склад») являются актуальными только на момент получения их из ЕГАИС, а запрос остатков разрешен не чаще раза в сутки, то алгоритм подбора кодов алкогольной продукции и справок РФУ2 в прошлых версиях учитывал количества приходов и расходов, которые отображаются в таблице остатков ЕГАИС в колонках «Приход по документам» и «Расход по документам» и образуются при получении из ЕГАИС квитанций о фиксации документов ЕГАИС.
В текущей версии в алгоритм добавлен учет расходов и приходов (акт постановки на баланс) по не зафиксированным документам ЕГАИС, то есть поставленным в очередь на отсылку, но с не полученным ответом из ЕГАИС.
Изменение внесено в связи с тем, что продажа немаркированной продукции разрешается при наличии одного идентификатора ФСРАР ИД для множества магазинов юридического лица. Соответственно, списание кассовой реализации выполняется в коротком диапазоне времени для многих магазинов, что приводит к тому, что подбор кодов алкогольной продукции и справок для одних и тех же артикулов разных магазинов происходит с использованием одних и тех же остатков и без ожидания фиксации в ЕГАИС других актов списания. Что, в свою очередь, приводит к ошибкам передачи документов в ЕГАИС.
Внесенные изменения не исключают вероятности того, что два или более документа будут одновременно выполнять подбор кодов алкогольной продукции и справок РФУ2. Если при отсылке ТТН в ЕГАИС, ЕГАИС вернет ошибку вида «необеспеченный расход», надо перевести ТТН в черновик, повторно выполнить функцию «Подбор кодов алкогольной продукции» и снова отослать ТТН в ЕГАИС.

Отправка кассового чека ЕГАИС. Простановка EAN кода.

В процессе «Подсчет алкоголя ТСД» имеется функция экспорта в расходную накладную с отправкой кассового чека в ЕГАИС. Отправка кассового чека происходит без создания документа в Торговой системе. По правилам ЕГАИС форма кассового чека требует обязательного заполнения поля EAN, тогда как в процессе подсчета алкоголя возможны случаи, когда EAN код может быть не заполнен.
В алгоритм отсылки кассового чека ЕГАИС внесено следующее изменение: если поле «штрихкод» в строке таблицы не заполнено, то в кассовом чеке оно заполняется штриховым кодом артикула типа EAN (то есть, содержащий 8, 12 или 13 чисел). Преимущество отдается внешним штриховым кодам.

Почтовый модуль. Экспорт в XML. Функция LocationGLNCross.

В перечень функций, доступных при формировании 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> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Остатки ЕГАИС. Склад. Приход по документам, расход по документам.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Функция «Подбор кодов алкогольной продукции».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Функция удаления строки ТТН.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">ТТН на отгрузку. Удаление ТТН с операцией «акт списания из торгового зала».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Отсылка ТТН на отгрузку по почте с подбором кодов алкогольной продукции.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Расходная накладная. Условия работы функции «Сформировать электронный УПД».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Почтовый модуль. УПД фильтр. Прием файла подтверждения для УПД на отгрузку.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Почтовый модуль. УПД фильтр. Сквозная рассылка провайдерам.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Контрагенты. Доп. характеристика «Пакет документов поставщика для приёмки по заказу».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Сервер обмена данными. «ЯндексЕда». Передача комментария заказа.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Сервер лицензий. Время офлайн работы WEB лицензии.</span></span> ]

ЕГАИС.

Остатки ЕГАИС. Склад. Приход по документам, расход по документам.

В предыдущих версиях на закладке «Склад» в колонках «Приход по документам» и «Расход по документам» не отображалось количество по документам, которые были зафиксированы в ЕГАИС после получения информации об остатках склада, как это было для остатков торгового зала. В текущей версии при получении квитанции о фиксации документа в ЕГАИС его количество отражается в соответствующей колонке. Для получения корректных значений в колонках необходимо после обновления версии произвести запрос остатков склада в ЕГАИС.

ТТН на отгрузку. Функция «Подбор кодов алкогольной продукции».

В предыдущих версиях функция «Подбор кодов алкогольной продукции» в ТТН на отгрузку в случае отгрузки с регистра склада была разрешена только для ТТН, созданных на основании кассовых документов (списание по кассовым документам). Это ограничение было обусловлено тем, что подбор кодов алкогольной продукции и справок РФУ имеет смысл только для немаркированной продукции. Списание по кассовому документу выполняет именно эту задачу. На основании кассового документа выполняется списание только немаркированной продукции, тогда как маркированная продукция при продаже по кассе списывается непосредственно в момент продажи кассовым чеком ЕГАИС.
При создании ТТН на основании расходной накладной в ТТН может присутствовать, как немаркированная, так и маркированная продукция вместе с кодами марок ЕГАИС. Выполнение функции «Подбор кодов алкогольной продукции» может привести к ошибочным ситуациям при обработке строк с маркированной продукцией.
В текущей версии разрешено использование функции «Подбор кодов алкогольной продукции» для ТТН на отгрузку, созданных на основании любых документов при условии, что в ТТН отсутствуют коды марок ЕГАИС.
Дополнительно в мастер запуска функции «Подбор кодов алкогольной продукции» добавлен диалог:

В прошлых версиях функция обрабатывала только строки с пустыми значениями поля «Алк. код».
Опция позволяет полностью пересчитать все привязки к алкокодам и справкам РФУ, если в течении времени остатки склада изменились так, что прежний подбор стал недействительным, например, в промежутке времени с прошлого выполнения функции был полностью израсходован товар по конкретной справке РФУ или даже по коду алкогольной продукции.

ТТН на отгрузку. Функция удаления строки ТТН.

В интерфейс ТТН на отгрузку добавлена кнопка «Уд. строку»:

Нажатие кнопки вызывает функцию, которая позволяет удалить из ТТН выделенные строки. Перед удалением строк функция проверяет, что в строках нет подобранных справок РФУ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"» информацией из поля «Комментарий» закладки «Доставка» заголовка документа «Заказ от клиента».

Сервер лицензий. Время офлайн работы WEB лицензии.

Время работы сервера лицензии в офлайн режиме увеличено до 10 суток.

Изменения функционала в версии 1.051 сервис пак 3.
Карточки складского учета. Выкладка.
Административный модуль. Поведение опции «Запрещать редактировать документы товародвижения с даты инвентаризации».
Весы DIGI SM-Ethernet. Выгрузка второй цены со скидкой.

Карточки складского учета. Выкладка.

В текущей версии в разделе карточек складского учета в таблице описания выкладки товара поле для описания сделано многострочным:

Административный модуль. Поведение опции «Запрещать редактировать документы товародвижения с даты инвентаризации».

В разделе «Склады и магазины» на закладке «Общие» имеется опция «Редактирование док-тов товародвиж. только с датой после». Такая же опция имеется в административном модуле, в разделе «База данных», на закладке «Конфигурация», в группе данных «Документы». Там же есть опция «Запрещать редактировать документы товародвижения с даты инвентаризации».
Опция «Редактирование док-тов товародвиж. только с датой после» позволяет установить дату запрета редактирования документов товародвижения, то есть дату, по которую включительно нельзя редактировать документы товародвижения. Опция для места хранения действует на документы товародвижения, связанные с этим местом хранения. Значение опции административного модуля используются, если для места хранения опция не определена.
Опция «Запрещать редактировать документы товародвижения с даты инвентаризации» указывает системе, что при смене статуса документа «Сличительная ведомость» на «Принят в количестве и ценах» для места хранения ведомости необходимо установить дату запрета редактирования документов товародвижения равной дате начала проведения инвентаризации из сличительной ведомости. Действие выполняется, если новая дата запрета редактирования больше старой даты, или атрибут «Редактирование документов товародвижения только с датой после» для места хранения не был установлен ранее.
В текущей версии изменено поведение системы при установленной опции «Запрещать редактировать документы товародвижения с даты инвентаризации». Теперь при смене статуса документа «Сличительная ведомость» на «Принят в количестве и ценах» устанавливается дата запрета редактирования документов товародвижения равной дате начала проведения инвентаризации со ссылкой на текущую ведомость. А также сохраняются прежние значения даты запрета и номера ведомости. При обратной смене статуса «Сличительная ведомость» с «Принят в количестве и ценах» на «Принят в количестве» восстанавливаются прежние значения даты и номера ведомости. Также прежние значения восстанавливаются при создании актов потерь и обнаружений функцией «Создать накладные» в разделе «Сличительные ведомости».
При ручном редактировании опции «Редактирование документов товародвижения только с датой после» ссылка на ведомость будет удалена.
Новое поведение позволяет решить проблему, когда на основании сличительной ведомости, уже получившей статус «Принят в количестве и ценах», создаются не приходные и расходные накладные, которые приводят остатки товаров к их фактическим значениям, а акты потерь и обнаружений, которые влияют не на текущие остатки, а на значение колонки «Потери» таблицы остатков.
Новое поведение опции сохраняет историю ее установки на один шаг назад. Это означает, что автоматически восстанавливается прежнее значение опции только для последнего действия. Если будет произведена отмена статуса сличительной ведомости предшествующей последней, то никакого изменения значения опции не произойдет. Если произвести последовательно отмену статусов двух или более сличительных ведомостей, то значение опции будет очищено.

Весы DIGI SM-Ethernet. Выгрузка второй цены со скидкой.

В диалог «Настройка электронных весов», для весов «DIGI SM-Ethernet» на закладку «Свойства модели» добавлен выбор вида цены для выгрузки в весы второй цены со скидкой:

При печати этикетки весы могут выполнять печать для товаров, у которых есть скидка и у которых нет скидки. Дизайн этикеток в таких случаях, как правило, разный. В одном дизайне печатается только одна цена, в другом цена со скидкой и цена без скидки. Чтобы использовались разные дизайны для печати этикетки для разных товаров, необходимо, чтобы в весы было загружено две этикетки с номерами 17 (11h) для этикетки с одной ценой и 18 (12h) для этикетки с двумя ценами. Если этикетки загружаются средствами Торговой Системы, описание обоих этикеток должно быть помещено в одну пару файлов F34.dat, F38.dat:

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


Изменения функционала в версии 1.051 сервис пак 4.
Сервер приложений. Работа с WEB лицензией.
Выход из производства ГИС Меркурий. Функция «Проставить признак «Скоропортящийся»».
Процесс «Отгрузка по заказу ТСД». Генерация расходной накладной.
Процесс «Отгрузка перемещения ТСД». Генерация накладной на перемещение.
УПД на приход, УПД на отгузку. ИНН и имя подписанта ЭДО.
Административный модуль.
Подписант ЭДО.
Задание «Генерация заказов».
Почтовый модуль. УПД фильтр. Перечень данных при отправке подтверждения приема и УПД на расход.
Раздел «Электронные весы». Флаг «Только локальные».

Сервер приложений. Работа с 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 лицензирование. Автоматическая загрузка лицензий новых версий.

В сервер приложений Супермаг+ добавлен механизм автоматического обращения к серверу лицензирования при несоответствии версии базы данных и версии WEB лицензии или при истечении срока действия временной лицензии. Если на сервере лицензирования будет обнаружена подходящая лицензия, она автоматически будет загружена в сервер приложений. Интервал опроса сервера лицензирования составляет 60 секунд.

Выгрузка в кассу по протоколу УКМ4 XML.

Для поддержки протокола работы ККТ при передаче данных о комиссионных и агентских продажах в алгоритм формирования файла suppliers внесено следующее изменение: при выгрузке тэга <SupplierTel> строка с информацией о телефоне юридического адреса комиссионера обрабатывается для выделения единственного номера телефона и преобразования его к формату, допустимому в ККТ:

• берется часть строки до первой запятой или точки запятой;
• удаляются все символы, отличные от числа;
• если первый символ получившейся строки равен 8, то 8 заменяется на +7, иначе в начало строки добавляется +;
• строка ограничивается 19 символами – предельным количеством символов, допустимых для передачи строки с номером телефона в ККТ.
  
  
  Изменения функционала в версии 1.051 сп6
  WEB лицензирование. Время автономной работы.
  ЕГАИС.
  Акт постановки на баланс по результатам инвентаризации. Операция «Пересортица».
  ТТН ЕГАИС на отгрузку на основании накладной на перемещение. Определение атрибутов контрагентов при отсылке ТТН в ЕГАИС.
  ТТН на приход. Цветовая индикация недостачи.
  Приходная накладная. Создание на основании УПД на приход. Копирование даты счета-фактуры.
  Акты потерь, Акты обнаружений. Поле «Комментарий».
  Сервер обмена данными. Формат «Яндекс.Еда». Изменение в протоколе обмена.

WEB лицензирование. Время автономной работы.

При использовании 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 – номер документа в кассе
В случае повторной выгрузки кассой квитанций о внесении или изъятии, полученные данные замещают ранее принятые.
Интерфейс просмотра информации документа внесения в ККТ и изъятия из ККТ имеет следующий вид:

Приходный / расходный кассовый ордер имеет следующий интерфейс работы с документом:

Номер для печати автоматически генерируется по следующим правилам:

• Для приходного кассового ордера: <Код МХ><ПКО><Дата><Номер внутри даты>
• Для расходного кассового ордера: <Код МХ><РКО><Дата><Номер внутри даты>
  Расходный кассовый ордер с операцией «Инкассация» имеет интерфейс с дополнительными элементами для регистрации необходимой для инкассации информации:
  
  Документ «Ревизия главной кассы» имеет следующий интерфейс:
  
  Номер для печати для ревизии главной кассы формируется следующим образом:
  <Код МХ><ИНВ><Дата><Номер внутри даты>
  Документ ревизии на баланс счета главной кассы не влияет. По результатам ревизии может быть создан вручную приходный или расходный кассовый ордер.
  Во всех документах и на экране со списком документов показывается текущее состояние счета операций главной кассы «Текущий баланс». На экране со списком документов можно дополнительно посмотреть остатки денежных средств на конец указанной даты. По умолчанию показываются остатки на конец трех предшествующих дней:
  
  

  Перерасчет баланса главной кассы.

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

  ТТН ЕГАИС на отгрузку.

  Отсылка ТТН ЕГАИС почтовым модулем, подбор кодов алкогольной продукции.

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

  Контроль соответствия ТТН ЕГАИС с операциями актов списания и кассового документа.

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

  Выбор кода алкогольной продукции.

  
  В диалог выбора кода алкогольной продукции, который можно вызвать по кнопке в колонке «Алк. код» спецификации ТТН ЕГАИС, добавлены колонки с остатками на складе и торговом зале:
  
  В колонках отображаются величины, которые показываются в колонке «Итого» в разделе остатков ЕГАИС.
  

  УПД на приход.

  Исправления и расхождения.

  
  В заголовке документа УПД на приход закладка «Исправления» получила название «Исправления и расхождения». На закладку добавлено поле «Расхождение УПД и накладной» для отображения многострочной информации о причинах расхождения между УПД на приход и приходной накладной, созданной на его основании. Поле заполняется при смене статуса приходной накладной со статуса «Черновик» на статус «Принят на складе» в ходе выполнения функции проверки на наличие расхождений между документом поставщика и результатами приемки товара.
  В прошлых версиях информация о расхождении помещалась в однострочном комментарии документа. При обновлении версии эта информация из комментария переносится в новое место.
  
  При отсылке УПД на приход поставщику в виде файла подтверждения приема (REPLY) информация о причинах расхождения по-прежнему помещается в тэг <COMMENTARY>.
  

  Отказ в приеме.

  
  В интерфейсе открытого на просмотр документа «УПД на приход» имеется кнопка «Отказ в приеме»:
  
  Нажатие кнопки приводит к смене статуса документа на «Заблокирован». В текущей версии функция получила диалог старта, в котором можно ввести строку с описанием причины отказа в приеме:
  
  Строка с причиной отказа помещается в поле «Комментарий» документа. При отсылке файла подтверждения приема (REPLY) информация помещается в тэг <COMMENTARY>.
  В интерфейсе отобранных документов в кнопку «Обработать» добавлена функция «Отказ в приеме» для отмены поставки нескольких документов. В диалоге функции также имеется возможность указать причину отказа:
  
  Отказ в приеме невозможен, если на основании УПД уже создана приходная накладная со статусом, отличным от «Черновик».
  

  Контрагенты. Доверительный прием поставки.

  
  В разделе контрагентов на закладку «Условия поставки» добавлен флаг «Разрешить доверительный прием»:
  
  По умочанию флаг не установлен. В текущей версии атрибут используется программой СМ Мобайл Андроид (начиная с версии 2.4.14.32) в процессе приема по заказу. Если флаг установлен, то количество принятого товара по умолчанию считается равным количеству заказа поставщику или накладной поставщика / УПД на приход, созданных на основании заказа поставщика.
  

  Генерация документов из процесса «Отгрузка перемещения ТСД».

  
  В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Генерация документов из процесса» для процесса «Отгрузка перемещения ТСД» разрешен выбор статуса «Отпущен полностью».
  
  

  Поддержка СМ Мобайл. Выгрузка справочника единиц измерения.

  
  В текущей версии реализована выгрузка в СМ Мобайл справочника единиц измерения для контроля ввода количества с учетом точности единицы измерения. Справочник используется программой СМ Мобайл Андроид в версии 2.4.20.34.
  

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

• УПД на отгрузку. Исправлено. Из диалога функции «Смена статуса» кнопки «Обработать» удалена возможность выбора статуса «Обработан».

• ЕГАИС. Функция подбора алкокода для отгрузки немаркированной продукции со второго регистра более не выполняет приоритетное списание алкокодов с самыми давними поставками. Изменение внесено для повышения производительности функции и в связи с запретом перемещения новых партий немаркированной продукции на второй регистр.

Изменения функционала в версии 1.052 сп1
WEB лицензирование. Время автономной работы.
ЕГАИС.
ТТН на расход. Ручное проставление справок РФУ при возврате без указания основания.
Акт постановки на баланс по результатам инвентаризации. Операция «Пересортица».
ТТН ЕГАИС на отгрузку на основании накладной на перемещение. Определение атрибутов контрагентов при отсылке ТТН в ЕГАИС.
ТТН на приход. Цветовая индикация недостачи.
Приходная накладная. Создание на основании УПД на приход. Копирование даты счета-фактуры.
Акты потерь, Акты обнаружений. Поле «Комментарий».
Сервер обмена данными. Формат «Яндекс.Еда». Изменение в протоколе обмена.

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 «Превышение максимально разрешенного изменения цены прихода отн. последней поставки данного поставщика». Условия выполнения.

В функции проверки приходной накладной 73 «Превышение максимально разрешенного изменения цены прихода отн. последней поставки данного поставщика» добавлено условие выполнения «при смене статуса с 1 на 2», то есть со статуса «Черновик» на статус «Принят на складе»:

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

УПД на приход. Проверка 244 (Корректность документов "УПД на приход").

В проверке 244 «Корректность документов "УПД на приход"» убрано условие срабатывания при смене статуса с «Черновик» на «Заблокирован».
Условие препятствовало отказу от приема УПД, если был установлен системный параметр «Неизвестный артикул при приеме товара» и в спецификации документа были позиции с таким артикулом.

УКМ4 XML. Выгрузка признака товара «разливное пиво».

В протокол выгрузки данных УКМ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. Выгрузка признака товара «разливное пиво».

В прошлой версии в протокол выгрузки данных УКМ4 XML было внесено изменение для выгрузки тэга <crptNotUnique> в файле updateItems_[ххх]_[F/I].xml. Признак <crptNotUnique> позволяет кассе одновременно требовать обязательное указание КИЗ маркированного товара и не контролировать уникальность КИЗ для таких товаров.
В прошлой версии артикул считался маркированным с неуникальным КИЗ, если артикул имел единицу измерения «литр» и входил в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки». Или артикул имел типа «набор» и один из компонентов набора имел единицу измерения «литр» и входил в группу классификатора алкогольной продукции с установленным флагом «Пиво или пивные напитки».
В текущей версии тэг выгружается по описанному выше условию не только для карточек с единицей измерения «литр», но и для всех карточек, которые имеют единицу измерения, производную от единицы измерения «литр». То есть единицу измерения, у которой в поле «Базовая единица измерения» установлено значение «литр». Например, это может быть «декалитр» или «дал».

Инвентаризация ТСД. Ограничение по типам артикула при выгрузке данных в документы.

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


Изменения функционала в версии 1.052
WEB лицензирование. Автоматическая загрузка лицензий новых версий.
Управление заданиями Супермаг Мобайл 3.
Закладка «Справочники».
Закладка «Типы заданий».
Закладка «Задания».
УПД на приход. Прием УПД с неизвестными артикулами.
Расходная накладная, Накладная на перемещение. Функция «Проставить основания…». Учет КИЗ.
Раздел «Коррекция заказов поставщикам».
Настройка автоматической генерации заказов поставщику.
Экспорт. Формат поля типа «Дата».
Передача уведомлений в Супермаг Мобайл 2.4.
Меркурий. Прямой обмен с сервисами ГИС Меркурий.
Справочник «Единицы измерения ГИС Меркурий».
Справочник «Площадки ГИС Меркурий».
Выгрузка в кассу по протоколу УКМ4 XML.
Перечень исправлений.

WEB лицензирование. Автоматическая загрузка лицензий новых версий.

В сервер приложений Супермаг+ добавлен механизм автоматического обращения к серверу лицензирования при несоответствии версии базы данных и версии WEB лицензии или при истечении срока действия временной лицензии. Если на сервере лицензирования будет обнаружена подходящая лицензия, она автоматически будет загружена в сервер приложений. Интервал опроса сервера лицензирования составляет 60 секунд.

Управление заданиями Супермаг Мобайл 3.

Создан новый раздел «Управление заданиями Супермаг Мобайл 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 «Корректность документов "УПД на приход"» с режимом работы «Всегда запрет». Проверка срабатывает при смене статуса УПД на приход с «Черновик» на другой статус, если установлен системный параметр «Неизвестный артикул при приеме товара» и в спецификации документа есть позиции, артикул которых совпадает со значением этого параметра.

Расходная накладная, Накладная на перемещение. Функция «Проставить основания…». Учет КИЗ.

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

Раздел «Коррекция заказов поставщикам».

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

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

• нормализация, то есть приведение количества заказа в соответствие с упаковкой заказа и минимальным количеством заказа, определенным соглашением о поставке;
• копирование в поле «количество» предложение заказа или среднесуточной реализации;
• коррекция количества на заданный процент относительно значения указанного столбца.
  Промежуточное сохранение результатов работы производится в документы «Заказ поставщику». Выполняется нажатием кнопки «Сохранить».
  По окончанию работы результат сохраняется в документах «Заказ поставщику» и их статус изменяется на «Размещен». Для этого надо нажать кнопку «Сохранить и принять заказы».
  
  

  Настройка автоматической генерации заказов поставщику.

  
  В мастере автоматической генерации заказов в разделе «Заказы поставщику» и в мастере настройки функции «Генерация заказов» в административном модуле, увеличен размер окна мастера и на страницу «Генерация заказов: соглашения о поставках» добавлен элемент для выбора или снятия выбора всех строк таблицы с соглашениями о поставке:
  
  

  Экспорт. Формат поля типа «Дата».

  
  В интерфейс диалога настройки полей выходных данных для экспорта добавлено описание применения поля «Формат»:
  
  

  Передача уведомлений в Супермаг Мобайл 2.4.

  
  Для Супермаг Мобайл 2.4 разработан новый механизм передачи уведомлений. Прежний механизм давал неверный результат, если пользователь ТСД переключался на другую базу данных, имея в ней тот же логин. Новый механизм поддерживает понятие «Прочитано», что позволяет выделять на ТСД новые сообщения и не перечитывать с сервера старые при новом входе в программу.
  Новый механизм работает с Супермаг Мобайл 2.4, начиная с версии 2.4.152.29. Другие версии Супермаг Мобайл работают с прежним механизмом получения сообщений.
  Примечание. Программа Супермаг Мобайл 2.4 при получении сообщения помещает его в системную очередь уведомлений и отражает в заголовке приложения в виде иконки «письмо». Настройки звукового оповещения о приходе уведомления и способы отражения прихода уведомления в системном заголовке окна или на столе с иконками приложений выполняются в разделе приложения в настройках ОС Андроид. Посмотреть сообщения можно либо кликом на уведомление, либо вызовом раздела «Сообщения» Супермаг Мобайл.
  Примечание. Если пользователь войдет под своим именем на нескольких устройствах одновременно, то сообщение будет показано на том устройстве, которое прочтет его первым.
  

  Меркурий. Прямой обмен с сервисами ГИС Меркурий.

  
  В Торговой системе Супермаг+ ведутся работы по переходу от обмена с ГИС Меркурий через провайдера к прямому обмену со службами ГИС. В текущей версии произведена замена механизмов обмена справочника «Единицы измерений ГИС Меркурий» и «Площадки ГИС Меркурий».
  Меркурий является компонентой системы ВетИС – государственной информационной системы в области ветеринарии. Помимо Меркурия система ВетИС содержит и другие компоненты, например, Цербер (хозяйствующие субъекты). Однако все разделы Супермаг+, необходимые для работы с документами компоненты Меркурий, по прежнему будут относиться к группе разделов «Меркурий» и содержать в названии «Меркурий».
  Обмен с ВетИС с использованием соответствующих протоколов реализован в сервере обмена данных в формате обмена «Меркурий – Ветис API»:
  
  Для обмена с ВетИС каждая организация получает свои атрибуты и может вести обмен с продуктивным контуром, то есть с областью, где хранятся данные, относящиеся к организации, и с тестовым контуром, где доступны справочные данные и где можно проводить тестирование работы с ВетИС.
  Логин, пароль и ключ ВетИС API - это реквизиты, для подключения к компоненте Ветис.API, которые выдает Ветис.API - Федеральная служба по ветеринарному и фитосанитарному надзору (Россельхознадзор).
  Учетная запись пользователя Меркурий – это логин пользователя, зарегистрированного в подсистеме Меркурий, который может быть создан на сайте {+}https://accounts.vetrf.ru+ администратором хозяйствующего субъекта.
  

  Справочник «Единицы измерения ГИС Меркурий».

  
  
  При обновлении версии содержание справочника не меняется. В нем сохранятся данные, введенные ранее вручную. В текущей версии появилась возможность получить полный перечень единиц измерения Меркурий. Для этого надо нажать кнопку «Запросить единицы измерения ГИС Меркурий» и спустя некоторое время нажать кнопку «Перечитать». Обращение к сервисам ВетИС занимает некоторое время и не отражается на экране без перечитывания справочника.
  Для обращения к справочникам ВетИС необходимо, чтобы в сервере обмена данных был настроен адресат обмена с форматом «Меркурий – Ветис API» и чтобы служба клиента сервера была запущена.
  При получении единиц измерения из сервиса ВетИС и при наличии уже заполненных строк, происходит поиск зависимых единиц измерения и автоматический расчет их коэффициентов пересчета:
  
  Лишние записи можно удалить в режиме редактирования справочника, также как и сопоставить с единицами измерения Супермаг+:
  
  Запрос единиц измерения позволяет получить атрибуты, которые могут потребоваться при передаче в Меркурий других объектов, но не отображаются в таблице справочника. По этой причине, если предполагается проводить прямой обмен с Меркурием, то после обновления версии надо выполнить запрос единиц измерения.
  Для контроля обмена с ВетИС имеется функция «Журнал истории обмена с ГИС «Меркурий»»:
  
  

  Справочник «Площадки ГИС Меркурий».

  
  Площадки в ГИС Меркурий - это функциональные объекты, которые характеризуются ветеринарной функцией и степенью ветеринарной защиты. Одной площадкой может пользоваться несколько хозяйствующих субъектов, также как и один хозяйствующий субъект может вести деятельность на нескольких площадках.
  Под хозяйствующим субъектом понимается субъект, ведущий деятельность и зарегистрированный в ГИС Меркурий. Это понятие не совпадает с юридическим или физическим лицом, поскольку, с точки зрения Меркурия, хозяйствующим субъектом могут владеть разные лица, и они могут меняться во времени, что не меняет сути хозяйствующего субъекта.
  В прошлых версиях понятия хозяйствующего субъекта в Супермаг+ не было. В текущей версии добавлены структуры данных для хранения информации о хозяйствующих субъектах, ассоциированных с площадками ГИС Меркурий.
  В прошлой версии площадки сопоставлялись с местами хранения или с контрагентами, чтобы можно было преобразовывать документы ГИС Меркурий в документы Супермаг+ и наоборот.
  В текущей версии площадки регистрируются вместе с их хозяйствующим субъектом. При обновлении версии эта информация отсутствует и для ее получения надо выполнить запрос данных из ГИС Меркурий:
  
  
  Запрос выполняется только для тех хозяйствующих субъектов, которые описаны в системе:
  
  То есть площадки добавляются в систему только с привязкой к хозяйствующему субъекту и только как объекты, связанные с хозяйствующими субъектами.
  Если данных о хозяйствующих субъектах нет, их можно добавить в режиме редактирования, нажав кнопку «Добавить»:
  
  
  
  Пара: Хозяйствующий субъект – площадка может быть вручную привязана к месту хранению или местам хранения Супермаг+ или к контрагенту. Во избежание проблем с учетом желательно для каждого места хранения в ВетИС регистрировать собственную площадку. Это позволит контролировать остатки подконтрольной продукции в том же разрезе, как и в ГИС Меркурий.
  Для контроля обмена с ВетИС имеется функция «Журнал истории обмена с ГИС «Меркурий»». Функция показывает историю обмена по выделенному хозяйствующему субъекту:
  
  

  Выгрузка в кассу по протоколу УКМ4 XML.

  
  Для поддержки протокола работы ККТ при передаче данных о комиссионных и агентских продажах в алгоритм формирования файла suppliers внесено следующее изменение: при выгрузке тэга <SupplierTel> строка с информацией о телефоне юридического адреса комиссионера обрабатывается для выделения единственного номера телефона и преобразования его к формату, допустимому в ККТ:
• берется часть строки до первой запятой или точки запятой;
• удаляются все символы, отличные от числа;
• если первый символ получившейся строки равен 8, то 8 заменяется на +7, иначе в начало строки добавляется +;
• строка ограничивается 19 символами – предельным количеством символов, допустимых для передачи строки с номером телефона в ККТ.
  

  Перечень исправлений.

• При создании УПД на отгрузку на основании расходной накладной перед его созданием делается проверка: не был ли уже создан такой документ ранее. В текущей версии сообщение «На основании расходной накладной «...» уже создан УПД» расширено указанием номера этого УПД: «На основании расходной накладной «...» уже создан УПД с номером ... от ...».