Изменения функционала в версии 1.033.2 сервис пак 1.
Остатки ЕГАИС. Показ изменения остатков после последнего получения остатков из ЕГАИС.
Классификатор номенклатур и классификатор ассортиментов. Интерфейс правил автоматического пополнения.
DIGI упаковщик 3600 серии. Загрузка ингредиентов, даты истечения годности и даты производства.
Весы DIGI. Загрузка даты истечения годности и даты производства.
Весы DIGI SM-120. Загрузка файлов шаблона этикеток.
Почтовый модуль. Фильтр EDI - системы электронного обмена данными. Отмена лицензирования EDI обмена.

Остатки ЕГАИС. Показ изменения остатков после последнего получения остатков из ЕГАИС.

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

Классификатор номенклатур и классификатор ассортиментов. Интерфейс правил автоматического пополнения.

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

DIGI упаковщик 3600 серии. Загрузка ингредиентов, даты истечения годности и даты производства.

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

Весы DIGI. Загрузка даты истечения годности и даты производства.

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

Для весов DIGI SM-120 дата производства выгружается всегда в отдельное поле строки PLU.

Весы DIGI SM-120. Загрузка файлов шаблона этикеток.

Для драйвера весов DIGI SM-120 Ethernet в настройку весов добавлены элементы для задания путей к файлам шаблона этикетки:

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

Почтовый модуль. Фильтр EDI - системы электронного обмена данными. Отмена лицензирования EDI обмена.

Для беспрепятственного почтового обмена с использованием фильтра «EDI - системы электронного обмена данными» более не требуется файл лицензии.

Изменения функционала в версии 1.033.2 сервис пак 2.
Создание ТТН ЕГАИС на основании расходной накладной с основаниями товародвижения.
Акт постановки на баланс. Поле «Наименование из справки «А»».

Создание ТТН ЕГАИС на основании расходной накладной с основаниями товародвижения.

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

Акт постановки на баланс. Поле «Наименование из справки «А»».

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

Изменения функционала в версии 1.033.2
Лицензионная политика.
Закрытие периода на складе. Опция «Максимальная дата документов, участвующих в расчете товародвижения».
ЕГАИС. Работа с регистром Торгового зала.
Прием ТТН ЕГАИС из файлов формата 2.
Почтовый фильтр «ЕГАИС – обмен данными». Атрибут «Учетный регистр».
Перемещение на регистр торгового зала при приеме ТТН ЕГАИС.
Перемещение с регистра торгового зала на регистр склада при возврате алкоголя.
Списание с регистра торгового зала.
Списание пива с регистра торгового зала по результатам розничных продаж.
Раздел «Остатки ЕГАИС».
Акт постановки на баланс. Подбор справок «А».
ТТН на приход и ТТН на отгрузку. Функция «Признать документ зафиксированным в ЕГАИС».
ТТН на приход, ТТН на отгрузку, Акт постановки на баланс. Функция «Запрос содержания справок «А» из ЕГАИС».
Кассовые документы. Статистика с кодами алкогольной продукции ЕГАИС.
Процесс «Подсчет алкоголя ТСД». Использование штрихового кода EAN.
Алкогольная декларация. Производители / импортёры в справочнике декларации.
Сравнение производителей / импортёров из данных поставщика и справочника декларации.
Перенос производителей / импортёров из справочника декларации в системный справочник.
Контроль соответствия справочников текущей и предыдущей декларации.
Кросс-докинг.
Создание заказов поставщику для аукционных закупок.
Разделы «Заказ поставщику», «Заказ от клиента». Атрибут «Валютный документ».
Касса СМ.+
Прикассовые весы CheckWay SL-100 / DIGI DS-782.
Использование параметров по умолчанию из настроек, сохраненных в серверной базе данных.
Правила пополнения списка ассортиментов и номенклатур товаров.
Классификатор товаров, ассортиментов, номенклатур. Поиск группы классификатора по названию.
Протокол «УКМ4 станд. XML». Выгрузка в кассу информации об упаковках.
Перечень исправленных ошибок и улучшений.

Лицензионная политика.

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

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

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

Если в базу данных загружена одна лицензия - основная, то отображение доступности роли показывается по-прежнему, то есть полным кругом зеленого или красного цвета.
В администраторе сервера приложений на экране управления активными сессиями показывается статистика использования основной и дополнительной лицензий:

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

Закрытие периода на складе. Опция «Максимальная дата документов, участвующих в расчете товародвижения».

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

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

ЕГАИС. Работа с регистром Торгового зала.

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

Прием ТТН ЕГАИС из файлов формата 2.

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

Почтовый фильтр «ЕГАИС – обмен данными». Атрибут «Учетный регистр».

В перечень атрибутов почтового фильтра «ЕГАИС – обмен данными» добавлен атрибут «Учетный регистр». Атрибут может принимать значение «Склад» или «Торговый зал». По умолчанию установлено значение «Склад».

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

Перемещение на регистр торгового зала при приеме ТТН ЕГАИС.

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

Перемещение с регистра торгового зала на регистр склада при возврате алкоголя.

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

Списание с регистра торгового зала.

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

Списание пива с регистра торгового зала по результатам розничных продаж.

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

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

Раздел «Остатки ЕГАИС».

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

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

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

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

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

Акт постановки на баланс. Подбор справок «А».

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

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

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

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

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

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

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


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

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

Для кассового документа создана новая статистика для передачи списка кодов алкогольной продукции ЕГАИС. Коды алкогольной продукции извлекаются из зарегистрированных в чеках кодов PDF417 и сохранятся в таблице SMSpecCashAlcCode, где для пункта спецификации кассового документа сохраняется перечень кодов алкогольной продукции и количество товара для каждого кода алкогольной продукции.
Статистика собирается безусловно (при каждом создании или пересоздании кассового документа) и передается по почте вместе с кассовыми документами. В интерфейсе содержание таблицы нигде не показывается.

Процесс «Подсчет алкоголя ТСД». Использование штрихового кода EAN.

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

Алкогольная декларация. Производители / импортёры в справочнике декларации.

Сравнение производителей / импортёров из данных поставщика и справочника декларации.

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

Перенос производителей / импортёров из справочника декларации в системный справочник.

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

Контроль соответствия справочников текущей и предыдущей декларации.

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

Кросс-докинг.

Под кросс-докингом понимается бизнес-процесс, при котором поставка по заказу поставщику или складскому требованию, сформированному для конкретного места хранения, доставляется исполнителем в другое место хранения, а именно на склад кросс-докинга, из которого поставка в полном составе перемещается непосредственно, или через промежуточные места хранения, в место назначения. Использование складов кросс-докинга в бизнес-процессе заказ-поставка обусловлено оптимизацией количества персонала, обученного принимать первичные поставки от внешних или внутренних поставщиков, и потребностями разделения внешней и внутренней логистики. Под внутренними поставщиками обычно понимают организации, относящиеся к холдингу, но имеющие высокую степень самостоятельности. Исходные требования к внешним поставщикам оформляются в виде заказов поставщикам, к внутренним поставщикам – в виде складских требований.
ПоставщикСклад кросс-докингаСкладМагазин 1*Магазин 2*Заказ поставщикуСклад-ское требо-ваниеПеремещениеПеремещениеПеремещениеПоставка
Документы «Заказ поставщику» и «Складское требование» упомянуты в бизнес-процессе по той причине, что эти документы используются для контроля соответствия параметров поставки (состава поставки, источник и место назначения поставки) исходному требованию. Эти параметры являются ключевыми для планирования и поддержания товарного запаса.
Для поддержки бизнес-процесса кросс-докинга внесены следующие изменения.
В заголовок документов «Соглашение о поставках», «Заказ поставщику», и «Складское требование» добавлено поле «Место хранения кросс-докинга». Если поле не заполнено, то подразумевается, что поставка должна выполняться в место хранение, определенное как место поставки в документе. Поле «Место хранения кросс-докинга» редактируется в статусе «Черновик».
Если поле заполнено, то для места хранения кросс-докинга должно выполняться следующее условие: оно должно быть старшим или равноправным по отношению к месту поставки. Для контроля этого правила создана новая функция проверки 228 «Контроль места хранения кросс-докинга». По умолчанию режим работы функции «Запрет». Функция срабатывает при переводе документа из статуса «Черновик» на следующий статус.
Документ «Соглашение о поставках» в схеме бизнес-процесса используется для генерации заказов поставщику на основании контрактов с поставщиком. В этом случае место хранения кросс-докинга копируется в новые документы «Заказ поставщику».
Заказ поставщику при получении статуса «Размещен» и складское требование при получении статуса «Принят к исполнению» для каждого артикула из своей спецификации формируют количество «Поставка» в месте хранения конечной поставки товара. Это количество учитывается в алгоритмах генерации заказа и складского требования для предотвращения избыточного заказа товара. Документы поставки (приходные накладные и накладные на перемещение), созданные на основании заказа поставщика или складского требования, влияют как на фактические остатки товара, так и на количество «Поставка». Это, в свою очередь, определяет строгие правила приема товара по заказу и складскому требованию, которые контролируются функцией проверки 38 "Соответствие накладных и заказа / складского требования / счета".
В прежних версиях функция проверки требовала совпадения мест хранения приходной накладной / перемещения и заказа / складского требования.
В текущей версии функция проверки разрешает прием приходной накладной не только в место поставки заказа, но и в место кросс-докинга заказа. Функция также разрешает прием перемещения в любое место хранения, если в складском требовании или заказе поставщику из общего основания накладной на перемещение задано место хранения кросс-докинга.
Таким образом, функция проверки позволяет поставить товар или в место поставки заказа / складского требования, или в место хранения кросс-докинга, а затем переместить товар из места хранения кросс-докинга в место назначения, в том числе, через промежуточные места хранения. Для корректного прохождения поставки и для правильного отражения остатков необходимо, чтобы накладные на перемещение товара, первоначально поставленного в место хранения кросс-докинга, имели в общем основании исходный заказ или складское требование.
Функция изменения текущих остатков и функция полного перерасчета остатков изменены таким образом, что уменьшают количество «Поставка» в месте хранения конечной поставки товара при поступлении товара как по приходной накладной, так и по накладной на перемещение, в основании которой находится заказ поставщику или складское требование.
В тех случаях, когда перемещение партии из места хранения кросс-докинга идет сразу в место конечной поставки, то есть не делается перемещение в промежуточные места хранения, можно воспользоваться функцией автоматического создания накладной на перемещение по факту приема поставки в место хранения кросс-докинга. Для этого в административном модуле необходимо в разделе «База данных» на закладке «Конфигурация» в группе данных «Заказы поставщикам» отметить флаг «Генерировать перемещение при приеме поставки в место хранения кросс-докинга». Накладная на перемещение создается в статусе «Черновик» при смене статуса приходной накладной с «Принят на складе» на «Принят полностью». В основание накладной на перемещение помещается приходная накладная и заказ поставщику. Если понизить статус приходной накладной после генерации накладной на перемещение и затем снова повысить статус, накладная на перемещение повторно не создается. Для того, чтобы она была создана, надо предварительно удалить предыдущий вариант накладной.

Создание заказов поставщику для аукционных закупок.

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


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

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

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

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

Разделы «Заказ поставщику», «Заказ от клиента». Атрибут «Валютный документ».

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

Касса СМ+.

Прикассовые весы CheckWay SL-100 / DIGI DS-782.

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

В текущей версии касса может использовать весы CheckWay SL-100 или родственные им DIGI DS-782.
Весы подключаются к COM-порту компьютера. Для проверки работоспособности весов надо нажать кнопку «Тест весов», предварительно включив питание весов. Весы должны работать в режиме передачи веса по запросу. При успешном выполнении теста будет показан порт, к которому подключены весы.

Если флаг «весы CheckWay SL-100 подключены к компьютеру» отмечен, то при всяком старте раздела будет проводиться тест весов для определения их работоспособности. Если весы при старте раздела будут выключены или отсоединены, то на главном экране раздела будет показано сообщение:

Если флаг «весы CheckWay SL-100 подключены к компьютеру» отмечен, то после ввода кода весового артикула будет доступна команда «Весы F2».

При нажатии кнопки F2 вес товара из весов попадает в поле «Количество» и артикул с этим количеством добавляется в чек. Протокол обмена с весами обеспечивает получение веса после успокоения весов.

Если весы будут включены уже после старта раздела, то есть, когда на экране видна надпись «Весы не подключены», нажатие на кнопку F2 позволит проверить их доступность, подключить к кассе и получить вес товара.

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

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

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

• «пинпад подключен к компьютеру»,
• «весы CheckWay SL-100 подключены к компьютеру»,
• «всегда использовать параметры по умолчанию»,
• «адрес УТМ ЕГАИС»,
• «контрагент магазина».
  

  Правила пополнения списка ассортиментов и номенклатур товаров.

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

  Классификатор товаров, ассортиментов, номенклатур. Поиск группы классификатора по названию.

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

  Протокол «УКМ4 станд. XML». Выгрузка в кассу информации об упаковках.

  \\ В протокол «УКМ4 станд. XML» добавлена выгрузка файла KIT_\[\]_\[F\].xml - состав наборов. \\ В файле выгружаются данные о составе артикулов типа «набор» в следующем формате: \\ <kit fullness="F"> <version="1.0"> <item article =""> // minOccurs="0" maxOccurs="unbounded" - артикул типа набор <subItem> // minOccurs="0" maxOccurs="unbounded" <article></article>- артикул товара, входящего в набор <quantity></quantity> - количество артикула состава, десятичное число </subItem > </item> </kit> \\ Файл выгружается с полной информацией обо всех артикулах наборах при полной загрузке и с информацией только об измененных наборах при инкрементальной загрузке кассы. \\

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

• ЕГАИС ТТН на возврат товара. Ошибка формирования ТТН, если в приходной ТТН, по которой делается возврат, для одной строки приходной накладной было несколько строк с одним и тем же алкокодом и разными справками «А», «Б». В ТТН на возврат для строки расходной накладной создавалось две строки ТТН, но с одним и тем же номером справки «А» и «Б».
• Требование на отбор. При выполнении функции «Скопировать документ в другие места хранения» очищается поле «Для операции».
• Требование на отбор. При импорте данных из портативного терминала, количество проставляется в поле «Фактическое количество», а не в поле «Затребованное количество».
• Цены конкурента. Нет функционального права на редактирование меток.
• «УКМ4 станд. XML». Вместо сокращенного наименования единиц измерения в УКМ4 выгружается полное.
• Ошибка формирования физического пакета в формате «ЕГАИС – обмен данными»: "Значение не может быть неопределенным. Имя параметра: outputDiretory".
• Ошибка "ORA-00904: "ID": invalid identifier" при подборе справок «А» в диалоге «Подбор справки «А»» акта постановки на баланс.
• Драйвер весов Штрих SmScaleShtrih.dll требует ручной регистрации после установки Торговой системы «Супермаг+» инсталлятором.
• Расчет товародвижения. Замедление расчета в версии 1.033.1 из-за изменения в обработке операций "Инвентаризация излишков" и "Пересортица (излишек)".
• Акты переоценки, Ведомости базовых цен, Складские требования. Интерфейс заголовка документа помещен на вкладку.
• Планограмма. Элемент интерфейса для выбора места хранения в заголовке документа заменен элементом выбора с использованием классификатора мест хранения.
• Ордер на доставку. При создании ордера на доставку на основании чека или расходной накладной при заполнении спецификации ордера теперь исключаются артикулы типа «Услуга» и «Деньги». При их обнаружении предварительно делается предупреждение.
• Инкрементальная выгрузка артикулов в кассу. Артикул теперь ставится в очередь в кассу при изменении / добавлении / удалении альтернативной единицы измерения "литр" и при изменении таблицы алкогольных кодов артикула.
• В фильтре документов выбор статуса документа из выпадающего списка заменен на выбор нескольких статусов в виде иконок:
  
  
  Изменения функционала в версии 1.033.3 сервис пак 1.
  Инвентаризация ЕГАИС. Функция «Перечитать».
  Подсчет алкоголя ТСД. Выгрузка данных в процесс инвентаризации ЕГАИС.

Дополнительно к описанию в сервис пак добавлены работы, описанные в Изменения1033.1 сп7.doc и Изменения1033.1 сп9.doc

Инвентаризация ЕГАИС. Функция «Перечитать».

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

Подсчет алкоголя ТСД. Выгрузка данных в процесс инвентаризации ЕГАИС.

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

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

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


Изменения функционала в версии 1.033.3 сервис пак 2.
Подсчет алкоголя ТСД. Ввод данных вручную.
Инвентаризация ЕГАИС. Режим редактирования.
Инвентаризация ТСД. Экспорт данных в процесс инвентаризации ЕГАИС.
Остатки ЕГАИС. Акты возврата продукции из торгового зала.

Подсчет алкоголя ТСД. Ввод данных вручную.

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

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

После нажатия на кнопку «Редактировать» в процесс можно вводить данные сканером или вручную до тех пор, пока не будет нажат кнопка «Завершить подсчет». При нажатии этой кнопки процесс закрывается. Если необходимо временно прервать ввод данных надо нажать кнопку «Сохранить» и закрыть окно процесса.
Мастер ввода строки журнала позволяет ввести штриховой код EAN или выбрать артикул, ввести код PDF 417 марки и код DATAMATRIX с серией и номером акцизной марки. Если код DATAMATRIX вводить не требуется, как например для целей инвентаризации ЕГАИС, то его ввод можно отключить с помощью флага «вводить сер. № акц. марки».
Кнопка «Завершить подсчет» позволяет завершить работу по наполнению журнала и перейти к экспорту данных в акт постановки на баланс на регистр склада или в процесс инвентаризации ЕГАИС.
Кнопка «Экспорт данных» доступна только для процессов с завершенным подсчетом.

Инвентаризация ЕГАИС. Режим редактирования.

В разделе «Инвентаризация ЕГАИС», в окно открытого экземпляра процесса добавлена кнопка «Редактировать» и кнопка «Перечитать»:

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

Инвентаризация ТСД. Экспорт данных в процесс инвентаризации ЕГАИС.

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

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

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

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

Остатки ЕГАИС. Акты возврата продукции из торгового зала.

В раздел «Остатки ЕГАИС» добавлена вкладка «Акты возврата продукции из торгового зала» и на вкладку «Акты передачи продукции в торговый зал» помещена кнопка «Вернуть».

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

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

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

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

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

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

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

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

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

Инвентаризационные описи. Экспорт в инвентаризацию ЕГАИС (только пиво).

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

Инвентаризация ЕГАИС. Функции создания актов и инвентаризационных документов.

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

Подсчет алкоголя ТСД. Экспорт данных в процесс «Инвентаризация ТСД». Контроль повторяемости данных.

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


Изменения функционала в версии 1.033.3 сервис пак 5.
Алкогольная декларация. Определение производителя/импортера.
ЕГАИС. Списание алкогольной продукции, переданной в производство.

Алкогольная декларация. Определение производителя/импортера.

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

ЕГАИС. Списание алкогольной продукции, переданной в производство.

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

Изменения функционала в версии 1.033.3 сервис пак 6.
Функция проверки «Соответствие времени поставки заказа поставщику и подтверждения заказа поставщику».
Акты перемещения ЕГАИС, акты списания и постановки на баланс ЕГАИС. Сохранение номера документа, присвоенного ЕГАИС.

Функция проверки «Соответствие времени поставки заказа поставщику и подтверждения заказа поставщику».

Создана новая функция проверки 229 «Соответствие времени поставки заказа поставщику и подтверждения заказа поставщику» По умолчанию функция имеет режим работы «Запрет».
Функция срабатывает при смене статуса документа «Подтверждение заказа поставщику» в основании которого находится «Заказ поставщику». Функция проверяет совпадение даты и времени поставки в заказе поставщику и в подтверждении заказа поставщику.
Соответствующая проверка удалена из функции проверки 213 «Соответствие заказа поставщику и подтверждения заказа поставщику».

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

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

Изменения функционала в версии 1.033.3 сервис пак 7.
Почтовый модуль. Поведение почтовых модулей при отсылке «во все подчиненные».
Контрагенты. Склады контрагента.

Почтовый модуль. Поведение почтовых модулей при отсылке «во все подчиненные».

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

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

В разделе «Контрагенты» на закладке «Склады» изменен интерфейс заведения складов контрагента. Из интерфейса удален элемент «Главный склад» и вместо него в таблицу складов контрагента добавлено поле с флагом «Главный склад». В таблице только одна строка может быть помечена как главный склад.



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

ЕГАИС.

Инвентаризация ЕГАИС.

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

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

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

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

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

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

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

Рассылка по почте объектов ЕГАИС.

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

Контроль совпадения идентификаторов ЕГАИС для разных почтовых ящиков.

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

Карточки складского учета. Производитель / импортер для кодов алкогольной продукции ЕГАИС.

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

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

При создании алкогольной декларации на этапе её создания происходит расчет данных движения по артикулам на основании информации из первичных документов движения Торговой Системы. Такое же действие выполняется функцией «Пересчитать данные». В результате происходит заполнение таблицы «Движение по артикулам», на основании которой формируются данные декларации, представленные в декалитрах в разрезе кодов видов продукции и производителей алкоголя.
В предыдущей версии информация о движении по артикулам бралась из документов товародвижения за период формирования декларации. В документах Торговой системы информация об алкогольных товарах имеется не в полном объеме, в частности в накладных отсутствуют данные о коде группы алкогольного классификатора, а в кассовых документах кроме этого нет информации о производителе алкогольного товара. Данные для алкогольной декларации в этом случае берутся из карточки товара. В действительности и группа алкогольного классификатора и производитель для одного и того же алкогольного товара могут быть разными. Это приводит к тому, что алкогольная декларация после её расчета требует дополнительной ручной обработки для коррекции неточностей.
В текущей версии при формировании алкогольной декларации и при пересчете данных дополнительно используется информация из ТТН ЕГАИС, связанных с приходными и расходными накладными и статистика о кодах алкогольной продукции кассовых документов.
При анализе данных ТТН ЕГАИС проверяется, что коды вида алкогольной продукции, которые встречаются в ТТН, присутствуют в поле «Код» справочника классификатора алкогольной продукции. Решение о том, имеется ли код из ТТН ЕГАИС в справочнике, принимается с учетом того, к какой группе классификатора алкогольной продукции и с каким флагом относится артикул, сопоставленный строке ТТН ЕГАИС. Это ограничение связано с тем, что в справочнике классификатора алкогольной продукции один и тот же код может встречаться дважды – с флагом «пиво» и без флага «пиво». Таким образом, несмотря на то, что ЕГАИС может один и тот же товар относить к разным группам алкогольного классификатора, считается, что ЕГАИС не должен один и тот же товар считать как пивом, так и маркированным алкоголем одновременно.
Если в ТТН ЕГАИС встретился новый код вида алкогольной продукции, для которого нет группы в классификаторе алкогольной продукции, то его необходимо внести в системный справочник «Классификатор алкогольной продукции», прежде чем можно будет сформировать декларацию.
При анализе данных ТТН ЕГАИС, также проверяется, есть ли производитель/импортер из строк ТТН в справочнике производителей/импортеров. Поиск и сопоставление производителей/импортеров осуществляется по ИНН и КПП из данных ТТН и справочника. Если обнаруживается, что в ТТН ЕГАИС имеется производитель/импортер, отсутствующий в справочнике, он будет добавлен в справочник Торговой Системы автоматически.
При анализе кассовых документов информация о группе вида алкогольной продукции и производителе/импортере товара кассовой реализации берется из данных кодов алкогольной продукции (алкокодов), связанных с артикулом товара. Алкокоды артикула для проданного/возвращенного товара берутся из статистики кассового документа. Статистика по алкокодам создается при формировании кассового документа на основании кодов PDF417, переданных вместе с чеками. Коды PDF417 передаются в Торговую Систему в составе чеков по протоколам «УКМ4 станд. XML» и «Супермаг+». Их обработка при приеме чеков осуществляется с версии Супермаг+ 1.033.2.
Статистика передается в базу данных, где формируется декларация, по почте в составе кассового документа. Для использования этих данных необходимо, чтобы кассовые документы содержали эту статистику и были заблаговременно переданы в базу данных. То же касается ТТН ЕГАИС. Они также должны быть переданы в базу данных, где формируется алкогольная декларация, до начала её формирования.
Если в кассовых документах отсутствует статистика по алкокодам, или в базе данных нет ТТН ЕГАИС, то формирование данных для алкогольной декларации осуществляется тем же способом, что и в прежних версиях.

