Изменения функционала в версии 1.0 50
Интервал постановки в почтовую очередь запросов остатков по маркам ЕГАИС.
Правила создания УПД на отгрузку для контрагентов, освобожденных от ЭДО.
Вывод из оборота маркированной продукции.
Проверка КИЗ на выбытие и загрузка в Супермаг Марко.
Подбор накладной поставщика при приеме по заказу поставщику.
Акты переоценки начала и завершения Маркетинговой акции. История изменения цен.
Разбор штрихового кода «маркировка GS 1». Определение веса и объема.
XML протокол. Пересылка КИЗ в спецификации документов.
Функция импорта из XML ArticleByAnyCodeUI.
Перечень исправленных ошибок и улучшений.
WEB сервер лицензирования.
В сервер приложений Супермаг+ добавлена возможность получать лицензионную информацию от WEB сервера лицензирования. В этом случае не требуется получать файл лицензии и не требуется аппаратный ключ.
WEB сервер лицензирования размещен в облачном пространстве и обслуживается силами компании производителя. В комплект поставки Торговой системы сервер лицензирования не входит.
Для работы с WEB сервером лицензирования на компьютере, где работает сервер приложений, исполняющий функцию сервера лицензий Торговой системы, необходимо создать специальную запись в системном реестре с URL сервера лицензирования. При установке или обновлении Торговой системы эта запись не создается и может быть выдана по запросу. При наличии такой записи в интерфейсе администратора сервера приложений в диалоге, доступном при нажатии кнопки «Лицензия БД», появляется кнопка «Лицензирование без ключа через веб-сервер»:
При нажатии на кнопку появляется возможность ввести номер лицензии и пароль, которые выдаются организации при заключении соглашения с компанией производителем:
Номер лицензии соответствует понятию «номер ключа» в случае использования физического ключа. Номер лицензии может быть один для всех баз данных, независимо от того обслуживаются они одним сервером приложений или несколькими.
В случае успешного доступа к серверу лицензирования и наличия в ней лицензии для указанной базы данных, лицензию можно загрузить:
Лицензия, загруженная с веб-сервера, представляет собой зашифрованные данные. Чтобы сервер приложений получил информацию о том, разрешена ли для использования та или иная функция, ему необходимо обратиться к веб-серверу. При получении ответа, ответ кешируется и одновременно сохраняется специальным образом. При рестарте сервера приложений все данные кеша при наличии связи перезагружаются с веб-сервера. Сохраненные ответы при отсутствии соединения могут использоваться до 72 часов.
При старте сервера приложений он будет работать с лицензией, то есть будет выполнять функцию сервера лицензий, только в том случае, если лицензия загружалась с его помощью. При переносе сервера приложений на другой компьютер надо заново загрузить лицензию.
Для защиты от несанкционированного доступа к лицензионной информации обмен данными с веб-сервером происходит по защищенному протоколу, с использованием протокола авторизации OAuth 2 и с подтверждением доступа к аутентичной службе.
Интервал постановки в почтовую очередь запросов остатков по маркам ЕГАИС.
В административный модуль в раздел «База данных» на закладку «Конфигурация» в группу данных «Документы» добавлен атрибут «Интервал (в минутах) постановки в почтовую очередь запросов остатков по маркам ЕГАИС» со значением по умолчанию 35 минут:
Атрибут действует на интервал времени между последовательной отсылкой запросов функцией «Запрос поштучных остатков по РФУ2» в разделе «Остатки ЕГАИС»:
Правила создания УПД на отгрузку для контрагентов, освобожденных от ЭДО.
При смене статуса расходной накладной процедура смены статуса может автоматически на основании расходной накладной создать документ «УПД на отгрузку». Для принятия решения о создании УПД на отгрузку используется следующий алгоритм:
УПД на отгрузку не создается:
- Если не установлен параметр «Учёт кодов КИЗ при приёмке и отгрузке товаров». То есть если принято решение управлять документооборотом УПД вне торговой системы.
- Если операция расходной накладной не «Продажа», «Возврат поставщику» или «Передача товара». То есть операция не подразумевает смену собственника товара.
- Если операция «Возврат поставщику», то для нее УПД на отгрузку не создается, если атрибут контрагента «ЭДО при возврате поставщику» имеет значение «УКД для документа поставки». В этом случае ожидается получение от поставщика УКД для коррекции уже принятой поставки.
Если ни одно из этих условий не выполнено, то УПД на отгрузку создается, если
- у контрагента заполнена доп. характеристика «Идентификатор участника обмена УПД»,
или
- есть марки в накладной,
или
- в накладной есть маркированные товары.
В текущей версии для контрагента добавлен атрибут «Освобожден от обязанности использовать ЭДО»:
По умолчанию флаг не установлен. Атрибут позволяет явным образом исключить создание УПД на отгрузку для отдельных контрагентов, независимо от выполнения других условий генерации УПД.
Аналогичное изменение внесено в функцию проверки расходной накладной 242 «Корректность накладной для создания УПД на отгрузку»: для накладных с контрагентом, освобожденным от использования ЭДО, проверка не выполняется.
Изменение внесено для поддержки следующего исключения из правил ведения электронного документооборота маркированной продукции: «муниципальные учреждения не обязаны подключаться к ЭДО до 01.12.2023».
Вывод из оборота маркированной продукции.
В версии 1.049 сп2 для расходной накладной была создана функция «Списание маркированной продукции» для создания файла с данными о выбытии маркированной продукции, который может быть загружен в ЦРПТ на сайте ГИС МТ. С момента выхода версии ЦРПТ изменил правила формирования файла: ввел новые причины выбытия, отменил ряд прежних причин выбытия и добавил новые условия для выгрузки данных.
В текущей версии алгоритм формирования файла, предлагаемые варианты выбора причины вывода из оборота и соответствующего вида первичного документа приведены в соответствие с актуальными правилами, добавлен ввод идентификатора ФИАС:
Проверка КИЗ на выбытие и загрузка в Супермаг Марко.
В раздел «Подсчет кодов КИЗ» добавлена функция «Проверить выбытие и передать в СММарко».
Функция обрабатывает КИЗ, выбранные из журнала подсчета:
Или все КИЗ, если выбрана другая закладка:
Функция проверяет каждый КИЗ на наличие в спецификации кассовых документов с операцией «Продажа» и «Возврат от покупателя», в спецификации приходных накладных с операцией «Возврат от покупателей» и в спецификации расходных накладных. Если количество расходов КИЗ превысит количество поступлений (возвратов), то КИЗ считается выбывшим. Документы рассматриваются со статусом «Принят в количестве» и «Принят полностью» («розовый» и «зеленый»).
Если КИЗ не выбыл, он ставится в очередь на отсылку в СММарко. Поскольку в процессе подсчета КИЗ все коды марок хранятся в том виде, в котором они были считаны сканером, то есть со всеми спецсимволами и дополнительными полями, то при отсылке КИЗ в СММарко, они предварительно приводятся к виду, рекомендованному ЦРПТ для их передачи в составе УПД.
Подбор накладной поставщика при приеме по заказу поставщику.
В мастере создания приходной накладной при указании заказа поставщику в качестве основания поставки производится поиск накладной поставщика или УПД на приход, созданной на основании этого заказа.
В некоторых случаях поставщики используют процедуру подтверждения заказа и присылают подтверждение заказа с измененным содержанием. В процедуре приема изменений создается новый заказ поставщику с содержанием, соответствующим предложению поставщика. В основании этого заказа указывается первичный заказ поставщику. Новый заказ отсылается поставщику.
В то же время некоторые поставщики формируют поставку и отсылают накладную поставщика / УПД на приход, указывая в ее основании первичный заказ поставщику, который уже признан недействительным и получил статус «Заблокирован». Соответственно, в прежних версиях при приеме поставки с указанием в качестве основания действующего заказа поставщику накладная поставщика не подбиралась, поскольку в ее основании указан другой заказ.
В текущей версии в мастере создания приходной накладной изменен алгоритм поиска накладной поставщика / УПД на приход для указанного заказа поставщику. Если документы, в основании которых стоит указанный заказ поставщику, не обнаружены, то дополнительно ищутся накладные поставщика или УПД на приход, созданные на основании заказа поставщику, который указан в основании текущего заказа поставщику.
Акты переоценки начала и завершения Маркетинговой акции. История изменения цен.
При исполнении актов переоценки применяется правило, по которому запись в журнал изменения цен помещается только, если исполнение акта привело к изменению цены. Если цена артикула не изменилась, в журнале истории запись не появляется.
В текущей версии из этого правила сделано исключение. При исполнении актов начала и завершения маркетинговой акции запись в журнал будет помещаться всегда для каждого артикула акта, даже если исполнение акта не привело к изменению цены артикула.
Изменение внесено для того, чтобы такие артикулы ставились в очередь на загрузку в кассу и при загрузке могли информировать кассу об изменении статуса принадлежности к маркетинговой акции.
Разбор штрихового кода «маркировка GS 1». Определение веса и объема.
В предыдущих версиях при сканировании штрихового кода и опознании его в качестве кода «маркировка GS 1» из кода извлекалась информация о GTIN товара, его серийном номере, цене и т.д. В текущей версии в разбор кода добавлено распознавание кодов применения 310 и 315 – вес нетто товара в килограммах и объем в литрах.
В формате GS 1 идентификатор применения 31 описывается как «Торговая величина» и служит для описания массогабаритных характеристик. Формат идентификатора выглядит как 31 XYVVVVVV , где X – тип величины, в частности 0 – вес в килограммах, 5 – объем в литрах, Y - место десятичной точки в числе VVVVVV . Число состоит из 6 знаков.
Например:
3103003140
Означает, что товар имеет вес 3,140 кг.
Примечание. Идентификатор применения 31 имеет фиксированную длину – 10 символов, и при размещении его к коде GS 1 после поля торговой величины может отсутствовать символ «разделитель полей».
При сканировании штриховых кодов GS 1, если GTIN не указывает на штрихкод с количеством и артикул имеет единицу изменения «кг» и в GS 1 имеется код применения 310, то артикул будет идентифицирован с весом из GS 1. Такое же правило относится к артикулам с единицей измерения «литр» и кодом применения 315.
Примечание. Штриховой код из GTIN не содержит количества, если он зафиксирован в системе, как код «Весовой ШК18».
Почтовый модуль.
XML протокол. Пересылка КИЗ в спецификации документов.
В предыдущих версиях при формировании XML файла документов содержание поля с КИЗ передавались в виде строк с экранированием нечитаемых символов. Для экранирования использовался синтаксис вида: &# x <код символа>, например, символ 1 D «разделитель полей» экранировался следующим образом: &# x 1 D . Этот синтаксис не является общеупотребительным и некоторые XML парсеры его не поддерживают.
В текущей версии строки с КИЗ передаются в формате BASE 64. Исключение сделано для документов «УПД на приход», «УПД на отгрузку» и «Накладная поставщика», где КИЗ представлен по правилам ЦРПТ в виде строк без специальных символов.
Данное изменение надо учесть всем, кто получает или передает документы с использованием третьих систем.
Функция импорта из XML ArticleByAnyCodeUI.
В перечень функций импорта данных из XML файлов добавлена функция ArticleByAnyCodeUI. Функция аналогична функции ArticleBy Supplier CodeUI за исключением того, что в качестве аргументов для определения контрагента используются не данные о его ИНН и КПП, а код клиента Супермаг+. Информация о контрагенте в функции нужна для определения артикула по артикулу контрагента, как одной из возможных альтернатив определения артикула.
В случае использования кода клиента Супермаг+ сам код клиента не обязан быть задан непосредственно в 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> 813098 35</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" - таможенный союз.
Данные поставщика (название, ИНН, КПП) теперь берутся не из данных контрагента накладной, а из данных связанной с ней ТТН (грузоотправителя ТТН).
Перечень исправленных ошибок и улучшений.
- Администратор почтового модуля. Исправлена ошибка: не сохранялись настройки почтового ящика, если после задания значения параметра перейти на другой почтовый ящик и снова вернуться к тому, параметры которого были изменены, и после этого нажать кнопку "Сохранить".
- Сервер обмена данных. Из диалога выбора доверительной базы данных в настройке правил рассылки исключена возможность выбора адресата, чей протокол обмена не подразумевает возможности отсылки произвольного почтового объекта. Аналогичное изменение внесено в диалоги отсылки объектов в разделах Супермаг+.