Отчет «Коды алкогольной продукции ЕГАИС».

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

• по коду вида;
• по ёмкости;
• по крепости.
  

  Приходные накладные. Переход к дополнительным расходам.

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

  Бонусы от поставщиков. Сумма для расчета по дате накладной поставщика.

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

  Акт о начислении бонуса. Поля заголовка и спецификации.

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

  Планограмма.

  Размещение товаров на полках списком.

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

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

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

  Выделение артикулов, находящихся в маркетинговой акции.

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

  Таблица артикулов. Фиксация поля «Артикул».

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

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

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

  Административный модуль. Управление заданиями.

  
  В предыдущих версиях настройка и управление запуском периодически исполняемых заданий выполнялась в четырех местах:
• в административном модуле в разделе «База данных» на закладке «Задания» настраивались задания без параметров, такие как, например, перестроение индексов или исполнение актов переоценки;
• в административном модуле в разделе «Аналитика» на закладке «Среднесут. реал-ция»;
• в административном модуле в разделе «Аналитика» на закладке «Заказы»;
• в разделе «Складские требования» в диалоге функции «Задания на генерацию документов».
  В текущей версии управление всеми заданиями сосредоточено в административном модуле в разделе «База данных» на закладке «Задания». Соответственно удалены закладки «Среднесут. реал-ция» и «Заказы» из раздела «Аналитика» и функция «Задания на генерацию документов» из раздела «Складское требование». Также удалены соответствующие функциональные права.
  Задания «Генерация складских требований» и «Расчет среднесуточной реализации» помещены в группу заданий «Функциональные», для задания «Генерация заказов» создана отдельная группа «Задания Сервера приложений».
  Настройка заданий выполнена в виде мастеров, сложность которых зависит от количества параметров в настройке задания.
  В интерфейс закладки «Задания» к фильтру заданий по типу функций добавлен фильтр по конкретной функции.
  

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

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

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

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

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

  Печать копии чека.

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

  Управление настройками работы с ЕГАИС.

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

  Продажа маркированного алкогольного товара. Контроль повторения кодов PDF417 в чеках закрытых смен.

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

  Возврат маркированного алкогольного товара. Контроль кода PDF417.

  
  При продаже маркированного алкоголя по правилам ФСРАР для каждого экземпляра проданного маркированного алкогольного товара считывается и регистрируется код PDF417 алкогольной марки. В прошлых версиях при возврате товара контроль точного соответствия кода возвращаемого товара и строки чека, по которой делается возврат, не осуществлялся. Это могло привести к ошибкам, в частности к невозможности повторной продажи возвращенного экземпляра товара.
  В текущей версии при частичном возврате по чеку, если возвращается позиция маркированного алкоголя, требуется дополнительно просканировать его код PDF417. Возврат разрешается, если код совпадет с кодом в возвращаемой позиции.
  Для быстрого позиционирования на нужной строке чека можно просканировать код PDF417. Если такой код будет найден в чеке, то курсор встанет на нужной строке. Далее надо будет ввести возвращаемое количество, которое для маркированного алкоголя всегда 1, и повторно просканировать код PDF417 для подтверждения возврата.
  При возврате всего чека, если в чеке имеются строки с маркированным алкоголем, кассиру показывается сообщение о необходимости сканирования кодов PDF417 алкоголя. К возврату принимаются только те товары, коды которых совпадут с кодами в чеке.
  Аналогично, при редактировании текущего открытого чека, если потребуется удалить из чека строку с маркированным алкоголем, потребуется подтвердить возврат сканированием кода PDF417.
  

  Сообщения при работе кассы.

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

  Прием по заказу ТСД.

  Отображение цены контракта.

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

  Прием по заказу в месте хранения кросс-докинга.

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

  Подсчет товаров ТСД. Операции перемещения.

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

  Отчет «Отчет о скидках». Опция «Только с ненулевой суммой скидки».

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

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

• Если в накладной все цены заканчиваются на .3 или .9, то сортировка строк по полю по возрастанию или убыванию цены ведется неверно.
• В документе «Сличительная ведомость» не работает сохранение сотрудников, если был изменен только список сотрудников.
• Оптимизирована функция проверки 33 «Корректность документов производства» для убыстрения приема по почте калькуляций.
• В разделах ЕГАИС в фильтре ТТН по местам хранения теперь показываются только места хранения, которые разрешены для просмотра должности оператора.
• Администратор почтового модуля. Диалог настройки почтового модуля и диалог настройки фильтра для отбора строк отсылки и приема сделаны изменяемого размера.
  
  
  
  
  Изменения функционала в версии 1.033.4 сервис пак 1.
  Контрагенты. Описание данных нескольких алкогольных деклараций поставщика.
  Алкогольная декларация. Выгрузка нескольких алкогольных деклараций для поставщика.
  Формирование ТТН ЕГАИС. Простановка цен.
  Драйвер весов «DIGI SM-5000 Ethernet». Настройка весов.

Контрагенты. Описание данных нескольких алкогольных деклараций поставщика.

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

Алкогольная декларация. Выгрузка нескольких алкогольных деклараций для поставщика.

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

Формирование ТТН ЕГАИС. Простановка цен.

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

Драйвер весов «DIGI SM-5000 Ethernet». Настройка весов.

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




Изменения функционала в версии 1.033.4 сервис пак 2.
Карточки складского учета. Вложения для артикула.
Звуковое оповещение при срабатывании функции проверки.
Изменение функции проверки 213 «Корректность документов "Подтверждение заказа поставщику».

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

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

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

Звуковое оповещение при срабатывании функции проверки.

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

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

Изменение функции проверки 213 «Корректность документов "Подтверждение заказа поставщику"».

Из функции проверки 213 «Корректность документов "Подтверждение заказа поставщику"» с режимом работы «Всегда запрет» изъята проверка отсутствия в спецификации подтверждения заказа поставщику артикула из заказа поставщику – основании текущего документа.
Проверка запрещала принятие документа, если в спецификации подтверждения заказа не обнаруживался артикул, имеющийся в заказе поставщику.
Проверка отсутствия артикула основания в спецификации текущего документа, перенесена в проверку 7 «Наличие товара в основании документа», режим работы которой может настраиваться по должностям. Проверка может управляться детальным режимом функции проверки: 6 «Заказ поставщику содержит артикул, отсутствующий в подтверждении заказа поставщику».


Изменения функционала в версии 1.033.4 сервис пак 3.
Периодическое задание «Закрытие заказов поставщикам».
Драйвер весов Bizerba CSV, Bizerba BCII, Bizerba BS 800. Загрузка артикулов с ценой за 0,1 ед.
Прием данных из кассы УКМ4 XML. Определение типа файла по его имени.

Периодическое задание «Закрытие заказов поставщикам».

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

Драйвер весов Bizerba CSV, Bizerba BCII, Bizerba BS 800. Загрузка артикулов с ценой за 0,1 ед.

В драйвер весов Bizerba CSV, Bizerba BCII, Bizerba BS 800 добавлена обработка флага артикула «Ценники за 0,1 ед.». При наличии флага цена артикула выгружается в весы с делением на 10 и в весы выгружается специальный признак «Класс взвешивания», указывающий, что цена соответствует 0,1 кг.
Отказаться от выгрузки цены за 100 грамм можно, если в диалоге старта загрузки весов отметить флаг «Не учитывать флаг «ценники за 0,1 ед.»»:

Прием данных из кассы УКМ4 XML. Определение типа файла по его имени.

\\
В предыдущих версиях тип данных, которые хранятся в файле выгрузки УКМ4 XML определялся по префиксу имени файла, например, по префиксу «shift» отбирались все файлы, содержащие Z отчеты, такие как: «shift_\[4\]_\[111\]_\[1\]_\[1\].xml».
\\
В текущей версии префикс имени включает подчеркивание, например, «shift_», чтобы исключить ошибки определения типа файлов в тех случаях, когда один и тот же набор символов входит в различные префиксы, например, shift и shiftopen.
\\
 \\
Изменения функционала в версии 1.033.4 сервис пак 4.
\\
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Рассылка информации о маркетинговых ценниках.</span></span> |C:\TEMP\4\2\Изменения1033.4 сп4.doc#_Toc483828378]

Рассылка информации о маркетинговых ценниках.

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


Изменения функционала в версии 1.033.4
Документы. Изменение интерфейса.
ЕГАИС.
ТТН на приход. Сопоставление с приходной накладной.
ТТН на расход. Возврат поставщику, контроль ИНН и КПП.
Инвентаризация ЕГАИС. Сверка остатков по артикулам.
Остатки ЕГАИС. Функция «Компенсация отрицательных остатков торгового зала».
Раздел «Коды PDF417 ЕГАИС». Запрос кодов нечитаемых марок.
Склады и магазины.
Инициализация нового магазина.
История изменения флагов места хранения.
Карточки складского учета.
Налоговые группы для артикулов типа «Набор».
История изменения ценников.
Маркировка товара.
Запрос информации о товаре по коду алкогольной продукции в ЕГАИС.
Акты переоценки маркетинговой акции. Прием в старшую базу и установка маркетинговых ценников.
Приходная и расходная накладные.
Транспортный раздел.
Функция «Все товары без НДС».
Функция проверки «Контроль ставки НДС для собственного контрагента - неплательщика НДС».
Расходная накладная. Функция «Проставить дату накладной».
Аукционные заказы. Создание предложения заказа из заказов поставщику.
Планирование контрактных цен. Информационные поля.
Периодическое задание «Регистрация ведомостей базовых цен с нацениванием».
Расчет среднесуточной реализации. Опция «Уменьшать диапазон расчета при наличии маркетинговой акции».
Регистрация платежей.
Фискальный регистратор Штрих-М-01Ф
Регистрация платежа по банковской карте при оплате платежного документа.
Просмотр списка смен.
Предупреждение о превышении суммы чека.
Журнал событий. Закрытие смены.
Поиск товара при отсутствии связи с базой данных.
Редактор XML-схем. Выгрузка значения доп. характеристики артикула.
Процесс «Возврат поставщику ТСД».
Драйвер для загрузки весов DIGI SM-120. Загрузка маркировки.
Драйвер для загрузки весов DIGI SM-5000.
Оборудование.
Сохранение настроек, локальных для компьютера.
Выбор COM-портов с номерами больше 9.
Бизнес-анализ. Кассовые чеки со спецификацией. Поля «Код PDF417» и «Штриховой код».
Административный модуль. Права на управление заданиями.
Открытие периода. Прерывание работы процедуры.
Обрезка базы.
Рассылка обрезки.
Журнал обрезки.
Отчет «Движение по коду алкогольной продукции».
Отчет «Почасовая статистика по группам товаров». Опция «показывать название товара».
Перечень исправленных ошибок и улучшений.

Документы. Изменение интерфейса.

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

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

  ЕГАИС.

  ТТН на приход. Сопоставление с приходной накладной.

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

  ТТН на расход. Возврат поставщику, контроль ИНН и КПП.

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

  Инвентаризация ЕГАИС. Сверка остатков по артикулам.

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

  Остатки ЕГАИС. Функция «Компенсация отрицательных остатков торгового зала».

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

  Раздел «Коды PDF417 ЕГАИС». Запрос кодов нечитаемых марок.

  
  Создан новый раздел для запроса и печати марок алкогольной продукции для товаров с нечитаемыми марками.
  Для получения новых марок в разделе надо создать экземпляр процесса и заполнить его данными с акцизных марок, на которых не читается код PDF417. При создании процесса необходимо указать идентификатор организации в ФСРАР, от имени которой будет создаваться запрос в ЕГАИС.
  При заполнении списка нечитаемых марок необходимо указать серию и номер марки одной строкой и тип марки. При сканировании кода DATAMATRIX алкогольной марки, когда курсор находится в поле «Серия и номер марки», все атрибуты заполняются автоматически по содержанию кода DATAMATRIX. При ручном вводе серия и номер марки переписываются с марки, а тип марки определяется визуально с учетом крепости, ёмкости и категории алкогольной продукции и выбирается из диалога с перечнем типов федеральных марок:
  
  После завершения ввода можно запросить марки в ЕГАИС. После запроса статус процесса меняется, и редактирование данных не разрешается. После получения ответа из ЕГАИС в процессе заполняются поля «Код марки» и «Алк. код» и становится возможной печать кода PDF417 на принтере этикеток.
  Журнал обмена с ЕГАИС в текущей версии для процесса не ведется.
  Для печати этикеток с кодом PDF417 используется шаблон этикеток, заданный в диалоге настройки принтера этикеток в поле «для ЕГАИС»:
  
  В шаблоне этикетки могут использоваться следующие ключевые поля:
  %EGAISPDF417 - код PDF417
  %EGAISMARKRANK - серия
  %EGAISMARKNUMBER - номер
  %EGAISMARKTYPE - тип марки (число)
  %EGAISMARKTNAME - тип марки (название)
  
  Пример шаблона этикетки на языке ZPL:
  ^XA
  ^BY2,3
  ^FO10,100
  ^B7N,5,5,,25,N
  ^FD%EGAISPDF417^FS
  ^CI28
  ^LH10,10
  ^FO10,40
  ^A032,25
  ^FD%EGAISMARKTYPE-%EGAISMARKRANK %EGAISMARKNUMBER
  ^XZ
  Тип, серию и номер марки надо печатать на этикетке, чтобы после печати можно было бы сопоставить её с той бутылкой, на которую её надо наклеить.
  Строки, для которых этикетки распечатаны, отмечаются флажком, и появляется возможность завершить процесс. Следует избегать повторной печати этикеток. Наклеивание на разные бутылки одинаковых этикеток с кодами PDF417 приведет к невозможности легальной продажи этих товаров.
  

  Склады и магазины.

  Инициализация нового магазина.

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

  История изменения флагов места хранения.

  
  В историю изменений атрибутов места хранения добавлено сохранение изменения флагов места хранения. Новое значение флагов показывается в виде числа, которое получено сложением значений флагов места хранения. Если флаг не установлен, его значение равно 0, если установлен, то его вклад в значение флага будет следующим:
  1 – Резервирование запрещено
  2 – Отключить автогенерацию заказов
  4 – Отключить перерасчет остатков
  8 – Контроль исполнения цен
  16 – Учитывать цены обратных перемещений при расчете товародвижения
  128 – Источник цен для перемещения: Место хранения прихода
  256 – Источник цен для перемещения: Старшее место хранения
  512 – Отложенное исполнение актов изменения цены
  2048 – Наценка от полной цены
  16384 – Акты смены цены на СВ копируют цены в учетные. Только для мест хранения типа склад возврата.
  65536 – В кассы загружать только номенклатуру места хранения
  131072 – Флаг «локальный склад» для места хранения типа «склад-магазин» или «склад»
  262144 – Уровень складских запасов минимальный: в количестве
  524288 – Уровень складских запасов максимальный: в количестве
  1048576 – Генерировать складские требования складу на полную потребность (без учета его остатков). Только для мест хранения с пометкой «локальный склад».
  

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

  Налоговые группы для артикулов типа «Набор».

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

  История изменения ценников.

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

  Маркировка товара.

  
  В разделе «Карточки складского учета» на закладку «Склад» добавлена группа элементов «Маркировка товара» с флажками ЕАС, CTM, KVI.
  
  Аналогичные флажки добавлены в фильтр на закладку «Склад».
  По умолчанию флажки не установлены. В текущей версии флажки используются при загрузке товаров в весы, если весы поддерживают печать изображений маркировки.
  

  Запрос информации о товаре по коду алкогольной продукции в ЕГАИС.

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

  Акты переоценки маркетинговой акции. Прием в старшую базу и установка маркетинговых ценников.

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

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

  Транспортный раздел.

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

  Функция «Все товары без НДС».

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

  Функция проверки «Контроль ставки НДС для собственного контрагента - неплательщика НДС».

  
  Создана новая функция проверки 230 «Контроль ставки НДС для собственного контрагента - неплательщика НДС». По умолчанию функция имеет режим работы «Предупреждение».
  Функция проверяет, что ставки НДС во всех строках спецификации равны 0%, если собственный контрагент является неплательщиком НДС. Функция срабатывает при смене статуса накладной с «Принят на складе» / «Отпущен со склада» на «Принят полностью» / «Отпущен полностью».
  

  Расходная накладная. Функция «Проставить дату накладной».

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

  Аукционные заказы. Создание предложения заказа из заказов поставщику.

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

  Планирование контрактных цен. Информационные поля.

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

  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="fe384fa0-f7f7-4354-b849-ca4679831579"><ac:plain-text-body><![CDATA[	Изменение суммы приходов, %	= ([Приходы. Кол-во] * [Новая полная цена контракта1] - [Приходы. Сумма]) * 100 / [Приходы. Сумма]	]]></ac:plain-text-body></ac:structured-macro>
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0a6a882c-bf37-4a3e-868e-fba44931a23e"><ac:plain-text-body><![CDATA[	Изменение цены, %	= ([Новая цена] - [Текущая цена]) * 100 / [Текущая цена]	]]></ac:plain-text-body></ac:structured-macro>
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c3fa372f-97b6-4059-81a0-dac6a9466758"><ac:plain-text-body><![CDATA[	Мин. новая наценка, %	= ([Мин. цена для кассы] - [Новая полная цена контракта1]) * 100 / [Мин. цена для кассы]	]]></ac:plain-text-body></ac:structured-macro>
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="feccee54-ff2e-4c98-9c0d-a6eb639534ce"><ac:plain-text-body><![CDATA[	Мин. текущая наценка, %	= ([Мин. цена для кассы] - [Текущая полная цена контракта]) * 100 / [Мин. цена для кассы]	]]></ac:plain-text-body></ac:structured-macro>
  Мин. цена для кассы	Минимальное значение вида цены для кассы среди всех мест поставки контракта2.
  НДС поставщика, %	Значение поля «НДС поставщика, %» из спецификации контракта.
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ef3521bb-a77d-4286-84d2-ff7ee2d862f9"><ac:plain-text-body><![CDATA[	Приходы. Кол-во,Приходы. Сумма	Общее количество и полная сумма текущего артикула из всех приходных накладных с операцией «Приход» в статусе «Принят полностью» со значением поля «Приход в», совпадающим с одним из мест поставки контракта2.Даты накладных должны попадать в интервал с [D]-[N дней] по [D], где[D] - текущая дата (если раздел находится в режиме "Цены контракта") или дата документа «Прайс-лист поставщика» (если раздел находится в режиме «Исполнение прайс-листа»);[N дней] - значение параметра раздела «Рассматривать приходы за указанное количество дней».	]]></ac:plain-text-body></ac:structured-macro>

  \\ ^1^ Новая полная цена контракта= \[Новая цена\], если цена контракта с НДС;= \[Новая цена\] * (1 + \[НДС поставщика, %\] / 100), если цена контракта без НДС. ^2^ Места поставки контракта - это места поставки из включающих текущий артикул соглашений о поставках в статусе «Принят», в общих основаниях которых находится рассматриваемый контракт с поставщиком. \\

  Периодическое задание «Регистрация ведомостей базовых цен с нацениванием».

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

  Расчет среднесуточной реализации. Опция «Уменьшать диапазон расчета при наличии маркетинговой акции».

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

  Регистрация платежей.

  Фискальный регистратор Штрих-М-01Ф

  
  В разделе «Регистрация платежей» реализован протокол работы с фискальным регистратором «Штрих-М-01Ф». Опознание типа фискального регистратора осуществляется автоматически, если устройство подключено к компьютеру и у него включено питание. При подключении устройства USB-кабелем предварительно надо установить «Драйвер преобразователя USB-RS232» и настроить его. Опознание устройства выполняется опросом доступных COM-портов.
  При работе с «Штрих-М-01Ф» необходимо учитывать, что большинство функций устройства начинают работать только после фискализации устройства. В нефискальном режиме любые функции, связанные с формированием чека, недоступны.
  Важной особенностью Штрих-М, также как и всех ФР с фискальными накопителями, является то, что фискальный накопитель имеет свои собственные часы, время которых не поддается регулировке. Фискальный регистратор Штрих-М, в котором стоит фискальный накопитель, также имеет свои часы, которые можно регулировать, но если их время разойдется с временем ФН более чем на 5 минут, произойдет блокировка работы ФР. По этой причине в случае, если время компьютера, на котором работает кассовая программа, и которое используется для фиксации времени пробития чека, разойдется с временем ФР, необходимо корректировать время компьютера, а не время ФР, как это было в фискальных регистраторах до введения ФЗ-54.
  Другой особенностью ФР Штрих-М является то, что при ошибке печати из-за обрыва или завершения чековой ленты и после установки ленты в рабочее положение, он отказывается работать, пока не будет произведена повторная печать. При этом команду на повторную печать он должен получить от кассовой программы. Такое поведение может привести к полной неработоспособности ФР, если кассовая программа не имеет информации о том, что причиной отказа в работе является случившийся в прошлом обрыв ленты. Так может быть, например, если после обрыва ленты случился сбой по питанию и кассовая программа после запуска ничего не знает о последовательности предыдущих событий. Для таких случаев в экране функции «Оборудование» на закладке «Фискальный регистратор» для регистратора Штрих-М имеется кнопка «Аварийная печать».
  
  
  Этой кнопкой следует пользоваться, если фискальный регистратор выдает ошибку «Ожидание команды продолжения печати», а кассовая программа по какой-то причине не в состоянии самостоятельно обработать такую ошибку.
  Если нажать эту кнопку в случае штатной работы ФР, будет получена сообщение «Команда не поддерживается в данном подрежиме».
  Еще одной особенностью Штрих-М, которая присутствует у всех ФР в силу закона ФЗ-54, является обязательность печати ставки НДС при печати в чеке строки продажи. Информация о ставке НДС и сумме НДС для каждой строки чека отправляется оператору фискальных данных и без этих данных формирование чека невозможно.
  В Штрих-М перечень ставок НДС и их название хранится в таблице ФР. При инициализации ФР эта таблица считывается в кассовую программу. При продаже каждого товара кассовая программа по величине ставки НДС определяет код строки таблицы ФР, которая должна использоваться для формирования строки чека. Для корректной работы ФР необходимо, чтобы перечень ставок НДС в таблице ФР соответствовал тем значениям ставок НДС, которые имеются в налоговых группах артикулов Торговой Системы. Если для артикула будет определена ставка НДС, отсутствующая в таблице ФР, то такая продажа пойдет с нулевой ставкой НДС.
  Если организация – собственный контрагент места хранения кассы, является неплательщиком НДС, то при формировании чека ставка НДС для всех товаров будет считаться нулевой.
  При поиске подходящей строки таблицы ФР кассовая программа просматривает таблицу с первой строки и останавливается при совпадении ставки НДС в строке с искомым значением. Если в таблице ФР имеется несколько строк с одним значением ставки, всегда будет выбираться только одна строка с наименьшим номером. В таблице ФР по умолчанию есть две ставки с нулевым значением НДС – «НДС 0%» и «Без НДС». Если требуется печатать «Без НДС», надо эту строку в таблице разместить выше строки «НДС 0%».
  Значения ставок НДС, переданных в ФР, сохраняются в чеке локальной базы данных для справки. В Торговой Системе эти значения в дальнейшем не используются.
  

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

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

  Просмотр списка смен.

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

  Предупреждение о превышении суммы чека.

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

  Журнал событий. Закрытие смены.

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

  Поиск товара при отсутствии связи с базой данных.

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

  Редактор XML-схем. Выгрузка значения доп. характеристики артикула.

  
  В редактор XML-схем для схем, предназначенных для экспорта информации, добавлена функция «CardPropertyValue», которая позволяет указать в XML-схеме почтового объекта поле для выгрузки значения заданной дополнительной характеристики артикула. Аргументом функции является поле схемы, в которое выводится артикул, и идентификатор дополнительной характеристики, который выбирается из выпадающего списка при настройке аргументов функции.
  Функция может быть использована для выгрузки в спецификации документов значения заданной дополнительной характеристики артикула.
  

  Процесс «Возврат поставщику ТСД».

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

  Драйвер для загрузки весов DIGI SM-120. Загрузка маркировки.

  
  Для весов DIGI SM-120 в интерфейс настройки весов добавлены элементы для указания файлов изображения маркировки товара EAC, CTM, KVI для загрузки их в весы:
  
  

  Драйвер для загрузки весов DIGI SM-5000.

  
  Создан новый драйвер для работы с весами DIGI 5000. Интерфейс настройки и функциональность аналогична весам DIGI SM-Ethernet.
  
  
  К перечню файлов, загружаемых в весы, добавились файлы маркировки товара:
  
  В свойствах модели добавился выбор группы классификатора номенклатур, которая будет загружаться в весы:
  
  Особенностью этой модели весов является сенсорный экран для выбора товара, на котором выводятся группы товаров с изображением группы и / или товары с изображением товаров. При нажатии на группу товаров показываются товары группы или ее подгруппы также со своими изображениями.
  В качестве классификатора товаров на весах используется группа номенклатур, заданная в настройках весов. Выбранная группа используется как корень классификатора весов и должна содержать другие группы, которые будут выводиться в качестве групп первого уровня или товары, если группировать товары не предполагается.
  Для того, чтобы в весы можно было загружать изображение групп товаров в классификатор номенклатур добавлена возможность сохранять изображение:
  
  Изображения для загрузки в весы должны быть в формате BMP или JPEG. Выбор формата настраивается в самих весах. Это относится как к изображениям групп номенклатур, так и карточек складского учета.
  

  Оборудование.

  Сохранение настроек, локальных для компьютера.

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

  Выбор COM-портов с номерами больше 9.

  
  В предыдущих версиях при настройке способа подключения оборудования разрешалось выбирать COM-порты с номерами от 1 до 9. Порты с большими номерами в списке выбора отсутствовали. Это было связано с устаревшим ограничением для старых операционных систем. Сейчас при использовании виртуальных COM-портов для подключения устройств через USB, номера COM-портов могут быть какими угодно.
  В текущей версии это ограничение убрано.
  

  Бизнес-анализ. Кассовые чеки со спецификацией. Поля «Код PDF417» и «Штриховой код».

  
  В модель данных бизнес-анализа «Кассовые чеки со спецификацией» в группу полей «Спецификация чека» добавлены поля «Код PDF417» и «Штриховой код». При выборе этих полей в таблице задачи в них выводятся значения из спецификации чека.
  

  Административный модуль. Права на управление заданиями.

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

  Открытие периода. Прерывание работы процедуры.

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

  Обрезка базы.

  Рассылка обрезки.

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

  Журнал обрезки.

  
  Создан журнал обрезки базы, куда заносится информация о ходе процесса обрезки, о документах, созданных процедурами закрытия периода и обрезки базы, а также информацию о документах товародвижения, удаленных в ходе обрезки базы. Журнал хранится в таблице SMDbTruncLog.
  Интерфейс для отображения журнала отсутствует. Журнал создан для технических нужд.
  

  Отчет «Движение по коду алкогольной продукции».

  
  Создан новый отчет «Товарные – Движение по коду алкогольной продукции ЕГАИС». Отчет предназначен для просмотра документов ЕГАИС по движению алкогольного товара. Документы выводятся отдельно для регистров «Склад» и «Торговый зал» с сортировкой по дате, номеру документа в ЕГАИС и номеру документа в торговой системе. В отчете участвуют следующие типы документов:
• ТТН ЕГАИС на приход / на отгрузку с датой создания в выбранном периоде;
• акты ЕГАИС списания / постановки на баланс с датой создания в выбранном периоде;
• акты ЕГАИС передачи продукции в торговый зал / возврата продукции из торгового зала с датой акта в выбранном периоде. Эти типы документов попадают в отчет дважды: первый раз - как приход в один регистр, второй раз - как расход из другого регистра.
• оприходованные кассовые документы с датой документа в выбранном периоде, если они содержат статистику по алкокодам. Если в администраторе почтового модуля указано место хранения УТМ для выбранного идентификатора организации в ФСРАР, то в отчете будут участвовать только кассовые документы указанного места хранения.
  

  Отчет «Почасовая статистика по группам товаров». Опция «показывать название товара».

  
  В диалог старта отчета «Магазинные - Почасовая статистика по группам товаров» добавлена опция «показывать название товара». Опция активна, если выбрана опция «детально по артикулам». При выборе опции в колонке с артикулами товаров дополнительно выводится название товара.
  

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

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

Создание аукционных заказов. Выбор мест хранений.

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

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

Функция проверки 221 «Ассортиментная матрица: превышение фактической ёмкости над плановой».

Внесено изменение в алгоритм работы функции проверки 221 "Ассортиментная матрица: превышение фактической ёмкости над плановой". В текущей версии функция проверки срабатывает, в том числе, для номенклатурных модулей, для которых не установлена плановая емкость для товарной модели. То есть, если емкость не установлена, она считается равной нулю и функция проверки предупреждает о любом превышении фактической емкости нулевого значения.

Печатная форма счета-фактуры.

В разделах «Приходные накладные», «Расходные накладные» и «Счета-фактуры кассового чека» В заголовок печатной формы счета-фактуры добавлено поле (8) «Идентификатор государственного контракта, договора (соглашения)».


Изменения функционала в версии 1.034 сервис пак 2.
Алкогольная декларация. Импорт остатка предыдущей декларации из файла.

Алкогольная декларация. Импорт остатка предыдущей декларации из файла.

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

При выборе опции «алкогольная декларация системы» функция работает также как и раньше, то есть предлагает выбрать декларацию из которой будут взяты данные.
При выборе опции «XML-файл алкогольной декларации» предлагается указать файл с данными, соответствующими описанию формата из файла 11-o.xsd, для групп данных «Алкоголь» и файл с данными, соответствующими описанию формата из файла 12-o.xsd, для групп данных «Пиво».

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

Изменения функционала в версии 1.034 сервис пак 3.
Регистрация платежей (К). Модель ККТ СП802-Ф.+
Ордер на доставку. Налоги в спецификации документа.
Импорт из портативного терминала в документы. Формат файлов УКМ-Gestori.

Регистрация платежей (К+). Модель ККТ СП802-Ф.

В разделе «Регистрация платежей» поддержана работа с моделью ККТ СП802-Ф, которая работает в рамках закона ФЗ-54. Для работы с ККТ его необходимо подсоединить к компьютеру, на котором работает Супермаг+. Подсоединение может быть как через COM порт, так и через USB порт. В последнем случае необходимо использовать драйверы, эмулирующие COM порт.
После подсоединения и включения устройства для его опознания и регистрации достаточно запустить раздел. Если устройство подключается первый раз, будет предложено зарегистрировать новую кассу с этим устройством. Кассу можно также зарегистрировать заранее, в разделе «Структура магазина/склада».
ККТ 802-Ф обладает следующими особенностями:

• перечень налогов в ККТ фиксированный и не может настраиваться. Перечень состоит из следующих значений: НДС 18%, НДС 10%, НДС 0%, Без НДС, НДС 18/118, НДС 10/110. При сопоставлении налоговой группы Супермаг+ с налогом в ККТ, ищется вхождение строки значения налога НДС артикула в строке налога ККТ.
• В ККТ передается цена артикула без учета скидок, количество и сумма скидки позиции. Цена артикула со скидкой и величина налога рассчитывается ККТ самостоятельно. Скидку на сумму чека ККТ не принимает. В случае, когда клиенту предоставляется скидка на мелочь, кассовая программа распределяет сумму скидки на мелочь по позициям чека таким образом, чтобы сумма позиции со скидкой, деленная на количество, давали бы такую цену, что её округление до копейки не приводило бы к изменению суммы при умножении цены на количество. При таком распределении часть суммы скидки может не распределиться по позициям чека и остаток скидки на мелочь считается кассовой программой скидкой на сумму чека. При работе с СП802-Ф эта часть скидки на мелочь присовокупляется к скидке для позиции с максимальной суммой. В этом случае ККТ может самостоятельно разделить строку позиции чека на две и напечатать чек, отличный от чека в кассовой программе. Сумма чека в кассовой программе и в ККТ будут совпадать.
• ККТ в информации о статусе устройства не предоставляет информации о превышении 24-х часового лимита времени открытой смены. Если лимит превышен, об этом становиться известно только в момент фиксации чека. В этом случае, после получения сообщения об ошибке, необходимо закрыть смену и сформировать чек заново.
• ККТ не имеет возможности сообщить какой будет номер у следующего чека. Соответственно, при формировании нового чека ему присваивается номер -1 и он заменяется на истинный номер при успешной фиксации чека. Если в процессе фиксации произошли ошибки и ККТ не вернул номер чека, то такой чек может остаться в локальной базе данных с номером -1, что означает, что такой чек не был зафиксирован, не может входить в сменный отчет и не может передаваться в базу данных Торговой Системы в качестве оперативного чека. В некоторых случаях отсутствие информации о номере нового чека может создать затруднение. Например, при повторной печати чека, если чек был зафиксирован ККТ, но по какой-то причине ККТ не смог вернуть его номер кассовой программе, для повторной печати чека в ККТ надо указать его номер, который кассовой программе неизвестен.
  ККТ позволяет настраивать содержание текста заголовка чека и нижний колонтитул. Для ввода значений надо вызвать функцию «Оборудование» и перейти на закладку «Чек»:
  
  

  Ордер на доставку. Налоги в спецификации документа.

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

  Импорт из портативного терминала в документы. Формат файлов УКМ-Gestori.

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

Инвентаризация ЕГАИС.

Предупреждение при вводе товара не относящегося к группе алкогольного классификатора.

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

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

Функция «Удалить строки с пустыми алк. кодами».

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

Завершение ввода данных. Контроль наличия кодов алкогольной продукции для всех строк журнала.

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

Сверка остатков ЕГАИС. Алгоритм функции «Подобрать алк. кода».

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

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

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

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

Коды PDF 417 ЕГАИС. Перевод в черновик.

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

Кассовые документы. Поиск связанных с документом ТТН ЕГАИС.

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

При выборе опции помимо поиска связанных документов производится поиск ТТН ЕГАИС:

Отсылка ТТН ЕГАИС. Формирование поля Identity.

В предыдущих версиях при формировании ТТН ЕГАИС в поле Identity помещалось значение номера накладной Торговой системы.
В связи со следующим действием ЕГАИС:
«Московский филиал доводит до Вашего сведения, что на серверной части реализован ФЛК номеров ТТН. В рамках одного календарного дня, система не даст зафиксировать ТТН с одинаковым номером от одного fsrar_id. При этом, если ТТН_1 будет иметь отказанный статус, ТТН_2 с таким же номером и датой зафиксируется, если поле «Identity» в ТТН_2 будет иметь отличное значение от ТТН_1.»
В текущей версии значение поля Identity формируется как номер документа плюс текущая минута и секунда. Изменение позволяет повторно отсылать в ЕГАИС документ, если его предыдущая отсылка была отвергнута ЕГАИС из-за ошибки в документе.



Изменения функционала в версии 1.034 сервис пак 6.
Инвентаризация ЕГАИС. Сверка остатков ЕГАИС при наличии неизвестных кодов алкогольной продукции.
Заполнение спецификации приходной накладной данными упаковочного листа. Контроль превышения количества заказа.
Почтовый модуль. Правила рассылки документов для абонентов типа «Контрагент».
Счет-фактура. Изменение печатной формы постановлением Правительства РФ №981 от 19.08.2017.

Инвентаризация ЕГАИС. Сверка остатков ЕГАИС при наличии неизвестных кодов алкогольной продукции.

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


Если отказаться исключать эти коды из инвентаризации, то строки с этими кодами будут сохранены в таблице и будут показываться красным цветом. Кодам алкогольной продукции красных строк необходимо поставить в соответствие артикулы до завершения работы по инвентаризации. Функция «Завершить ввод данных» не позволит завершить работу при наличии таких кодов:

Заполнение спецификации приходной накладной данными упаковочного листа. Контроль превышения количества заказа.

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

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

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

При попытке настроить другие правила будет показано следующее сообщение:

Счет-фактура. Изменение печатной формы постановлением Правительства РФ №981 от 19.08.2017.

В соответствии с постановлением Правительства РФ №981 от 19.08.2017 в печатную форму счета-фактуры внесены следующие изменения:

• в угловом штампе документа: «(в ред. Постановления Правительства РФ от 19.08.2017 № 981)»
• в шапке документа в пункте 8 добавлены в скобках слова «(при наличии)».
• в табличной части добавлена колонка 1а «Код вида товара». Поля колонки заполняются прочерками в каждой строчке спецификации.
• изменено название колонки 11. Старое название: «Номер таможенной декларации», новое название: «Регистрационный номер таможенной декларации».
• в подвале документа в текстовой части поле «Индивидуальный предприниматель» дополнено словами «или иное уполномоченное лицо».
  
  
  
  Изменения функционала в версии 1.034 сервис пак 6.
  Инвентаризация ЕГАИС. Сверка остатков ЕГАИС при наличии неизвестных кодов алкогольной продукции.
  Заполнение спецификации приходной накладной данными упаковочного листа. Контроль превышения количества заказа.
  Почтовый модуль. Правила рассылки документов для абонентов типа «Контрагент».
  Счет-фактура. Изменение печатной формы постановлением Правительства РФ №981 от 19.08.2017.

Инвентаризация ЕГАИС. Сверка остатков ЕГАИС при наличии неизвестных кодов алкогольной продукции.

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


Если отказаться исключать эти коды из инвентаризации, то строки с этими кодами будут сохранены в таблице и будут показываться красным цветом. Кодам алкогольной продукции красных строк необходимо поставить в соответствие артикулы до завершения работы по инвентаризации. Функция «Завершить ввод данных» не позволит завершить работу при наличии таких кодов:

Заполнение спецификации приходной накладной данными упаковочного листа. Контроль превышения количества заказа.

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

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

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

При попытке настроить другие правила будет показано следующее сообщение:

Счет-фактура. Изменение печатной формы постановлением Правительства РФ №981 от 19.08.2017.

В соответствии с постановлением Правительства РФ №981 от 19.08.2017 в печатную форму счета-фактуры внесены следующие изменения:

• в угловом штампе документа: «(в ред. Постановления Правительства РФ от 19.08.2017 № 981)»
• в шапке документа в пункте 8 добавлены в скобках слова «(при наличии)».
• в табличной части добавлена колонка 1а «Код вида товара». Поля колонки заполняются прочерками в каждой строчке спецификации.
• изменено название колонки 11. Старое название: «Номер таможенной декларации», новое название: «Регистрационный номер таможенной декларации».
• в подвале документа в текстовой части поле «Индивидуальный предприниматель» дополнено словами «или иное уполномоченное лицо».
  
  
  
  
  
  Изменения функционала в версии 1.034 сервис пак 8.
  Сличительные ведомости. Функция «Проставить цены» для вида цены «цены поставки». Управление количеством потоков расчета товародвижения.
  Буферизация сообщений в сервере приложений для пользователей ТСД.

Сличительные ведомости. Функция «Проставить цены» для вида цены «цены поставки». Управление количеством потоков расчета товародвижения.

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



При изменении количества потоков перед выполнением функции расчета необходимо рестартовать программу Супермаг+. Это связано с тем, что количество доступных соединений с базой данных, которые используются потоками расчета товародвижения, резервируется в момент старта программы. Если пользователь не выполняет расчета цен поставки в сличительной ведомости, не следует изменять количество потоков в этом диалоге. Это может увеличить нагрузку на базу данных из-за установления избыточного количества соединений.
При увеличении количества потоков каждый поток выполняет расчет товародвижения одного артикула независимо от других потоков и за счет того, что процессы отбора, сохранения данных и расчета товародвижения в разных потоках выполняются не одновременно, достигается большая равномерность и эффективность использования ресурсов компьютеров клиента и сервера и сокращается время работы функции.
Оптимальное количество потоков для расчета товародвижения зависит от объема памяти компьютеров, количества ядер процессора и/или процессоров, производительности дисков и сети. Для обычных компьютеров при количестве потоков больше 4-х, роста производительности работы функции не наблюдается.

Буферизация сообщений в сервере приложений для пользователей ТСД.

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



Изменения функционала в версии 1.034
Накладные на перемещение.
Транспортный раздел.
Печатная форма «Товарно-транспортная накладная по форме 1-Т».
Ведомость базовых цен. Количество в спецификации документа.
Подтверждение заказа поставщику. Статус «Закрыт».
ЕГАИС.
Обмен с ЕГАИС файлами 2-го формата.
Обмен с ЕГАИС при перемещении товара накладными на перемещение.
Запрос остатков ЕГАИС по расписанию.
Акты списания и постановки на баланс в торговом зале. Редактирование количества.
Подсчет алкоголя ТСД. Оформление розничной продажи алкоголя организациям.
Коды PDF417 ЕГАИС. Получение данных из программы ТСД.
Инвентаризация ЕГАИС. Ввод кода EAN и PDF417 сканером в разрыв клавиатуры.
Алкогольная декларация. Производитель / импортер для кассовой реализации.
Карточки складского учета.
Кода алкогольной продукции ЕГАИС. Производитель.
Фильтр по типу артикулов.
Фильтр по короткому названию с использованием национального алфавита.
История номенклатур. Право на просмотр закладки.
Структура магазина склада. Функция перемещения весов в другой отдел.
Классификатор номенклатур. Право на удаление групп классификатора номенклатур.
Состав номенклатур / ассортиментных матриц. Ввод / вывод товаров из матрицы.
Касса Супермаг.+
Продажа товара по максимальной розничной цене.
Управление скидкой на мелочь.
Автоматическая печать ценников.
Почтовый модуль.
Настройка правил рассылки и сквозной пересылки.
Обработка очереди почтовых объектов.
Бизнес-анализ. Условие фильтра по числовому полю.
Отчеты и печатные формы. Вывод отчета в файл «Страница HTML».
Перечень исправленных ошибок и улучшений.

Накладные на перемещение.

Транспортный раздел.

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

Печатная форма «Товарно-транспортная накладная по форме 1-Т».

Для накладной на перемещение реализована печатная форма «Товарно-транспортная накладная по форме 1-Т»:

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

Ведомость базовых цен. Количество в спецификации документа.

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

Подтверждение заказа поставщику. Статус «Закрыт».

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

ЕГАИС.

Обмен с ЕГАИС файлами 2-го формата.

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

Обмен с ЕГАИС при перемещении товара накладными на перемещение.

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

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

В административном модуле в разделе «База данных» на закладке «Задания» в функциональные типы заданий добавлено задание «Запрос остатков ЕГАИС»:

При настройке задания необходимо задать идентификатор организации в ФСРАР, для которой будут запрашиваться остатки и вариант запроса остатков – в торговом зале или на складе:

В установленное расписанием время в ЕГАИС будет послан запрос для получения соответствующих остатков. В разделе «Остатки ЕГАИС» на соответствующей закладке можно наблюдать ход прохождение запроса в ЕГАИС.

Акты списания и постановки на баланс в торговом зале. Редактирование количества.

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

Подсчет алкоголя ТСД. Оформление розничной продажи алкоголя организациям.

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

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

Коды PDF417 ЕГАИС. Получение данных из программы ТСД.

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

Инвентаризация ЕГАИС. Ввод кода EAN и PDF417 сканером в разрыв клавиатуры.

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

Алкогольная декларация. Производитель / импортер для кассовой реализации.

В текущей версии при составлении алкогольной декларации производитель / импортер для кассовой реализации определяется для артикула как производитель / импортер по умолчанию из таблицы «Производители / импортеры» на закладке «Описание» раздела «Карточки складского учета». Данные о производителе / импортере из таблицы «Коды алкогольной продукции» при составлении декларации более не используются (см. ниже).

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

Кода алкогольной продукции ЕГАИС. Производитель.

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

Фильтр по типу артикулов.

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

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

Фильтр по короткому названию с использованием национального алфавита.

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

История номенклатур. Право на просмотр закладки.

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

Структура магазина склада. Функция перемещения весов в другой отдел.

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

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

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

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

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

Состав номенклатур / ассортиментных матриц. Ввод / вывод товаров из матрицы.

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

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

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


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

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

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

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

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

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

Продажа товара по максимальной розничной цене.

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

Управление скидкой на мелочь.

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

Автоматическая печать ценников.

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

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

Необходимость ведения журнала определяется флагом в диалоге настройки задания:

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

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

Настройка правил рассылки и сквозной пересылки.

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



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

Обработка очереди почтовых объектов.

В текущей версии внесены изменения в способ работы с очередью почтовых объектов. В прошлых версиях почтовый объект, будучи поставлен в очередь объектов на рассылку, изымался из неё только после получения ответа от абонента об успешном приеме объекта. Это было сделано для облегчения повторной отсылки объекта при превышении времени, отведенного на отклик от абонента.
В текущей версии отосланные объекты немедленно изымаются из очереди объектов на рассылку и помещаются в отдельную таблицу SMPostQueueInProcessing. Изменение должно обеспечить большую производительность работы базы данных на операциях формирования почтовых пакетов при наличии в очереди большого количества объектов (миллионы записей). Одновременно с этим проведена оптимизация алгоритмов отсылки и приема объектов для повышения производительности работы почтового модуля.

Бизнес-анализ. Условие фильтра по строковому или числовому полю.

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

Смена условие «ИЛИ» на условие «И» осуществляется кликом мыши на кнопку условия «ИЛИ» («И»).

Отчеты и печатные формы. Вывод отчета в файл «Страница HTML».

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

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

• Редактор XML-схем потребляет лицензию на рабочее место.
• Разделы классификаторов. Закладка «Объекты». Реализован переход к объекту по двойному щелчку мыши.
• Инкрементальная загрузка в кассу. Теперь в очередь на загрузку в кассу ставятся артикулы при изменении цены любого вида цены без флага «Не для кассы», а не только при изменении цены для кассы.
• В стандартном диалоге поиска документа поиск документов по месту хранения теперь ведется, в том числе, по списку дополнительных мест хранений (например, места поставки для соглашений о поставках).
• Ведение журнала ошибок почтового модуля перенесено из файла журнала SmErrorLog...txt в собственный файл журнала SmPostErrorLog...txt.
• Процедура автоматической рассылки и сквозной пересылки теперь использует место хранения кросс-докинга документов «Заказ поставщику», «Складское требование», «Соглашение о поставках» наравне с местом хранения документа для определения абонента для рассылки или пересылки.
• В спецификацию заказа от клиента разрешено добавлять артикулы типа «услуга» и «тара».
• Исправлена ошибка: при сокрытии строк с нулевым приемом в приходной накладной не сохраняется информация об этих строках, специфичная для Беларуси (Цена производителя, Оптовая надбавка, Розничная цена, Сумма трансп. расходов, Регулирование цены).
• Увеличен размер поля для хранения значений меток документов (4000 символов).
• Исправлена ошибка автоматического восстановления соединения кассового модуля с базой данных при обрыве сети: «С базой данных ... и местом хранения ... в настоящий момент уже работает другой экземпляр кассового модуля с компьютера ...»
  
  Изменения функционала в версии 1.035 сервис пак 1.
  Создание аукционных заказов.
  Выбор условий отбора документов для формирования предложения заказа.
  Страница подтверждения мастера генерации аукционных заказов.
  Контроль мест хранения, для которых не сформировано предложение заказа.
  Отчет «Доходность по товарам». Колонки «Кол-во» и «Ед. изм.».
  Отчет «Товародвижение по операциям». Опция «Группировать по местам хранения».
  Отчет «Реализация товаров». Опция «Группировать по местам хранения». Опция выбора артикула.

Создание аукционных заказов.

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

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

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

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

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

Контроль мест хранения, для которых не сформировано предложение заказа.

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

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

Отчет «Доходность по товарам». Колонки «Кол-во» и «Ед. изм.».

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

Отчет «Товародвижение по операциям». Опция «Группировать по местам хранения».

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

Отчет «Реализация товаров». Опция «Группировать по местам хранения». Опция выбора артикула.

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



Изменения функционала в версии 1.035 сервис пак 2.
Буферизация сообщений в сервере приложений для пользователей ТСД.
Функция проверки 128 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят полностью"». Изменение алгоритма.
Аукционные заказы. Дата поставки при создании процесса.
Отчет «Реализация товаров». Доля от итога по местам хранения.
Отчет «Требование ингредиентов для выполнения заданий на производство».

Буферизация сообщений в сервере приложений для пользователей ТСД.

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

Функция проверки 128 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят полностью"». Изменение алгоритма.

В предыдущих версиях функция проверки проверяла цены только в строках с артикулами типа «товар». В текущей версии проверка работает для всех артикулов спецификации приходной накладной.

Аукционные заказы. Дата поставки при создании процесса.

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

Отчет «Реализация товаров». Доля от итога по местам хранения.

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

Отчет «Требование ингредиентов для выполнения заданий на производство».

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

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

Контрагенты. Флаг «При генерации заказов формировать отдельный заказ на каждое соглашение о поставке».

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

Формирование пакета заказов на базе контракта. "Суммарное количество".

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

Изменения функционала в версии 1.035
ЕГАИС.
Подбор кодов алкогольной продукции при списании продаж пива.
Повторное создание кассового документа после отсылки акта списания в ЕГАИС.
Отсылка в ЕГАИС ТТН на отгрузку на основании накладной на перемещение с основаниями товародвижения.
Отсылка документов в ЕГАИС. Предупреждение о том, что дата документа меньше текущей даты более чем на 5 дней.
Списание алкогольной продукции при инвентаризации. Предупреждение при списании большого количества.
Обмен документами формата 3.
Метка документов «Не включать в алкогольную декларацию».
Функция проверки 209 «Дата накладной поставщика больше даты приходной накладной». Режим работы функции проверки.
Карточка складского учета.
Коды алкогольной продукции ЕГАИС. Издатель РФУ1.
Опция расчета среднесуточной реализации.
Поле «Название маркетинговой группы» в таблице отобранных карточек.
Карточка складского учета, классификатор товаров. Коэффициент вариативности.
Управление планом цен.
Цены. Дифференцированное ценообразование.
Справочник «Форматы мест хранений». Параметры дифференцированного ценообразования по умолчанию.
Классификатор списков мест хранения.
Склады и магазины. Функции работы со списками мест хранения.
Генерация аукционных заказов. Использование групп классификаторов и списков мест хранений.
Заказ поставщику, Складское требование. Права на задание места хранения кросс-докинга.
Заказ поставщику. Флаг «Учитывать при автогенерации заказа».
Функция проверки 19 «Контроль минимального количества заказа поставщику».
Алгоритм генерации заказа «Fresh».
Алгоритм генерации заказов «Стандартный». Округление количества до упаковки заказа.
Контракты с поставщиком. Функция «Копировать соглашения о поставках из контракта ...».
Накладная на перемещение.
Причина несоответствия и создание компенсирующих накладных по причинам несоответствия.
Прием фактического количества из ТСД функцией «Чтение накладной из портативного терминала».
Акты потерь и акты обнаружений. Закладка «Вложения и метки» и поле «Комментарий».
Заказы от клиента. Поля «Номер заказа» и «Комментарий». Прием заказа из ТСД.
Отгрузка заказа ТСД. Проставление цен в расходную накладную.
Финансовые обязательства. Выбор даты обязательства и контроль её значения.
Рассылка статистики остатков и статистики продаж.
Редактор XML схем. Преобразование схемы почтового объекта к схеме с другими именами таблиц и полей.
Сервер приложений. Максимальное количество одновременно исполняющихся запросов.
Потоки работ.
Создание мини отчетов и их рассылка по электронной почте и в SMS сообщениях.
Мониторинг ошибок от ЕГАИС.
Печать штриховых кодов штрихами.
Печатная форма «Накладная на перемещение».
Печатная форма «Заказ от клиента».
Печатная форма «Складское требование».
Отчет «Остатки в производстве». Печать цен и сумм.
Перечень исправленных ошибок и улучшений.

ЕГАИС.

Подбор кодов алкогольной продукции при списании продаж пива.

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

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

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

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

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

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

  Отсылка документов в ЕГАИС. Предупреждение о том, что дата документа меньше текущей даты более чем на 5 дней.

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

  Списание алкогольной продукции при инвентаризации. Предупреждение при списании большого количества.

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

  Обмен документами формата 3.

  
  Реализована возможность приема и отсылки ТТН ЕГАИС, а также акта списания в формате 3. Обмен документами формата 2 полностью сохранен и может вестись параллельно с обменом в формате 3.
  В настоящий момент обмен документами в формате 3 доступен только в тестовом контуре.
  

  Метка документов «Не включать в алкогольную декларацию».

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

  Функция проверки 209 «Дата накладной поставщика больше даты приходной накладной». Режим работы функции проверки.

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

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

  Коды алкогольной продукции ЕГАИС. Издатель РФУ1.

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

  Опция расчета среднесуточной реализации.

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

  Поле «Название маркетинговой группы» в таблице отобранных карточек.

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

  Карточки складского учета, классификатор товаров. Коэффициент вариативности.

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

  Цены. Дифференцированное ценообразование.

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

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

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

  Классификатор списков мест хранения.

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

  Склады и магазины. Функции работы со списками мест хранения.

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

  Генерация аукционных заказов. Использование групп классификаторов и списков мест хранения.

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

  Заказ поставщику, Складское требование. Права на задание места хранения кросс-докинга.

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

  Заказ поставщику. Флаг «Учитывать при автогенерации заказа».

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

  Функция проверки 19 «Контроль минимального количества заказа поставщику».

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

  Алгоритм генерации заказа «Fresh».

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

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

  
  В алгоритме генерации заказов «Стандартный» изменен способ округления количества заказа до упаковки заказа в случае, когда потребность в товаре меньше количества упаковки заказа. В предыдущих версиях алгоритм был следующий:
• Количество заказа округляется до величины кратной количеству упаковки заказа по математическим правилам. Если при этом оказалось, что потребность в товаре меньше чем половина упаковки заказа, то заказывается упаковка заказа, но при условии, что минимальный уровень складских запасов артикула (минимум плюс зал) меньше или равен 0.5 упаковки заказа.
  В текущей версии алгоритм следующий:
• Количество заказа округляется до величины кратной количеству упаковки заказа по математическим правилам. Если при этом оказалось, что потребность в товаре меньше чем половина упаковки заказа, то заказывается упаковка заказа, но при условии, что минимальный уровень складских запасов артикула (минимум плюс зал) меньше или равен 0.6 упаковки заказа.
  Новое значение коэффициента определено экспертным путем по результатам длительной эксплуатации алгоритма.
  

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

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

  Накладная на перемещение.

  Причина несоответствия и создание компенсирующих накладных по причинам несоответствия.

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

  Прием фактического количества из ТСД функцией «Чтение накладной из портативного терминала».

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

  Акты потерь и акты обнаружений. Закладка «Вложения и метки» и поле «Комментарий».

  
  В заголовок документов «Акт потерь» и «Акт обнаружений» добавлено поле «Комментарий» и закладка «Вложения и метки».
  

  Заказы от клиента. Поля «Номер заказа» и «Комментарий». Прием заказа из ТСД.

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

  Отгрузка заказа ТСД. Проставление цен в расходную накладную.

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

  Финансовые обязательства. Выбор даты обязательства и контроль её значения.

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

  Рассылка статистики остатков и статистики продаж.

  
  Создан новый почтовый объект «Статистика по текущим остаткам» (SG) с возможностью его автоматической рассылки (таблицы FSGoodsHeader, FSGoods). Объект предназначен для передачи информации об остатках других мест хранения в те места хранения, где отсутствует полный набор документов товародвижения.
  Объект ставится в очередь на рассылку функциональным заданием «Отправка по почте статистики по текущим остаткам». То есть рассылка объекта производится не по событию, например, по изменению текущего состояния остатков, а по расписанию.
  Задание работает только для оприходованных мест хранения. В ходе выполнения задания в статистических таблицах сохраняется информация о текущих остатках и ставится в очередь на отсылку в соответствии с правилами автоматической рассылки. То есть, если правило автоматической рассылки не задано, то в результате работы задания статистика будет собрана, но не будет отослана. Ручная рассылка объекта не предусмотрена.
  Перечень мест хранения, для которых будет собрана и отправлена по почте статистика, может быть задан в параметрах задания.
  Почтовый объект «Статистика по текущим остаткам» представляет собой набор всех артикулов с ненулевыми остатками для места хранения и, следовательно, может быть достаточно большим. Это необходимо учитывать, при составлении расписания запуска задания «Отправка по почте статистики по текущим остаткам».
  Создан новый почтовый объект «Статистика по оперативной реализации» (SD) с возможностью его автоматической рассылки (таблица FSOperGoods). Объект предназначен для передачи информации об оперативной реализации других мест хранения. Поскольку оперативные чеки по почте не рассылаются, объект является единственным способом для получения оперативной информации о продажах в других местах хранения.
  Создано функциональное задание «Отправка по почте статистики по оперативной реализации». При наличии в торговой системе такого задания и после рестарта кассового модуля или клиентской части Супермаг+ (если фиксация чеков производится в разделе «Регистрация платежей») сохранение и / или удаление оперативных чеков будет сопровождаться помещением информации об изменении оперативной реализации в очередь на обработку (таблица FSOperGoodsQueue). То есть, все события, связанные с созданием или удалением оперативных чеков до создания задания «Отправка по почте статистики по оперативной реализации» и рестарта кассового модуля, в отсылку не попадут.
  В ходе работы задания все данные из очереди на обработку перемещаются в статистическую таблицу, и она отправляется по почте в соответствии с правилами автоматической рассылки.
  Объем данных почтового объекта статистики по оперативной реализации зависит от количества чеков, созданных в промежутке времени между двумя отсылками.
  Данные из новых статистических таблиц показываются в разделе «Остатки». В диалог фильтра раздела добавлена опция «Остатки: статистика».
  
  
  При выборе этой опции в таблице остатков отображаются те же колонки, что и при выборе опции «Остатки: текущие» и добавлены две новые колонки «Время обновления остатков» и «Время обновления оперативной реализации». В этих колонках показывается дата и время сбора соответствующей информации в базе-источнике. Также в этом режиме можно очистить информацию о статистике для выбранного или для всех мест хранения с помощью функции «Удалить статистику». Для выполнения функции необходимо иметь функционально право.
  В функциональное задание «Сбор 'мусора'» добавлено удаление из статистических таблиц устаревших данных. Устаревшими считаются все данные старше одного месяца.
  

  Редактор XML-схем. Преобразование схемы почтового объекта к схеме с другими именами таблиц и полей.

  
  В почтовый обмен с использованием XML-фильтра добавлена возможность частичного преобразования данных из одной XML-структуры в другую для того, чтобы можно было осуществить обмен объектами между базами данных разных версий.
  Возможности по преобразованию ограничены. В текущей версии можно осуществлять прием и отсылку данных с изменением названия таблицы и названия полей в таблице.
  Например, в текущей версии в документе «Заказ поставщику» таблица «SMDATEDOCS» заменена таблицей «SMDOCOR», в которой часть полей получили новые названия, в частности поле «DATEDAT» получило название «ORDERDATE», поле «DATEDAT2» название «SUPPLYDATE» и поле «TIMEAT2» название «SUPPLYTIME». То же самое касается полей таблицы SMDOCOС заказа от клиента.
  Преобразование работает в обе стороны, то есть при отсылке происходит создание XML-файла с нужными названиями таблиц и полей, а при приеме информация из таблиц с заданными названиями и полями принимается в нужные таблицы объекта системы.
  В редакторе XML-схем реализована возможность описывать такие изменения, как привязку прежних названий таблиц и полей к новым названиям таблиц и полей.
  Для выполнения этого действия в интерфейсе структуры объекта необходимо удалить новую таблицу кнопкой «Удалить таблицу» и, затем, создать таблицу кнопкой «Добавить таблицу», выбрав опцию «Собственная таблица»:
  
  
  В диалоге «Добавление таблицы» надо ввести название прежней таблицы, которая использовалась в почтовом обмене в предыдущей версии или которая используется внешним контрагентом в качестве аналога таблицы объекта Супермаг+, и выбрать в качестве эталонной таблицы имя ранее удаленной новой таблицы:
  
  
  В результате будет создана таблица с заданным именем и со структурой такой же, как в эталонной таблице. В структуре таблицы необходимо заменить названия полей на те, которые были в прежней таблице и удалить лишние поля:
  
  
  В результате будет создан XSD-файл, который необходимо поместить в каталог со схемами XML-файлов почтового модуля того абонента, который использует прежнюю схему.
  Примеры XSD-файлов со схемами документов OR, OC и OE для обмена документами с базами данных предыдущей версии прилагаются к дистрибутиву версии.
  

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

  
  В интерфейс администратора сервера приложений в диалог «Параметры сессии для базы данных» добавлен атрибут «Максимальное количество одновременно исполняющихся запросов для всех пользователей сервера приложений». По умолчанию установлено значение 50.
  Сервер приложений при обращении к нему клиента Супермаг+ или Супермаг Мобайл формирует запрос для получения данных из базы данных, получает их и отдает их клиенту. В тех случаях, когда обмен с клиентом происходит медленнее, чем с базой данных, информация, полученная из базы данных, начинает копиться в памяти сервера приложения в ожидании, когда клиент сможет её забрать. Такое может случаться, если имеется большое количество обращений от ТСД с запросом большого объема данных (например, карточек и штриховых кодов для инвентаризации). Это может приводить к значительному использованию виртуальной памяти на компьютерах с небольшим объемом оперативной памяти, что приводит к замедлению работы самого сервера приложений и, в том числе, может привести к ошибке «Out of memory».
  Для защиты от избыточного накопления данных в памяти сервера приложений введен контроль над количеством одновременно обрабатываемых запросов клиентов. По умолчанию в памяти могут находиться данные не более, чем для 50 клиентов одновременно. Если в этот момент времени сервер приложений получит запросы от других клиентов, эти запросы будут поставлены в очередь и будут выполнены после того, как данные предыдущих запросов будут переданы по назначению, и количество одновременно обрабатываемых запросов станет меньше заданной величины.
  

  Потоки работ.

  Создание мини-отчетов и их рассылка по электронной почте и в SMS-сообщениях.

  
  При создании нового потока работ предлагается выбрать шаблон для создания нового процесса. В перечень шаблонов добавлены шаблоны для создания мини-отчетов и шаблон для мониторинга работы с ЕГАИС:
  
  
  
  
  Под мини-отчетом понимается сообщение, в которое могут быть добавлены данные, соответствующие текущему значению того или иного параметра, например, сумма текущей реализации или значение остатка товара.
  В мастере создания шаблона для мини-отчета можно задать расписание выполнения процедуры отчета, аналогично тому, как задается расписание выполнения периодических процедур:
  
  
  Расписание задает периодичность выполнения процедуры формирования отчета. Если в результате составления отчета данные в нем окажутся не пустыми, отчет будет отослан адресату в соответствии с настройками отсылки.
  Далее в мастере, в зависимости от типа отчета, предлагается задать фильтр для отбора данных, например, место хранения и группу товаров для отчета по реализации:
  
  
  
  
  В дальнейшем фильтры отчета могут быть скорректированы в интерфейсе редактирования потока работ.
  На странице мастера «текст сообщения» можно задать содержание сообщения, вставив в него переменные, которые будут содержать результат вычисления параметра на момент исполнения отчета:
  
  
  Сообщение может посылаться адресату следующими способами:
  
  
  
• Система сообщений Супермага позволяет передать сообщение в клиентскую часть Супермаг+ или в программу ТСД Супермаг Мобайл и отобразить её на экране оператора.
• Отсылка на электронную почту передает содержание отчета в теле электронного письма.
• SMS на мобильный телефон – позволяет отослать сообщение в виде SMS на заданный телефон.
  Настройка адресата для передачи отчета системой сообщений Супермаг+ заключается в выборе должности или сотрудника, которому будет передано сообщение. При выборе должности в качестве адресата сообщение будет получено всеми сотрудниками данной должности.
  
  
  Настройка отсылки на электронную почту позволяет задать адрес получателя отчета и настроить параметры почтового сервера:
  
  
  
  
  Параметры почтового сервера настраиваются один раз. При создании следующего мини-отчета они используются в качестве значений по умолчанию, и диалог настройки отсылки e-mail не показывается. При необходимости изменить настройки можно в интерфейсе редактирования потока работ. Настройки отсылки e-mail запоминаются для каждого мини-отчета отдельно.
  При выборе отсылки отчета в виде SMS-сообщения необходимо задать номер телефона получателя отчета и задать учетную запись провайдера отсылки SMS-сообщений:
  
  
  
  
  В текущей версии реализована работа с провайдером ООО «СМС-центр». Провайдер предоставляет возможность рассылки СМС сообщений на телефон любого оператора связи. При необходимости, могут быть реализованы алгоритмы работы с другими провайдерами SMS-сообщений.
  В параметрах учетной записи необходимо задать логин и пароль клиента провайдера:
  
  
  Логин и пароль можно получить на сайте провайдера, пройдя регистрацию.
  Поток работ начинает работать при переводе его в статус «Активен» и при условии, что для базы данных запущен хотя бы один сервер приложений с разрешением выполнять потоки работ. После активизации потока работ его работу можно контролировать в разделе «Контроль исполнения потоков работ». Поток работ появляется в этом разделе через некоторое время после активизации, когда сервер приложений начнет его обрабатывать.
  В текущей версии имеются следующие мини-отчеты:
• Реализация - сумма продаж по месту хранения за период времени для группы товаров;
• Поставки - количество приходных накладных с операцией «Приход» за период времени по месту хранения;
• Отрицательные остатки - количество артикулов с отрицательными остатками.
  В каждом отчете имеется по одному параметру, который рассчитывается с учетом заданных в описании потока работ фильтров. Для отчетов «Реализация ...» и «Поставки ...» задается период времени в днях (по умолчанию 7 дней), для всех отчетов - место хранения, для отчета «Реализация ...» - группа товаров, для отчета «Поставки ...» - поставщики.
  При создании потока работ в один поток работ можно поместить несколько отчетов одновременно, тогда сообщение абоненту будет содержать данные всех отчетов, если они не пустые.
  Перечень отчетов и параметров отчетов будет расширяться по выявленным практическим задачам.
  

  Мониторинг ошибок от ЕГАИС.

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

  Печать штриховых кодов штрихами.

  Печатная форма «Накладная на перемещение».

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

  Печатная форма «Заказ от клиента».

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

  Печатная форма «Складское требование».

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

  Отчет «Остатки в производстве». Печать цен и сумм.

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

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

• Заказ поставщику, Подтверждение заказа поставщику. При добавлении артикула / артикулов в спецификацию или при смене места хранения в заголовке документа не перечитывается значение информационных полей «Зал», «Мин.», «Макс.», «Мин. дней», «Макс. дней», «Среднесут. реал-ция», «Потери», «Остатки-потери», «Поставка».
• Акты переоценки. Разный порядок следования полей в режиме просмотра и редактирования.
• Акты переоценки. Кнопка вызова диалога «Расчет новой цены» перенесена из ячейки поля «Расчет цены» в ячейку поля «Цена». Колонка «Расчет цены» удалена. Кнопка доступна в режиме редактирования.
• Контрагенты. Если выбрать группу «Все» в закладке «Списки клиентов» или «Списки поставщиков», то показываются все контрагенты.
• Генерация заказа с учетом маркетинговых акций. Не учитывается коэффициент К2 при расчете заказа, если ССР был рассчитан на следующий день после завершения МА и заказ рассчитывался в тот же день сразу после расчета ССР.
• Изменена структура заголовков документов, которые использовали таблицу SmDateDocs: для заказов поставщикам создана таблица расширения заголовка SmDocOR, для заказов от клиентов создана таблица расширения заголовка SmDocOC, для подтверждений заказов поставщикам данные из SmDateDocs перенесены в уже существующую таблицу SmOrderEndorsement. Таблица SmDateDocs удалена.
• В сервере приложения при журнализации событий событие вида «Превышено время ожидания простоя в (00:20:00).» переведено из категории «Ошибка» в категорию «Предупреждение».
• Исправлена ошибка «Превышено время ожидания простоя в (00:10:00).» при долгом ожидании потоком работ события, требующего действия.
  
  Изменения функционала в версии 1.036.1 сервис пак 1.
  Третий формат.
  Подсчет алкоголя ТСД.
  Подсчет с контролем совпадения кодов PDF417 с содержанием ТТН ЕГАИС на приход.
  Функция создания приходной накладной с привязкой накладной и подсчета марок к ТТН ЕГАИС на приход.
  Режим работы для постановки продукции на баланс.

Третий формат.

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

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

Подсчет с контролем совпадения кодов PDF417 с содержанием ТТН ЕГАИС на приход.

При создании экземпляра процесса «Подсчет алкоголя ТСД» в мастере создания можно указать, что процесс создается для поштучного учета поставки, то есть на основании ТТН ЕГАИС:

Для выбора ТТН ЕГАИС необходимо указать ФСРАР ИД, если их несколько:

И, затем, выбрать необходимую ТТН ЕГАИС на приход:

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

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

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

Если код не относится к поштучному учету, то проверка выполняется для контроля количества товара по ТТН.

Функция создания приходной накладной с привязкой накладной и подсчета марок к ТТН ЕГАИС на приход.

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

Режим работы для постановки продукции на баланс.

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

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

Изменения функционала в версии 1.036.1 сервис пак 2.
Автоматическая генерация заказа поставщику с учетом маркетинговой акции. Коррекция уровня складских запасов.
Подсчет алкоголя ТСД. Контроль считываемых кодов PDF417, для случая прихода одного товара как с поштучным учетом, так и с партионным учетом.

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

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

Подсчет алкоголя ТСД. Контроль считываемых кодов PDF417, для случая прихода одного товара как с поштучным учетом, так и с партионным учетом.

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

Изменения функционала в версии 1.036.1 сервис пак 3.
Заказ поставщику. Поле «Время поставки по ...»
Подсчет алкоголя ТСД на основании ТТН. Выбор идентификатора организации в ФСРАР.

Заказ поставщику. Поле «Время поставки по ...»

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

Подсчет алкоголя ТСД на основании ТТН. Выбор идентификатора организации в ФСРАР.

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


Если идентификатор организации не связан с местом хранения, то в диалоге создания приходной накладной надо задать место хранения поставки.

Изменения функционала в версии 1.036.1 сервис пак 4.
Регистрация платежей.
ККТ СП 801-Ф
Интерфейс для работы с сенсорным экраном.

Регистрация платежей.

ККТ СП 801-Ф

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

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

Интерфейс для работы с сенсорным экраном.

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

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

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

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

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

В этом экране поиск товара производится либо сканированием штрихового кода или вводом части названия товара.

Изменения функционала в версии 1.036.1 сервис пак 5.
Окно старта программы для планшета.
Регистрация платежей.
Интерфейс для сенсорного экрана.
Сканер в разрыв клавиатуры.
Журнал событий.
Трассировка обмена с ККТ СП801-Ф.

Окно старта программы для планшета.

В настройки программы «Переключатель БД» добавлен флажок «Заставка для планшета»:

Если флажок отмечен, то при старте базового модуля Супермаг+ показывается окно старта программы, оптимизированное для сенсорных экранов разного разрешения и разных настроек масштабирования ОС:

Напротив поля «Сотрудник» помещена кнопка вызова виртуальной клавиатуры.

Регистрация платежей.

Прерывание поиска ККТ.
В текущей версии поиск порта, по которому размещен ККТ, визуализирован в окне «Поиск ККТ» с кнопкой прерывания процесса поиска:

После нахождения ККТ по некоторому порту (физическому или виртуальному для USB соединения) порт запоминается и при следующем старте ККТ ищется в первую очередь по ранее запомненному порту. В этом случае поиск выполняется быстро и окно поиска не показывается. Прерывание поиска может быть полезно, если у компьютера имеется множество портов, то есть опрос может занимать значительное время, тогда как, например, требуется перейти в тестовый режим или указать известный оператору порт для доступа к устройству.
При опросе портов теперь в опрос включается и порт, зарезервированный для сканера (если сканер настроен для работы с COM портом), поскольку при динамическом подключении/отключении USB устройств порт, ранее предназначавшийся для сканера может быть занят ККТ. Обычно ОС запоминает порт, который был выделен USB устройству, и не предоставляет его другим устройствам, однако в случае использования USB концентраторов (разветвителей) и попеременного подключения устройств в разные выходы концентратора или напрямую к USB выходу компьютеру, такое пересечение номеров виртуальных портов становится возможным, также как, и в случае ручной очистки зарезервированных портов в ОС.

Интерфейс для сенсорного экрана.

В интерфейс для сенсорного экрана добавлена кнопка «Расчет» (дублируется клавишей «пробел» на клавиатуре при ее наличии):

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

Название кнопки меняется в ходе выполнения расчета для выбора формы оплаты:

«Безнал» означает переключение формы оплаты от текущей – наличные на безналичную, «Нал.» - соответственно, наоборот.

Сканер в разрыв клавиатуры.

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

Журнал событий.

В журнал событий (Функции->Журнал событий) добавлена фиксация события открытия смены.

Трассировка обмена с ККТ СП801-Ф.

Для драйвера ККТ СП801-Ф в функции «Оборудование» на закладке ККТ добавлен флажок «Трассировка обмена с ККТ».

Если флажок отмечен, то обмен с ККТ записывается в файл с именем вида: SMCashLogSP801F1804.txt

Изменения функционала в версии 1.036.1 сервис пак 6.
Альтернативные названия товара.

Альтернативные названия товара.

В разделе карточек складского учета на закладке «Ценники» добавлены элементы «Альтернативное название 1» и «Альтернативное название 2» для ввода дополнительных названий товара с использованием символов UNICODE:

Альтернативные названия могут быть использованы для печати в ценниках:


Изменения функционала в версии 1.036.1 сервис пак 8.
Регистрация платежей. Тест дисплея покупателя.
Весы DIGI SM 5000. Передача в весы картинок разных форматов.

Регистрация платежей. Тест дисплея покупателя.

В функцию раздела «Функция->Оборудование» на закладку «ККТ» добавлена кнопка «Тест дисплея покупателя»:

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

Весы DIGI SM 5000. Передача в весы картинок разных форматов.

В предыдущих версиях в весы передавались картинки формата .bmp. В текущей версии передаются также картинки форматов .jpg, .jpeg и .png. Регистр букв расширения имени файла картинки может быть любой. При передаче в весы регистр расширения приводится к нижнему регистру, а расширение .jpeg к .jpg, то есть к такому виду, который корректно воспринимается весами.



Изменения функционала в версии 1.036.1
ЕГАИС
Третий регистр.
Раздел «Остатки ЕГАИС», закладка «Поштучный учет».
Прием ТТН ЕГАИС 3-го формата с поштучным учетом.
Списание кодов PDF417 при формировании кассовых документов.
Списание кодов PDF417 при вскрытии бутылки.
Продажа и возврат по основанию товародвижения. Алгоритм подбора справок Б .
Контроль формирования и отсылки ТТН ЕГАИС при незаполненном поле «Производитель» алкогольного товара.
Классификатор категорий товаров.
Карточки складского учета.
Копирование параметров ценообразования.
История цен. Комментарий.
Документы. Право на изменение номера документа при его создании.
Приходные накладные. Автоматическая простановка цен из контрактов.
Накладные на перемещение. Беларусь. Наценивание перемещения.
Акты переоценки. Повторный прием акта по почте.
Контракты с поставщиками. Контракты с клиентами. Обязательства склада. Просмотр и редактирование общих оснований.
Контракты с поставщиками. Учет маркетинговых контрактов при подборе цен.
Инвентаризационная опись. Контроль ввода в спецификацию исключенных артикулов.
Процесс «Акт разделки ТСД».
Рецепт. Калькуляция. Печать штриховых кодов.
Товарно-транспортная накладная по форме 1-Т. Пункты погрузки и разгрузки.
Выгрузка в кассу по протоколу УКМ4 XML. Управление выгрузкой налоговых групп.
Перечень исправленных ошибок и улучшений.

ЕГАИС

Третий регистр.

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

Раздел «Остатки ЕГАИС», закладка «Поштучный учет».

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


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

Прием ТТН ЕГАИС 3-го формата с поштучным учетом.

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


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


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


И выбрать необходимый процесс подсчета алкоголя ТСД:


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


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


Детально информацию о составе кодов можно посмотреть, нажав кнопку в поле «Марки»:


Синим цветом показываются коды PDF417, которые были фактически просканированы, но отсутствуют в ТТН ЕГАИС. Если ТТН ЕГАИС не содержит строки с поштучным и партионным учетом для одного и того же алкокода, то такая ТТН не будет отослана в ЕГАИС с сообщением:


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


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



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

Списание кодов PDF417 при формировании кассовых документов.

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

Списание кодов PDF417 при вскрытии бутылки.

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

Продажа и возврат по основанию товародвижения. Алгоритм подбора справок Б.

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

Контроль формирования и отсылки ТТН ЕГАИС при незаполненном поле «Производитель» алкогольного товара.

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

Классификатор категорий товаров.

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

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

Копирование параметров ценообразования.

При массовой обработке карточек «Обработать – Изменение ценообразования» для выбранных артикулов можно установить индивидуальные параметры ценообразования (наценка, шаг цены, предел скидки, минимальная цена, максимальная цена) путем задания конкретных значений. Теперь эти параметры можно установить также путем их копирования из выбранного вида цены. Для этого добавлена опция «Параметры ценообразования … Скопировать из».

История цен. Комментарий.

На закладке «История цен» в таблицу добавлено поле «Комментарий» для вывода причины, по которой цена артикула не была изменена в результате приема акта переоценки из подчиненной базы данных. Если принимаемый акт уже присутствует в базе данных со статусом «Исполнен», то есть уже был ранее исполнен и принят, то в комментарий будет занесен текст «Цена не изменена, т.к. акт был исполнен ранее». Если цена из принимаемого акта не была перенесена в карточку из-за срабатывания контроля порядка исполнения цен, то в комментарий будет занесен текст «Цена не изменена из-за ранее исполненного акта <Номер акта>».

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

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

Приходные накладные. Автоматическая простановка цен из контрактов.

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

Накладные на перемещение. Белоруссия. Наценивание перемещения.

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

Акты переоценки. Повторный прием акта по почте.

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

Контракты с поставщиками. Контракты с клиентами. Обязательства склада. Просмотр и редактирование общих оснований.

В разделы документов «Контракты с поставщиками», «Контракты с клиентами», «Обязательства склада» на вкладку заголовка документа «Главная» добавлен элемент для просмотра и редактирования общих оснований документа.

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

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

Инвентаризационная опись. Контроль ввода в спецификацию исключенных артикулов.

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



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

Процесс «Акт разделки ТСД».

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

Рецепт. Калькуляция. Печать штриховых кодов.

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

Товарно-транспортная накладная по форме 1-Т. Пункты погрузки и разгрузки.

В печатных формах «Расходная накл. : товарно-транспортная накладная по форме 1-Т» и «Накл. на перемещение : товарно-транспортная накладная по форме 1-Т» реализовано заполнение полей «Пункт погрузки» и «Пункт разгрузки» значениями из полей заголовка документа «Адрес погрузки» и «Адрес разгрузки», соответственно.

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

В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Касса» имеется атрибут «Налоги для артикулов» для управления выгрузкой ставок налогов или кодов налоговых групп артикулов в кассу. В предыдущих версиях протокол «УКМ4 станд. XML» игнорировал значение опции и всегда при выгрузке данных об артикуле выгружал значение налоговой группы артикула. В текущей версии, если для опции установлено значение «Не выгружать», то при выгрузке в файле updateItems пропускается тэг <taxgroupId>, в остальных случаях выгружается код налоговой группы артикула.

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

• Исправлена ошибка в функции смены номера документа: «Найдена ТТН ЕГАИС, ссылающаяся на данный документ ORA-04088: ошибка во время выполнения триггера 'SUPERMAG.SMEGAISDOCHEADERLINKDOCD'». Функция не учитывала использование номера документа в документах ЕГАИС.
• Накладная на перемещение, Требования на отбор. К перечню полей таблицы отобранных документов добавлено поле «на основании». Поле добавляется в таблицу в диалоге «Поля таблиц документов» на закладке «Заголовки». Диалог вызывается нажатием кнопки «Поля...».
• Карточки складского учета. Восстановлены всплывающие подсказки к полям таблицы отобранных карточек.
• Процесс формирования пакета заказов на базе контрактов. Увеличены размеры элементов для вывода номеров контракта с поставщиком и соглашения о поставке в заголовке процесса.
• Ордер на доставку на основании чека. Теперь все строки с одним артикулом и одной ценой до скидки складываются в одну строку ордера.
  
  Изменения функционала в версии 1.036
  Меркурий. Прием ВСД.
  ЕГАИС. Списание маркированного алкоголя при вскрытии упаковки (бутылки).
  Акт постановки на баланс ЕГАИС. Изменение содержания справки «А» и повторная отсылка.
  Упаковочные листы. Статус «Распакован».
  Сертификаты / декларации соответствия. Шаблон ввода номера сертификата.
  Функции наценивания. Автоматическое добавление производных артикулов в список нацениваемых.
  Акты переоценки. Функция проверки «Контроль наличия минимальной цены для алкогольного товара».
  Управление планом цен.
  Перечень исправленных ошибок и улучшений.

Меркурий. Прием ВСД.

Для приема и гашения ветеринарных сопроводительных документов создан фильтр почтового модуля «Меркурий-обмен данными» и раздел «Прием ВСД».
Почтовый модуль из заданного каталога принимает пакеты ВСД, связанные с одной поставкой. По протоколу Меркурия одному наименованию продукции должен соответствовать один транспортный ветеринарный сопроводительный документ. По соглашению с провайдерами, работающими с системой Меркурий, от провайдеров для одной поставки приходит один файл, содержащий все транспортные ВСД, относящиеся к этой поставке.
Принятые почтовым модулем пакеты ВСД показываются в разделе «Прием ВСД». Одному пакету соответствует одна строка поставки. Спецификация поставки состоит из перечня ВСД, относящихся к поставке.
В строке спецификации в поле «Объём» показывается количество поставки так, как оно указано в ВСД, и с наименованием единицы измерения из ВСД в поле «Ед. изм.». Если в ВСД название единицы измерения указано не будет, то это поле также не будет заполнено.
Количество поставки в ВСД указывается в некоторой единице измерения системы Меркурий, которая может быть сопоставлена с другой – базовой единицей измерения системы Меркурий с коэффициентом пересчета, который задается в том же ВСД. Для отображения количества поставки в единицах измерения Торговой системы в справочнике единиц измерения необходимо заполнить новое поле «Код ГИС Меркурий» для базовых единиц измерения системы Меркурий. Производные единицы измерения Меркурия сопоставлять с единицами измерения Торговой системы не надо, эти сопоставления использоваться не будут.
Например в ВСД могут быть такие строки:
<vd:volume>25.1</vd:volume>
<vd:unit>
<bs:uuid>0fd4780c-efd0-4f6d-bf10-f4ee7843ce2a</bs:uuid>
<argc:name>т</argc:name>
<argc:fullName>тонна</argc:fullName>
<argc:commonUnitGuid>ff1118b0-1045-485e-8c5d-d051df5c7616</argc:commonUnitGuid>
<argc:factor>1000</argc:factor>
</vd:unit>
Строки «0fd4780c-efd0-4f6d-bf10-f4ee7843ce2a» и «ff1118b0-1045-485e-8c5d-d051df5c7616» - даны в качестве условного примера кодов единиц измерения системы Меркурий. Истинные значения кодов надо брать из описания системы Меркурий или, при ее отсутствии, из примеров ВДС.
Код базовой единицы измерения записан в тэге «argc:commonUnitGuid».
Если в справочнике Торговой системы для базовых единиц измерения указаны коды ГИС Меркурий, то в поле «Количество» строки спецификации будет показано количество поставки с пересчетом в единицу измерения Торговой системы:

В разделе «Прием ВСД» пакету ВСД можно поставить в соответствие приходную накладную со статусом «Принят складом» и произвести сопоставление строк накладной и ВСД из пакета ВСД. Сопоставление производится вручную.
В результате сопоставления в строке ВСД заполняется поле «Фактический объем» в единицах измерения ВСД:

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

Провайдер после обмена данными с системой Меркурий должен вернуть пакет со статусами гашения ВСД.
Статусы могут быть погашен или аннулирован:

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

ЕГАИС. Списание маркированного алкоголя при вскрытии упаковки (бутылки).

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

Акт постановки на баланс ЕГАИС. Изменение содержания справки «А» и повторная отсылка.

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

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

Упаковочные листы. Статус «Распакован».

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

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

  Сертификаты / декларации соответствия. Шаблон ввода номера сертификата.

  
  В мастере создания нового документа «Сертификат / декларация соответствия» на закладке «номер» имеется возможность ввода номера сертификата с использованием шаблона. Шаблон построен с использованием правил формирования номера сертификата в соответствии с требованиями системы сертификации ГОСТ, технических регламентов Российской Федерации и Таможенного союза.
  В текущей версии к перечню шаблонов добавлены шаблоны по требованиям технических регламентов Евразийского Экономического Союза.
  
  Под строкой ввода номера по шаблону показывается строка с результатом формирования номера:
  
  В текущей версии добавлена возможность ввода и запоминания нового префикса для тех случаев, когда изменения законодательства будут опережать изменения программы шаблона:
  
  Собственные значения префикса сохраняются в системном реестре текущего пользователя в ключе HKEY_CURRENT_USER\Software\Service Plus\SuperMag2000\Defaults\DocumentsDefaults SertificateTypes.
  Если префиксы были введены неверно или стали неактуальны, их можно удалить из этого ключа.
  В приходной и расходной накладных при вводе номера сертификата путем выбора из документов Торговой системы более не делается попытки разбора номера по полям шаблона, и номер показывается одной строкой:
  
  
  

  Функции наценивания. Автоматическое добавление производных артикулов в список нацениваемых.

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

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

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

  Управление планом цен.

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

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

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

Загрузка в кассу по протоколу УКМ2 TXT. Передача цены до акции.

\\
В административном модуле в разделе «База данных» на закладке «Конфигурация» в группу данных «Касса» добавлен атрибут «Цена до акции». По умолчанию значение атрибута «Нет».
\\
Если атрибуту назначить значение «поле \[Add1\]», «поле \[Add2\]» или «поле \[Add3\]», то при выгрузке данных в кассу по протоколу УКМ2 TXT в соответствующее поле файла PLUCASH.dat будет выгружаться значение цены до акции умноженное на 100, то есть в копейках.
\\
Если для артикула в момент выгрузки не проводится маркетинговая акция, значение выгружаться не будет. Если в момент выгрузки в кассу для артикула проводится акция, то в указанное поле будет выгружена значение сохраненной цены артикула.
\\
То есть, под ценой до акции подразумевается сохраненная цена артикула или цена, которая будет восстановлена при завершении маркетинговой акции. Эта цена будет иметь то же значение, которое имела цена до начала маркетинговой акции если в ходе акции не исполнялись акты переоценки с новыми значениями цены. Если такие акты исполнялись, то после завершения маркетинговой акции артикул получит цену из последнего исполненного акта переоценки.
\\

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

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

В текущей версии перечень функция дополнен следующими:

Функция StoreLocPropertyValue применима только приходных и расходных накладных, поскольку использует данные транспортного раздела накладных. Функция сличает данные адреса погрузки/разгрузки внешнего контрагента с адресами его складов и, если такой склад находится, то возвращает значение комментария для этого склада.


Изменения функционала в версии 1.037.1 сервис пак 2.
Установка встроенной базы данных.
Склады и магазины. Инициализация места хранения. Копирование уровней складских запасов
Поиск подходящего контракта на дату заказа.

Установка встроенной базы данных.

В текущей версии СУБД Firebird 2.0.7 встроенной базы данных заменено на версию 2.2.8. Замена СУБД не влияет на содержание и структуру встроенной базы данных клиента Супермаг+.

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

В разделе «Склады и магазины» при нажатии кнопки «инициализация» для выбранного магазина показывается экран «Инициализация места хранения». На закладке «Логистика» имелась опция «Скопировать уровни складских запасов активных артикулов, входящих в номенклатуру склада инициализируемого места хранения, из места хранения:». В текущей версии она заменена опцией: «Скопировать уровни складских запасов активных артикулов из места хранения:».
То есть, в предыдущих версиях выбор опции приводил к копированию уровней складских запасов только для артикулов из номенклатуры нового (инициализируемого) места хранения, в текущей версии копируются уровни складских запасов всех активных артикулов, если они есть в эталонном месте хранения.

Поиск подходящего контракта на дату заказа.

В алгоритм поиска подходящего контракта на дату заказа, то есть на дату выставления заказа поставщику (эта дата может отличаться от даты документа «Заказ поставщику») внесено следующее изменение: при поиске маркетинговых контрактов теперь ищутся маркетинговые контракты действовавшие иди действующие на дату заказа, а не на дату документа для которого выполняется этот поиск.
Функция применяется в функции «Заполнить документ ценами из контрактов» приходной накладной и в функциях проверки 128 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят полностью"» и 185 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят на складе"»

Изменения функционала в версии 1.037.1 сервис пак 3.
Драйвер весов DIGI SM-Ethernet. Печать названия товара.
Драйвер весов DIGI SM-120 Ethernet. Управление загрузкой.

Драйвер весов DIGI SM-Ethernet. Печать названия товара.

В драйвер весов внесено следующее изменение – при печати названия товара на этикетке шириной 58 мм в режиме «Уменьшать размер шрифта на второй строке»:

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

Драйвер весов DIGI SM-120 Ethernet. Управление загрузкой.

В диалог загрузки весов по протоколу DIGI SM-120 Ethernet добавлены флажки «Клавиши клавиатуры» и «Синхронизация даты и времени»:

По умолчанию флажки установлены и эти данные загружаются в весы, что соответствует поведению в предыдущих версиях.

Изменения функционала в версии 1.037.1
Установка Супермаг.+
Настройка работы с Oracle Provider for OLE DB.
Установка отчетов при работе с сетевым каталогом.
64-x разрядные службы Супермаг.+
Сервер лицензий. Ключи Sentinel, HASP и Guardant.
Справочники «Доп. характеристики товара», «Доп. характеристики контрагента», «Доп. характеристики дисконтных карт», «Доп. характеристики склада».
ЕГАИС. Новый формат акцизной марки.
ИНН сотрудника.
Регистрация платежей.
Тестовая касса.
Вызов функции блокировки экрана через функции раздела.
Оплата заказа от клиента.
Интерфейс кассы с плиточным размещением товаров на экране.
ККТ СП802-Ф. Версия программного интерфейса 11.1
Структура магазина/склада. ИНН кассира.
Выгрузка в кассу по протоколу УКМ4 XML. Название дополнительной характеристики, ИНН кассира.
Почтовая рассылка. Отсылка команды удаления документа при удалении места хранения.
Генерация платежей. Простановка в документы платежа банковских атрибутов контрагентов
Документ «Складское требование». Информационные поля «Остаток в месте хран. "В"», «Поставка», «Среднесут. реал-ция.»
Документ «Маркетинговая акция». Дата фактического завершения акции.
Расчет среднесуточной реализации. Учет времени фактического окончания акции.
Перечень исправленных ошибок и улучшений.

Установка Супермаг+.

Настройка работы с Oracle Provider for OLE DB.

В предыдущей версии Microsoft Oracle Provider for OLE DB, который использовался для доступа к базе данных Oracle, был заменен на Oracle Provider for OLE DB. Новый провайдер для своей работы использует компоненты клиента Oracle. Если на компьютере установлено несколько клиентов, то используется компонент последнего установленного клиента Oracle. В тех случаях, когда после установки клиентов Oracle, произошли изменения в порядке использования клиентов (например, изменился порядок путей к каталогам клиентов Oracle в переменной окружения Path), зарегистрированный при последней установке клиента компонент Oracle Provider for OLE DB не будет соответствовать версии текущего используемого клиента и работа Супермаг+ будет невозможной из-за ошибок в работе провайдера.
В текущей версии, при установке Супермаг+ анализируется, какой из клиентов Oracle является приоритетным, и производится регистрация его компонента, отвечающего за работу Oracle Provider for OLE DB.
Если уже после установки Супермаг+ будет изменен порядок путей к клиентам Oracle, то надо будет вручную зарегистрировать компонент вида OraOLEDB12.dll (цифра в имени файла зависит от версии клиента Oracle), либо повторно установить Супермаг+.

Установка отчетов при работе с сетевым каталогом.

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

64-разрядные службы Супермаг+.

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

Сервер лицензий. Ключи Sentinel, HASP и Guardant.

Примечание. Сервер лицензий - это часть сервера приложений, отвечающая за работу с лицензиями.
Сервер лицензий более не поддерживает работу с ключами Guardant.
В сервер лицензий добавлена возможность работы с ключами Sentinel.
Ключи Sentinel и HASP аппаратно создаются в одном корпусе и известны под названием SentinelHASP, но имеют разные протоколы работы и разные возможности. То есть, один физический ключ внутри себя содержит два разных ключа, работающих по разным протоколам. Когда происходит обращение к ключу, он опознает протокол и управление передается нужному типу ключа.
Ключи SentinelHASP имеют несколько серий выпуска. Текущая серия, выпускаемая в синем корпусе, и предшествующая ей серия в красном корпусе малой длины содержат оба ключа и могут работать по обоим протоколам. Еще более ранняя серия, которая выпускалась 10 лет назад, в красном корпусе большой длины может работать только по протоколу HASP.
Проверить принадлежность ключа к версии Sentinel можно в администраторе сервера приложений, нажав кнопку «О программе». Если ключ относится к новым сериям, то в диалоге будет запись как о ключе HASP, так и о ключе Sentinel:

Если установлен ключ заведомо новой модели, а в диалоге имеется только запись о ключе HASP, необходимо проверить, что при обновлении или установке версии выбран компонент «Сервер приложений – Компоненты сервера лицензий - Драйвер ключа HASP / Sentinel».
При работе сервера лицензий в 64-битном исполнении доступен только драйвер ключа Sentinel. Ключ HASP 64-битного драйвера не имеет.
Лицензии для ключа Sentinel и для ключа HASP различаются и при создании лицензии необходимо выбирать тип ключа, с которым будет работать лицензия. После загрузки лицензии в базу данных сервер лицензии будет работать с ключом по протоколу, указанному в лицензии.

Справочники «Доп. характеристики товара», «Доп. характеристики контрагента», «Доп. характеристики дисконтных карт», «Доп. характеристики склада».

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

• При сохранении данных диалога «Дополнительная характеристика» проверка на уникальность названия характеристики сделана не чувствительной к регистру символов.
• В диалог редактирования дополнительной характеристики добавлена кнопка «А -> Я» для сортировки списка значений характеристики в алфавитном порядке. При выходе из диалога по кнопке «OK» установленный порядок сортировки сохраняется.
  Порядок сортировки при выводе значений характеристики (например, на вкладке «Описание» раздела «Карточки складского учета») задается кнопками со стрелками в диалоге дополнительной характеристики. Кнопка «А -> Я» служит для автоматизации работы в тех случаях, когда порядок вывода должен соответствовать алфавитному порядку.
• Добавлена строка поиска строки значения характеристики по первой части строки (по суффиксу).
• В справочник «Доп. характеристики товара» добавлен флажок «Обязательна». Когда флажок установлен, то при активизации карточки товара будет выполняться проверка на наличие в карточке значения дополнительной характеристики.
  Сделана проверка 232 «Контроль задания обязательной дополнительной характеристики для карточки», которая срабатывает при активизации карточки.
  

  ЕГАИС. Новый формат акцизной марки.

  
  ЕГАИС опубликовал формат новой акцизной и федеральной специальной марки, которая заместит текущие марки, и изменил методологию поштучного учета. По текущей методологии поштучный учет должен вестись для всех экземпляров алкогольной продукции, для которой в приходной ТТН имеются марки, независимо от того, относятся ли они к маркам нового или старого образца. В предыдущей методологии поштучный учет велся только для той продукции, для которой количество марок в приходной ТТН равнялось количеству продукции.
  Соответственно, в текущей версии при приеме ТТН ЕГАИС на третий регистр переводятся все марки, пришедшие в составе ТТН.
  Новые марки будут печататься кодом DataMatrix (вместо кода PDF417) и будут содержать следующую информацию:
  Тип марки (3 символа) + Серия марки (3 символа) + Номер марки (8 символов)+ Служебная информация ЕГАИС (7 символов) + Контрольная сумма и электронная подпись, созданная при помощи СКЗИ по ГОСТ (129 символов)
  ИТОГО: 150 символов.
  Пример состава штрихового кода:
  101100261679680118001D5CCFC794963898C1B13E41231CKY42T7UDIJJY2AWLHS7HPGINLMY7PQPDNJALVS42WNCHYRCO257SPCSCF4ASM37BZNTLIASYRVGFUTCXDXDJPML5MMVLEEHZWPWJVI
  Предыдущие марки содержали следующую информацию:
  Номер Версии ПС ЕГАИС (3 символа) + Зашифрованный в кодировке Base36 код продукции (алкокод) (16 символов) + Номер заявки на печать (12 символов) + номер марки на печать (6 символов) + электронная подпись (31 символ)
  Новые марки больше не содержат информацию о коде алкогольной продукции. Код алкогольной продукции при сканировании марки теперь можно определить только с помощью справок РФУ2, в которых эти марки перечисляются при поступлении алкогольной продукции.
  Соответственно, в процессе «Подсчет алкоголя ТСД», созданного на основании ТТН, при сканировании марок нового образца информация о коде алкогольной продукции теперь берется из ТТН.
  Аналогичные изменения внесены в программу Супермаг Мобайл, режим «Подсчет алкоголя».
  Также в программе Супермаг Мобайл в режиме «Контроль марок» (который раньше назывался «Контроль кодов PDF417») при выборе варианта работы «Проверка наличия марок на 3-м регистре - Проверять марки: только нового образца / все марки» при сканировании марок выполняется обращение к серверу для проверки наличия марки на третьем регистре. В этом режиме работы ТСД должен иметь постоянное Wi-Fi-соединение.
  Первоначально процесс контроля марок был предназначен для проверки читаемости марок и подготовки данных для получения от ЕГАИС новых кодов PDF417. В связи с появлением марок нового образца эта функция будет терять значение. Для новых марок не предусмотрено получение новых кодов. Процесс предполагается использовать для внутренней проверки принятой алкогольной продукции и для выявления ошибок учета, когда, например, при продаже или отгрузке была просканирована одна бутылка, а отгружена другая.
  

  ИНН сотрудника.

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

  Регистрация платежей.

  Тестовая касса.

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

  Вызов блокировки экрана через функции раздела.

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

  Оплата заказа от клиента.

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

  Интерфейс кассы с плиточным размещением товаров на экране.

  
  В текущей версии создан вариант интерфейса кассы, который позволяет выбирать товар нажатием на зону экрана с названием и изображением товара. Для нормальной работы такого интерфейса необходимо создать группу в классификаторе категорий или древовидную ветвь в этом классификаторе, если предполагается, что торгуемых товаров будет много, и назначить группам необходимые товары. На экран будут выводиться только товары, назначенные группам классификатора. Если группам будут назначены не все товары, загружаемые в кассу, то остальные товары можно будет вводить сканером или традиционным выбором из списка товаров, отобранных по части названия.
  Для самих товаров необходимо сохранить подходящие изображения в разделе карточек складского учета на закладке «Склад». Пропорции изображения, то есть соотношения длины и ширины картинки, желательно иметь одинаковыми для всех картинок. При выводе изображения на экран кассы пропорции картинок не меняются, чтобы не вносить искажения во внешний вид товара. Исходный размер картинок для товаров может быть любой. При сохранении картинки для артикула сохраняется как исходная картинка, так и ее уменьшенная копия размером не больше 300х300 точек, которая в дальнейшем и используется для работы с кассой.
  В разделе «Структура магазина / склада» в диалог настройки кассы типа «Супермаг+» добавлена возможность указать группу классификатора категорий, которая будет использоваться для формирования списка товаров на экране кассы:
  
  В разделе «Регистрация платежей» на закладку «Вид экрана» функции «Параметры раздела» добавлен флажок «выводить список товаров на экране работы с чеком»:
  
  Флаг можно отметить только совместно с флагом «сенсорный экран».
  Группа классификатора категорий товаров, указанная в настройках кассы, используется в качестве корневой группы и не показывается в интерфейсе кассы.
  
  В верхней правой (левой - для левостороннего экрана) зоне экрана показывается линейный список групп классификатора категорий. При старте экрана и после пробития чека показывается список групп первого подуровня от корневой группы. Нажатие на группу позволяет показать связанный с ней список товаров на экране или перейти к следующему уровню групп, если группа является промежуточной. Если классификатор состоит из единственной группы, то её список товаров будет показываться сразу, а интерфейс будет иметь вид, как при нажатой кнопке «☰».
  Нажатие на кнопку «☰» справа от классификатора товаров позволяет заменить список групп списком функций, как в случае простого сенсорного интерфейса:
  
  Нажатие на кнопку «⑆» позволяет вернуться к классификатору.
  Кнопка «☰» справа от списка товаров позволяет изменить количество плиток товаров, выводимых на экран и способ сортировки:
  
  Кнопка «❖» позволяет раскрыть или сжать список артикулов за счет зоны экрана спецификации чека:
  
  Кнопки «>» и «<» позволяют листать список товаров, если они не помещаются на одном экране.
  Двойной щелчок по плитке товара позволяет получить информацию о товаре:
  
  Однократное нажатие на плитку товара позволяет перейти к вводу количества:
  
  При наличии прикассовых весов вес можно получить, нажав кнопку «Enter». При использовании сенсорных экранов клавиатура может отсутствовать и кнопка F2, с помощью которой вводится вес с весов, недоступна. Кнопка «Enter» выполняет ту же функцию, при условии, что поле «Количество» пусто.
  

  ККТ СП802-Ф. Версия программного интерфейса 11.1

  
  В текущей версии поддержана работа с ККТ СП802-Ф с программным интерфейсом 11.1. Прошивка с программным интерфейсом 11.1 поддерживает протокол налоговой инспекции ФФД 1.05. До 1 января 2019 года на всех ККТ СП802-Ф необходимо обновить прошивку для работы с этим протоколом в связи с прекращением действия протокола ФФД 1.0
  В соответствии с протоколом в ККТ дополнительно передается ИНН кассира при открытии, закрытии смены и при пробитии чека, в строке чека передается единица измерения товара. Признак способа расчета – всегда полный расчет, признак предмета расчета - товар. Новые атрибуты, за исключением признака расчета, в форме стандартного чека не отображаются, но передаются ОФД.
  ИНН кассира также передается в ККТ СП801- Ф.
  

  Структура магазина / склада. ИНН кассира.

  
  В разделе «Структура магазина / склада» в свойствах отдела на закладке «Персонал - Кассиры» в перечень полей добавлено поле «ИНН».
  

  Выгрузка в кассу по протоколу «УКМ4 станд. XML». Название дополнительной характеристики, ИНН кассира.

  
  В протокол выгрузки данных по протоколу «УКМ4 станд. XML» внесено следующее изменение:
  В файле выгрузки данных артикула updateItems тэг <addProperty> (информации о значении дополнительной характеристики) дополнен атрибутом <name> - названием дополнительной характеристики. Теперь тэг <addProperty> имеет следующий вид:
  <addProperty> // minOccurs="0" maxOccurs="unbounded"
  <id></id> (код доп.характеристики в СМ+)
  <name></name> (название дополнительной характеристики в СМ+)
  <value></value> (значение дополнительной характеристики артикула)
  </addProperty>
  В файле выгрузки storeCashiers добавлен тэг INN. Тэг выгружается, если заполнено поле ИНН для кассира в разделе «Структура магазина / склада».
  <storeCashiers fullness="F" storeId="">
  <version="">
  <cashier> // minOccurs="0" maxOccurs="unbounded"
  <id></id> (целое число больше 0)
  <name></name> (символьная строка – 40 символов)
  <password></password>(символьная строка – 15 символов)
  <INN></INN> (ИНН кассира, если есть)
  </cashier>
  </storeCashiers>
  
  

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

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

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

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

  Документ «Складское требование». Информационные поля «Остаток в месте хран. "В"», «Поставка», «Среднесут. реал-ция».

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

  Документ «Маркетинговая акция». Дата фактического завершения акции.

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

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

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

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

• При установке обновления Супермаг+ производилось замещение содержания каталога BIN\Sberbank данными из дистрибутива Супермаг+. Это приводило к сбросу настроек работы с пинпадом. В текущей версии содержание каталога \Sberbank при обновлении версии не меняется.
• Регистрация платежей. Если в разделе указано, что пинпад подключен к компьютеру, но в действительности он не подключен, то в предыдущих версиях при проверке наличия пинпада блокировался порт, прописанный в настройках пинпада, независимо от того, включен ли пинпад или нет. В текущей версии, если при проверке наличия пинпада он не обнаруживается, его порт освобождается и может использоваться другими устройствами.
• При выборе пункта меню "Мониторинг состояния базы" возникала ошибка "Критическая ошибка SEH: ACCESS_VIOLATION, код = 0xc0000005. Состояние программы нестабильно. Как можно быстрее завершите приложение."
• Исправлена ошибка. Расходные накладные. Простановка оснований по срокам годности удаляла срок годности из спецификации.
• Исправлена ошибка – кассовый сервер продолжал выгрузку по расписанию после остановки сервера лицензий.
• Внесено изменение в протокол обмена с Супермаг Мобайл, которое позволяет программе при сканировании весового штрихового кода определять единицу изменения артикула. Для штучных товаров количество в весовом штриховом коде кодируется в штуках для весовых товаров - в граммах. Изменение внесено в программу Супермаг Мобайл 1.6.1008.30.
• Исправлена ошибка: Редактор XML-схем почтовых объектов. Если функция имеет в качестве параметра значение из списка, например, имя дополнительной характеристики, то повторное редактирование поля, например, чтобы поправить название поля, добавляет пробелы к имени значения.
• Протокол выгрузки в кассу «УКМ4 станд. XML». Добавлена обработка значения свойства штрихового кода. При длине свойства больше 20 символов такое значение свойства не выгружается. Сам штриховой код выгружается. В предыдущих версиях выгрузка значения свойства длиной больше 20 символов при штриховом коде приводила к ошибке в УКМ4 «Импортирование завершено с ошибкой».
• Исправлена ошибка. В процессе «Прием перемещения ТСД» если в накладной на перемещение один артикул присутствовал в нескольких строках, то при подсчете фактически принятого количества все количество относилось к одной строке артикула.
• Процедура сборки мусора. Расширено условие очистки таблицы SMCollectDiscCardQueue - очереди накопительных дисконтных карт, требующих перерасчета накопительных скидок. Ранее очистка таблицы происходила, если в базе не было локальных мест хранения, по которым возможна выгрузка данных на кассу. Теперь очистка происходит, в том числе, если тип данных "Дисконтные карты" не выбран для полной и не выбран для инкрементальной выгрузки ни для одной из кассы. Отсутствие этого условия могло приводить к бесконтрольному росту количества записей в таблице.
• Почтовый модуль. При приеме почтовых объектов с включенным параметром «Контроль версий почтовых объектов» в таблице SMPostObjVersion сохраняются идентификаторы всех принятых по почте объектов. В текущей версии в таблицу более не добавляются записи с неустановленной версией объекта. В задание «Сборка мусора» добавлено условие: удалять из таблицы все объекты с версией больше чем годичной давности, а если параметр «Контроль версий почтовых объектов» отключен, то очищать таблицу полностью.
• При попытке исполнения отчёта в дизайнере FastReport могла возникнуть ошибка "Ключ не может быть использован в указанном состоянии", если была повреждена информация в системном реестре. Теперь при возникновении подобной ситуации выводится диалог ввода параметров подключения к БД, и данные заново сохраняются в реестре. Такой же диалог показывается при первом обращении дизайнера отчётов к БД.
  
  
  
  
  Изменения функционала в версии 1.037
  Использование Oracle Provider for OLE DB.
  Установка 64-х разрядной версии служб Супермаг.+
  ЕГАИС
  Поштучный учет ЕГАИС.
  Расходная накладная. «Формирование и отсылка ТТН в ЕГАИС» для расходной накладной с операцией «Списание брака». Списание марок с 3-го регистра.
  Приходная накладная. Функция «Заполнение из процесса подсчета алкоголя ТСД».
  Процесс «Подсчет алкоголя ТСД». Экспорт данных «в накладную на перемещение с созданием ТТН ЕГАИС».
  Постановка на баланс пива, возвращенного через кассу.
  Процесс «Подсчет алкоголя ТСД». Положение в дереве разделов.
  Алкогольная декларация. Движение по артикулам.
  Карточки складского учета. Функциональная роль «Редактирование карточки в статусе "Исключена"».
  Выбор контрагента. Столбец «КПП».
  Формирование заказа на базе контракта.
  Поиск строки по артикулу, названию товара или по штриховому коду.
  Поле «Маркетинговый контракт».
  Поле «Остатки на складе возврата».
  Приходная и расходная накладные. Адрес погрузки и разгрузки.
  Приходная накладная. Функция «Заполнить документ ценами из контрактов» для операции «Поступление инвентаря».
  Контракты с поставщиком. Функция «Проставить общие основания».
  Функция проверки 106 «Запрет принятия маркетингового контракта без основания».
  Системная дополнительная характеристика товара «Разрешён возврат поставщику».
  Функция проверки 105 «Наличие товара с признаком "Разрешён возврат поставщику"».
  Детализация функции проверки 65 «Запрет понижения статуса документа - общего основания» для заказа поставщику.
  Функция проверки 231 «Контроль параметров счета-фактуры и накладной поставщика».
  Функции проверки 128, 134, 185, 186. Операция "Поступление инвентаря".
  Функции проверки 134, 186. Артикулы типа "Инвентарь".
  Процесс «Акт разделки ТСД».
  Процесс «Прием заказа ТСД». Счет-фактура поставщика.
  Процесс «Контроль ценников ТСД». Печать ценников с группировкой по элементам планограммы.
  Регистрация платежей.
  Управление интерфейсом.
  Просмотр смен, чеков и позиций чеков.
  Работа с ККТ СП801-Ф.
  Протокол «УКМ4 станд. XML». Прием данных о дисконтных картах для скидок с типом, отличным от «персональная скидка».
  Отчет «Списание и естественная убыль».
  Печать бейджика сотрудника для аутентификации в программе Супермаг Мобайл.
  Печать ценников весовых товаров.
  Перечень исправленных ошибок и улучшений.

Использование Oracle Provider for OLE DB.

В текущей версии внесены изменения в работу с СУБД Oracle, а именно для работы с СУБД Oracle теперь используется Oracle Provider for OLE DB вместо Microsoft Oracle Provider for OLE DB. Использование Microsoft Oracle Provider for OLE DB в предыдущих версиях было обусловлено тем, что Oracle Provider for OLE DB не обеспечивал необходимой надежности при работе с ранними версиями СУБД Oracle, в частности, при работе с Oracle 8i.
В связи с прекращением поддержки Microsoft Oracle Provider for OLE DB компанией Microsoft, использование провайдера при работе .Net приложений с 32-х разрядным клиентом Oracle 12 и работа с 64-битными приложениями C++ оказались невозможными. В предыдущих версиях системы это приводило к необходимости использовать для работы клиент иной версии Oracle (например, клиент Oracle 11 для работы с СУБД Oracle 12). В текущей версии этот недостаток исправлен.
Современная версия Oracle Provider for OLE DB работает с СУБД Oracle версий 10,11 и 12. Oracle Provider for OLE DB использует компоненты клиента Oracle и устанавливается при установке клиента. Во время установки клиента регистрируется один из компонентов Oracle Provider for OLE DB с именем OraOLEDBxx.dll, где хх – номер версии клиента. Если на компьютере установлено несколько клиентов, то зарегистрированным будет компонент от последнего установленного клиента. Если после этого производить замену рабочего клиента путем перестановки путей в переменной окружения Path, то может возникнуть ситуация, когда компоненты Oracle Provider for OLE DB будут браться из разных клиентов. Это будет приводить к ошибке вида: «Клиент Oracle некорректно установлен или не зарегистрирован OraOLEDB12.dll (либо OraOLEDB11.dll, OraOLEDB10.dll...)». В таком случае надо зарегистрировать компонент от текущего рабочего клиента с помощью команды regsvr32.
При создании отчетов в новой версии Супермаг+ и при необходимости их использования в предыдущих версиях Супермаг+ нужно открыть файл отчета в текстовом редакторе и заменить текст, идущий в кавычках после «ReferencedAssemblies=» на следующий:
System.dll System.Drawing.dll System.Windows.Forms.dll System.Data.dll System.Xml.dll System.Data.OracleClient.dll Sm.Objects.dll Sm.Interfaces.dll Sm.Core.dll Sm.Forms.dll Sm.AppServer.Interfaces.dll Sm.AppServer.Link.dll Sm.FastReports.dll Sm.FastReports.Link.dll
То есть, надо поменять заголовок отчета на тот, который был бы сгенерирован, если бы отчет разрабатывался в версии 1.036.1 и раньше.
 
Отчеты созданные в предыдущих версиях в текущей версии исполняются без каких-либо модификаций.

Установка 64-х разрядной версии служб Супермаг+.

Создана программа установки служб Супермаг+ в 64-х разрядном исполнении для 64-х разрядных операционных систем Windows. В комплект установки входят все службы Супермаг+ и программы администрирования служб. Базовый модуль Супермаг+, по-прежнему, имеет только 32-х разрядную реализацию. Сервер лицензий – компонент сервера приложений, также имеет только 32-х разрядную реализацию, то есть 64-х разрядная реализация сервера приложений не выполняет функции сервера лицензий.
64-х разрядные программы могут использовать всю оперативную память компьютера без ограничений. 32-х разрядные программы не могут использовать оперативную память за пределами 4-х ГБ и прекращают свою работу, когда для программы требуется выделить больше 4-х ГБ памяти.
При установке файлы 64-х разрядных компонентов программ размещаются в каталоге .\Bin64.
Службы и программы в 64-х разрядном исполнении имеют те же имена, что и в 32-х разрядном. Соответственно, на одном компьютере могут быть установлены либо 32-х разрядные службы, либо 64-х разрядные. Несмотря на то, что 32-х и 64-х разрядные программы устанавливаются в разные каталоги, операционная система не позволяет функционировать разным службам с одними и теми же именами.
При совместной установке 32-х разрядной и 64-х разрядной версий служб Супермаг+ работать будет тот вариант, который установлен последним.
При удалении установленных компонентов производится удаление всех установленных компонентов, вне зависимости от того, в каком варианте они были установлены.
Соответственно, во избежание путаницы, рекомендуется, по возможности, устанавливать на один компьютер либо только 32-х разрядную версию Супермаг+, либо 64-х разрядную.
При установке 32-х и 64-х разрядных версий Супермаг+ необходимо учитывать, что программы разной разрядности работают с клиентом Oracle разной разрядности. То есть, 32-х разрядные программы работают с 32-х разрядным клиентом, а 64-х разрядные программы работают с 64-х разрядным клиентом Oracle. Также надо учитывать, что клиенты Oracle разных разрядностей имеют разные файлы TNSNAMES.ORA и информацию о базах данных надо заносить в оба файла синхронно или настраивать путь к одному файлу в настройке TNS_ADMIN Oracle Home.
Базовый модуль Супермаг+ и администраторы служб могут взаимодействовать со службами Супермаг+ при любом сочетании вариантов исполнения.

ЕГАИС

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

Поштучный учет ЕГАИС.

В Торговую Систему добавлена модульная роль «Поштучный учет ЕГАИС» с тремя функциональными ролями:

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

  Расходная накладная. «Формирование и отсылка ТТН в ЕГАИС» для расходной накладной с операцией «Списание брака». Списание марок с 3-го регистра.

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

  Приходная накладная. Функция «Заполнение из процесса подсчета алкоголя ТСД».

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

  Процесс «Подсчет алкоголя ТСД». Экспорт данных «в накладную на перемещение с созданием ТТН ЕГАИС».

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

  Постановка на баланс пива, возвращенного через кассу.

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

  Процесс «Подсчет алкоголя ТСД». Положение в дереве разделов.

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

  Алкогольная декларация. Движение по артикулам.

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

  Карточки складского учета. Функциональная роль «Редактирование карточки в статусе "Исключена"».

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

  Выбор контрагента. Столбец «КПП».

  
  В диалог выбора контрагента в таблицу списка контрагентов добавлен столбец «КПП»:
  
  Поле «КПП» добавлено в перечень колонок для поиска строки с контрагентом.
  

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

  Поиск строки по артикулу, названию товара или по штриховому коду.

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

  Поле «Маркетинговый контракт».

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

  Поле «Остатки на складе возврата».

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

  Приходная и расходная накладные. Адрес погрузки и разгрузки.

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

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

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

  Контракты с поставщиком. Функция «Проставить общие основания».

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

  Функция проверки 106 «Запрет принятия маркетингового контракта без основания».

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

  Системная дополнительная характеристика товара «Разрешён возврат поставщику».

  
  Создана системная дополнительная характеристика товара «Разрешён возврат поставщику», Sys.CanBeReturnedToSupplier. Со значениями «Да» и «Нет». По умолчанию характеристика активна, то есть доступна для редактирования на закладке «Описание» карточки складского учета.
  Дополнительная характеристика, будучи назначенная артикулу, позволяет указать, разрешен или запрещен возврат данного товара поставщику.
  

  Функция проверки 105 «Наличие товара с признаком "Разрешён возврат поставщику"».

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

  Детализация функции проверки 65 «Запрет понижения статуса документа - общего основания» для заказа поставщику.

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

  Функция проверки 231 «Контроль параметров счета-фактуры и накладной поставщика».

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

  Функции проверки 128, 134, 185, 186. Операция "Поступление инвентаря".

  
  Следующие функции проверки теперь срабатывают не только для операции «Приход», но и для операции «Поступление инвентаря»:
• 128 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят полностью"»,
• 134 «Проверка на наличие контракта при подъеме статуса док-та до "Принят полностью"»,
• 185 «Проверка на соответствие цен контрактам при подъеме статуса док-та до "Принят на складе"»,
• 186 «Проверка на наличие контракта при подъеме статуса док-та до "Принят на складе"».
  

  Функции проверки 134, 186. Артикулы типа "Инвентарь".

  
  Следующие функции проверки теперь срабатывают не только для артикулов типа «Товар», но и для артикулов типа «Инвентарь»:
• 134 «Проверка на наличие контракта при подъеме статуса док-та до "Принят полностью"»,
• 186 «Проверка на наличие контракта при подъеме статуса док-та до "Принят на складе"».
  

  Процесс «Акт разделки ТСД».

  
  Создан новый раздел «Акт разделки ТСД» для получения от программы ТСД информации о результатах разделки артикула с заданной калькуляцией. По данным ТСД создается акт производства артикула с флагом «разделка» в статусе «Черновик».
  

  Процесс «Прием заказа ТСД». Счет-фактура поставщика.

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

  Процесс «Контроль ценников ТСД». Печать ценников с группировкой по элементам планограммы.

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

  Регистрация платежей.

  Управление интерфейсом.

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

  Просмотр смен, чеков и позиций чеков.

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

  Работа с ККТ СП801-Ф.

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

  Протокол «УКМ4 станд. XML». Прием данных о дисконтных картах для скидок с типом, отличным от «персональная скидка».

  
  В предыдущих версиях при приеме чеков из кассы по протоколу «УКМ4 станд. XML» информация о номере дисконтной карты (карте клиента) принималась и сохранялась вместе с суммой предоставленной скидки, если тип скидки, указанный в чеке, соответствовал типу «персональная скидка». В протоколе «УКМ4 станд. XML» персональной скидке соответствует скидка с programType=1. В остальных случаях номер дисконтной карты игнорировался, так как считалось, что его появление вместе с другими типами скидки, например, «скидка на товар или группу классификатора» не имеет смысла.
  В текущей версии если тип скидки не совпадает с типом «персональная скидка», но при этом указан номер дисконтной карты, то номер карты сохраняется в структуре чека Супермаг+, но с нулевой суммой скидки. Сумма скидки сохраняется, как и прежде, при том типе скидки, который указан в чеке.
  Изменение сделано для поддержки комбинированных скидочных программ, когда предоставление дисконтной карты активирует применение других видов скидки.
  

  Отчет «Списание и естественная убыль».

  
  Отчет «Списание и естественная убыль» (группа «Магазинные») реализован в формате среды исполнения FastReport. Новый вариант отчета не работает с опцией «Предварительный просмотр - Файл: Форматированный текст». В случае выбора этой опции выполняется прежний вариант отчета, созданный для работы в среде исполнения Oracle Reports.
  

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

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

  Печать ценников весовых товаров.

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

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

• Белоруссия. При экспорте Расходной накладной в Накладную на перемещение, не заполнялись поля «Цена производителя» и «Оптовая надбавка»;
• Белоруссия. Накладная на перемещение. При выборе функции «Заполнить документ ценами последнего прихода», не заполнялись поля «Цена производителя» и «Оптовая надбавка»;
• Белоруссия. Накладная на перемещение. Функция «Проставить основания…» с опцией «Проставлять цены из оснований» проставляет цены иначе, чем функция «Заполнить документ ценами из основания для товародвижения». Поведение функции приведено к поведению функции «Заполнить документ ценами из основания для товародвижения».
• Для весов модели «BIZERBA StandartCSV» исправлена ошибка выполнения функции «Тест соединения всех весов».
• При работе клиентской части через сервер приложений по медленным каналам связи получение от сервера больших объемов данных могло сопровождаться сообщением о потере соединения.
• Исправлена ошибка неожиданного удаления внутренних справочников при одновременном многократном обращении к ним с разных потоков. Ошибка происходила из-за неверного подсчета ссылок обращения к COM объекту. Ошибка проявлялась в остановке сервера весов при одновременной загрузке нескольких весов.
  
  Изменения функционала в версии 1.038 сервис пак 2.
  ЕГАИС. Запрос марок третьего регистра.
  Карточки товара типа «Деньги». Номинальная стоимость.
  Выгрузка артикулов типа «Деньги» в кассу.
  Справочник «Типы штрихкодов».
  Справочник «Штрихкоды».
  Использование штрихового кода со сроком годности.
  Раздел «Скидки». Скидки по срокам годности.
  Карточки складского учета. Скидки по срокам годности.
  Пределы скидок.
  Скидки по срокам годности.
  Регистрация платежей.
  ККТ Атол 11Ф.
  Скидка по срокам годности.
  Продажа подарочных сертификатов.
  Проверка подарочного сертификата.
  Прием оплаты подарочными сертификатами.
  Внешний денежный ящик.

ЕГАИС. Запрос марок третьего регистра.

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

Карточки товара типа «Деньги». Номинальная стоимость.

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

Выгрузка артикулов типа «Деньги» в кассу.

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

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

Справочник «Типы штрихкодов».

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

Типы штриховых кодов с 12 по 15 уже использовались в предыдущих версиях программы и помещены в справочник для информирования об их применении и описания их структуры. Тип штрихового кода «со сроком годности» добавлен для распознавания товара и срока истечения его годности в процессе чтения сканером. Его структура схожа со структурой кода GS1, но содержит иные служебные коды и не может использоваться повсеместно. Для включения / отключения распознавания кода такой структуры необходимо обратиться к справочнику «Штрихкоды».

Справочник «Штрихкоды».

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

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

Использование штрихового кода со сроком годности.

Пример штрихового кода со сроком годности:

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

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

В разделе «Скидки» изменен интерфейс для работы с различными видами скидок:

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


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

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

Пределы скидок.

Описание пределов скидки для артикула вынесено из закладки «Скидки» в отдельную закладку «Пределы скидок»:

Скидки по срокам годности.

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

Скидка, заданная для артикула, отменяет для него скидку, заданную для группы товаров.

Регистрация платежей.

ККТ Атол 11Ф.

В раздел «Регистрация платежей» добавлена поддержка ККТ «Атол 11Ф». Для работы с устройством необходимо установить драйвер ККТ и службы, которые предоставляются производителем устройства. При установке Супермаг+ устанавливаются компоненты, необходимые для взаимодействия с драйвером ККТ, но сам драйвер необходимо установить самостоятельно. Службы компании Атол необходимо устанавливать, если передача данных в ОФД выполняется через компьютер кассы. В этом случае службы забирают данные из ККТ по USB соединению и пересылают их в ОФД через сетевую плату компьютера.
Для работы Торговой системы необходимо установить 32-х разрядный драйвер, даже если операционная система 64-х разрядная. Файл для установки драйвера может называться например «KKT10-10.4.2-windows32-setup.exe» и находиться в файле «10.4.2.zip» по пути «\installer\exe\». Драйвер и программу управления драйверами (KKT_8_16_04_00_Full) можно получить с сайта компании: http://fs.atol.ru/SitePages/Центр%20загрузки.aspx

Скидка по срокам годности.

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

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

Продажа подарочных сертификатов.

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

Если центр верификации в настройках не задан или не доступен, то при обращении к нему будет показано сообщение об ошибке:

При продаже подарочных сертификатов используются следующие правила:

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

  Проверка подарочного сертификата.

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

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

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

  Внешний денежный ящик.

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

ЕГАИС. Запрос марок третьего регистра по заданной справке РФУ2.

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

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

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

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

При изменении ставки происходит перерасчет цен и сумм в строках документа с соответствии с видом цены контракта – с НДС или без НДС.
Обрабатываемые документы могут иметь любой статус, кроме «Заблокированный».

Изменения функционала в версии 1.038 сервис пак 4.
Функция проверки «Контроль максимального уровня складских запасов в заказе поставщику».
Печатная форма накладной на перемещение «раздел Б справки к ТТН».

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

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

Печатная форма накладной на перемещение «раздел Б справки к ТТН».

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

Изменения функционала в версии 1.038 сервис пак 5.
Почтовый модуль. Стандартный XML фильтр. Прием файлов с произвольным составом полей.
Процесс «Управление планом цен».

Почтовый модуль. Стандартный XML фильтр. Прием файлов с произвольным составом полей.

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

 
Этот режим работы XML протокола имеет следующие ограничения:

• В XML объекте должны быть заполнены обязательные поля, как правило это ключевые поля, которые нужны для идентификации объекта.
• В одном XML файле объекты одного типа должны иметь одну и ту же структуру. Или иначе, два объекта одного типа с разным набором полей должны передаваться в разных файлах. Ограничение связано с тем, что при приеме XML файла фильтр почтового модуля фактически воссоздает схему объекта по содержанию файла и в дальнейшем использует эту схему при обработке именно этого файла.
  Такое же требование одинаковости структуры предъявляется к компонентам сложного объекта. То есть, его части должны иметь одинаковую структуру, например, в спецификации документа все строки должны иметь одинаковый набор полей.
  Опция позволяет получать обновления объектов в тех случаях, когда сторонняя система не имеет возможности передавать полный набор данных об объекте при его изменении.
  

  Процесс «Управление планом цен».

  
  В интерфейс режима редактирования экземпляра объекта «Управление планом цен» добавлена кнопка «Завершить». Действие кнопки аналогично выбору нового статуса «Завершен» и нажатию кнопки «Сохранить».
  
  В раздел добавлен проверка, не позволяющая завершить процесс, если он имеет пустую спецификацию.
  
  Изменения функционала в версии 1.038
  Сервер обмена данными.
  ЕГАИС.
  Подсчет алкоголя ТСД. Прием алкоголя на основании заказа.
  Подсчет алкоголя ТСД. Ввод кода марки сканером в разрыв клавиатуры.
  Списание пива на основании кассового документа при отсутствии остатков ЕГАИС.
  Кассовый документ. Поле «Комментарий».
  Инициализация магазина. Опции копирования цен и уровней складских запасов.
  Карточки складского учета.
  Закладка «История наценок».
  Закладка «Документы». Сохранение выбора вида документов.
  Прайс-лист поставщика. Функция «Создать маркетинговый контракт».
  Сличительные ведомости. Функция «Создать накладные». Выбор клиента.
  Счет. Ввод количества в мастере ввода строки спецификации.
  Заказ поставщику. Функция «Нормировать количество по условиям соглашения о поставках».
  Накладная на перемещение. Функция «Копировать количество в фактическое количество».
  «Акты потерь», «Акты обнаружений». Информационные поля для отображения остатков.
  Белоруссия.
  Перенос дополнительных расходов в приходную накладную.
  Экспорт из накладной поставщика в приходную накладную. Копирование цен производителя и оптовой надбавки.
  Выгрузка в кассы.
  Расписание полной выгрузки: в указанный день и время.
  Протокол «УКМ4 станд. XML». Выгрузка дополнительных цен.
  Драйвер весов «DIGI RM-5800».
  Перечень исправленных ошибок и улучшений.

Сервер обмена данными.

В состав Супермаг+ добавлен сервер обмена данными и администратор сервера обмена данными.
Сервер и администратор устанавливаются как в 32-х битном исполнении, так и в 64-х битном.
При обновлении версии опция установки сервера по умолчанию не выбрана:

Чтобы установить службу и администратор, необходимо отметить флаг «Сервер обмена данными».
Сервер обмена данными является WEB-сервисом. Сервис работает по REST-протоколу и передает информацию в виде XML-данных.
В текущей версии сервис выполняет команды запроса информации.
Запросить объекты из БД Супермага можно, например, утилитой curl.exe:
curl -X GET http://хост:порт/out/xml/схема/идентификатор_объекта.xml,
например, curl -X GET http://192.168.10.3:8080/out/xml/CD/00345.xml.
Для задания идентификаторов объектов, имеющих в составе русские буквыили служебные символы, надо использовать шестнадцатеричные коды символов:
curl -X GET http://localhost:8080/out/xml/CD/%%D0%%A6004177.xml (карточка Ц004177).
Для запроса справочника после его имени надо указать произвольный идентификатор
curl -X GET {+}http://localhost:8080/out/xml/RFSABANKS/*+
Если объект имеет составной идентификатор, то части идентификатора должны разделяться запятой. Если часть идентификатора объекта содержит запятую или начинается с апострофа, то эта часть идентификатора должна быть заключена в апострофы. Например:
curl -X GET http://localhost:8080/out/xml/BC/5000281006024 ,'%%D0%%A6004177'.xml

Перед началом работы с сервисом его необходимо настроить. В администраторе сервера обмена данных необходимо указать базу данных, с которой будет работать служба:

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

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

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

Опции для генерации схемы объекта могут быть использованы в том случае, когда объект предполагается передавать в том виде, в котором он хранится в базе данных. Если схема объекта должна быть модифицирована, то необходимо выполнить генерацию XSD-схем данных для фильтра почтового модуля в административном модуле и отредактировать схемы с помощью программы «Редактор XML-схем».
WEB-сервис может формировать объекты таким же образом, как почтовый модуль: с использованием тех же правил и функций.
При сохранении схемы объекта в базе данных показывается содержание схемы для контроля корректности схемы выбранного объекта:

Опция «Доступна на сервере ...» позволяет указать службе, что эта схема может быть использована службой на этом компьютере.
При использовании нескольких WEB-служб, размещенных на разных компьютерах, можно обеспечить обмен данными с разными сторонними программами, используя для каждой такой программы свой набор объектов. Когда разные программы предъявляют разные требования к содержанию объектов одного и того же типа, для WEB-службы необходимо загрузить несколько XSD-схем одного и того же объекта, присвоив им разные имена, например, OR и OR1C, или ORDER.
Проверить доступный перечень типов объектов и выполнить запрос содержания объекта можно в интернет-браузере, обратившись к компьютеру WEB-службы по ее адресу, например: {+}http://localhost:8080+

Схемы объектов:


Запрос объекта из Супермаг+:

Например:

Скачивание объекта происходит в виде XML-файла в каталог Downloads текущей учетной записи.

ЕГАИС.

Подсчет алкоголя ТСД. Прием алкоголя на основании заказа.

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

Добавлена страница для задания номера заказа, на основании которого выполнена поставка:

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

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

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

При вводе кода марки сканером в разрыв клавиатуры добавлена автоматическая перекодировка символов кода в латинскую кодировку, если при сканировании выбрана кириллическая раскладка клавиатуры.

Списание пива на основании кассового документа при отсутствии остатков ЕГАИС.

При создании акта списания ЕГАИС для немаркированной алкогольной продукции (пива) на основании кассового документа выполняются следующие действия:

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

  Кассовый документ. Поле «Комментарий».

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

  Инициализация магазина. Опции копирования цен и уровней складских запасов.

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

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

  Закладка «История наценок».

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

  Закладка «Документы». Сохранение выбора вида документов.

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

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

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

  Сличительные ведомости. Функция «Создать накладные». Выбор клиента.

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

  Счет. Ввод количества в мастере ввода строки спецификации.

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

  Заказ поставщику. Функция «Нормировать количество по условиям соглашения о поставках».

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

  Накладная на перемещение. Функция «Копировать количество в фактическое количество».

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

  «Акты потерь», «Акты обнаружений». Информационные поля для отображения остатков.

  
  В документы «Акты потерь» и «Акты обнаружений» добавлены информационные поля «Остатки», «Остатки-потери», «Оперативные остатки» и «Оперативные остатки-потери».
  В поле «Остатки» показывается текущий остаток по документам со статусом 2 и 3. В поле «Остатки-потери» показывается текущий остаток за минусом потерь, зафиксированных документами акты потерь и акты обнаружений. В полях «Оперативные остатки» и «оперативные остатки-потери» показываются остатки с учетом оперативных продаж.
  

  Белоруссия.

  Перенос дополнительных расходов в приходную накладную.

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

  Экспорт из накладной поставщика в приходную накладную. Копирование цен производителя и оптовой надбавки.

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

  Выгрузка в кассы.

  Расписание полной выгрузки: в указанный день и время.

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

  Протокол «УКМ4 станд. XML». Выгрузка дополнительных цен.

  \\ В административном модуле в разделе «База данных» на закладке «Конфигурация» в группе данных «Касса» для типов данных полной и инкрементальной загрузки добавлен флаг «Дополнительные цены». В текущей версии флаг действует только на протокол обмена «УКМ4 станд. XML». Если флаг отмечен, то при выгрузке данных по этому протоколу будет дополнительно выгружаться файл дополнительных цен вида: \\ storePricesAdd_\[Х\]_\[ХХХХ\]_\[I/F\], \\ где \[X\] – код места хранения \[XXXX\] – уникальный номер выгрузки, \[I\] или \[F\] – признак инкрементальной или полной выгрузки. \\ В файле для каждого вида цены места хранения, исключая цену для кассы и цены с флагом «не для кассы», выгружаются код цены, название вида цены и перечень артикулов с их ценами в том же виде как в файле storePrices. \\ Если дополнительных цен у места хранения не будет, то файл выгружаться не будет. \\

  Драйвер весов «DIGI RM-5800».

  
  Создан новый драйвер «DIGI RM-5800» для загрузки весов с сенсорным экраном. Технология работы с весами аналогична весам DIGI SM-5000.
  Особенностью драйвера является загрузка в весы уменьшенных изображений товаров, таких же, как те, что используются для работы планограммы. Уменьшенные копии изображений размером 300х300 в формате jpeg создаются в момент загрузки в базу данных изображения артикула в разделе карточек складского учета.
  

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

• Весы Digi 5000. Если весы не в сети, то при обращении к весам в процессе загрузки происходила ошибка: "Критическая ошибка SEH: ACCESS_VIOLATION ..."
• Карточки складского учета, закладка «Остатки». Не работала сортировка строк в таблице по двойному клику по полю заголовка таблицы.
• Исправлена ошибка многократного размещения в памяти программы автоматического обновления при работе клиента через сервер приложений.
• Исправлена ошибка неверного размещения правил автоматического пополнения категорий товаров. Добавлены права для работы с правилами автоматического пополнения категорий товаров.
• Исправлена ошибка: сохранение документа «Платеж» и «Получение платежа» с буквенным номером платежного поручения завершалась ошибкой "ORA-01722: invalid number".
• Раздел «Кассовые чеки». Автоматическая печать завершалась ошибкой "ORA-00904: "H.NONCASHSUM": invalid identifier".
• Исправлено: «Ошибка вывода ценников с помощью MS Word» при печати нескольких ценников с использованием шаблонов MS Word.
• Контрагенты. Исправлена ошибка «Нет прав на 'Редактирование списка складов'» при наличии такого права.
  
  Изменения функционала в версии 1.039 сервис пак 1.
  Инвентаризация ЕГАИС. Инвентаризация с марками нового и старого образца.
  Подсчет алкоголя ТСД. Проверка марок на наличие их в учете ЕГАИС.
  Справочник «Номенклатура ГИС «Меркурий»». Добавление нового артикула.
  Рассылка номенклатуры ГИС «Меркурий».
  Приходные накладные. Редактирование атрибутов счета-фактуры на статусе «Принят полностью».
  Рекламные компании. Подарки.
  Структура магазина-склада. Логин, пароль и штриховой код продавца-консультанта.
  Регистрация платежей.
  Продавец-консультант в чеке.
  Остаток товара в информации о товаре.
  Продажа товара с подарками.
  Чек будет выглядеть следующим образом (на ККТ СП-801Ф):
  Изменение интерфейса центра верификации сертификатов.
  Справочник типов штриховых кодов. Типы кодов для табака и срока годности.

Инвентаризация ЕГАИС. Инвентаризация с марками нового и старого образца.

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

Подсчет алкоголя ТСД. Проверка марок на наличие их в учете ЕГАИС.

В раздел «Подсчет алкоголя ТСД» добавлена функция «Проверить марки в УТМ». Функция позволяет направить запрос в УТМ для проверки наличия марки на поштучном учете ЕГАИС. Для работы функции необходимо задать адрес и порт УТМ:

Адрес УТМ запоминается и при следующем вызове функции подставляется. Диалог позволяет проверить работоспособность УТМ и правильность введенных параметров.
Функция запрашивает для всех марок подсчета наличие их на учете на третьем регистре. Результат показывается в следующем диалоге:

Справочник «Номенклатура ГИС «Меркурий»». Добавление нового артикула.

В справочник «Номенклатура ГИС «Меркурий»» в процедуру добавления артикула внесены следующие изменения:

• при добавлении артикула в поле GTIN автоматически подставляется значение штрихового кода артикула с флагом «Обмен с EDI».
• добавлен диалог для выбора GTIN из штриховых кодов артикула:
  
• при выборе единицы измерения «Меркурий» выполняется подбор коэффициента пересчета в единицу измерения Торговой системы. Информация берется из атрибутов единицы измерения «Меркурий», если есть возможность установить соответствие между единицей измерения «Меркурий» и основной или дополнительной единицей измерения артикула.
• реализован переход к карточке товара по двойному щелчку мыши в таблице номенклатуры «Меркурий».
  

  Рассылка номенклатуры ГИС «Меркурий».

  
  Для обмена с провайдером ГИС «Меркурий» в почтовом модуле необходимо выбрать почтовый фильтр «Меркурий – обмен данными»:
  
  Обмен производится XML-файлами с использованием стандартных файловых транспортов.
  В текущей версии можно отсылать номенклатуру ГИС «Меркурий» для синхронизации справочников номенклатуры провайдера. Пример файла:
  <?xml version="1.0" encoding="UTF-8"?>
  <Message xmlns="http://www.w-vetis-sm.org" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" MessageNo="19032100001">
  <Nomenklatura>
  <OuterID>Ц034127</OuterID>
  <Naimenovaniye>НАБОР ДЛЯ ПЕРВЫХ БЛЮД</Naimenovaniye>
  <EdinitsaIzmereniyaUUID>069792f0-053d-11e1-99b4-d8d385fbc9e8</EdinitsaIzmereniyaUUID>
  <GTIN>0000002299479</GTIN>
  </Nomenklatura>
  <Nomenklatura>
  <OuterID>Ц034147</OuterID>
  <Naimenovaniye>ФАРШ ИЗ БАРАНИНЫ</Naimenovaniye>
  <EdinitsaIzmereniyaUUID>069792f0-053d-11e1-99b4-d8d385fbc9e8</EdinitsaIzmereniyaUUID>
  <GTIN>2400000000259</GTIN>
  </Nomenklatura>
  </Message>
  Где OuterID – артикул.
  

  Приходные накладные. Редактирование атрибутов счета-фактуры на статусе «Принят полностью».

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

  Рекламные кампании. Подарки.

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

  Структура магазина-склада. Логин, пароль и штриховой код продавца-консультанта.

  
  В разделе «Структура магазина-склада» на закладке «Персонал - Продавцы-консультанты» добавлены атрибуты «Логин», «Пароль», «Штриховой код»:
  
  Пароль после ввода не показывается. Штриховой код каждого продавца консультанта должен быть уникальным. Штриховой код может быть любого формата – EAN13, CODE128 и т.д.
  Атрибуты могут использоваться для безопасной авторизации продавца-консультанта в кассовой программе.
  

  Регистрация платежей.

  Продавец-консультант в чеке.

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

  Остаток товара в информации о товаре.

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

  Продажа товара с подарками.

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

  Чек будет выглядеть следующим образом (на ККТ СП-801Ф):

  
  
  

  Изменение интерфейса центра верификации сертификатов.

  
  В перечень команд центра верификации добавлены команды:
  GET/5lb/authority/id/activationcode
  GET/5lb/annul/id
  authority – команда проверки пригодности подарочного сертификата для использования в качестве средства платежа. Команда регистрирует сертификат, как готовый к погашению
  annul – команда отмены готовности сертификата к погашению.
  Полный перечень команд теперь следующий:
  GET/5lb/sale/Id/price
  GET/5lb/activation/id
  GET/5lb/validate/id
  GET/5lb/pay/id/activationcode
  GET/5lb/authority/id/activationcode
  GET/5lb/annul/id
  sale - запрос разрешения продажи сертификата
  activation - запрос на фиксацию продажи и активацию сертификата
  validate - запрос состояния сертификата (значения атрибутов сертификата)
  authority - запрос на готовность к погашению и фиксация готовности к погашению
  annul - запрос на отмену готовности к погашению.
  pay - запрос на фиксацию оплаты сертификатом 
  дополнительные параметры команд:
  id - код подарочного сертификата (штриховой код)
  activationcode - проверочный код (секретный код)

  Справочник типов штриховых кодов. Типы кодов для табака и срока годности.

  
  В справочник типов штриховых кодов добавлены следующие типы:
  Срок годности, партия - Секционный штриховой код CODE 128, содержащий код EAN-13, идентифицирующий товар, партию и срок годности товара. Имеет длину 29 символов и формат "010(ШК поставщика EAN-13)10(Номер партии 5 символов)15(Срок годности формата ГГММ)"
  Пачка табака - DataMatrix штриховой код пачки табака. Идентифицирует товар, серию и максимальную розничную цену товара. Имеет длину 29 символов.
  Блок табака без МРЦ - DataMatrix секционный штриховой код блока табака без МРЦ. Идентифицирует товар и серию. Имеет длину 25 и более символов.
  Блок табака с МРЦ - DataMatrix секционный штриховой код блока табака с МРЦ. Идентифицирует товар, серию и максимальную розничную цену товара. Имеет длину 41 символ.
  При сканировании штриховых кодов указанных выше типов, в текущей версии доступна идентификация артикула и срока годности.
  
  Изменения функционала в версии 1.039 сервис пак 2.
  Рекламные компании. Подарок на кассе.
  Регистрация платежей.
  Регистрация подарков на кассе.
  Номер фискального накопителя в параметрах кассы.
  Отчет «Денежный ящик. Внесение и изъятие наличных».

Рекламные компании. Подарок на кассе.

В перечень предложений Рекламных компаний добавлено предложение типа «Подарок на кассе». Подарок на кассе выдается покупателю кассиром при выполнении условия предложения. В отличии от предложения типа «Подарок» товары - подарки не должны входить в перечень товаров, предъявленных покупателем.
Предложения типа «Подарки» можно использовать в программах вида «Купите 2 ручки и получите третью в подарок». Когда покупатель сам выбирает 3 ручки и одну из них получает в подарок при оплате покупки.
Предложения типа «Подарок на кассе» можно использовать в программах вида «Купите товаров на 1000 р. и получите у кассира игрушку в подарок». Когда кассир при оформлении чека должен выдать по игрушке на каждую 1000 р. покупки.
Например:

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

Регистрация платежей.

Регистрация подарков на кассе.

В тех случаях, когда содержание чека соответствует условию рекламной компании с предложением подарка на кассе, при переходе в режим расчета кассиру показывается экран для регистрации выдачи подарков и с информацией из рекламной компании:

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

Номер фискального накопителя в параметрах кассы.

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

Отчет «Денежный ящик. Внесение и изъятие наличных».

В экран старта отчета добавлена опция «Период с ... по ...». Опция позволяет получить отчет в заданном диапазоне дат, не задавая номер смены:


Изменения функционала в версии 1.039 сервис пак 3.
ЕГАИС.
Подсчет алкоголя ТСД. Прием упаковок маркированной продукции.
Инвентаризация ЕГАИС. Сверка остатков поштучного учета.
Раздел «Коды PDF417 ЕГАИС». Печать нечитаемой марки нового образца.
Остатки ЕГАИС. Перевод остатков с поштучным учетом в торговый зал.
ТТН ЕГАИС на приход/отгрузку. Признать документ зафиксированным в ЕГАИС.
ТТН ЕГАИС на приход/отгрузку. Детализация по кодам марок. Серия и номер марки.
Перенос учета ЕГАИС в другую базу данных.
Классификатор товаров. Флаг «Запрет продажи без использования ШК со сроком годности».
Рекламные кампании. Скидка вида «Фиксированная цена».
Регистрация платежей.
Применение скидки вида «Фиксированная цена» на кассе.
Запрет продажи без регистрации в чеке продавца-консультанта.
Запрет продажи без использования ШК со сроком годности.
Информационная строка. Вывод информации о номере кассы, смены, чека.
Время пробития чека.
ККТ «Атол 30Ф».
Приходные накладные. Функция «Проставить номер счета-фактуры».

ЕГАИС.

Подсчет алкоголя ТСД. Прием упаковок маркированной продукции.

Упаковки маркированной алкогольной продукции могут иметь штриховой код одного из двух видов: для короба – длиной 26 символов и для паллеты - длиной 16 символов.
Для распознавания этих типов штриховых кодов в справочник «Типы штрихкодов» добавлен тип «групповая тара ЕГАИС» со следующим описанием: «Групповая тара ЕГАИС. Цифровой, Code 128, имеет длину 26 символов (короб) или 18 символов (паллета)».
Код упаковки минимальной вместимости фиксируется в ТТН ЕГАИС вместе со списком кодов марок товаров, помещенных в эту упаковку.
В разделе «Подсчет алкоголя ТСД» в случае подсчета на основании ТТН ЕГАИС на приход реализована возможность вводить штриховой код упаковки маркированной продукции вместо штриховых кодов марок. Если код упаковки соответствует коду минимальной упаковки, зарегистрированному в ТТН ЕГАИС, журнал заполняется марками этой упаковки.
Поддерживается ввод только минимальных упаковок. Упаковка из упаковок не распознается.
При вводе кода упаковки в разделе подсчета алкоголя ТСД, надо по-прежнему вводить штриховой код товара (EAN) для дальнейшего сопоставления ТТН с подсчетом алкоголя и приходной накладной.

Инвентаризация ЕГАИС. Сверка остатков поштучного учета.

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

Раздел «Коды PDF417 ЕГАИС». Печать нечитаемой марки нового образца.

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

Остатки ЕГАИС. Перевод остатков с поштучным учетом в торговый зал.

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

ТТН ЕГАИС на приход/отгрузку. Признать документ зафиксированным в ЕГАИС.

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

ТТН ЕГАИС на приход/отгрузку. Детализация по кодам марок. Серия и номер марки.

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

Перенос учета ЕГАИС в другую базу данных.

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

Классификатор товаров. Флаг «Запрет продажи без использования ШК со сроком годности».

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

Рекламные кампании. Скидка вида «Фиксированная цена».

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

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

Регистрация платежей.

Применение скидки вида «Фиксированная цена» на кассе.

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

Запрет продажи без регистрации в чеке продавца-консультанта.

В экран функции «Параметры раздела» на закладку «Общие» добавлен флаг «Запрет продажи без регистрации в чеке продавца-консультанта»:

Если флаг отмечен, а продавец-консультант не задан ни одним из доступных способов, кассиру перед расчетом с покупателем будет показан диалог:

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

Запрет продажи без использования ШК со сроком годности.

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

Информационная строка. Вывод информации о номере кассы, смены, чека.

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

Состав информации зависит от типа ККТ. Некоторые ККТ, например, СП 802-Ф не возвращают номер смены и чека до пробития чека.
Выше пример экрана тестовой кассы с номером -2. Для тестовой кассы показывается номер кассы и номер чека с текущей операцией (Продажа: 2).

Время пробития чека.

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

ККТ «Атол 30Ф».

В перечень поддерживаемых ККТ добавлена ККТ «АТОЛ 30Ф». При опросе ККТ «Атол 30Ф» опрашивается вместе с ККТ «Атол 11Ф».

Приходные накладные. Функция «Проставить номер счета-фактуры».

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

Изменения функционала в версии 1.039 сервис пак 4.
Административный модуль. Максимальная длина значения дополнительной характеристики артикула.
Супермаг Мобайл. Использование кода упаковки для подсчета алкоголя ТСД.

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

В раздел «Базы данных» на закладку «Конфигурация» в группу данных «Касса» в перечень атрибутов «Загрузка» добавлен атрибут «Макс. длина значения доп. характеристики артикула» со значением по умолчанию 300 символов.
Ограничение действует на длину строки значения дополнительной характеристики, передаваемой в кассу по протоколам «УКМ4 станд. XML» и «УКМ4 станд. TXT». Максимальное значение длины дополнительной характеристики 4000 символов.

Супермаг Мобайл. Использование кода упаковки для подсчета алкоголя ТСД.

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



Изменения функционала в версии 1.039
Меркурий.
Раздел «Справочники ГИС «Меркурий»».
Раздел «Площадки ГИС «Меркурий»»
Раздел «Номенклатура ГИС «Меркурий»».
ЕГАИС.
Прием ТТН ЕГАИС с марками нового и старого образца.
Поштучный возврат.
Подсчет алкоголя ТСД.
Функция «Заново открыть завершенный процесс для редактирования».
Функция «Подобрать алкокод» для марок нового образца.
Функция «Заполнить марками 3-го регистра».
Функция «Удалить строки». Удаление строк с указанными марками.
Функция «Удалить записи с новыми марками».
Функция экспорта данных «в акт постановки на баланс». Контроль наличия новых марок.
Рекламные кампании.
Регистрация платежей.
ЕГАИС. Контроль марок нового образца.
Рекламные кампании.
Служебные функции.
Журнализация ошибок выгрузки чеков и смен в серверную базу данных.
Отчеты. «Денежный ящик. Внесение и изъятие наличных»
Накладные. Функция слияния документов. Слияние упаковочных листов.
Документ «Счет». Ценовой режим. Функции проставления ставки налогов.
Карточки складского учета. Закладка «Скидки».
Контрагенты.
Опция «Проставлять цены из контрактов в приходные накладные».
Опция «Коэффициент срока поставки».
УКМ4 XML. Загрузка в кассу кодов алкогольной продукции.
Печать этикеток. Ключевое слово %BARPRICE.
Отчеты. «Реализация по Z-отчетам». Данные оперативных чеков.
Функции для работы с Супермаг Мобайл.
Контроль заказа при подсчете алкоголя ТСД.
Смена места хранения без выхода из программы.
Перечень исправленных ошибок и улучшений.

Меркурий.

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

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

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

Раздел «Площадки ГИС «Меркурий»»

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

Раздел «Номенклатура ГИС «Меркурий»».

Раздел «Номенклатура ГИС «Меркурий»» предназначен:

• для составления перечня артикулов, которые сопровождаются ветеринарными сертификатами;
• определения штрихового кода GTIN, который используется для идентификации артикула в обеих системах;
• для задания количества пересчета для артикула из единицы измерения «Меркурий» в единицу измерения Торговой системы, если учетные единицы артикула в Торговой Системе и в ГИС «Меркурий» не совпадают по смыслу, например, когда упаковка некоторого продукта учитывается в штуках, а в ГИС «Меркурий» - в килограммах или литрах. Для разных артикулов такие коэффициенты пересчета могут быть разными.
  
  

  ЕГАИС.

  Прием ТТН ЕГАИС с марками нового и старого образца.

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

  Поштучный возврат.

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

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

  Функция «Заново открыть завершенный процесс для редактирования».

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

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

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

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

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

  Функция «Удалить строки». Удаление строк с указанными марками.

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

  Функция «Удалить записи с новыми марками».

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

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

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

  Рекламные кампании.

  
  Раздел «Рекламные кампании» предназначен для планирования и реализации мероприятий по предоставлению покупателям тех или иных выгод. В рекламных кампаниях описывается период времени, места проведения мероприятия, список участников, то есть на кого распространяется мероприятие, перечень условий предоставление выгоды и соответствующие им содержание выгод.
  В текущей версии раздел документов «Рекламные кампании» заменен новым разделом с тем же названием. При обновлении версии все документы будут потеряны. После обновления будет необходимо создать нужные документы заново.
  В текущей версии раздел позволяет описывать механизмы предоставления выгоды в виде скидок, но не позволяет описывать варианты безвозмездной передачи материальных ценностей, обычно называемых «подарки», или предоставления денежных эквивалентов в виде балов или бонусов.
  Рекламные кампании позволяют описать два разных механизма предоставления скидок: пропорциональный и пороговый.
  
  Пропорциональные скидки предоставляются при достижении условия скидки в объеме, пропорциональном количеству повторений условия скидки в покупке, например, скидка 50% на третью штуку товара при покупке трех штук. Скидка будет предоставлена на каждый третий товар в покупке.
  Пороговые скидки – это скидки, которые предоставляются на все экземпляры покупаемого товара при достижении условия предоставления скидки, например, скидка 10% при покупке больше 5 штук товара. Скидка будет предоставлена на все экземпляры товара, если в покупке их 6 или более штук.
  Способ описания рекламной кампании зависит от характера скидки. По этой причине смена характера скидки требует пересоздания условий и выгод кампании.
  Рекламные кампании содержат заголовок и три закладки:
  
  В заголовке описывается сроки, время и дни недели проведения рекламной кампании, характер применения скидки, ограничение по суме чека для применения рекламной кампании, порядок применения и предел применения.
  Порядок применения указывает, в каком порядке будут рассматриваться рекламные кампании при расчете скидок, если для покупателя одновременно действует более одной кампании.
  Предел применения используется для пропорциональных скидок и указывает на максимальное количество раз предоставления выгоды. Например, давать скидку 50% на каждый второй товар, но не более 5 раз. Ноль означает отсутствие ограничения.
  На закладке «Места проведения» задается список мест хранения, в которых проводится рекламная кампания. На закладке «Участники» задается список участников, для которых проводится рекламная кампания. Это могут быть все покупатели или только держатели тех или иных дисконтных карт (карт покупателя).
  
  На закладке «Условия применения и предложения» описывается перечень условий покупки товаров и соответствующие им вознаграждения. Описание предложений и их интерпретация зависит от характера применения скидки.
  Для пороговых скидок интерфейс выглядит следующим образом:
  
  Условия применения могут содержать несколько условий, которые проверяются по принципу «ИЛИ». Выгода описывается в виде абсолютной или относительной скидки, которая будет применена либо к товару, для которого выполнено условие предложения, либо будет применена к сумме чека.
  Для приведенного выше примера скидка в 20% будет дана на любой товар из заданного списка при условии покупки 2-х или более штук товара этого вида или на любой товар из заданной группы при условии покупки этого товара на сумму не меньше 500 р.
  При расчете пороговых скидок не используется условия вида «купи 2 штуки любых товаров из списка и получи выгоду». Для получения выгоды на товар необходимо купить именно этого товара не меньше, чем указано в условии предложения.
  Для пороговых скидок можно описать только одно предложение. Если требуется в рамках маркетинговой кампании описать несколько разных предложений, необходимо создать несколько рекламных компаний.
  Для пропорциональных скидок интерфейс для описания условий применения выглядит также, как в случае пороговых скидок, но их смысл при расчете скидок иной.
  
  Для пропорциональных скидок количество или сумма товара, которую необходимо купить, относится не к каждому артикула из списка условия, а к их совокупности. Например, «купи любые два товара из списка и получи выгоду». Кроме того, артикулы условия предложения не идентичны артикулами, для которых будет предоставлена выгода. Артикулы, для которых предоставляется выгода, описываются отдельно в предложениях выгоды.
  Если описывается два или более пункта условия применения, то для предоставления выгоды они оба должны присутствовать в чеке. Например, «купи два любых торта и один любой коньяк из списка и получи бокал со скидкой».
  Если имеется несколько условий применения, то количество применений выгоды считается как сумма количества вхождений каждого условия применения.
  Предложение выгоды может быть описано одним или несколькими правилами, которые должны содержать описание товаров, к которым применяется выгода. Скидка может быть относительной и абсолютной и применяется только к описанным артикулам. К сумме чека скидка не применяется.
  При расчете скидки для каждого пункта условия рассчитывается количество вхождений этого условия в чек. Для дальнейшего определения выгоды берется наименьшее количество вхождений разных условий. Например, при условии купи два ластика и одну ручку и при наличии в чеке шести ластиков и двух ручек количество вхождений в чек совокупного условия будет равно двум. Это количество потом используется для определения количества выгод, предоставляемых покупателю. Общее количество выгод может быть ограничено атрибутом заголовка «Предел применения».
  При определении товаров, для которых будет предоставлена выгода, если в чеке есть больше одного артикула из списка предложения, то выгода в первую очередь предоставляется на те товары, где она будет наименьшей.
  Если предложений несколько, то они будут рассматриваться последовательно, в порядке описания рекламной кампании, и если какое-либо предложение будет выполнено, остальные рассматриваться не будут. То есть, предоставлена будет выгода только по одному предложению.
  В приведенном выше примере описано следующее условие: при покупке одного любого торта из заданного списка и одновременно при покупке любых товаров из группы «фигурный шоколад» на 1000 р. будет предоставлена скидка 70% на один любой йогурт из заданного списка или скидка в 300 р. на любой товар из группы товаров «Коньяк», но не более чем пять раз. Если в чеке имеются как йогурты, так и коньяки, то выгода будет предоставлена только на йогурты, а среди них на йогурты с наименьшей стоимостью.
  Примеры описания типовых пропорциональных скидок.
  При покупке М товаров из списка, подарок N товаров из другого списка.
  
  Предупреждение. Подарок не может присутствовать в чеке на продажу из-за законодательных ограничений, по этой причине 100% скидки в текущей реализации не разрешены. Под подарком будем понимать продажу с максимально возможной скидкой.
  Два товара по цене одного.
  
  Подарок на сумму покупки товаров из заданной группы.
  
  Скидка на N товаров, при покупке M товаров из списка:
  
  

  Регистрация платежей.

  ЕГАИС. Контроль марок нового образца.

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

  Рекламные кампании.

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

  Служебные функции.

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

  Журнализация ошибок выгрузки чеков и смен в серверную базу данных.

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

  Отчеты. «Денежный ящик. Внесение и изъятие наличных»

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

  Накладные. Функция слияния документов. Слияние упаковочных листов.

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

  Документ «Счет». Ценовой режим. Функции проставления ставки налогов.

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

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

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

  Контрагенты.

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

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

  Опция «Коэффициент срока поставки».

  
  С закладки «Поставщик» удален атрибут «Коэффициент срока поставки», который использовался в удаленном ранее пользовательском процессе заказа ЕТС.
  

  УКМ4 станд. XML. Загрузка в кассу кодов алкогольной продукции.

  
  В протокол загрузки данных в кассу «УКМ4 станд. XML» в файл данных о товарах «UpdateItems» добавлен тэг «ProductAlcCodes».
  Структура файл приобрела следующий вид:
  <updateItems fullness="F/I">
  <version="1.5">
  <item>// minOccurs="0" maxOccurs="unbounded"
  <article></article>
  <name></name>
  <measure></measure> (Сокращение)
  <measprec></measprec> (Точность – 1, 0.001, 0.01, 0.1)
  <groupId></groupId> (ссылка на узел классификатора)
  <egaisType></egaisType> ((int), признак акцизного товара; 0 - неакцизный товар, 1 - маркированный товар, 2 - немаркированный)
  <ProductAlcCodes> присутствует, если egaisType = 1
  <AlcCode></AlcCode> код алкогольной продукции, может быть от 0 до множества.
  </ProductAlcCodes>
  <propertyId></PropertyId> («Свойство» в СМ+, Размеры в терминах УКМ2. В СМ+ к товару может быть привязано только одно
  «Свойство»)
  <taxgroupId></taxgroupId>
  <addProperty> // minOccurs="0" maxOccurs="unbounded"
  <id></id> (код доп.характеристики в СМ+)
  <name></name> (название дополнительной характеристики в СМ+)
  <value></value>
  </addProperty>
  <barcode> // minOccurs="0" maxOccurs="unbounded"
  <id></id> (сам штрихкод)
  <PropertyValue></PropertyValue> («Размер» в УКМ2)
  <quantity></quantity> (в СМ+ «Количество» для штрихкода)
  </barcode>
  </item>
  </updateItems>
  

  Печать этикеток. Ключевое слово %BARPRICE.

  
  Перечень ключевых слов для шаблона этикеток дополнен словом: %BARPRICE.
  При формировании этикетки слово заменяется строкой штрихового кода с ценой.
  Состав строки штрихового кода с ценой следующий:
  PR|<BarCode>|<Price*100>|<PricerCategory>
  PR – префикс, указывающий на то, что это штриховой код с ценой
  <BarCode> - штриховой код EAN/UPC на единицу товара
  <Price*100> - цена товара в копейках
  <PricerCategory> - код категории ценника, 0, если вид ценников не известен.
  

  Отчеты. «Реализация по Z-отчетам». Данные оперативных чеков.

  
  Изменен алгоритм отчета «Реализация по Z-отчетам». В отбор данных для отчета включены оперативные чеки. В предыдущих версиях отчет строился только на информации из чеков закрытых Z-отчетов.
  

  Функции для работы с Супермаг Мобайл.

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

  Контроль заказа при подсчете алкоголя ТСД.

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

  Смена места хранения без выхода из программы.

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

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

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