Бюллетени изменений 1.039.1 - 1.045

Изменения функционала в версии 1.039.1 сервис пак 1.
Подсчет алкоголя ТСД.
Функция «Заново открыть завершенный процесс для редактирования».
Использование сканера «в разрыв клавиатуры».
Инвентаризация ЕГАИС. Сверка остатков поштучного учета.
ЕГАИС. Список кодов типов ФСМ/АМ.
Рекламные кампании. «Распределить сумму скидки».
Регистрация платежей. Распределение скидки по позициям чека.

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

Функция «Заново открыть завершенный процесс для редактирования».

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

Использование сканера «в разрыв клавиатуры».

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

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

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

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

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

  ЕГАИС. Список кодов типов ФСМ/АМ.

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

  Рекламные кампании. «Распределить сумму скидки».

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

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

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

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

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

Заказ поставщику. Опция «Копировать предложение заказа в количество заказа».

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

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

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

Расходная накладная. № и дата корректировочной счет-фактуры.

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


Изменения функционала в версии 1.039.1

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

Меркурий.

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

Документ «Перевозка» ГИС «Меркурий»

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

Документ «Расход на производство» ГИС «Меркурий»

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

Документ «Выход из производства» ГИС «Меркурий»

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

ЕГАИС.

Остатки ЕГАИС. Запрос марок по справкам РФУ2 и у УТМ.

В функцию «Запрос поштучных остатков по РФУ2» добавлен диалог для выбора опций запуска функции:

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


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

ТТН ЕГАИС на приход. Обработка квитанции «Накладная ... распроведена».

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

Переименование раздела «Коды PDF417 ЕГАИС».

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

Функциональное право на выполнение доверительной приемки.

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

Справочник «Коды ТН ВЭД».

В раздел «Справочники» в группу справочников «Карточки» добавлен справочник «Коды ТН ВЭД». Для работы со справочником необходимо иметь функциональное право «Редактирование кодов ТН ВЭД».
При заполнении справочника необходимо учитывать, что в таможенных документах используется полный код товара. Полный код товара образуется объединением граф справочника «Товарные позиции ТНВЭД» GRUPPA + TOV_POZ + SUB_POZ. Например, строка справочника «Товарные позиции ТНВЭД» классификатора товарной номенклатуры внешнеэкономической деятельности:
04|03|101100|ЙОГУРТ БЕЗ ВКУСО-АРОМАТИЧЕСКИХ ДОБАВОК И БЕЗ ДОБАВЛЕНИЯ ФРУКТОВ, ОРЕХОВ ИЛИ КАКАО, БЕЗ ДОБАВЛЕНИЯ САХАРА ИЛИ ДРУГИХ ПОДСЛАЩИВАЮЩИХ ВЕЩЕСТВ, С СОДЕРЖАНИЕМ ЖИРА НЕ БОЛЕЕ 3 МАС.%|01.01.2002|31.12.2006|
Должна представляться в справочнике «Коды ТНВЭД» следующим образом:

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

Классификация. Код ТН ВЭД.

В разделе «Карточки складского учета» на закладку «Классификация» добавлен выбор кода ТН ВЭД для карточки товара:

В функцию «Обработать - Изменение классификации» добавлен выбор кода ТН ВЭД:

Функция позволяет проставить значение кодов ТН ВЭД для выбранного перечня товаров.

Карточки типа «Инвентарь». Отображение контрактов.

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

Контракт с поставщиком. Соглашение о поставках. Вид обязательства.

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

• купля-продажа
• комиссия
• агентирование
  По умолчанию проставляется значение «купля-продажа». Значение поля копируется в соглашение о поставках, в котором оно не редактируется. При изменении значения поля в контракте, у которого уже имеются соглашения о поставках, значение поля в соглашениях о поставках синхронизируется с контрактом.
  

  Функция проверки «Действующее соглашение о поставках уже существует».

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

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

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

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

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

  Рецепт. Несколько рецептов на одну и ту же продукцию.

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

  Процесс «Подсчет марок ТСД».

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

  Белоруссия. Граф калькулятора «BY_NoTaxSum_RubDoc».

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

  УКМ4 станд. XML.

  Выгрузка кодов ТН ВЭД.

  
  При выгрузке данных в кассу по протоколу «УКМ4 станд. XML» в текущей версии дополнительно выгружается файл CodeTNVED со справочником кодов ТН ВЭД следующего содержания:
  <CodeTNVED fullness="F">
  <version>1.0</version>
  <group>
  <id></id> // идентификатор справочника
  <code></code> // код группы ТН ВЭД (строка)
  <name></name>// Название группы ТН ВЭД
  </group>
  </CodeTNVED>
  Файл выгружается полностью при полной и при инкрементальной выгрузке.
  В файле updateItems дополнительно выводится тэг <TNVEDId></TNVEDId> c идентификатором справочника ТН ВЭД. Тэг выводится, если артикулу назначен код группы ТН ВЭД.
  

  Выгрузка поставщиков комиссионных и агентских товаров.

  
  При наличии соглашений о поставках для места хранения магазина с видом обязательства «комиссия» или «агентирование», действующих на текущую дату, при выгрузке по протоколу «УКМ4 станд. XML» выгружается файл suppliers следующего содержания:
  <suppliers fullness="F">
  <version>1.0</version>
  <Suppliers>
  <SupplierType></SupplierType>// Тип поставщика: 32 – комиссионных товаров, 64 – агентских товаров
  <SupplierINN></SupplierINN>// ИНН поставщика
  <SupplierName></SupplierName>// Название поставщика
  <SupplierTel></SupplierTel> // Телефон поставщика
  </Suppliers>
  </suppliers>
  При полной выгрузке в файл попадают все поставщики комиссионных и агентских товаров, при инкрементальной - только те, которые относятся к выгруженным артикулам.
  В файл updateItems для товаров из соглашений о поставках с видом обязательства «комиссия» или «агентирование» дополнительно выгружается следующая информация:
  <SupplierLink>
  <SupplierINN></SupplierINN> // ИНН поставщика
  <SupplierTax></SupplierTax> // НДС поставщика из контракта с поставщиком. Может принимать три значения: 20%, 10%, Не облагается
  </SupplierLink>
  

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

  Максимальная длина значения дополнительной характеристики артикула.

  
  В раздел «Базы данных» на закладку «Конфигурация» в группу данных «Касса» в перечень атрибутов «Загрузка» добавлен атрибут «Макс. длина значения доп. характеристики артикула» со значением по умолчанию 300 символов.
  Ограничение действует на длину строки значения дополнительной характеристики, передаваемой в кассу по протоколам «УКМ4 станд. XML» и «УКМ4 станд. TXT». Максимальное значение длины дополнительной характеристики может достигать 4000 символов.
  

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

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

  Запрос параметров подчиненных баз данных.

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

  Супермаг Мобайл. Использование кода упаковки для подсчета алкоголя ТСД.

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

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

  
  
• Кассовый сервер не работал при использовании соединения с 64-х битным сервером приложений.
• Ошибка печати ценника из ТСД при использовании сетевого принтера и при подключении к 64-х разрядному серверу приложений: «Ошибка взаимодействия с сервером. Could not load file or assembly 'file:///C:\SM2000\Bin64\Sm.FastReports.dll' or one of its dependencies.»
• Сервер загрузки весов не реагировал на несоответствие версии базы данных и сервера.
• Контрагенты. При вводе ИНН, КПП и ОКПО теперь обрезаются финишные пробелы.
• Рассылка плана цен. Теперь при установленном правиле рассылки «*» план цен в статусе «Черновик» не рассылается.
• Проведена оптимизация кода автоматической генерации заказов для повышения скорости расчета. Из алгоритма удален расчет заказа по значениям свойств.
• Маркетинговая акция. В спецификацию документа не добавлялся артикул типа "размер".
• Протокол «УКМ4 станд. TXT». Исправлено: при выгрузке файла PLUPRICE.dat в нем выгружались дополнительные цены всех мест хранения.
  
  Изменения функционала в версии 1.039.2 сервис пак 1.
  Расходная накладная. № и дата корректировочной счет-фактуры.
  Расчет товародвижения. Формирование очереди документов перед расчетом товародвижения.

Расходная накладная. № и дата корректировочной счет-фактуры.

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

Расчет товародвижения. Формирование очереди документов перед расчетом товародвижения.

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



Изменения функционала в версии 1.039.2 сервис пак 2.
Меркурий.
Выбор площадок при создании документов Меркурий.
«Выход из производства» ГИС Меркурий. Простановка дат изготовления и срока годности.
Гашение ВСД ГИС Меркурий. Формат XML данных при почтовой отсылке.
Прием перемещений ТСД. Создание компенсирующих накладных.
Весы DIGI RM5800 с прошивкой 1.5.51.

Меркурий.

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

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

«Выход из производства» ГИС Меркурий. Простановка дат изготовления и срока годности.

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

Гашение ВСД ГИС Меркурий. Формат XML данных при почтовой отсылке.

В предыдущих версиях при отсылке документа «Гашение ВСД ГИС Меркурий» в файле TTN_gashenie_ххххххххххх.XML почтового обмена тэги <NomerTTN> и <DataTTN> заполнялись значениями номера и даты приходной накладной Торговой системы, для которой был создан документ гашения. В текущей версии эти тэги заполняются значениями «Накладная поставщика» и «Дата накладной поставщика» из заголовка приходной накладной.

Прием перемещений ТСД. Создание компенсирующих накладных.

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

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

Весы DIGI RM5800 с прошивкой 1.5.51.

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

Если флаг не установлен, на закладке «Файлы» шаблонные названия файлов указаны как prf0uall.csv, pff0uall.csv и tex0uall.csv, если флаг установлен, то как prd0uall.csv, pfd0uall.csv и tex0uall.csv. Файл описания текстов в обоих версиях одинаков.
Файлы, которые содержат описание формата этикетки могут иметь произвольные названия, но в весы они передаются с фиксированными шаблонными названиями и весы ожидают соответствующего содержания этих файлов:




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

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

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

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

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

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

Меркурий. Гашение. Даты «Изготовлен» и «Годен до».

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

Заказ поставщику. Опция «Копировать предложение заказа в количество заказа».

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

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

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

Драйвер весов DIGI упаковщик 3600 серии. Передача флага печати времени упаковки.

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

Изменения функционала в версии 1.039.2 сервис пак 3.
Заказ поставщику. Поиск строки в спецификации по артикулу поставщика.

Поиск строки в спецификации по артикулу поставщика.

В элемент поиска строки спецификации документов «Заказ поставщику», «Подтверждение заказа поставщику», «Прайс-лист поставщика», «Приходная накладная», «Накладная поставщика» добавлено поле «Артикул поставщика»:

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

Изменения функционала в версии 1.039.2

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

Меркурий.

Раздел «Гашение ВСД ГИС «Меркурий»».

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

Утилизация производственных отходов.

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

В других случаях поле «Цель перемещения» не заполняется.

Номенклатура ГИС «Меркурий». Функции массовой обработки строк.

В интерфейс раздела «Номенклатура ГИС «Меркурий»» добавлена кнопка «Обработать» с функциями «Задать единицу измерения» и «Задать коэффициент пересчета»:

Функции позволяют проставить соответствующее значение в выделенные строки таблицы артикулов.

Товары, подлежащие обязательной маркировке.

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

Справочник коды ТН ВЭД. Поле «Маркируемый».

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


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

Загрузка в кассу по протоколу «УКМ4 XML». Передача признака маркируемого товара.

Если артикулу назначена группа ТН ВЭД с флагом маркируемого товара и этот товар не относится к алкогольным товарам, то есть, ему не назначена группа алкогольного классификатора, то при выгрузке таких артикулов в УКМ4 в файле updateitems, в тэге <egaisType> будет передаваться значение 3, что для УКМ означает признак товара, подлежащего обязательной маркировки.

Продажа маркируемого товара в разделе «Регистрация платежей».

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

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

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

Регистрация платежей. Формирование чека в ККТ СП802-Ф, СП101-Ф, СП402-Ф

Изменен порядок формирования строк в чеке ККТ СП802-Ф, СП101-Ф, СП402-Ф для позиции чека. В прежних версиях для позиции чека печатались следующие строки: артикул с количеством, ценой и суммой, во второй строке - НДС и способ расчета, в третьей строке – название товара.
В текущей версии для позиции в чеке печатается строка с названием артикула с количеством, ценой и суммой и строка с НДС и способом расчета. Строка с артикулом товара не печатается.

Обработка чеков с наборами.

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

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

  Сервер обмена данными. Передача объектов в Супермаг+.

  
  Сервер обмена данными является WEB-сервисом, который работает по REST-протоколу. В прошлых версиях сервер мог использоваться для получения информации из Супермаг+ в виде XML-данных, выполняя команды вида:
  curl -X GET http://хост:порт/out/xml/схема/идентификатор_объекта.xml,
  например, curl -X GET http://192.168.10.3:8080/out/xml/CD/00345.xml.
  Подробно о настройках службы и правилах построения строки запроса см. «Изменения1038.doc».
  В текущей версии в сервере обмена данными реализована возможность выполнять команды добавления объектов в Супермаг+ с получением подтверждения об успешном выполнении или ошибке. Команда загрузки данных в Супермаг+ имеет следующий вид:
  curl -F "xml_file=@имя_файла" http://хост:порт/in/xml > ticket_id.xml
  Где имя_файла – это полное имя XML-файла с объектами Супермаг+, ticket_id.xml – имя файла, в который будет помещен ответ службы по результату обработки принятой информации. Ответ может прийти с некоторой задержкой, которая зависит от объема передаваемой информации и от загруженности сервера базы данных.
  Файл с информацией об объекте – это XML-файл такой же структуры, как в XML-протоколе почтового модуля, и с таким же управлением структурой XML-файла, как в программе «Редактор XML-схем».
  Для передачи данных можно воспользоваться сайтом сервера обмена данными:
  
  На сайте надо выбрать «Передача объектов в Супермаг»:
  
  Выбрать файл и нажать кнопку «Загрузить». После передачи объекта в Супермаг можно запросить результат выполнения операции. Для этого надо нажать кнопку «Обновить»:
  
  В случае ошибки приема данных будет показано сообщение о ее причине:
  
  Для приема объектов необходимо объявить перечень типов объектов, которые службе разрешено принимать. Для этого в интерфейсе администратора сервера обмена данных надо нажать кнопку «Настройка объектов обмена». Кнопка нажимается только при остановленной службе:
  
  И определить перечень и структуру принимаемых объектов:
  
  Ограничение перечня принимаемых объектов необходимо для построения безопасной схемы обмена данными. Например, службе, которая работает с портом, доступным извне локальной сети, можно разрешить принимать объекты поставщиков или клиентов. Служба, которая работает с портом, к которому сетевыми политиками разрешен доступ только определенных, доверенных компьютеров, может принимать критические данные, например, акты переоценки или карточки товаров.
  

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

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

  Номенклатура цеха.

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

  Генерация выхода из производства по расходу товара за день.

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

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

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

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

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

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

  
  
• В разделе «Структура магазина / склада» в названиях драйверов касс убрано слово «станд.». Кассы теперь называются: «УКМ2 TXT», «УКМ4 TXT», «УКМ4 XML» вместо «УКМ2 станд. TXT», «УКМ4 станд. TXT», «УКМ4 станд. XML».
• Исправлена ошибка: Если задание «Генерация заказов» выполняется с ошибкой, то в журнал ошибок задания вместо содержания ошибки попадает сообщение вида: «Доступ к ликвидированному объекту невозможен. Имя объекта: "WcfClient".»
• В журнале установки Супермаг+ теперь, помимо номера устанавливаемой версии, указывается версия, которая была до обновления.
• Исправлена ошибка: Если у должности отозвать право на модуль «Настройка отчетов», то при старте Супермаг+ пользователем с этой должностью модуль показывался активным.
• Подсчет алкоголя ТСД. Функция «Экспорт данных в расходную накладную на возврат с созданием ТТН ЕГАИС». Если в подсчете есть старая марка, не учтенная на поштучном учете, функция не выполняется с сообщением об ошибке "... кода с маркой ... нет на собственном поштучном учете ...". Сообщение об ошибке расширено следующим текстом: «Для возврата товара с марками старого образца с регистра торгового зала надо создать расходную накладную с указанием основания».
• При запросе поштучных остатков в ЕГАИС, при наличии нескольких УТМ, запросы отправлялись в ЕГАИС последовательно, т.е. сначала все поштучные остатки для первого FSRARID, затем для второго и т.д.
• Установка и удаление программы. Теперь при деинсталляции программы файл локальной базы данных переименовывается, чтобы не создавать коллизий при последующей установке программы с иной версией.
  
  Изменения функционала в версии 1.040 сервис пак 1.
  Меркурий. Проставление дат изготовления и годности из документов гашения.
  Задание на производство. Печать документа. Выбор групп товаров.
  Алгоритмы генерации заказа. Определение текущего остатка.
  Маркетинговые акции. Почтовый прием из доверительных баз данных.
  Печать этикеток. Новые ключевые слова.
  Касса. Регистрация КИЗ табачной продукции.

Меркурий. Проставление дат изготовления и годности из документов гашения.

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

Задание на производство. Печать документа. Выбор групп товаров.

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

Алгоритмы генерации заказа. Определение текущего остатка.

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

Маркетинговые акции. Почтовый прием из доверительных баз данных.

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

Печать этикеток. Новые ключевые слова.

Для печати этикеток используются файлы шаблоны этикеток, которые содержат команды печати на языке принтера и определяют дизайн и содержание этикетки. В файл шаблона этикетки разрешается добавлять ключевые слова, которые при обработке его программой перед отправкой на принтер заменяются соответствующим содержанием.
В текущей версии перечень ключевых слов, разрешенных в файле шаблоне, дополнен следующими:
%PRINTDATE – дата печати в формате ДД.ММ.ГГ
%PRINTTIME – время печати в формате ЧЧ:ММ:СС
%MANUFACTURER - производитель по умолчанию из карточки складского учета

Касса. Регистрация КИЗ табачной продукции.

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

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

Изменения функционала в версии 1.040 сервис пак 2.
Меркурий. Выбор документов Супермаг для создания документов Меркурий.+
Расходные накладные. Печатная форма «Акт о порче».

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

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

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

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

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

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

И будет выполнено создание документов гашения.

Расходные накладные. Печатная форма «Акт о порче».

В диалог старта печатных форм раздела «Расходные накладные» добавлен вариант выбора «Акт о порче»:

Условие доступности опции такие же как для акта на списание товара – накладная должна иметь операцию «Списание брака». При выборе опции печатается печатная форма ТОРГ-15 «Акт о порче, бое, ломе товарно-материальных ценностей».
Изменения функционала в версии 1.040 сервис пак 2.
Меркурий. Выбор документов Супермаг для создания документов Меркурий.+
Расходные накладные. Печатная форма «Акт о порче».

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

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

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

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

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

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

И будет выполнено создание документов гашения.

Расходные накладные. Печатная форма «Акт о порче».

В диалог старта печатных форм раздела «Расходные накладные» добавлен вариант выбора «Акт о порче»:

Условие доступности опции такие же как для акта на списание товара – накладная должна иметь операцию «Списание брака». При выборе опции печатается печатная форма ТОРГ-15 «Акт о порче, бое, ломе товарно-материальных ценностей».

Изменения функционала в версии 1.040 сервис пак 3.
УКМ4 XML. Изменение в протоколе обмена.
Весы DIGI RM-5800. Убраны загрузка логотипа и выбор сортировки PLU.
Подсчет товаров ТСД. Операция «продажа» с ценами и контрагентом.
Контрагенты. Штриховые коды в таблице артикулов контрагента.
Процесс формирования заказа на базе контракта. Поле «Штрихкод».
Документы «Заказы поставщику», «Контракты с поставщиком», «Соглашение о поставках», «Приходная накладная», «Расходная накладная», «Накладная на перемещение», «Накладная поставщика». Информационное поле «Штриховой код».

УКМ4 XML. Изменение в протоколе обмена.

В протокол обмена УКМ4 XML внесены следующие изменения:
Выгрузка в УКМ4:
Файл CodeTNVED для выгрузки справочника кодов ТНВЭД получил название TNVDCode. Содержание файла осталось без изменений.
В файле updateItems – сведений о товаре, название тэга <TNVEDId> заменено на <TNVDcode>
Прием из УКМ4:
В файл Shift – информации о смене, в тэг <item> добавлены тэги <serialNumber>, <KIZ> и <maxPrice> с информацией о табачной продукции:
<receipt storeId="" posNum="" shiftNum="" receiptNum="">
...
<item> // minOccurs="1" maxOccurs="unbounded" <секция товара в чеке>
....
<serialNumber></serialNumber> серийный номер товара со специальной маркировкой (тег присутствует если товар маркируемый))
<KIZ></KIZ>полное содержание специальной марки в кодировке Base64 (тег присутствует если товар маркируемый)
<maxPrice></maxPrice> максимальная розничная цена маркируемого товара (тег присутствует если товар маркируемый и маркировка содержит МРЦ)
</item>
...
</receipt>
При приеме смены или оперативного чека в Супермаг+ значение тэга KIZ принимается в поле «Mark» таблицы «SMCashCheckItems» или «SMOnlineCheckItems», соответственно.

Весы DIGI RM-5800. Убраны загрузка логотипа и выбор сортировки PLU.

Из интерфейса настройки электронных весов модели «DIGI RM-5800 Ethernet» с закладки «Файлы» удалена настройка для загрузки файла с изображением логотипа. Соответствующая опция удалена из диалога «Параметры загрузки весов».
С закладки «Свойства модели» интерфейса настройки удалена настройка предварительной сортировки PLU перед загрузкой из в весы.
Весы DIGI RM-5800 игнорируют первоначальную сортировку и выполняют ее в соответствии с внутренней настройкой.

Подсчет товаров ТСД. Операция «продажа» с ценами и контрагентом.

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

Контрагенты. Штриховые коды в таблице артикулов контрагента.

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

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

Процесс формирования заказа на базе контракта. Поле «Штрихкод».

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

Документы «Заказы поставщику», «Контракты с поставщиком», «Соглашение о поставках», «Приходная накладная», «Расходная накладная», «Накладная на перемещение», «Накладная поставщика». Информационное поле «Штриховой код».

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

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

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

Флаг «По факту» в журнале инвентаризации.

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

Функция «Обработать» -> «Заполнить журнал марками поштучного учета».

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

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

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


Изменения функционала в версии 1.040 сервис пак 5.
Приходная накладная. Функция «Заполнить документ ценами из ТТН ЕГАИС».
Настройка сканеров в последовательном порту. Сканер без префикса.
Весы DIGI Ethernet. Редактор раскладки клавиатуры. 96 клавиш (New).
Функции преобразования для XML фильтра.

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

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

Настройка сканеров в последовательном порту. Сканер без префикса.

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

Весы DIGI Ethernet. Редактор раскладки клавиатуры. 96 клавиш (New).

Некоторые модели весов DIGI, работающие по протоколу DIGI Ethernet, используют модифицированную 96 клавишную раскладку, в которой отсутствует смещение в нумерации клавиш второй половины клавиатуры. Для поддержки таких весов в диалог настройки «Редактор раскладки клавиатуры» добавлен выбор варианта раскладки «96 клавиш (New)»:

Функции преобразования для XML фильтра.

В Редактор XML-схем добавлены следующие функции для обработки входящих XML-файлов:
CurrencyTypeByISOВозвращает идентификатор типа валюты по коду валюты ISO
CurrencyTypeByOKVВозвращает идентификатор типа валюты по коду валюты ОКВ
Функции определяют код валюты Супермаг+ по коду ISO или ОКБ соответственно. Соответствие устанавливается по справочнику валют. Справочник надо заполнить заблаговременно.



Изменения функционала в версии 1.040
Модуль администратора. 64-х битный вариант исполнения.
ЕГАИС.
Карточки складского учета. Закладка «ЕГАИС».
ТТН ЕГАИС на приход, ТТН ЕГАИС на отгрузку. Журнал удаленных ТТН.
Группа разделов «Торговая точка».
Раздел «Прием поставки».
Раздел «Отгрузка».
Документ «Коррекция».
КИЗ в спецификации накладных.
Расходные накладные. Информационные поля «Дата счет-фактуры основания» и «Номер счет-фактуры основания».
Формирование пакета заказа на базе контракта. Поле «Маркетинговый контракт».
Сервер обмена данными. Формат обмена данными JSON.
Буферизация картинок для разделов «Планограмма» и «Касса».
Свойства для артикула. Уровни торгового запаса.
Перечень исправленных ошибок и улучшений.

Модуль администратора. 64-х битный вариант исполнения.

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

Будет показан список ранее установленных компонентов, среди которых «Модуль администратора» не отмечен:

Для установки компонента надо его отметить и нажать кнопку «Далее».
Модуль администратора используется для расчета товародвижения и закрытия периода. Оба алгоритма используют компонент расчета товародвижения. При расчете товародвижения алгоритм расчета обрабатывает артикул за артикулом и для одного артикула забирает в оперативную память все его движение. При большом количестве движения в 32-х битном исполнении программы возможна остановка её работы из-за ошибки нехватки памяти. 64-х битное исполнение модуля администратора позволяет избежать этой проблемы.
При старте и во время работы административные модули 32-х и 64-х битной разрядности можно отличить по внешнему виду ярлычков. На ярлычках 64-х разрядной программы имеется отметка «64»:

ЕГАИС.

Карточки складского учета. Закладка «ЕГАИС».

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

Список ТТН можно ограничить фильтром по операциям, датам и идентификатору ФСРАР (местом хранения) ТТН:

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

ТТН ЕГАИС на приход, ТТН ЕГАИС на отгрузку. Журнал удаленных ТТН.

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

Журнал ведется только после установки текущей версии. Информация о ранее удаленных ТТН в журнале отсутствует.

Группа разделов «Торговая точка».

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

Либо выбрать новое место хранение в окне фильтра документов – оснований поставки / отгрузки:

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

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

Можно выбрать одну из четырех предопределенных палитр или создать свою. Свою палитру можно создать, используя системную палитру в качестве шаблона.
Журнал событий:

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


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

Раздел «Прием поставки».

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

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

Поиск можно ограничить одним из следующих параметров:

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

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

Раздел «Отгрузка».

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

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

Документ «Коррекция».

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

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

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

Функции доступны в режиме редактирования документа со статусом «Принят»:

КИЗ в спецификации накладных.

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

При выполнении функции экспорта можно создать новую накладную или поместить марки в уже существующую:

После создания или изменения накладной предлагается перейти к ней для дальнейшей работы:

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

Расходные накладные. Информационные поля «Дата счет-фактуры основания» и «Номер счет-фактуры основания».

В документ «Расходная накладная» добавлена возможность показывать в спецификации документа информационные поля «Дата счет-фактуры основания» и «Номер счет-фактуры основания»:

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

Формирование пакета заказа на базе контракта. Поле «Маркетинговый контракт».

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

Сервер обмена данными. Формат обмена данными JSON.

В текущей версии данные можно передавать в сервер обмена данными или получать их из сервера обмена данных, как в формате XML, так и в формате JSON. Формат передаваемых данных необходимо указать при описании схемы объекта:

Буферизация картинок для разделов «Планограмма» и «Касса».

Разделы «Планограмма» и «Касса» в своем интерфейсе используют изображения товаров. Считывание изображений из базы данных, особенно в случаях, когда требуется показать изображение многих товаров одновременно, может занимать заметное время. По этой причине картинка, считанная из базы данных, сохраняется в локальном каталоге компьютера и считывается из базы данных повторно, только если она была изменена.
В предыдущих версиях картинки сохранялись в каталогах «...\user\.....\ AppData\Local\Temp \Sm.CashDesk» и «...\user\.....\AppData\Local\Temp\SmPlanogramma». Операционная система Windows время от времени очищает содержимое временных каталогов, что может приводить к временному исчезновению изображений товаров в интерфейсах соответствующих разделов.
В текущей версии каталоги с картинками сохраняются в каталоге: \SM2000\Data\

Свойства для артикула. Уровни торгового запаса.

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

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

• ТТН ЕГАИС на приход, расход. Выбор процесса подсчета алкоголя. Не работал фильтр процессов.
• Карточки складского учета. При попытке печати ценника, если файл печати ценника отсутствовал, после сообщения, например : "Файла C:\SM2000\Report\price_card.frx не существует.", появлялось сообщение "Критическая ошибка SEH: ACCESS_VIOLATION, код = 0xc0000005. Состояние программы нестабильно. Как можно быстрее завершите приложение."
• Карточки складского учета. Поле поиска строки отобранных артикулов при старте раздела всегда было «Артикул». Теперь выбранное поле запоминается. Если ранее выбранное поле поиска удалить из перечня полей таблицы, поле поиска получит значение «Артикул».
• Весы Digi RM-5800. Не работала загрузка веса тары.
• Контроль исполнения актов переоценки при приходе исполненных актов в подчиненную БД. Исправлена ошибка – при проверке пришедшего акта с условием исполнения, отличным от «немедленно», дата предполагаемого исполнения акта сравнивалась с датой фактического исполнения ранее пришедших актов. Теперь сравниваются даты фактического исполнения.
• Ошибка недостаточных прав доступа при автоматической установке клиентской части на ОС Windows 10 (будет работать при обновлении с текущей версии на более новую).
  
  Изменения функционала в версии 1.041 сервис пак 1.
  ЕГАИС. Поштучный учет марок старого образца.
  Карточки. Установка флага «Ценники за 0,1 единицу».
  Функции преобразования для XML фильтра.

ЕГАИС. Поштучный учет марок старого образца.

В предыдущих версиях Торговой Системы для учета продукции с марками старого образца рекомендовалось в настройках почтового модуля для фильтра «ЕГАИС – обмен данными» не устанавливать флаг «Поштучный учет старых марок» для регистра «торговый зал». В этом случае вся продукция с марками старого образца оказывалась на регистре торгового зала. Это достигалось принудительным переводом всей продукции не с новыми марками на второй регистр при ее получении от поставщика, независимо от того, были ли перечислены марки старого образца в ТТН ЕГАИС, или продукция пришла без перечисления марок. Перевод продукции на второй регистр автоматически приводил к снятию с поштучного учета тех старых марок, которые могли быть поставлены на этот учет производителем или поставщиком и делал всю продукцию со старыми марками одинаковой, с точки зрения технологии учета. Если флаг «поштучный учет старых марок» был установлен, то на второй регистр переводились все партионные поставки и партии с неполным списком старых марок.
03.03.2020 ФСРАР опубликовал следующее сообщение:
"С 01.04.2020 будет включен дополнительный контроль системы, который не позволит учитывать оборот продукции, маркированной марками "старого" образца, в партионном режиме, после фиксации ее отгрузки от производителя и импортера в поштучном режиме после указанной даты".
Это означает, что все партии со старыми марками, выпускаемые в оборот после 01.04 будут поштучными, и ТТН ЕГАИС должны содержать полный список марок для партий с соответствующими справками РФУ1.
Кроме того, Центринформ утверждает, что "если отправитель укажет старую марку в партии, где марки не учтены поштучно, будет ошибка, например:
0c3 Некорректная РФУ2: TEST-FB-000000038098291 для ШК: 22N00002NV07ITWMXCN7IFO804280050016958OAWKGQIPZDWZEQE7QRT4JE0QK23350"
Также 03.03.2020 было опубликовано следующее сообщение:
"В целях полного перехода на поштучный учет алкогольной продукции в ЕГАИС, Росалкогольрегулирование сообщает, что с 01.07.2020 учет оборота всей маркируемой алкогольной продукции будет возможен только в поштучном режиме".
В связи с этим в Торговой Системе изменена работа с марками старого образца. В текущей версии в администраторе почтового модуля в настройках фильтра «ЕГАИС – обмен данными» убрана опция «Поштучный учет для старых марок». Теперь, при поступлении вся продукция с марками старого образца будет учитываться на третьем регистре. Это обеспечивается следующими мерами: марки старого образца, перечисленные в ТТН ЕГАИС на приход, будут регистрироваться на третьем регистре, партии без марок или с неполным списком марок будут требовать полного подсчета марок. Подсчитанные марки будут ставиться на поштучный учет и регистрироваться на третьем регистре. Перевод партий с марками старого образца на второй регистр отменен и больше осуществляться не будет.
В результате изменений, после установки текущей версии, партионная маркированная продукция на второй регистр больше поступать не будет, а будет с нее только списываться.
Для поддержки этой технологии при приеме продукции будет необходимо выполнять полное сканирование марок всех экземпляров алкогольной продукции, за исключением тех случаев, когда вся поступившая продукция относится к поштучному учету. Для этого случая сохраняется возможность доверительного приема.
Можно ожидать, что количество партионного товара в обороте будет быстро снижаться и практически перестанет существовать к 01.07.2020. Для тех случаев, когда к указанному сроку на втором регистре сохранится остаток партионных товаров, будет предложено решение для их перевода на первый регистр с постановкой на поштучный учет.
В разделе «ТТН ЕГАИС на приход» при приеме ТТН ЕГАИС с неполным составом марок теперь обязательно требуется присоединить к ТТН процесс или несколько процессов «Подсчет марок ТСД» с полным составом отсканированных алкогольных марок. Марки, отсутствующие в ТТН, но имеющиеся в подсчете, в дальнейшем, распределяются по строкам ТТН ЕГАИС соответственно кодам алкогольной продукции. Если для одного кода алкогольной продукции будет несколько строк с неполным составом марок, марки между ними будут распределяться последовательно. Это распределение производится для того, чтобы определить принадлежность марок справкам РФУ2. После завершения фиксации ТТН в ЕГАИС, в ЕГАИС отсылается акт фиксации кодов алкогольной продукции в разрезе справок РФУ2 (ActFixBarCode). После чего все марки партии ставятся на собственный поштучный учет. Если ТТН принята не полностью, то на учет ставятся только принятые марки.
В разделе «Остатки ЕГАИС» внесено изменение в функцию «Перевод остатков продукции в торговый зал». В прошлом такая функция позволяла перевести на второй регистр всю продукцию со старыми марками, в текущей версии функция не позволяет перевести на второй регистр продукцию с поштучным учетом.
Остальные функции работают без изменений. Разделение в обработке поштучных старых марок и партионных существовало уже в прошлых версиях.

Карточки. Установка флага «Ценники за 0,1 единицу».

В разделе карточек складского учета в функцию «Обработать - Изменение карточки» добавлена возможность устанавливать или снимать флаг «Ценники за 0,1 единицу» для отобранных карточек.

Функции преобразования для XML фильтра.

В Редактор XML-схем добавлены следующие функции для обработки входящих XML-файлов:
GenerateDocNoWEbyINNГенерирует номер документа Супермага при приёме УПД
GenerateDocNoWEDatebyINNГенерирует номер документа Супермага при приёме УПД с контролем даты документа
Функция GenerateDocNoWEbyINN генерирует новый номер накладной поставщика при приеме документа, используя номер документа поставщика, ИНН и КПП контрагента поставщика и КПП места хранения поставки.
Функция GenerateDocNoWEDatebyINN дополнительно использует дату документа поставщика для генерации уникального номера документа Супермаг+ в случае повторения нумерации документа поставщика по истечении календарного периода, например, при возобновлении нумерации с Нового года.



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

Беларусь. Планирование контрактных цен.

Для законодательства «Беларусь» в разделе «Планирование контрактных цен» реализован следующий интерфейс:
Показываются цена производителя и оптовая надбавка из контракта (текущие значения), показываются три предыдущих значения этих величин из истории цен контракта, а также предоставляется возможность запланировать изменение этих величин (новые значения). После ввода новой цены производителя и оптовой надбавки в поле «Изменение цены поставки %» будет показано относительное изменение расчётной величины: [Цена производителя] * ( [Оптовая надбавка] / 100 + 1 ).
В предыдущих версиях история изменения цен контрактов для законодательства «Беларусь» не использовалась. Соответственно, в текущей версии ведется история изменения цены производителя и оптовой надбавки в контрактах с поставщиками, и эта история будет доступна только для новых изменений.

Отчет «Движение в производстве по себестоимости», опция «Виды документов».

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

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

Отчет «Контракты по товару», опция «Показывать штриховые коды производителя».

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

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

«Приём товара по заказу ТСД». Создание приходной накладной. Простановка производителя из карточки товара.

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

«Подсчет кодов КИЗ ТСД». Интерфейс ввода КИЗ.

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

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

ЕГАИС.

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

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

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

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

Акт списания с регистра №3 ЕГАИС. Простановка цены продукции.

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

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

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

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

В протокол загрузки весов CAS CL5000 добавлена загрузка состава, дат производства и срока истечения годности.
Состав передается в поле PLU «Direct message» не более 300 символов. Дата изготовления в поле «Produced date». Дата истечения срока годности в поле «Sell By date». Дата изготовления передается как количество дней, которое истекло с даты производства по текущую дату (вчера это 2). Дата истечения срока годности как количество дней от текущего дня плюс 1.
Даты, переданные в весы, актуальны только в течении дня.

Изменения функционала в версии 1.041
Установка 64-х разрядной реализации Супермаг.+
Штриховой код GS1.
Меркурий.
Справочник «Единицы измерений ГИС «Меркурий»».
Пополнение номенклатуры ГИС «Меркурий».
Контроль номенклатуры «Меркурий» при создании документов «Меркурий».
Повторное редактирование и отсылка отосланного документа «Меркурий».
Печать QR кодов ветеринарных сертификатов.
Подсчет кодов КИЗ ТСД.
Функция «Заново открыть завершенный процесс для редактирования».
Функция «Проверить КИЗ табачных марок в МОТП».
ЕГАИС.
ТТН ЕГАИС на приход. Права на отсылку отказа и акта расхождения.
Подсчет алкоголя ТСД. Ввод данных одним сканированием при подсчете без ТТН.
Приходная накладная. Функция «Заполнить документ ценами из ТТН ЕГАИС».
Инвентаризация ЕГАИС. Поиск марки в журнале инвентаризации.
Ценники.
Назначение артикулу категории ценника.
Журнал напечатанных ценников.
Торговая точка.
Касса Супермаг. Реализация маркированной продукции.+
Раздел «Товары». Печать ценников.
Раздел «Уценка ТСД».
Заказ поставщику.
Функции создания заказа поставщику.
Формирование пакета заказов на базе контракта.
Раздел «Инвентаризационные описи». Вложения и метки.
Раздел «Кассовые чеки». Функция «Автоматическая печать».
Функция проверки «Наличие товара в основании документа». Детализация.
Сервер обмена данными.
Почтовый модуль.
Передача информации в сервер обмена данными.
Функции преобразования для XML фильтра.
Количество потоков для приема входящих пакетов.
Администратор сервер приложений. Настройка принтера для печати документов из ТСД.
Административный модуль.
Настройка расчета товародвижения.
Генерация калькуляций по расписанию. Параллельное исполнение заданий.
Опции функции поиска цены последнего прихода.
Опция «Вести журнал формирования заказа на базе контракта».
Рассылка печатных форм документов в виде вложения в электронное письмо.
Законодательство Республики Беларусь.
Перечень исправленных ошибок и улучшений.

Установка 64-х разрядной реализации Супермаг+.

В перечень компонентов 64-х разрядных компонентов Супермаг + добавлен модуль загрузки весов:

По умолчанию модуль не устанавливается. Для его установки надо отметить флажок модуля.
64-х разрядный модуль загрузки весов не обслуживает весы CheckWay, Dibal, Shtrih и Toledo, имеющие 32-разрядные внешние драйверы.

Штриховой код GS1.

В справочник типов штриховых кодов добавлен код «маркировка GS1», предназначенный для распознавания кодов, составленных по правилам GS1. Это коды, которые могут содержать разнообразную информацию о товаре или упаковке, например, штриховой код EAN (GTIN), номер партии, серийный номер или дату изготовления. Набор данных может быть произвольным, то есть те или иные данные могут, как присутствовать, так и отсутствовать.
Подробнее см. {+}http://www.gs1ru.org/gs1stds/+. Для получения информации о структуре кода на странице сайта надо нажать кнопку «Далее».
Тип кода GS1 используется для идентификации КИЗ табачной и обувной продукции, за исключением КИЗ пачек табака.
Одновременно с добавление кода GS1 из типов штриховых кодов удалены типы «Блок табака без МРЦ - DataMatrix секционный штриховой код блока табака без МРЦ. Идентифицирует товар и серию. Имеет длину 25 и более символов» и «Блок табака с МРЦ - DataMatrix секционный штриховой код блока табака с МРЦ. Идентифицирует товар, серию и максимальную розничную цену товара. Имеет длину 41 символ». Эти типы являются вариантами использования типа кода GS1.
При работе с кодами GS1 необходимо учитывать, что в составе кода предусмотрено использование нечитаемого символа «табуляция полей». При чтении штрихового кода GS1 сканером в разрыв клавиатуры этот символ искажается или удаляется из строки штрихового кода, что делает невозможным его корректную обработку.
Для работы с КИЗ, нанесенными кодом GS1, необходимо использовать только сканеры в COM-порт. Это могут быть сканеры с USB-разъемом, но обязательно сконфигурированные для работы в режиме эмуляции COM-порта.

Меркурий.

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

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

Пополнение номенклатуры ГИС «Меркурий».

В разделе «Классификатор товаров» на закладку «Узел» добавлен атрибут «Ветеринарный надзор (Меркурий)». По умолчанию флаг не установлен.

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

При нажатии на кнопку «Да» выполняется переход к диалогу добавления артикула в номенклатуру ГИС «Меркурий»:


В раздел «Номенклатура ГИС «Меркурий» добавлена функция «Проверить номенклатуру». Функция проверяет артикулы из групп с флагом «Ветеринарный надзор (Меркурий)» и добавляет недостающие артикулы в список номенклатуры ГИС «Меркурий». Новые артикулы номенклатуры выделяются фоном для удобства дальнейшей обработки:

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

Контроль номенклатуры «Меркурий» при создании документов «Меркурий».

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

Повторное редактирование и отсылка отосланного документа «Меркурий».

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

Печать QR кодов ветеринарных сертификатов.

В текущей версии поддержано следующее изменение протокола обмена с системой «Ветис».
В файле ответа от системы «Ветис» на отсылку документа «Перевозка» ожидается перечень номеров ветеринарных транспортных сертификатов следующего вида:
<?xml version="1.0" encoding="UTF-8"?>
<ReceiptMessage MessageNo="20022000001" xmlns:xsi="http://www/w3/org/2001/XMLSchema">
<Receipt>
<OuterID>6d136560-d8b3-401e-8844-000000000044</OuterID>
<OtpravlenRanee>false</OtpravlenRanee>
<LoadSuccess>true</LoadSuccess>
<ObjecName>Vetis_Perevozka</ObjecName>
<PartiiZapolneny>true</PartiiZapolneny>
<DocumentZapolnen>true</DocumentZapolnen>
<Otpravlen>true</Otpravlen>
<ErrorText/>
<ErrorCode/>
<UUID_VSD_List>
<UUID_VSD_String>
<UUID>7f8d50e9-14fb-46f1-9023-cbad2f7fe2b3</UUID>
</UUID_VSD_String>
<UUID_VSD_String>
<UUID>f700abd0-1957-4fdd-a6aa-cd77baf451ef</UUID>
</UUID_VSD_String>
<UUID_VSD_String>
<UUID>7f8d50e9-14fb-46f1-9023-cbad2f7fe2b4</UUID>
</UUID_VSD_String>
<UUID_VSD_String>
<UUID>7f8d50e9-14fb-46f1-9023-cbad2f7fe2b5</UUID>
</UUID_VSD_String>
</UUID_VSD_List>
</Receipt>
</ReceiptMessage>
При приеме тикета информация о номерах ветеринарных сертификатов сохраняется в документе «Перевозка» и используется в печатной форме «Реестр ВСД» накладной, на основании которой был сделан документ «Перевозка»

Печатная форма содержит перечень QR кодов ветеринарных сертификатов следующего вида:

Подсчет кодов КИЗ ТСД.

В текущей версии раздел «Подсчет марок ТСД» получил название «Подсчет кодов КИЗ ТСД» и перемещен в группу разделов «Накладные».

Функция «Заново открыть завершенный процесс для редактирования».

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

Функция «Проверить КИЗ табачных марок в МОТП».

В раздел добавлена функция «Проверить КИЗ табачных марок в МОТП». Функция обращается в МОТП за информацией о принадлежности КИЗ табачных марок, перечисленных в журнале процесса.
По требованию протоколов МОТП, обмен данными происходит с использованием криптографических алгоритмов для надежной аутентификации участника обмена и шифрования потока данных.
Прежде чем использовать функцию «Проверить КИЗ табачных марок в МОТП» необходимо установить программу КриптоПро, получить и установить сертификат от МОТП или любого другого удостоверяющего центра, уполномоченного МОТП, например, сертификат ТаксКом.
Для установки программы КриптоПро необходимо скачать с сайта {+}https://www.cryptopro.ru/+ дистрибутив программы «КриптоПро CSP 5.0». Для скачивания программы необходимо зарегистрироваться.
Примечание. Программа КриптоПро поддерживает алгоритмы шифрования, криптографического хэширования, создания и проверки электронных подписей и т.д., которые необходимы для обмена с МОТП. Криптографические алгоритмы, входящие в состав ОС Windows, выполняя все необходимые действия, несовместимы с протоколом МОТП. Программа КриптоПро является платной и требует покупки лицензии для ее использования за пределами пробного периода.
Для установки сертификата скопируйте файл сертификата *.cer и каталог с шестью файлами *.key в корень диска, из которого будет устанавливаться сертификат. Если файлы размещены на флэш-накопителе, то в дальнейшем флэш-накопитель надо будет подключать к компьютеру на время работы с сертификатом.
Запустите программу КриптоПро CSP. Если программу запустить стандартным образом, то сертификат можно будет создать только для «Пользователя», то есть для текущего пользователя компьютера. Если программу КриптоПро CSP запустить от имени администратора, будет доступна установка сертификата для компьютера.
Для установки сертификата выберите закладку «Сервис», функцию «Установить личный сертификат». Далее надо следовать мастеру. При установке сертификата «Пользователя» необходимо учитывать, что он будет доступен только текущему пользователю ОС на этом компьютере. В этом случае при использовании сервера приложения для обмена с МОТП, то есть при работе клиента Супермаг+ через сервер приложений, необходимо будет запускать сервер приложений от имени того пользователя, для которого установлен сертификат.
Далее надо настроить параметры электронного документооборота. Для этого необходимо вызвать функцию «Настройка - Электронный документооборот»:

URL для связи с МОТП необходимо получить в МОТП. На картинке показан путь к тестовому контуру. Издатель сертификата выбирается из списка издателей установленных сертификатов. Если на компьютере установлено множество сертификатов, необходимо выбрать того издателя, сертификаты которого признаются МОТП.
При работе через сервер приложений необходимо выполнить такую же настройку в администраторе сервера приложений:

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

После получения такого сообщения можно выполнять проверку наличия марок КИЗ в МОТП и их принадлежность юридическому лицу:

Проверка кодов КИЗ может занять значительное время.

ЕГАИС.

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

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

Подсчет алкоголя ТСД. Ввод данных одним сканированием при подсчете без ТТН.

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

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

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

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

В разделе «Инвентаризация ЕГАИС» на закладку «Журнал инвентаризации» добавлен поиск строки журнала по номеру марки или по части номера марки:

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

Ценники.

Назначение артикулу категории ценника.

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

В карточке товаров на закладке «Ценники» можно определить персональное значение флага для категории ценника артикула (индивидуальные установки для артикула подсвечиваются желтым фоном):

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

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

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

Журнал напечатанных ценников.

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

Торговая точка.

Касса Супермаг+. Реализация маркированной продукции.

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

Раздел «Товары». Печать ценников.

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

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

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

Список напечатанных ценников периодически очищается от записей, срок печати которых превышает предел, заданный в параметрах раздела:

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

Раздел «Уценка ТСД».

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

Заказ поставщику.

Функции создания заказа поставщику.

Функции создания заказов вынесены из мастера создания нового документа в отдельные функции:

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

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

Если выбраны группы товаров, то при переходе к странице выбора контракта сразу показывается список контрактов, в которых встречаются товары выбранных групп:

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

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

Раздел «Инвентаризационные описи». Вложения и метки.

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

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

Из раздела «Кассовые чеки» удалена функция «Автоматическая печать». Функция была предназначена для специфического процесса магазинов Cash & Carry, потерявшего актуальность.

Функция проверки «Наличие товара в основании документа». Детализация.

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

• Товар отсутствует в заказе - основании данного прихода (при ручном добавлении товара в документ)
• Товар отсутствует или кол-во товара превышает кол-во в заказе - основании данного прихода (при ручном добавлении товара в документ)
  Общий список детализаций теперь выглядит следующим образом:
  
• Товар отсутствует в заказе - основании данного прихода
• Товар отсутствует или кол-во товара превышает кол-во в заказе - основании данного прихода
• Товар отсутствует в складском требовании - основании данного перемещения
• Товар отсутствует или кол-во товара превышает кол-во в складском требовании - основании данного перемещения
• Кол-во в расходе / перемещении превышает кол-во в общем основании (приходе / перемещении)
• Заказ поставщику содержит артикул, отсутствующий в подтверждении заказа поставщику
  • Товар отсутствует в заказе - основании данного прихода (при ручном добавлении товара в документ)*
• Товар отсутствует в заказе - основании данного перемещения
• Товар отсутствует или кол-во в расходе / перемещении превышает кол-во в общем основании (требовании на отбор)
  • Товар отсутствует или кол-во товара превышает кол-во в заказе - основании данного прихода (при ручном добавлении товара в документ)*
    

    Сервер обмена данными.

    
    В Администратор сервера обмена данными добавлена настройка локальных параметров базы данных:
    
    В локальных настройках можно определить параметры обмена для каждого из форматов обмена, если таковые для него имеются:
    
    В перечень форматов обмена добавлен формат «SM» - стандартный формат почтового обмена Супермаг+. Поскольку файлы почтового обмена стандартного протокола имеют бинарный формат, то при обмене через сервер приложений данные пересылаются с использованием MIME типа данных application/octet-stream.
    

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

    Передача информации в сервер обмена данными.

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

    Функции преобразования для XML фильтра.

    
    В Редактор XML-схем добавлены следующие функции для обработки входящих XML-файлов:
    CurrencyTypeByISOВозвращает идентификатор типа валюты по коду валюты ISO
    CurrencyTypeByOKVВозвращает идентификатор типа валюты по коду валюты ОКВ
    Функции определяют код валюты Супермаг+ по коду ISO или ОКБ соответственно. Соответствие устанавливается по справочнику валют. Справочник надо заполнить заблаговременно.
    ArticleBySupplierArticleВозвращает артикул в Супермаге по артикулу поставщика, его ИНН и КПП
    BarcodeKey Получение ключевой части штрихкода из любого штрихкода (для извлечения штрихового кода из кода КИЗ)
    CountryIdByCodeВозвращает идентификатор страны в Супермаге по цифровому коду страны (ОКСМ)
    ClientByINN Возвращает код контрагента по его ИНН и КПП
    LocationByKPP Возвращает код места хранения по его КПП
    

    Количество потоков для приема входящих пакетов.

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

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

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

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

    Настройка расчета товародвижения.

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

    Генерация калькуляций по расписанию. Параллельное исполнение заданий.

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

    Опции функции поиска цены последнего прихода.

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

    Опция «Вести журнал формирования заказа на базе контракта».

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

    Рассылка печатных форм документов в виде вложения в электронное письмо.

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

    Законодательство Республики Беларусь.

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

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

    
    
• Исправлено: если в настройках расчета товародвижения указать количество потоков чтения больше, чем количество рабочих буферов, то после завершения этапа расчета процесс подвисает.
  
• Исправлено: попытка соединения службы загрузки весов с базой данных через сервер приложений приводит к ошибке вида: «База данных … не зарегистрирована. Соединение с БД невозможно».
  
• Реестр процессов. Оптимизирована функция удаления экземпляров процесса. Процесс удаления происходил медленно при удалении более чем 5000 экземпляров процесса. Кнопка «Обработать» заменена на кнопки «Открыть» и «Удалить». Удалена кнопка «Новый».
  
• Исправлено: при настроенной автоматической рассылке накладных изменение их статуса с «Принят складом» на «Принят полностью» и обратно не приводит к рассылке связанных с ними финансовых обязательств.
  
• Настройка сканеров в последовательном порту. Добавлен флажок «Код префикса». По умолчанию флажок отмечен. Если его снять, при обработке данных от сканера код префикса анализироваться не будет.
  
• Прикрепление налогов к карточкам. Назначение / замещение налоговых групп для артикулов теперь будет происходить с отображением прогресс-бара процесса обновления артикулов.
  
  Изменения функционала в версии 1.042 сервис пак 1.
  Накладная поставщика. Состояние обмена с системой ЭДО.
  Фильтр УПД.
  Справочник «Метки документов». Системная метка «Тип скидки в LOYA».
  Тип кассы «Loya WEB API».

Накладная поставщика. Состояние обмена с системой ЭДО.

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

Фильтр УПД.

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

УПД фильтру XML соответствует пара объектов обмена «Подтверждение приема УПД XML» и «Прием УПД XML из 1С»:

и

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

Для схемы «Приём УПД XML из 1С» имеется два варианта описания – краткая для стороны, формирующей УПД, и полная, для описания преобразований, необходимых для приведения содержания УПД к содержанию накладной поставщика.
Алгоритм приема УПД входящего дополнен шагом, связанным с ожиданием прихода УПД взамен УПД входящего, прием по которому произошел с расхождением. Повторное УПД должно содержать в общих основаниях номер приходной накладной, для которой оно предназначено. Номер накладной в общих основаниях УПД позволяет исключить попытку повторного приема товара и позволяет автоматизировать обработку такого документа. Если повторный УПД имеет корректное содержание, то накладная поставщика, в которую он принимается, автоматически получает статус «Закрыт» и автоматически отсылается подтверждение приема с флагом приема без расхождений.
Алгоритм обмена подразумевает, что в случае приема с расхождением первичный УПД, содержание которого не совпало с результатами приемки, отвергается, а взамен него поставщик присылает другой УПД, совпадающий по содержанию с результатами приемки. Оба документа в виде накладных поставщика помещаются в основание приходной накладной – первичный со статусом «Заблокирован», повторный со статусом «Закрыт».

Справочник «Метки документов». Системная метка «Тип скидки в LOYA».

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

Тип кассы «Loya WEB API».

В текущей версии для кассового модуля добавлена касса типа «Loya WEB API». Драйвер кассы предназначен для передачи информации о маркетинговых акциях в систему «LOYA» одновременно с загрузкой в кассы информации о товарах, ценах и т.д.
Касса типа «Loya WEB API» может быть назначена только месту хранения типа «Центральный офис». Это связано с тем, что система «LOYA» устанавливается для всей организации, а не для отдельных магазинов.
В настройках драйвера необходимо задать IP адрес и порт системы LOYA, параметры аутентификации и перечень обслуживаемых мест хранений с указанием номера места хранения в LOYA:


Обслуживаемые места хранений указываются для отбора маркетинговых акций, данные которых будут передаваться в LOYA.
В настройках можно отметить флаг «Журнал выгрузки» и указать каталог, в котором будет формироваться файл с данными последней выгрузки в LOYA.
В систему LOYA выгружается информация из действующих маркетинговых акций с заданным значением системной метки «Тип скидки в LOYA» и с местом проведения акции из списка обслуживаемых мест хранений.
Выгрузка выполняется всегда полная, то есть, всегда выгружаются данные всех маркетинговых акций предназначенных для системы LOYA. Инкрементальная выгрузка не поддерживается.
Пример запроса: http://192.168.10.226:9000/api/1.0/mechanic/pricelist/541/list/upload
[
{
"sku": "00975",
"locationID": 85,
"awardValue": 120
},
{
"sku": "00975",
"locationID": 84,
"awardValue": 130
},
{
"sku": "07646",
"locationID": 23,
"awardValue": 444
}
]
Где:

• 192.168.10.226:9000 – сервер ЛОЯ
• 541 – ID скидки в ЛОЯ (значение системной метки маркетинговой акции «Тип скидки LOYA»)
• upload – команда на замещение.
• sku – артикул
• locationID – Код места хранения в ЛОЯ
• awardValue – значение аукционной цены.

Изменения функционала в версии 1.042 сервис пак 2.
Подсчет кодов КИЗ.
Отображение КИЗ для неизвестных штриховых кодов.
Идентификация товара с неизвестным штриховым кодом.
Добавление кодов КИЗ в накладные.
Приходные накладные.
Контроль соответствия КИЗ.
Доверительный прием поставки с КИЗ.
Почтовый модуль. «УПД фильтр XML».
Сервер обмена данными. Настройки фильтров УПД.
Драйвер касс «Loya Web API». Тест соединения с сервером LOYA.
Драйвер весов DIGI RM-5800. Управление длиной строк при печати названия товара.
Касса Супермаг. Модель ККТ АТОЛ 77Ф.+
Отчет «Движение в производстве по себестоимости». Детализация итогов по операциям.

Подсчет кодов КИЗ.

Отображение КИЗ для неизвестных штриховых кодов.

В процесс подсчетов кодов КИЗ на закладку «Неизвестные штриховые коды» добавлен колонка «КИЗ» для отображения КИЗ, содержащих неопознанные штриховые коды:

Идентификация товара с неизвестным штриховым кодом.

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

Если выбрано «Да», то показывается диалог для ввода штрихового кода EAN товара или выбора артикула с использованием раздела карточек складского учета:

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

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

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

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

Добавление кодов КИЗ в накладные.

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

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

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

Не разрешается дважды добавлять в накладную один и тот же КИЗ:

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

Контроль соответствия КИЗ.

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

Если в строке спецификации имеются КИЗ и количество, идентифицируемое КИЗ, больше, чем количество в строке, то ячейка с КИЗ окрашивается в розовый цвет:

Если в основании приходной накладной имеется накладная поставщика и в строке спецификации в перечне КИЗ имеется хотя бы один КИЗ, отсутствующий в накладной поставщика, то ячейка с КИЗ окрашивается в красный цвет:

В диалоге «КИЗ маркированной продукции» КИЗ, отсутствующие в накладной поставщика, окрашиваются в красный цвет:

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

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

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

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

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

При настройке фильтра необходимо указать путь к папке со схемами, также как для стандартного XML фильтра. В этой папке должна быть только схема для объекта WE (накладная поставщика). Схема для формирования ответа, то есть подтверждения приема поставки, встроена в фильтр.
Настройка правил рассылки для этого фильтра не требуется. Правила рассылки объектов для него заданы алгоритмом.

Сервер обмена данными. Настройки фильтров УПД.

В диалог настройки адресатов обмена для «УПД фильтра XML» и «УПД фильтра JSON» внесены следующие изменения в настройки обмена:
HTTP-адрес теперь должен содержать только IP-адрес и порт. В прошлых версиях он содержал полный URL. Теперь URL для приема и для отсылки данных составляется из HTTP-адреса и продолжения URL, которое встроено в алгоритм:
Прием УПД в формате XML:

/in/db/[Ид. уч. ЭДО]/xml

Прием УПД в формате JSON:

/in/db/[Ид. уч. ЭДО]/json

Отсылка подтверждения приема: /esb/send/REPLY
Проверка готовности к приему со стороны сервиса контрагента: /esb/ping
В заголовок HTTP-пакета при отсылке информации контрагенту добавляется информация для распознавания источника посылаемых данных, то есть Супермаг+:
prm-source-point-id: 1000300prm-source-sync: 1
В настройки добавлен выбор типа контента. Multipart/form-data – соответствует передаче данных в виде файла в составе HTTP-пакета. Text/plain – соответствует передаче данных в теле URL запроса:

Драйвер касс «Loya Web API». Тест соединения с сервером LOYA.

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

Драйвер весов DIGI RM-5800. Управление длиной строк при печати названия товара.

Весы DIGI RM-5800 позволяют в своих настройках указать шрифт, который будет использоваться для печати при выборе того или иного номера шрифта. Это не позволяет заранее точно определить количество символов, которое можно вывести на печать.
В диалог настройки весов DIGI RM-5800 Ethernet добавлены элементы для указания максимального количества символов, которое можно вывести на печать при использовании шрифта указанного размера:

При печати названия товара используются шрифты 7, 5, 4. Соответственно, количество символов задается для шрифтов с этими размерами.
Нажатие на кнопку «Стандартное» возвращает значения по умолчанию.

Касса Супермаг+. Модель ККТ АТОЛ 77Ф.

Перечень моделей ККТ, поддерживаемых кассой Супермаг+, пополнен ККТ АТОЛ 77Ф.

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

В диалог старта отчета «Движение в производстве по себестоимости» добавлена опция «Группировать по операциям»:

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

Изменения функционала в версии 1.042 сервис пак 3.
Функция проверки "Контроль совпадения КИЗ приходной накладной и накладной поставщика".
Почтовый модуль. XML фильтр. Экспорт результата приема по накладной поставщика.
Принтер этикеток. Ключевые слова %FOODVALUE1 и %FOODVALUE2 для разделение текста пищевой ценности на несколько строк.

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

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

Почтовый модуль. XML фильтр. Экспорт результата приема по накладной поставщика.

Для XML фильтра почтового модуля реализована функция «AcceptResultWE» - «Результат приёма накладной поставщика». Функцию можно использовать при редактировании XSD схемы накладной поставщика в редакторе xml-схем почтового модуля. Функция применима только для накладных поставщика и только при создании схемы для экспорта данных в XML.
Функция помещает в указанное поле одно из следующих значений:
0 – ожидается прием по накладной поставщика
1 – товары (работы, услуги, права) приняты без расхождений (претензий)
2 – товары (работы, услуги, права) приняты с расхождениями (претензией)
3 – товары (работы, услуги, права) не приняты
-1 – ошибочное состояние, например, накладная поставщика или, созданная на ее основании приходная накладная, имеют статус «Черновик».

Принтер этикеток. Ключевые слова %FOODVALUE1 и %FOODVALUE2 для разделение текста пищевой ценности на несколько строк.

В перечень ключевых слов для файла шаблона принтера этикеток добавлены слова %FOODVALUE1 и %FOODVALUE2 и опция «=» для вывода текста со значением пищевой ценности товара в нескольких строках с указанием максимальной длины строки в символах.
Например шаблон:
Пищевая ценность: %FOODVALUE=20
%FOODVALUE1=38
%FOODVALUE2

Будет преобразован в текст следующим образом:
Пищевая ценность: В 100 г. содержится:
белков 1,3 г. жиров 0,13 г. углеводов
3,3 г. Энергетическая ценность 19,9 ккал

Изменения функционала в версии 1.042 сервис пак 4.
Подсчет кодов КИЗ при приеме поставки на основании накладной поставщика (УПД).
Кассовые чеки. Отображение кода КИЗ в спецификации чека.
Создание кассовых документов. Перенос кодов КИЗ из чеков.

Подсчет кодов КИЗ при приеме поставки на основании накладной поставщика (УПД).

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

При отборе накладных поставщика в список попадают только накладные поставщика, содержащие КИЗ и в статусе «Принят». Накладные поставщика, содержащие только немаркированные товары, не могут служить основанием для подсчета кодов КИЗ:

При проведении подсчета считанный код КИЗ сличается с кодами из накладной поставщика и, если в накладной такого кода не оказывается, показывается сообщение об ошибке:

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

Экспорт может проводиться либо в новую приходную накладную, либо в уже существующую, если подсчет ведется несколькими счетчиками:

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

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

Кассовые чеки. Отображение кода КИЗ в спецификации чека.

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

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

Создание кассовых документов. Перенос кодов КИЗ из чеков.

В процедуру создания кассовых документов добавлен перенос кодов КИЗ из кассовых чеков.
В интерфейс кассовых документов добавлено поле для отображения списка проданных / возвращенных кодов КИЗ для артикула спецификации:


Для хранения кодов КИЗ в кассовом документе используется новая таблица «SMSpecCashTobacco». Таблица «SMSpecCashMarkCode» для хранения кодов марок алкогольной продукции переименована в «SMSpecCashAlcCodeDetail» во избежание недоразумений.
Изменение структуры таблиц кассовых документов требует обязательного завершения и остановки почтового обмена кассовыми документами до начала обновления структуры баз данных сети и возобновления почтового обмена только после завершения обновления в том случае, когда в магазинах регистрируется кассовая реализация маркированной продукции.

Изменения функционала в версии 1.042 сервис пак 5.
Накладная поставщика. Поле «Идентификатор участника обмена».
Почтовый модуль. УПД фильтр. Формат данных «ФНС XML».
Управление структурой файла ответа УПД фильтра для опции «XML» и «JSON».
Содержание файла ответа УПД фильтра для опции «XML» и «JSON».
Справочник «Типы штрихкодов». Тип штрихового кода «блок табака в УПД».
Подсчет кодов КИЗ ТСД. Использование сканера в разрыв клавиатуры.

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

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

Это же поле показывается на закладке «Главная» открытого документа:

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

Почтовый модуль. УПД фильтр. Формат данных «ФНС XML».

В УПД фильтр почтового модуля добавлен вариант формата данных «ФНС XML»:

В настройки фильтра также добавлена опция «Сохранять копию (.bak) при приёме».
При выборе формата данных «ФНС XML» в каталоге приема ожидается файл с УПД в том виде, в котором он должен приходить из системы ЭДО, то есть в формате, определенным приказом ФНС России от 19 декабря 2018 г. № ММВ-7-15/820@.
Фильтр позволяет принимать файл обмена продавца (УПД) и отсылать ответ о результате приемки в виде файла обмена покупателя. Файл обмена покупателя содержит только тэг «ИнфПок»: «Документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг), включающий в себя счет-фактуру (информация покупателя), или документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг) (информация покупателя)». То есть не содержит тэги, содержание которых определяется системой электронного документооборота.
Фильтр УПД может сформировать файл обмена покупателя о результатах приемки с двумя вариантами ответа: 1 – товары (работы, услуги, права) приняты без расхождений (претензий),
3 – товары (работы, услуги, права) не приняты. Вариант приема 2 – товары (работы, услуги, права) приняты с расхождениями (претензией) - в текущей версии фильтра УПД не поддерживается.
При приеме УПД контрагенты определяются по ИНН и КПП продавца и покупателя («СвПрод» «ИННЮЛ» и «КПП» и «СвПокуп» «ИННЮЛ» и «КПП»), артикул определяется по содержанию тэга «ИнфПолФХЖ2». Из атрибута «Значен» извлекается штриховой код EAN товара при условии, что атрибут «Идентиф» имеет значение «штрихкод». По значению кода EAN определяется артикул спецификации УПД.
Структура УПД не имеет однозначного указания о том, где и каким образом должен идентифицироваться артикул спецификации. Способы идентификации артикула будут определяться соглашениями между контрагентами.
Примеры принимаемого файла и файла ответа см. в каталоге дистрибутива сервис пака «УПД фильтр схемы и примеры». Файлы «ExFnsWE.xml» и «ExFnsReply.WE.xml».
Имя файла ответа формируется в соответствии с правилами ФНС:
6. Имя файла должно иметь следующий вид:
_R_Т_A_О_GGGGMMDD_N{_}, где:
_R_Т_ – префикс, принимающий значение ON_NSCHFDOPPOK в общем случае или значение ON_NSCHFDOPPOKХХХХ (где ХХХХ формируется в случае, если законодательством Российской Федерации предусмотрено использование настоящего формата в целях контроля за движением товара; принимает значение «PRОS» - для товаров, подлежащих прослеживаемости; «MАRK» - для товаров, подлежащих маркировке);
А – идентификатор получателя файла обмена информации покупателя, где идентификатор получателя совпадает с идентификатором участника электронного документооборота в рамках обмена счетами-фактурами и первичными учетными документами по телекоммуникационным каналам связи;
О – идентификатор отправителя файла обмена информации покупателя, где идентификатор отправителя совпадает с идентификатором участника электронного документооборота в рамках обмена счетами-фактурами и первичными учетными документами по телекоммуникационным каналам связи;
GGGG – год формирования передаваемого файла обмена, MM - месяц, DD - день;
N – 36 символьный глобально уникальный идентификатор GUID (Globally Unique IDentifier).
Расширение имени файла обмена - xml. Расширение имени файла обмена может указываться как строчными, так и прописными буквами.
Например:
ON_NSCHFDOPPOKMАRK_2AL-90908D02-F8F1-4F13-BD28-587A15534CF6-00000_2AL-1A7193A2-109F-4DD3-BABB-46C41C7FF60F-00000_20200903_AC4E25A0-C1CE-4D17-82A6-77BA3812957C.XML
XSD-схемы для файлов приема и ответа не требуются. Схемы принимаемых и отсылаемых файлов зафиксированы в коде УПД фильтра.

Управление структурой файла ответа УПД фильтра для опции «XML» и «JSON».

В предыдущих версиях структура файла ответа УПД фильтра с результатом приемки для опций «XML» и «JSON» была единственной. Описание схем можно посмотреть в файлах «Reply.WE.xsd» и «Reply.WE.json» в каталоге «УПД фильтр схемы и примеры» дистрибутива сервис пака.
Для приема с расхождениями в файле ответа была предусмотрена отсылка спецификации принятого товара с указанием артикула поставщика «SUPPLIERARTICLE».
В текущей версии перечень вариантов структуры ответа дополнен передачей спецификации с указанием собственного артикула «ARTICLE» или штрихового кода (GTIN) артикула «BARCODE».
Примеры схем файла ответа с собственным артикулом или штриховым кодом: «Reply.WE.A.xsd», «Reply.WE.A.json», «Reply.WE.B.xsd», «Reply.WE.B.json» можно посмотреть в каталоге «УПД фильтр схемы и примеры» дистрибутива сервис пака.
Управление схемой файла ответа осуществляется размещением того или иного файла в каталоге схем. Помещать сразу несколько схем в каталог не разрешается. В каталог надо поместить ту схему, в соответствии с которой должен формироваться файл ответа.

Содержание файла ответа УПД фильтра для опции «XML» и «JSON».

В структуру файла ответа УПД фильтра добавлены поля (пример описания полей дан в нотации XSD):
<xs:element name="CLIENTINN" type="xs:string" />
<xs:element name="CLIENTKPP" type="xs:string" />
<xs:element name="CLIENTGLN" type="xs:string" />
В поля выводятся данные об ИНН, КПП и GLN контрагента поставщика.

Справочник «Типы штрихкодов». Тип штрихового кода «блок табака в УПД».

В справочник типов штриховых кодов добавлен тип «блок табака в УПД»: секционный штрихкод блока табака. Идентифицирует товар, серию и максимальную розничную цену товара. Имеет длину 25, 29, 35 или 41 символ.
При обновлении версии одновременно добавляется запись в справочник «Штрихкоды» для включения нового типа в перечень используемых.
Тип штрихового кода предназначен для распознавания кодов КИЗ блоков табака, сформированных в соответствии с методическими рекомендациями ЦРПТ по описанию сведений о передаче маркированных товаров при оформлении электронных документов для уведомления ГИС МТ об обороте маркированной продукции.
В соответствии с методическими рекомендациями КИЗ блоков табака передается в электронных документах в виде строки, содержащей три поля с идентификаторами применения 01, 21 и 8005 (GTIN 14 символов, серийный номер 7 символов, МРЦ 6 символов). Символы идентификаторов применения могут быть заключены в скобки. Это представление КИЗ отличается от стандарта GS1, в частности, отсутствием символов разделителей полей, и от содержания КИЗ на упаковке блоков табака отсутствием полей с дополнительными сведениями.

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

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

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

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

Закладка «Нормы продукции».

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


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

Массовая обработка, смена статуса.

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

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

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





Если выбрать «Да», лидирующие пробелы при сохранении карточки будут удалены.

Документ «Рецепт».

Функция «Расчет пищевой ценности продукта».

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


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

Печатная форма «технологическая карта».

В диалог печати технологической карты № 17 добавлена опция «Пищевая ценность» (не показывать / на 100 грамм продукта / на выход продукта):


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

Печать этикетки. Ключевое слово %FOODVALUE.

В перечень ключевых слов шаблона этикетки добавлено слово %FOODVALUE, которое замещается словами "белки N г, жиры N г, углеводы N г, калорийность N ккал на 100г"
где N - значения соответствующих величин из карточки товара.
Из перечня ключевых слов удалены слова %EGAISNOPDF и %EGAISBEAR. Удален флаг «Только пиво» при печати этикеток из накладных.

Документ «Расходная накладная». Функция «Сформировать электронный УПД».

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


Если УПД уже отослан, то его пересоздание невозможно.

Документ «УПД на отгрузку».

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

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

Сервер обмена данными. Отсылка объектов получателям.

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


Адресату обмена присваивается имя, IP-адрес, тип обмена (старшая база / доверительная база / равноправная база), формат обмена (Стандартный XML фильтр / JSON фильтр / Стандартный фильтр / УПД фильтр).


Тип обмена влияет на правила приема объектов аналогично таким же правилам почтового модуля. Формат обмена частично соответствует фильтрам почтового модуля. «XML фильтр» и «Стандартный» позволяют использовать такую же нотацию форматов данных, как в почтовом модуле. «JSON фильтр» позволяет обмениваться информацией в формате JSON такого же содержания, как и при использовании «XML фильтр». Управление структурой объектов в формате JSON в текущей версии выполнено не полностью. Разрешено только упрощение объекта, то есть удаление полей и таблиц в структуре объекта. Функции преобразования данных для JSON формата в текущей версии не поддерживаются.
«УПД фильтр» поддерживает специальный протокол обмена для приема и передачи электронных УПД. В текущей версии УПД фильтра поддерживается обмен XML данными. В отличие от XML и JSON фильтров «УПД фильтр» не позволяет управлять структурой пакетов данных и поддерживает служебный обмен, в соответствии с требованиями электронного документооборота. HTTP адрес для УПД фильтра включает также URL для передачи информации адресату.
Для УПД фильтра не доступна настройка правил рассылки. Правила обмена и тип объектов обмена зафиксирован протоколом. По протоколу УПД принимается в документ типа «Накладная поставщика». По факту смены статуса накладной поставщика, полученной из ЭДО, на «Закрыт» (поставка принята) или «Заблокирован» (поставка отвергнута) адресату отсылается документ ЭДО «Подтверждение приема». При регистрации документа «УПД на отгрузку» выполняется его отсылка адресату обмена.
Структура файла подтверждения приема поставки в текущей версии следующая:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="PACKAGE">
<xs:complexType>
<xs:sequence>
<xs:element name="REPLY">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:string" />
<xs:element name="CREATEDAT" type="xs:dateTime" />
<xs:element name="RESULT" type="xs:int" minOccurs="1" maxOccurs="1" nillable="false" />
<xs:element name="SUPPLIERDOC" type="xs:string" />
<xs:element name="SUPPLIERINVOICE" type="xs:string" />
<xs:element name="SUPPLINVOICECREATE" type="xs:dateTime" />
</xs:sequence>
<xs:attribute name="description" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>
Для адресата обмена УПД фильтра имеется поле «Ид. уч-ка ЭДО», в которое надо заносить идентификатор собственного участника электронного документооборота. Если организация имеет несколько юридических лиц, для каждого из них необходимо создать свой адресат обмена. При обращении адресата к серверу обмена данных этот идентификатор должен добавляться в поле идентификатор_адресата строки URL:
curl -F "xml_file=@имя_файла" http://хост:порт/in/db/идентификатор_адресата/xml > Response.xml
Где имя_файла – это полное имя XML-файла с содержанием УПД, идентификатор_адресата – идентификатор, заданный в настройках адресата обмена, позволяющий различить разных адресатов, Response.xml – имя файла, в который будет помещен ответ службы по результату обработки принятой информации. Ответ может прийти с некоторой задержкой, которая зависит от объема передаваемой информации и от загруженности сервера базы данных.
В файл Response.xml помещается квитанция, например:
<?xml version="1.0" encoding="UTF-8"?>
<A>
  <ticketId>7f811134-ffe9-44e6-9c12-7b9e3d9cde6e</ticketId>
  <date>2020-05-21T09:48:07.295</date>
</A>
Далее необходимо запросить результат получения данных по номеру квитанции, например:
curl -X GET http://хост:порт/out/ticket/7f811134-ffe9-44e6-9c12-7b9e3d9cde6e > GetTicket.xml
Файл результата имеет содержание вида:
<?xml version="1.0" encoding="UTF-8"?>
<ticket>
<ticketId>3a9a55da-a20d-433f-b77d-dbe1cb16c73b</ticketId>
<date>2020-05-27T18:22:32.000</date>
<state>Success</state>
<direction>Import</direction>
<schemaType>utd</schemaType>
<processed>
<object ObjType="WE" ObjId="0000000015" />
</processed>
</ticket>
 
Для других протоколов в настройках имеется поле «Кому»:


Это необязательный параметр, который необходимо заполнять для адресного обмена данными с адресатом. Если поле не заполнено, то адресату доступно обращение с анонимным доступом вида:
curl -F "xml_file=@имя_файла" http://хост:порт/in/db/xml > Response.xml
Если заполнено, то адресное:
curl -F "xml_file=@имя_файла" http://хост:порт/in/db/От_кого/xml > Response.xml
Формат с использованием части URL «От кого» используется при связи двух БД через два сервера обмена данными. В этом случае на принимающей стороне должен быть заведен адресат с полем «Кому» = «От кого» отсылающего сервера.
Для управления доступа абонентов к информации при отсылке или приеме необходимо отметить схемы, разрешенные конкретным абонентам, или пометить их общедоступными:

«Заказ поставщику». «Заказ в торговом зале ТСД». Комментарий для поставщика.

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

Документ «Заказ от клиента». Статусы и атрибуты для интернет-заказа.

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


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


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


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

Торговая точка.

Раздел «Отгрузка». Отбор заказов от клиентов.

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

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

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

Документ «Маркетинговая акция». Печать ценников.

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

Торговая точка. Товары. Печать ценников для принятых маркетинговых акций.

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

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

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

Реестр платежей. Фильтр по местам поставки.

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

Функция проверки 142 «Контроль номенклатуры места хранения в документах»

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

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

  Процесс «Формирование пакета заказов на базе контракта».

  Создание процесса. Заполнение спецификации артикулами.

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

  Управление просмотром полей.

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

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

  
  В предыдущих версиях, если должность была назначена на отсутствующую дополнительную лицензию, то пользователь при подключении к базе данных получал сообщение об отсутствии лицензии или ее разрушении без указания на вид лицензии.
  В текущей версии сообщение выглядит следующим образом:
  сообщение: "Невозможно подключиться к базе данных «DEMO10»"
  hResult: 80004005h
  источник: Супермаг+
  сообщение: "Дополнительная лицензия не была введена в базу данных или разрушена"
  

  Отчеты.

  Отчет «Наличие товара поставщика в номенклатуре склада»

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

  Группа отчетов «Производственные»

  
  Создана новая группа отчетов «Производственные», куда перенесены имеющие отношение к производству отчеты из других групп.
  

  Отчет «Остатки в производстве по себестоимости»

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

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

  
  
• Для документа «Акт уценки» удалена функциональная роль «Просмотр цен».
• Сличительная ведомость с видом цены «цена поставки». Исправлена ошибка просмотра цен поставки для новой строки: «ORA-00936: отсутствует выражение ...».
• Изменена система блокировок, чтобы избежать конкуренции при большом количестве подключений. Для блокировки базы создана отдельная таблица SSDbLocks, которая блокируется в эксклюзивном доступе при необходимости блокировать базу. Таблица SSLocks эксклюзивно теперь не блокируется при установке или снятии блокировки на объект Торговой системы.
• Выполнен обход ошибки Oracle "Bug 9437010 DBMS_ALERT.REGISTER is slow. Range of versions believed to be affected Versions BELOW 12.1". Теперь процедура DBMS_ALERT.REGISTER вызывается с параметром cleanup=false для Oracle 11.2.0.2 и выше. Для младших версий Oracle процедура работает, как и раньше.
• Исправлено: в диалоге прогресса процесса обрезки, неверно форматировалась строка, отображающая длительность идущего процесса обрезки (при длительности более суток показывались только часы последних суток).
  
  
  Изменения функционала в версии 1.043 сервис пак 1.
  Остатки ЕГАИС. Акты фиксации марок на регистре №3.
  Отсылка акта возврата с регистра торгового зала. Проверка наличия справки РФУ2.
  Изменение в протоколе загрузки весов CheckWay.

Остатки ЕГАИС. Акты фиксации марок на регистре №3.

В раздел «Остатки ЕГАИС» добавлена закладка «Акты фиксации марок на регистре №3» для отображения списка актов фиксации марок и их содержания.

Например:

Отсылка акта возврата продукции из торгового зала. Проверка наличия справки РФУ2.

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

Изменение в протоколе загрузки весов CheckWay.

Для печати даты и времени истечения годности и даты "Реализовать до" в протокол весов CheckWay внесено следующее изменение - переставлены местами выгрузка в поля Shelf Date и  Sale Date/Sale Time. Пояснение см. ниже.  Изменение распространяется на все весы, использующие этот протокол. Информацию необходимо учитывать при проектировании формата этикетки.
При работе с весами Торговая система использует следующие понятия дат и времени:

• Текущая дата и время (в весы не передается, используется команда в формате этикетки)
• Дата и время производства
• Дата реализации или "Реализовать до" (время реализации не поддерживается, так как традиционно дата реализации - это количество дней от даты упаковки)
• Дата и время истечения годности
   
  По информации от производителя для весов CheckWay имеются следующие поля для даты и времени:
  Print Date/Print Time – текущая дата и время на момент печати
  Sale Date – дата в будущем
  Sale Time - текущее время или можно загрузить любое другое
  Package Date – дата в будущем
  Package Time - текущее время или можно загрузить любое другое
  Shelf Date – дата в будущем, рассчитывается от текущей даты + количество дней
  При передаче данных в весы данные времени теперь передаются следующим образом:
  - Текущее время и дата – управляется форматом этикетки (не передается)
• Дата реализации - Shelf Date. (PC_UD)

• Дата/время истечения годности - Sale Date/ Sale Time (PC_SD, PC_ST)
  Дата производства в весы не передается, поскольку весы не имеют возможности напечатать дату в прошлом.
  Приложение. Структура данных PLU, передаваемая в весы:
  int ID; //PLU unique ID. 1~9999996
  int Remark; //PLU cargo ID, Used for barcode print normally
  char Index[21]; //PLU exterior barcode. It is EAN/UPC barcode normally
  int Unit; //PLU unit. 1 is default by-weight unit, 2 is default by-count unit. (refer to table at last)
  double Price; //PLU default unit price
  double Cost; //Normally no use. PLU cost
  double Tare; //Normally no use. PLU default tare
  int Label1, BarT1, BarF1, Label2, BarT2, BarF2; //Normally no use. Print format
  int Class; //Normally no use. Stat. Class
  char Text[8][MAX_TEXT_LEN + 1]; //PLU text information. Text[0] is PLU name, other is information printable.
  int PS_SD, PS_ST, PS_PD, PS_PT, PS_UD;//PLU date print information. For example: PS_UD: Print shelf date or not: 1-print; 0-not print
  int PC_SD, PC_ST, PC_PD, PC_PT, PC_UD;//PLU date print days. For example: PC_UD: shelf days: 0- intraday, and so on…
  int DF_D, DF_U; //Normally no use. Manually discount limit sort
  double DF_DN, DF_UN; //Normally no use. Manually discount limit number
  
  
  
  
  
  Изменения функционала в версии 1.043 сервис пак 2.
  [<span style="color: #0000ff"><span style="text-decoration: underline; ">Подсчет алкоголя ТСД.</span></span> ]
  [<span style="color: #0000ff"><span style="text-decoration: underline; ">Произвольный подсчет. Определение ФСРАР ИД.</span></span> ]
  [<span style="color: #0000ff"><span style="text-decoration: underline; ">Функция «Удалить записи с марками поштучного учета».</span></span> ]
  [<span style="color: #0000ff"><span style="text-decoration: underline; ">Исправление описания сервис пака 5 для версии 1.042.</span></span> ]

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

Произвольный подсчет. Определение ФСРАР ИД.

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

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

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

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

Исправление описания сервис пака 5 для версии 1.042.

В описании версии 1.042 сервис пак 2 было указано, что структура файла ответа УПД фильтра для опции «XML» и «JSON» определяется выбором одного из файлов «Reply.WE.xsd», «Reply.WE.A.xsd», «Reply.WE.B.xsd», «Reply.WE.json», «Reply.WE.A.json», «Reply.WE.B.json»
В частности было сказано «Управление схемой файла ответа осуществляется размещением того или иного файла в каталоге схем. Помещать сразу несколько схем в каталог не разрешается. В каталог надо поместить ту схему, в соответствии с которой должен формироваться файл ответа.
». Данное описание необходимо дополнить фразой «и переименовать файл со схемой, присвоив ему имя «WECONFIRM.XSD»». УПД Фильтр ищет информацию о схеме ответа в файле WECONFIRM.XSD, если его не будет, фильтр сгенерирует ошибку.




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

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

Функция «Смена ФСРАР ИД».

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

Функция «Дублировать в новый подсчет».

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




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

Инвентаризация ЕГАИС. Поиск процесса по справке РФУ2.

В процессе «Инвентаризация ЕГАИС» на закладку «Товары» фильтра отбора процессов добавлен элемент «РФУ2» для отбора тех процессов, марки которых связаны с указанной справкой РФУ2:

Остатки ЕГАИС. Функция «Перевод крепкого алкоголя с регистра склада на поштучный учет». Алгоритм.

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

Подсчет алкоголя ТСД. Экспорт данных «в расходную накладную на возврат с созданием ТТН ЕГАИС». Алгоритм.

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

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

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

Драйвер касс УКМ4 XML. Загрузка группы классификатора средств индивидуальной защиты.

В протокол загрузки касс УКМ4 XML внесено следующее изменение:
При выгрузке файла updateItems_[x]_[x].xml для артикулов, у которых задана группа классификатора средств индивидуальной защиты (см. закладку «Классификация» в разделе «Карточки складского учета»)

в теге <addProperty> артикула товара теперь выгружается запись
<addProperty>
<id>ind_pro_means</id>
<name/>
<value>код_группы_средств_индивидуальной_защиты</value>
</addProperty>
где код_группы_средств_индивидуальной_защиты – значение кода группы средств индивидуальной защиты, например, 2400003675805
Предупреждение. Если в справочнике дополнительных характеристик товара создать характеристику с идентификатором «ind_pro_means», то значения этой характеристики для артикулов по протоколу УКМ4 XML выгружаться не будут.

Изменения функционала в версии 1.043 сервис пак 5.
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Справочник «Коды ТН ВЭД». Флаг «Немаркируемый остаток».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Драйвер касс УКМ4 XML.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Загрузка в кассу признака частично маркированного товара</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Загрузка в кассы признака маркированного товара для пива и пивной продукции.</span></span> ]

Справочник «Коды ТН ВЭД». Флаг «Немаркируемый остаток».

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

Драйвер касс УКМ4 XML.

Загрузка в кассу признака частично маркированного товара

В прежних версиях (с 1.039.2) артикулы, относящиеся к маркируемым товарам, то есть к группе классификатора ТН ВЭД с флагом «Маркируемый», выгружались по протоколу УКМ4 XML с значением в файле updateItems тэга egaisType равным 3.
Для некоторых видов маркируемых товаров разрешено не маркировать переходящие остатки. Для таких групп в справочник ТН ВЭД добавлен признак «Немаркируемый остаток». Артикулы, принадлежащие к группам с одновременно установленными флагами «Маркируемый» и «Немаркируемый остаток», выгружаются в кассу со значением тэга egaisType равным 4.

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

В предыдущих версиях для артикулов, принадлежащих к группе алкогольного классификатора с флагом «пиво», тэг egaisType в файле updateItems заполнялся значением 2. См. описание протокола:
<egaisType></egaisType>    ((int), признак акцизного товара; 0 - неакцизный товар, 1 - маркированный товар, 2 - немаркированный)
Теперь при выгрузке по протоколу УКМ4 XML пиво приравнено к неакцизному товару и для него тэг egaisType заполняется значением 0.



Изменения функционала в версии 1.043 сервис пак 6.
Сличительные ведомости. Генерация накладных по списку документов
Подсчет кодов КИЗ. Прием товаров с групповыми КИЗ
Сведение пересортицы. Создание накладных
Почтовый модуль, Сервер обмена данных. Фильтр «СуперМагМарко»

Сличительные ведомости. Генерация накладных по списку документов

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

Подсчет кодов КИЗ. Прием товаров с групповыми КИЗ

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

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

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

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

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

Почтовый модуль, Сервер обмена данных. Фильтр «СуперМагМарко»

В протокол обмена СупермагМарко внесено следующее изменение:
При выгрузке кодов алкогольных марок структура данных, передаваемая в Супермарко, такая же, как и в предыдущих версиях,:
<span style="color: #1d1c1d">{</span>
<span style="color: #1d1c1d"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e75e13d4-8655-4d35-a30c-5623c465984a"><ac:plain-text-body><![CDATA[  "marks": [

    {       "mark": "string",       "state": 1,       "store": 0,

      "items": [

        "string"       ]     }   ] } где marks - массив информации о марках элемент массива:mark string – Код марки state integer($int32) {_}default: 1 - {_}Состояние КИЗ (1 , 2) (прибыло,убыло)store integer($int64) - Идентификатор магазинаitems array\[string\] - массив штриховых кодов товара, через запятую \\ \\ Для неалкогольных марок, то есть для КИЗ в текущей версии тег «store» не передается (в отличии от кодов марок алкоголя, КИЗ стоят на учете всей организации, а не места хранения){*}:* {

  "marks": [

    {       "mark": "string",       "state": 1,

      "items": [

        "string"       ]     }   ] } \\ \\ \\ Изменения функционала в версии 1.043 сервис пак 7. \\ [Алкогольная декларация. Формы 7 и 8. |C:\TEMP\4\3\Изменения1043 сп7.doc#_Toc68520859]]]>

Алкогольная декларация. Формы 7 и 8.

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

• В таблицу страницы «Алкоголь: Закупки» добавлена колонка «Лицензируемая деятельность». При расчете декларации в нее будет сохранено значение новой дополнительной характеристики контрагента «Вид деятельности, указанной в лицензии на алкоголь» (Alco.LicActivity).
  Создание характеристики происходит при обновлении версии в тех базах данных, где до этого уже был установлен раздел «Алкогольная декларация» и созданы дополнительные характеристики контрагента для этого раздела. В случае первичной установки раздела для добавления необходимых дополнительных характеристик необходимо выполнить скрипт ProcessALCOLoad.sql.
  
• Добавлены новые страницы «Алкоголь: возвраты поставщикам» и «Пиво: возвраты поставщикам». Страницы могут быть скрыты. Для их отображения нужно вызвать диалог «Функции - Параметры раздела».
  
• Изменены печатные формы.
  Для маркированного алкоголя вместо формы 11 будет выводиться форма 7. Форма 7 по сравнению с формой 11 имеет следующие отличия:
  Раздел I. Отсутствует колонка «Закупки по импорту». Содержимое прежней колонки приплюсовано к колонке «Закупки от организаций-производителей».
  Раздел I. Отсутствует колонка «В т.ч. остатки продукции, маркированные ... марками, требования к которым утрачивают силу".
  Раздел II. Вместо четырех колонок с данными о лицензии («серия, номер», «дата выдачи», «дата окончания», «кем выдана») выводится одна колонка «вид деятельности, указанной в лицензии».
  Раздел III. В форме 11 отсутствовал. В нем выводятся документы возврата поставщику.
  Для пива и пивной продукции вместо формы 12 будет выводиться форма 8. Форма 8 по сравнению с формой 12 имеет следующие отличия:
  Раздел I. В форме 8 добавлены колонки «Поступление: перемещение» и «Расход: перемещение». Ранее содержимое этих колонок включалось в содержание колонок «Прочие поступления» и «Прочий расход».
  Раздел III. Ранее отсутствовал. В нем выводятся документы возврата поставщику.
  
• Изменен экспорт в XML-формат.
  XSD-формы 11 и 12 версии формата 4.31 заменены на XSD-формы 37 и 38 версии формата 4.4.
  Функция «Заполнить поле "Остаток предыдущей декларации"» при выборе в качестве источника данных «XML-файл алкогольной декларации» теперь будет требовать файлы, соответствующие версии формата 4.4.
  
  Изменения функционала в версии 1.043.1 сервис пак 2.
  Сервер обмена данными. Формат «Внешний XML/JSON». Авторизация.

Сервер обмена данными. Формат «Внешний XML/JSON». Авторизация.

В интерфейс администратора сервера обмена данных в диалог настройки адресата обмена для форматов обмена «Внешний [XML]» и «Внешний [JSON]» добавлена возможность выбора варианта авторизации «Basic без шифрования» и задания логина и пароля для этого способа авторизации:

При использовании Basic авторизации в заголовке каждого запроса указывается:
Authorization: Basic {login}:{password}

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



Изменения функционала в версии 1.043.1 сервис пак 3.
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Прием заказа ТСД. Отказ от приема товара.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Справочник «Коды ТН ВЭД». Флаг «Немаркируемый остаток».</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Драйвер касс УКМ4 XML.</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Загрузка в кассу признака частично маркированного товара</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Загрузка в кассы признака маркированного товара для пива и пивной продукции.</span></span> ]

Прием заказа ТСД. Отказ от приема товара.

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

Справочник «Коды ТН ВЭД». Флаг «Немаркируемый остаток».

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

Драйвер касс УКМ4 XML.

Загрузка в кассу признака частично маркированного товара

В прежних версиях (с 1.039.2) артикулы, относящиеся к маркируемым товарам, то есть к группе классификатора ТН ВЭД с флагом «Маркируемый», выгружались по протоколу УКМ4 XML с значением в файле updateItems тэга egaisType равным 3.
Для некоторых видов маркируемых товаров разрешено не маркировать переходящие остатки. Для таких групп в справочник ТН ВЭД добавлен признак «Немаркируемый остаток». Артикулы, принадлежащие к группам с одновременно установленными флагами «Маркируемый» и «Немаркируемый остаток», выгружаются в кассу со значением тэга egaisType равным 4.

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

В предыдущих версиях для артикулов, принадлежащих к группе алкогольного классификатора с флагом «пиво», тэг egaisType в файле updateItems заполнялся значением 2. См. описание протокола:
<egaisType></egaisType>    ((int), признак акцизного товара; 0 - неакцизный товар, 1 - маркированный товар, 2 - немаркированный)
Теперь при выгрузке по протоколу УКМ4 XML пиво приравнено к неакцизному товару и для него тэг egaisType заполняется значением 0.



Изменения функционала в версии 1.043.1 сервис пак 4.
Сличительные ведомости. Генерация накладных по списку документов
Подсчет кодов КИЗ. Прием товаров с групповыми КИЗ
Сведение пересортицы. Создание накладных
Административный модуль. Управление статусом документов процесса «Произвольный подсчет»
Почтовый модуль, Сервер обмена данных. Фильтр «СуперМагМарко»

Сличительные ведомости. Генерация накладных по списку документов

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

Подсчет кодов КИЗ. Прием товаров с групповыми КИЗ

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

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

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

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

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

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

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

Почтовый модуль, Сервер обмена данных. Фильтр «СуперМагМарко»

В протокол обмена СупермагМарко внесено следующее изменение:
При выгрузке кодов алкогольных марок структура данных, передаваемая в Супермарко, такая же, как и в предыдущих версиях,:
<span style="color: #1d1c1d">{</span>
<span style="color: #1d1c1d"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="618c5841-23b9-49d8-9bb1-f15554513b73"><ac:plain-text-body><![CDATA[  "marks": [

    {       "mark": "string",       "state": 1,       "store": 0,

      "items": [

        "string"       ]     }   ] } где marks - массив информации о марках элемент массива:mark string – Код маркиstate integer($int32) {_}default: 1 - {_}Состояние КИЗ (1 , 2) (прибыло,убыло)store integer($int64) - Идентификатор магазинаitems array\[string\] - массив штриховых кодов товара, через запятую \\ \\ Для неалкогольных марок, то есть для КИЗ в текущей версии тег «store» не передается (в отличии от кодов марок алкоголя, КИЗ стоят на учете всей организации, а не места хранения){*}:* {

  "marks": [

    {       "mark": "string",       "state": 1,

      "items": [

        "string"       ]     }   ] } \\ \\ \\ Изменения функционала в версии 1.043.1 сервис пак 5. \\ [Алкогольная декларация. Формы 7 и 8. |C:\TEMP\4\3\Изменения1043.1 сп5.doc#_Toc68598547] [Кассовые документы. Прием данных о возврате артикулов типа «Деньги». |C:\TEMP\4\3\Изменения1043.1 сп5.doc#_Toc68598548]]]>

Алкогольная декларация. Формы 7 и 8.

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

• В таблицу страницы «Алкоголь: Закупки» добавлена колонка «Лицензируемая деятельность». При расчете декларации в нее будет сохранено значение новой дополнительной характеристики контрагента «Вид деятельности, указанной в лицензии на алкоголь» (Alco.LicActivity).
  Создание характеристики происходит при обновлении версии в тех базах данных, где до этого уже был установлен раздел «Алкогольная декларация» и созданы дополнительные характеристики контрагента для этого раздела. В случае первичной установки раздела для добавления необходимых дополнительных характеристик необходимо выполнить скрипт ProcessALCOLoad.sql.
  
• Добавлены новые страницы «Алкоголь: возвраты поставщикам» и «Пиво: возвраты поставщикам». Страницы могут быть скрыты. Для их отображения нужно вызвать диалог «Функции - Параметры раздела».
  
• Изменены печатные формы.
  Для маркированного алкоголя вместо формы 11 будет выводиться форма 7. Форма 7 по сравнению с формой 11 имеет следующие отличия:
  Раздел I. Отсутствует колонка «Закупки по импорту». Содержимое прежней колонки приплюсовано к колонке «Закупки от организаций-производителей».
  Раздел I. Отсутствует колонка «В т.ч. остатки продукции, маркированные ... марками, требования к которым утрачивают силу".
  Раздел II. Вместо четырех колонок с данными о лицензии («серия, номер», «дата выдачи», «дата окончания», «кем выдана») выводится одна колонка «вид деятельности, указанной в лицензии».
  Раздел III. В форме 11 отсутствовал. В нем выводятся документы возврата поставщику.
  Для пива и пивной продукции вместо формы 12 будет выводиться форма 8. Форма 8 по сравнению с формой 12 имеет следующие отличия:
  Раздел I. В форме 8 добавлены колонки «Поступление: перемещение» и «Расход: перемещение». Ранее содержимое этих колонок включалось в содержание колонок «Прочие поступления» и «Прочий расход».
  Раздел III. Ранее отсутствовал. В нем выводятся документы возврата поставщику.
  
• Изменен экспорт в XML-формат.
  XSD-формы 11 и 12 версии формата 4.31 заменены на XSD-формы 37 и 38 версии формата 4.4.
  Функция «Заполнить поле "Остаток предыдущей декларации"» при выборе в качестве источника данных «XML-файл алкогольной декларации» теперь будет требовать файлы, соответствующие версии формата 4.4.
  

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

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

Программа инициализации базы данных.

Изменен интерфейс программы инициализации / обновления версии базы данных Супермаг+. Ранее программа позволяла определять параметры работы с базой данных в общем диалоговом интерфейсе.
В текущей версии задание параметров осуществляется в мастере начала работы с программой

Программа снабжена дополнительными проверками, которые помогают избежать типичных ошибок при работе с базой данных:
В прошлых версиях для успешной работы программы требовалась корректная установка параметра NLS_LANG в системном реестре для ключа Oracle или в переменной окружения операционной системы. Сейчас нужный для работы NLS_LANG параметр (AMERICAN_AMERICA.CL8MSWIN1251) устанавливается автоматически перед каждым запуском SQL*Plus внутри программы инициализации базы.
В прошлых версиях для работы программы пользователям нужно было обязательно устанавливать параметр экземпляра базы данных Oracle "O7_DICTIONARY_ACCESSIBILITY" в значение TRUE. Иначе случалась ошибка ORA-28009. Теперь внутри программы подключение выполняется от имени SYS с привилегией SYSDBA.
В прошлых версиях инициализация могла пройти без ошибок, но в базе могли остаться нескомпилированные объекты. Этот факт обнаруживался уже в ходе работы с торговой системой. Теперь после окончания инициализации базы показывается список нескомпилированных объектов.
Подробное описание программы см. Инициализация базы данных.docx

Классификатор товаров. Свойство группы товаров «Группа ТН ВЭД».

В разделе «Классификатор товаров» на закладку «Узел» добавлен атрибут «Группа ТН ВЭД». Значение атрибута копируется в карточку при создании.

ЕГАИС

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

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

ТТН ЕГАИС. Функция «Отменить документ».

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

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

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

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

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

Инвентаризация ЕГАИС. Поиск строки в журнале по значению алкокода или РФУ2

В разделе «Инвентаризация ЕГАИС» на закладке «Журнал инвентаризации» открытого процесса добавлена возможность поиска строки журнала по значению кода алкогольной продукции или справки РФУ2:

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

Журнал обмена с ЕГАИС. Удаление записей журнала при сборке мусора.

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

Документы. Дополнительные характеристики товара в спецификации.

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

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

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

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

Заказ от клиента. Сумма затребованного количества.

В заголовок таблицы спецификации добавлено поле «Сумма затреб.» - сумма затребованного количества.

Типы штриховых кодов.

В справочник «Типы штрихкодов» добавлено три типа для внешних весовых штриховых кодов:
19. Весовой ШК18«Штриховой код, нанесённый производителем товара и содержащий вес товара. Содержит 18 цифр, из которых первые 13 используются для уникальной идентификации товара, следующие 5 - вес товара в граммах. Может иметь префикс, совпадающий со штучными штрихкодами.»
22. Весовой + дата ШК20«Секционный штрихкод, нанесённый производителем товара и содержащий вес и дату производства товара. Содержит 20 цифр, из которых первые 8 используются для уникальной идентификации товара, следующие 5 - вес товара в граммах, далее - 6 цифр – дата производства ДДММГГ. Последний символ – контрольный разряд. Может иметь префикс, совпадающий со штучными штрихкодами.»
23. Весовой без ун. префШтриховой код EAN-13, нанесённый производителем товара и содержащий вес товара. Содержит 13 цифр, из которых первые 7 используются для уникальной идентификации товара, следующие 5 - вес товара в граммах и последняя цифра - контрольный разряд. В БД хранятся первые 7 цифр штрихкода. Может иметь префикс, совпадающий со штучными штрихкодами.
Новые типы штриховых кодов предназначены для идентификации весового товара белорусских производителей. Такие товары могут иметь этикетки, например, следующего вида:

Не следует включать использование этих весовых штрихкодов без предварительного анализа товарного состава торгового предприятия, поскольку они конфликтуют с другими типами штриховых кодов.
Штриховой код типа «Весовой ШК18» может быть принят за код «групповая тара ЕГАИС» - «Групповая тара ЕГАИС. Цифровой, Code 128, имеет длину 26 символов (короб) или 18 символов (палетта).». Для использования кода «Весовой ШК18» необходимо отключить использование кода «групповая тара ЕГАИС».
Штриховой код «Весовой без ун. преф» может быть принят за код «EAN 13» - «Штрихкод EAN-13. Содержит 13 цифр, включая контрольный разряд. Используется для уникальной идентификации товара и его количества в упаковке.». При использовании кода «Весовой без ун. преф» необходимо убедиться, что не существует других штучных товаров с кодами EAN13, у которых первые 7 символов совпадают с кодами весовых белорусских товаров. При использовании этого кода необходимо обязательно задать префикс, например, 481.
При использовании кода «Весовой ШК18» артикульную часть кода, то есть код EAN13 из состава композитного 18 символьного кода, необходимо присвоить артикулу с указание типа «Весовой ШК18». Количество для этого штрихкода не задается, что позволяет не допустить ошибку при сканировании товара, на который нанесены оба кода и EAN13 и 18 символьный с количеством:

При сканировании кодов в документах, если вместо 18 символьного кода с количеством будет просканирован EAN13, то будет показано сообщение:

Артикульная часть для 20-ти символьного кода вводится при выборе типа штрихового кода «Весовой + дата ШК20». Вводить надо ровно 8 символов. Если ввести иное количество символов будет получено сообщение об ошибке.

Срок годности из штрихового кода при работе с документами в текущей версии не используется.

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

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

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

Сервер обмена данными.

Настройка каталога для отсылки данных в чужой сервер.

В текущей версии в сервер обмена данными добавлены протоколы «Внешний XML» и «Внешний JSON»:

Протоколы «Стандартный XML фильтр», «Стандартный JSON фильтр», «Стандартный фильтр» получили название: «Сервер обмена [XML]», «Сервер обмена [JSON]», «Сервер обмена [SM]».
Новые протоколы идентичны протоколам «Сервер обмена [XML]» и «Сервер обмена [JSON]», за исключением настроек обращения к серверу адресата. В протоколах «Сервер обмена [XML]» и «Сервер обмена [JSON]» при настройке адресата задается IP адрес, порт сервера адресата и название БД адресата. В этих протоколах при отсылке данных обращение к серверу адресата формируется по фиксированному правилу:
http://IP адрес:порт/in/db/название БД абонента/формат данных
Например:
http://94.23.172.61:53080/in/db/SH22/json
В протоколах «Внешний XML» и «Внешний JSON» каталог для передачи данных задается явным образом в строке URL:

Запрос аналитических объектов.

В сервере обмена данными реализована возможность запроса информации аналитического объекта. Для этого создан новый тип объектов IO «Аналитические данные». Данные объектов можно получать либо в XML, либо в JSON формате. Структура объекта позволяет иметь неограниченное количество аналитических объектов различного назначения и состава.
Для примера создан объект «Остатки текущие», который можно получить запросом:
curl.exe -s -X GET {+}http://localhost:8085/out/json/IOSMIOGOODSCURRENT/*+
где «/*» - идентификатор объекта.
Объект выгружает суммарные текущие остатки по всем местам хранения.
Предупреждение. Объект «Остатки текущие» в настоящей версии не имеет опций для фильтрации отбираемых данных. Объект сделан для примера и в следующих версиях будет модифицирован.
Для включения доступа к аналитическим объектам необходимо в администраторе сервера обмена данных нажать кнопку «Настройка объектов обмена» и в диалоге «Схемы объектов обмена» на закладке «Отсылаемые из Супермага» нажать кнопку «Добавить» (в принимаемых объектах аналитические объекты не разрешены). В диалоге «Добавление схемы объекта обмена» надо выбрать опцию «аналитические данные» и выбрать нужную схему:

Нажать кнопку «Далее», поправить, при необходимости, название схемы и нажать кнопку «Готово»:

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

Процессы ТСД. Функция «Импорт данных из файла».

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

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

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

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

Администратор сервера приложений. Разрешение на подключение ТСД.

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

Раздел «Отчеты».

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

В разделе реализован поиск отчета по части названия:

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

Запоминается и показывается пять последних запущенных отчетов:

В системе более не поддерживаются отчеты Microsoft Access 2000 и Crystal Reports.

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

• Изменено ограничение уникальности названия пользовательской операции. Теперь уникальность контролируется в пределах системной операции. Раньше требовалась сквозная уникальность.
  
• При создании новой площадки или редактировании существующей и использовании уже существующего GUID, показывалось сообщение: ORA-00001: нарушено ограничение уникальности (SUPERMAG.SMCMERCURYPLACES_PK. Теперь показывается сообщение: «Площадка с кодом ... уже существует».
  
• Исправлена ошибка создания акта списания маркированной алкогольной продукции. Ошибка возникала, если марка числилась израсходованной на собственном поштучном учете и не израсходованной на учете ЕГАИС. При выполнении функции экспорта в расходную накладную с созданием акта списания в процессе подсчета алкоголя ТСД для таких марок создавался акт списания с типом «акт списания из торгового зала» вместо акта списания со склада.
  
  
  Изменения функционала в версии 1.043
  ЕГАИС.
  Перевод маркированных остатков второго регистра на поштучный учет.
  Подсчет алкоголя ТСД. Функция «Заполнить марками 3-го регистра». Опция «Только марки артикула».
  Подсчет алкоголя ТСД. Функция «Заполнить коды алкогольной продукции».
  Остатки ЕГАИС. Акты передачи и возврата продукции. Фильтр по справкам РФУ2.
  Меркурий. Площадки ГИС «Меркурий».
  Почтовый модуль. Фильтр «СуперМагМарко».
  Сервер обмена данными. Формат обмена «СуперМагМарко».
  Касса.
  Справочник «Классификатор средств индивидуальной защиты».
  Заполнение тэга 1162 при формировании чека.
  Продажа табачных изделий с контролем МРЦ из кода КИЗ.
  Пречек на основании заказа от клиента при продаже маркированных товаров.
  Процесс «Сведение пересортицы».
  Сличительные ведомости, инвентаризационные описи, требования на отбор. Использование упаковочных листов.
  Упаковочные листы. Генерация требований на отбор.
  Классификатор категорий товаров, карточки товаров. Сопутствующие товары.
  Склады и магазины. Цена для интернет-магазина.
  Комплектация заказа ТСД.
  Сличительные ведомости в ценах поставки. Генерация накладных.
  Расходы на производство. Функция «Проставить основания и принять».
  Драйвер весов «Falcon».
  Печать ценников. Печать PLU для штучных товаров.
  Задание на производство. Печатная форма «Выполнение задания на производство».

ЕГАИС.

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

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


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

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

Подсчет алкоголя ТСД. Функция «Заполнить марками 3-го регистра». Опция «Только марки артикула».

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

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

Подсчет алкоголя ТСД. Функция «Заполнить коды алкогольной продукции».

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

Остатки ЕГАИС. Акты передачи и возврата продукции. Фильтр по справкам РФУ2.

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

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

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

В текущей версии для площадки ГИС «Меркурий» разрешено вводить несколько ИНН хозяйствующих субъектов. В прошлых версиях считалось, что на площадке может работать только один хозяйствующий субъект.
При создании площадки, как и в прошлых версиях, мастер создания площадки позволяет задать один хозяйствующий субъект. Добавить дополнительный перечень хозяйствующих субъектов можно, нажав кнопку «...» в поле «ИНН ХС площадки» в режиме редактирования:


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

Почтовый модуль. Фильтр «СуперМагМарко».

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

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

  "marks": [

    {
      "mark": "string",
      "state": 1,
      "store": 0,

      "items": [

        "string"
      ]
    }
  ]
}
marks - массив информации о маркахэлемент массива: mark string - КИЗ state integer($int32) default: 1 - Состояние КИЗ (1 , 2) store integer($int64) - Идентификатор магазина (опциональное)

items array[string] - массив идентификаторов товаров, которым может принадлежать КИЗ (артикулы и/или штрихкоды), через запятую

Сервер обмена данными. Формат обмена «СуперМагМарко».

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

Касса.

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

Справочник «Классификатор средств индивидуальной защиты».

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

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

Такие же элементы добавлены в функцию «Обработать - Изменение классификации» для массовой обработки карточек:

Заполнение тэга 1162 при формировании чека.

В прежних версиях в соответствии с законодательством при заполнении тэга 1162 использовались следующие префиксы:
табак - 44h 4Dh
меха - 52h 48h
ЕГАИС старые марки - C5h 14h
ЕГАИС новые марки - C5h 1Eh
В соответствии с новыми требованиями к этому перечню добавляются средства индивидуальной защиты (маски, перчатки), которые маркируются идентификационными кодами в формате EAN13 (это не код товара, а аналог кода классификатора, сформированный по правилам EAN13):
Средства индивидуальной защиты - Префикс "45h 0Dh"; Строка GTIN - EAN дополненный слева нулями до 14 символов и преобразованный в BIN (big endian), размером 6 байт. Если после преобразования получается менее 6, то следует добавить лидирующие нули.
При создании чека, если артикул относится к группе классификатора средств индивидуальной защиты, то строка с таким артикулом передается в ОФД с заполнением тэга 1164 по описанным выше правилам.

Продажа табачных изделий с контролем МРЦ из кода КИЗ.

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

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

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

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

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

Процесс «Сведение пересортицы».

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

И предоставить право для использования процесса:

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

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

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

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

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

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

При успешном завершении создания накладных показывается список созданных документов и процесс завершается:

Перейти к созданным документам можно по кнопке «Созданные документы»:

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

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

Упаковочные листы. Генерация требований на отбор.

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

Документ создаётся в статусе «Черновик» и операцией «Возврат перемещения». Спецификация документа заполняется совокупной спецификацией упаковочных листов. Список упаковочных листов помещается в заголовок документа.
Функция предназначена для подготовки заданий сотрудникам магазина по возврату на склад упаковок, переданных для продажи клиентам интернет-магазина, но не выкупленных ими.

Классификатор категорий товаров, карточки товаров. Сопутствующие товары.

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

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



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

Склады и магазины. Цена для интернет-магазина.

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

Комплектация заказа ТСД.

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

Сличительные ведомости в ценах поставки. Генерация накладных.

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

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

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

Драйвер весов «Falcon».

В текущей версии поддержан протокол весов самообслуживания с печатью «DP Falcon». Протокол весов аналогичен протоколу «DIGI SM-5000 Ethernet». Отличие заключается в способе загрузки групп товаров (классификатора), который в этих весах загружается на «дополнительную панель».

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

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

Задание на производство. Печатная форма «Выполнение задания на производство».

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

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

Изменения функционала в версии 1.044 сервис пак 1.
ЕГАИС.
Подсчет алкоголя ТСД. Экспорт данных в накладную на перемещение. Простановка цен.
Почтовый модуль. Функция экспорта таблицы кодов КИЗ для документа.
Заказ в торговом зале ТСД. Отображение созданных документов.
Прием заказа ТСД. Отображение созданных документов.
Печать этикеток. Ключевое слово %PRICEDATESET.

ЕГАИС.

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

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

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

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

Предлагается создать новое поле CARDFULLNAME, которое при выгрузке документа будет содержать название артикула:

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

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

При создании собственной таблицы для выгрузки данных КИЗ, из схемы нужно удалить таблицу SMSPECTOBACCO, во избежание путаницы:

Из собственной таблицы надо удалить все лишние поля, которые были скопированы из эталонной таблицы при ее создании:

И добавить поле, которое будет содержать КИЗ с помощью функции «SpecTobaccoWI»:


В качестве аргументов надо выбрать поля собственной таблицы (в примере SMSPECKIZ)

В результате будет получена таблица следующего содержания:

Необходимо учитывать, что в этой таблице одному пункту спецификации может соответствовать множество КИЗ, то есть поле с КИЗ (в примере MARKCODE) входит в первичный ключ таблицы.
Функция «SpecTobaccoWI» работает следующим образом: она заполняет таблицу кодами КИЗ из приходной накладной, если в накладной имеются КИЗ, или заполняет кодами КИЗ из накладной поставщика - основания приходной накладной, если прием был доверительным. Накладные поставщика рассматриваются, если они имеют статус «Принят» или «Закрыт».

Заказ в торговом зале ТСД. Отображение созданных документов.

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

Прием заказа ТСД. Отображение созданных документов.

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

Печать этикеток. Ключевое слово %PRICEDATESET.

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

Изменения функционала в версии 1.044 сервис пак 2.
Прием маркированного товара.
Алкогольная декларация. Формы 7 и 8.

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

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

Режим приема УПД «с предварительным приемом накладной поставщика».
Режим приема УПД «с предварительным приемом накладной поставщика» соответствует ранее реализованному варианту приема маркированного товара, когда перед началом приема маркированного товара от поставщика приходит накладная поставщика с КИЗ маркированного товара, затем, на ее основании производится прием, и результат приема (приходная накладная с КИЗ принятых товаров) отсылается поставщику. Поставщик, получив уведомление о приеме, посылает УПД, который принимается в документ «УПД на приход» и при получении сопоставляется с поставкой через накладную поставщика. По результатам сопоставления поставщику отсылается документ подтверждения приема или отказа от приема, УПД на приход переводится в статус «Закрыт» или «Заблокирован», а приходная накладная, в случае совпадения с УПД, получает статус «Принят полностью».
Режим приема УПД «с созданием накладной поставщика по УПД».
Режим приема УПД «с созданием накладной поставщика по УПД» предполагает, что поставщик не посылает накладную поставщика, но до поставки отсылает УПД.
В этом случае УПД играет, как роль уведомления об отгрузке, так и собственно УПД, то есть документа подтверждающего переход собственности на товар. При приеме УПД помещается в документ «УПД на приход» и одновременно создается его копия в виде накладной поставщика. Далее производится прием маркированного товара по тем же правилам, что и в случае режима «с предварительным приемом накладной поставщика». То есть, либо с полным сканированием всех принятых КИЗ, либо с доверительным приемом маркированного товара.
В случае полного приема товара, при смене статуса приходной накладной с «Черновик» на «Принят складом» поставщику отсылается подтверждение приема. УПД на приход получает статус «Закрыт», накладная поставщика получает статус «Закрыт». Дальнейший перевод приходной накладной в статус «Принят полностью» выполняется оператором. В случае частичного приема товара, поставщику отсылается отказ от приема УПД, и УПД на приход получает статус «Заблокирован». Накладная поставщика до приема повторного УПД также получает статус «Заблокирован». В УПД фильтре XML и JSON в документе с отказом от приема отсылается содержание приходной накладной и ожидается, что поставщик вышлет повторный УПД, совпадающий по составу с фактически принятым товаром.
Внимание! В режиме приема УПД «с предварительным приемом накладной поставщика» поставщику отсылается уведомление о приеме поставки в виде приходной накладной при любом результате приема. В режиме приема УПД «с созданием накладной поставщика по УПД» уведомление о приеме не отсылается, а отсылается документ подтверждения приема УПД, и содержание приходной накладной помещается в него только в случае приема с расхождением.
При приеме повторного УПД, он распознается, как повторный по совпадению номера документа поставщика с таким же номером в накладной поставщика. В этом случае документ принимается только в «УПД на приход» и новая накладная поставщика не создается. При совпадении его состава с составом приходной накладной, поставщику автоматически отсылается документ с подтверждением приема, УПД на приход переводится в статус «Закрыт», накладная поставщика из заблокированного состояния переводится в статус «Закрыт», а приходная накладная - в статус «Принят полностью». При несовпадении состава на повторный УПД отсылается отказ от приема и УПД переводится в статус «Заблокирован».
Режим приема УПД «без накладной поставщика».
Режим приема УПД «без накладной поставщика» подразумевает, что в момент приема поставки от поставщика нет никаких документов, уведомляющих об отгрузке.
В этом случае необходимо провести приемку маркированного товара с полным подсчетом КИЗ и с занесением в заголовок приходной накладной номера документа поставщика. Доверительный прием в этом режиме невозможен из-за отсутствия документов, содержанию которых можно было бы доверять.
По результатам приемки поставщику в качестве уведомления о приеме отсылается приходная накладная (при смене статуса с «Черновик» на «Принят складом») и ожидается, что поставщик пришлет УПД.
При приеме УПД от поставщика он помещается в документ «УПД на приход», и для него ищется приходная накладная по совпадению номера документа поставщика в УПД и в приходной накладной. Если такой приход найден, проводится сопоставление содержания УПД и приходной накладной. Если состав документов не совпадает, поставщику отсылается отказ от приема и УПД переводится в статус «Заблокирован». При совпадении содержания документов, поставщику отсылается документ подтверждения приема, УПД на приход получает статус «Закрыт», а приходная накладная переводится в статус «Принят полностью».
При повторном приеме УПД, если первый документ УПД не совпал по составу с приходной накладной и получил статус «Заблокирован», например, по случайной ошибке отправителя, первый документ будет удален, как потерявший значение, и новый УПД будет принят на его место.
Журнал изменений такого документа будет выглядеть, например, так:

«Отправка почтой» - это отправка документа подтверждения приема УПД

Алкогольная декларация. Формы 7 и 8.

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

• В таблицу страницы «Алкоголь: Закупки» добавлена колонка «Лицензируемая деятельность». При расчете декларации в нее будет сохранено значение новой дополнительной характеристики контрагента «Вид деятельности, указанной в лицензии на алкоголь» (Alco.LicActivity).
  Создание характеристики происходит при обновлении версии в тех базах данных, где до этого уже был установлен раздел «Алкогольная декларация» и созданы дополнительные характеристики контрагента для этого раздела. В случае первичной установки раздела для добавления необходимых дополнительных характеристик необходимо выполнить скрипт ProcessALCOLoad.sql.
  
• Добавлены новые страницы «Алкоголь: возвраты поставщикам» и «Пиво: возвраты поставщикам». Страницы могут быть скрыты. Для их отображения нужно вызвать диалог «Функции - Параметры раздела».
  
• Изменены печатные формы.
  Для маркированного алкоголя вместо формы 11 будет выводиться форма 7. Форма 7 по сравнению с формой 11 имеет следующие отличия:
  Раздел I. Отсутствует колонка «Закупки по импорту». Содержимое прежней колонки приплюсовано к колонке «Закупки от организаций-производителей».
  Раздел I. Отсутствует колонка «В т.ч. остатки продукции, маркированные ... марками, требования к которым утрачивают силу".
  Раздел II. Вместо четырех колонок с данными о лицензии («серия, номер», «дата выдачи», «дата окончания», «кем выдана») выводится одна колонка «вид деятельности, указанной в лицензии».
  Раздел III. В форме 11 отсутствовал. В нем выводятся документы возврата поставщику.
  Для пива и пивной продукции вместо формы 12 будет выводиться форма 8. Форма 8 по сравнению с формой 12 имеет следующие отличия:
  Раздел I. В форме 8 добавлены колонки «Поступление: перемещение» и «Расход: перемещение». Ранее содержимое этих колонок включалось в содержание колонок «Прочие поступления» и «Прочий расход».
  Раздел III. Ранее отсутствовал. В нем выводятся документы возврата поставщику.
  
• Изменен экспорт в XML-формат.
  XSD-формы 11 и 12 версии формата 4.31 заменены на XSD-формы 37 и 38 версии формата 4.4.
  Функция «Заполнить поле "Остаток предыдущей декларации"» при выборе в качестве источника данных «XML-файл алкогольной декларации» теперь будет требовать файлы, соответствующие версии формата 4.4.
  
  Изменения функционала в версии 1.044 сервис пак 3.
  ЕГАИС.
  Четвертый формат.
  Подсчет алкоголя ТСД. Функция «Исключить из подсчета марки, проданные по кассе».
  Подсчет кодов КИЗ ТСД. Функция «Дублировать в новый подсчет».
  Кассовые документы. Прием данных о возврате артикулов типа «Деньги».

ЕГАИС.

Четвертый формат.

В протокол обмена с ЕГАИС внесены изменения для приема и отсылки ТТН в 4-м формате. ТТН в 3-м формате будут по-прежнему приниматься. ТТН отсылаются только в 4-м формате.
При отсылки ТТН для транспортного раздела обязательные значения заполняются следующими значениями по умолчанию:

• Изменение права собственности (ChangeOwnership) для перемещения: NotChange, для расхода: IsChange.
• Тип перевозки (TRAN_TYPE): 413.
• Транспортное средство (TRANSPORT_TYPE): car.
  Установку текущего обновления необходимо согласовать с обновлением УТМ и отсылкой в ЕГАИС уведомления о готовности работать с четвертым форматом.
  

  Подсчет алкоголя ТСД. Функция «Исключить из подсчета марки, проданные по кассе».

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

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

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

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

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

ЕГАИС.

Контрагенты. Выбор 3-го или 4-го формата документа для отсылки ТТН контрагенту.

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

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

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

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

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

Подсчет алкоголя ТСД. Поиск строки журнала по марке, алкокоду или РФУ2.

В процессе «Подсчет алкоголя ТСД» в интерфейс открытого процесса добавлен элемент для поиска строки журнала по номеру марки, алкокода или РФУ2:

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

Остатки ЕГАИС. Поштучный учет. Функция «Проверить в УТМ».

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

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

Сличительные ведомости. Генерация номеров документов при выполнении функции «Обработать->Создать накладные»

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

Изменения функционала в версии 1.044 сервис пак 5.
ЕГАИС
Инвентаризация пива ЕГАИС. Функция «Создать акты списания / постановки на баланс»
Остатки ЕГАИС. Функция «Перевод остатков в торговый зал»
Остатки ЕГАИС. Поштучный учет. Функция «Проверить в УТМ».
Отсылка в ЕГАИС актов возврата продукции из торгового зала большого объема
Остатки ЕГАИС. Акты возврата из торгового зала. Поле «Подсчет алкоголя ТСД»
Отчет «Остатки». Остатки «текущие»
Печатная форма «товарно-транспортная накладная по форме 1Т»

ЕГАИС

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

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

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

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

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

Остатки ЕГАИС. Поштучный учет. Функция «Проверить в УТМ».

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

Отсылка в ЕГАИС актов возврата продукции из торгового зала большого объема

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

Остатки ЕГАИС. Акты возврата из торгового зала. Поле «Подсчет алкоголя ТСД»

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

Отчет «Остатки». Остатки «текущие»

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

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

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

Изменения функционала в версии 1.044 сервис пак 6.
Почтовый модуль. Функции импорта из XML пакетов.

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

Для документа «УПД на приход» добавлены следующие функции для генерации номера документа: GenerateDocNoUI, GenerateDocNoUIbyINN , GenerateDocNoUIDate, GenerateDocNoUIDatebyINN.
Функции работают аналогично таким же функциям документа «Накладная поставщика» («WE»).
При приеме XML-пакета в функциях GenerateDocNoWEbyINN, GenerateDocNoWEDatebyINN, GenerateDocNoWEDatebyINN2, GenerateDocNoUIbyINN, GenerateDocNoUIDatebyINN, GenerateDocNoUIDatebyINN2 и ClientByINN для определения контрагента используется информация об ИНН и КПП. В предыдущих версиях предполагалось, что ИНН и КПП однозначно характеризуют контрагента. Однако выяснилось, что в некоторых случаях в базе данных может существовать множество контрагентов с одним и тем же ИНН, КПП, что порождает неопределенность и ошибку при нахождении контрагента в процессе выполнения функций.
В текущей версии в перечисленных выше функциях в случае обнаружения нескольких контрагентов с заданным ИНН и КПП выбирается один с наименьшим значением GLN.



Изменения функционала в версии 1.044 сервис пак 7.
ЕГАИС. Возврат немаркированной продукции с регистра склада без указания основания.
Накладные. Печатная форма Счет-фактуры.

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

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

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

Накладные. Печатная форма Счет-фактуры.

Печатная форма счет-фактуры приведена в соответствие с Постановлением Правительства РФ от 02.04.2021 № 534


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

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

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

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

В протоколе почтового обмена «УПД фильтр» с форматом «ФНС XML», то есть в протоколе, основанном на использовании форматов ФНС для ЭДО, УПД теперь принимается в документ «УПД на приход», а не в накладную поставщика. При использовании этого протокола никаких изменений в настройки обмена вносить не требуется.
Также как и прежде, протокол УПД фильтр ФНС XML не требует для своей работы XSD схем описания структуры принимаемых и отсылаемых файлов и не требует настройки правил рассылки. Формат файлов обмена и правила рассылки для этого протокола являются фиксированными и не перенастраиваются.
При использовании протокола «УПД фильтр» с форматом XML или JSON для приема УПД теперь вместо схемы накладной поставщика необходимо использовать схему документа «УПД на приход».
Для приема накладной поставщика более нельзя использовать протокол «УПД фильтр». Накладную поставщика надо принимать другими протоколами. При использовании протокола «Стандартный XML фильтр» в схеме приема не должно быть полей «EDOID», «EXCHANGESTATE», «OURUTDID». Для накладной поставщика попытка приема документа с наличием в схеме этих полей приведет к ошибке приема.
Схема документа «УПД на приход» полностью совпадает со схемой документа «Накладная поставщика» с той разницей, что тип документа должен быть «UI» и в схеме документа «УПД на приход» отсутствуют таблицы SMSPECPACKSWE, SMSPECSCALEWE и SMDOCPACKS, в которых обычно передается информация о сроках годности, детализация по значениям свойств, список упаковочных листов в поставке.
Если поставщик уже отладил схему документооборота по протоколу XML, то для перехода к новой нотации ему необходимо при создании документа «УПД на приход» заменить значение WE на UI в следующих тэгах:
<Id>WE</Id>
<WE>
.....
<DOCTYPE>WE<DOCTYPE >
......
</WE>
<Id>UI</Id>
<UI>
.....
<DOCTYPE>UI<DOCTYPE >
.....
<\UI>
Примечание. Тэг «DOCTYPE» - тип документа, может быть указан в XSD схеме документа со значением по умолчанию и в этом случае в файле поставщика с документом УПД этот тэг может отсутствовать.
При приеме документа «УПД на приход» делается проверка на наличие в системе документа «Накладная поставщика» в статусе «Принят» или «Закрыт» с теми же значениями контрагентов и места поставки, что и в УПД на приход и с тем же значением атрибута «Накладная поставщика» (номер документа поставщика). Поиск проводится только среди документов с датой не далее 365 дней назад. Если такой документ найден, он проставляется в основание УПД на приход вместе с номером приходной накладной, созданной на основании накладной поставщика.
Далее делается проверка одинаковости содержания УПД и приходной накладной, в том числе проверяется совпадение кодов КИЗ, за исключением случая доверительного приема. Если содержание совпадает, то документ УПД на приход получает статус «Закрыт» и поставщику отсылается документ подтверждения приема. Схема подтверждения приема осталась прежней, за исключением того, что поменялось название файла со схемой на «UICONFIRM.xsd».
При успешной смене статуса УПД на прием одновременно меняется статус накладной поставщика на «Закрыт», если накладная поставщика имела статус «Принят», а приходная накладная переводится в статус «Принят полностью».
При расхождении в составе УПД и приходной накладной УПД на приход получает статус «Заблокирован» и поставщику отправляется документ отказа от приема.

Редактор XML схем. Функции импорта из XML пакетов.

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

Функция имеет дополнительный аргумент – ИНН собственного контрагента места хранения.

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

ЕГАИС.

ТТН ЕГАИС на приход. Повторный прием ТТН из ЕГАИС.

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


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


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

После завершения повторного приема ТТН строки получают пометку «Обмен успешно завершен». Их можно удалить вручную.

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

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

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


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

В прошлых версиях в ТТН всегда проставлялась цена для кассы места хранения «Из».

Учет кодов марок при частичном отказе поставщика принять возврат.

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

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

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

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

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

Остатки ЕГАИС. Информация о количестве строк в таблице.

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

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

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

Функция работает, если в основании приходной накладной имеется накладная поставщика.

Ценообразование. Применение правила округления цен.

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

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

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

Структура магазина / склада. Код отдела во внешней системе

В разделе «Структура магазина / склада» в атрибуты отдела добавлен «Код отдела во внешней системе:

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

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

В процедуру выгрузки данных в кассу по протоколу УКМ4 XML внесены следующие изменения:
В файлах stocks – справочник отделов магазина и itemStoreStock – привязка товаров к отделам магазина в поле storeId теперь вместо кода отдела выгружается значение кода отдела во внешней системе. Если поле кода отдела во внешней системе в описании отдела отсутствует, информация об отделе не выгружается.

Администратор сервера обмена данными.

Опция повторной отсылки

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

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

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

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

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

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

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

Группа данных «Совместимость с СМ 2.6»

Из раздела «База данных», закладка «Конфигурация» удалена группа данных «Совместимость с СМ 2.6».

Процесс «Комплектация требования ТСД».

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

Процесс «Заказ в торговом зале ТСД». Генерация заказов и складских требований

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

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

В диалогах «О программе» Администратора сервера приложений Супермаг+ и Базового модуля Супермаг+ стало возможным копирование номера ключа (ключей для Сервера приложений) в буфер обмена:

В диалоге базового модуля термин «номер ключа» имеет название «номер лицензии».

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

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

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

Заказ от клиента имеет статусы «Черновик», «Размещен», «Собран», «Закрыт». В предыдущих версиях функция проверки 12 «Документ содержит товары с нулевой ценой» позволяла контролировать нулевые цены в заказе от клиента отдельно от других документов при смене статуса «Размещен» - «Собран» (2-3). В текущей версии для этого документа добавлен контроль при смене статуса «Черновик» - «Размещен». Это сделано для того случая, когда на стадии оформления заказа в него был помещен артикул с еще не оформленной ценой или подарок, то есть товар с нулевой ценой, при условии, что товары с нулевой ценой клиенту в заказах запрещены. В таком случае, при размещении заказа артикул пропускался проверкой, а проверка срабатывала, когда, заказ формально уже оформлен и подтвержден клиенту.

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

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

Отчет «Оборачиваемость товаров и групп товаров».

Создан новый отчет «Оборачиваемость товаров и групп товаров». Отчет помещен в группу «Менеджерские».
В отчете участвуют артикулы типа «товар», «тара» и «инвентарь», входящие в документы товародвижения отчетного периода в статусах 2 и 3 или имеющие ненулевой остаток на конец отчетного периода. При выборе опции «включать только товары со среднесуточной реализацией <> 0» из рассмотрения исключаются артикулы, у которых среднесуточная реализация (в единицах измерения артикула) равна нулю.
Основные термины отчета:
Остаток на конец периода - количественный остаток в единицах измерения артикула на конец последнего дня отчетного периода.
Средний остаток = ( [Остаток 1] / 2+ [Остаток 2] + [Остаток 3] + … + [Остаток N-1] + [Остаток N] / 2 ) / ( [N] - 1 ),
где [Остаток N] - количественный остаток в единицах измерения артикула на конец N-го дня отчетного периода, [N] - количество дней в периоде. Расчет производится, если отчетный период включает более одного дня.
Реализация - количество в единицах измерения артикула из кассовых продаж за вычетом возвратов от покупателя. Рассматриваются оприходованные кассовые документы отчетного периода с операциями «Продажа» и «Возврат от покупателя».
Дни продаж - дни, в которые были кассовые продажи или возвраты от покупателей.
Среднесуточная реализация - реализация (количество), деленная на количество дней периода или на количество дней продаж в зависимости от выбора опции "среднесуточная реализация".
Оборачиваемость «в разах» = [Реализация] / [Средний остаток].
Оборачиваемость в днях = [Средний остаток] * [Количество дней периода] / [Реализация].

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

Отчеты

В перечисленных ниже отчетах в диалог старта добавлена опция «Учитывать артикулы типа «деньги»»:
Бухгалтерские:

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

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

  
  
• Ошибка вида "Не удалось включить ограничения. По меньшей мере одна строка содержит значение, нарушающее ограничения по отсутствию пустых значений, уникальности или внешним ключам" при рассылке кассовых документов. Ошибка случалась из-за наличия финишных пробелов в номерах дисконтных карт в кассовых чеках. Теперь при создании чека в базе производится обрезка конечных пробелов у номера дисконтной карты.
  
• Установка. Ошибка регистрации служб. При определенном порядке действий установки 32-х и 64-х битных версий программы, включающем разрегистрацию служб, могла происходить ошибка, из-за которой не регистрировались службы. При возникновении такой ситуации теперь после неудачи в журнал установки пишется «ОШИБКА», происходит снятие регистрации службы, в журнал пишется «ОК» и выполняется регистрация службы, в журнал пишется «ОК».
  
• Ошибка создания алкогольной декларации «ORA-12899: значение для столбца "SUPERMAG"."SPALCOINCOMESPEC"."DOCID" слишком велико (фактическое: 93, максимальное: 50)» случалась из-за того, что номер накладной поставщика в приходной накладной содержал много концевых пробелов. Теперь при сохранении в базе данных номера накладной поставщика, номера счета-фактуры поставщика в приходной накладной, а также номера счета-фактуры в расходной накладной из этих строк удаляются концевые пробелы.
  
• Сервер приложений. Потеря соединение пользователей с сервером приложений из-за ошибки OutOfMemory, например, при выполнении отбора всех документов одним из пользователей. Ошибка происходила, когда при чтении строк из базы данных в буфер обмена сервера приложений, клиентская часть не успевала вовремя забирать данные, и буфер заполнялся до такого размера, что при готовности клиента принять данные не хватало памяти для передачи массива. Теперь установлено ограничение на размер буфера в 16384 строки. После чего чтение из базы данных приостанавливается до освобождения буфера.
  
• В поле «Марки» спецификации ТТН ЕГАИС показывается информация о состоянии списка принятых марок. Раньше в нем показывалась строка «совпадение всех кодов», когда все принятые марки имели соответствие в ТТН ЕГАИС независимо от того, все ли количество продукции было принято. Теперь выводится строка «совпадение всех принятых кодов», что точнее отражает смысл.
  
  Изменения функционала в версии 1.045
  ЕГАИС
  Справочник «Пересортица алкогольной продукции».
  Инвентаризация ЕГАИС. Функция «Создать акты списания / постановки на баланс».
  Кассовые документы. Функция «Списание пива ЕГАИС». Запрет генерации актов постановки на баланс.
  Остатки ЕГАИС. Поштучный учет. Фильтр по номеру марки.
  Подсчет алкоголя ТСД. Функция «Объединить выделенные подсчеты в новый подсчет».
  Подсчетов кодов КИЗ ТСД. Экспорт данных в упаковочный лист.
  Раздел «Структура разделов». Поиск раздела.
  Карточки складского учета. Добавление в набор артикулов с флагом «Разрешена безвозмездная передача».
  Кассовый документ. Показ алкогольных марок в спецификации кассовых документов.
  Сличительная ведомость. Функция «Создать накладные». Блокирование актов потерь / обнаружений
  Приходная накладная. Функция «Проставить срок годности из карточки»
  Контракты с поставщиками. Функция «Копировать соглашения о поставках из контракта». Опция формирования списка артикулов.
  Заказ поставщику. Отображение названия контрагента поставщика
  Акт сортировки. Общие основания.
  Требование на отбор. Отображение суммы по фактическому количеству.
  Заказ от клиента. Название статуса «Согласован».
  Торговая точка. Обработка КИЗ.
  Процесс «Формирование пакета заказов на базе контракта».
  Использование цен маркетингового контракта при создании заказа.
  Проверка допустимости даты заказа.
  Процесс «Прием по заказу ТСД». Простановка цены в приходную накладную.
  Процесс «Отгрузка товара по заказу ТСД». Отгрузка по заказу поставщику.
  Заказ в торговом зале ТСД. Подсчет товаров ТСД. Управление статусом документов.
  Почтовый модуль, Сервер обмена данными. Фильтр СуперМагМарко.
  Почтовый модуль. Функции импорта из XML пакетов.
  Отчет «Реализация по поставщикам». Опция «Доля поставщика в реализации»
  Перечень исправленных ошибок и улучшений.

ЕГАИС

Справочник «Пересортица алкогольной продукции».

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

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

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

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

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

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

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

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

  Остатки ЕГАИС. Поштучный учет. Фильтр по номеру марки.

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

  Подсчет алкоголя ТСД. Функция «Объединить выделенные подсчеты в новый подсчет».

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

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

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

  Раздел «Структура разделов». Поиск раздела.

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

  Карточки складского учета. Добавление в набор артикулов с флагом «Разрешена безвозмездная передача».

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

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

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

  Сличительная ведомость. Функция «Создать накладные». Блокирование актов потерь / обнаружений

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

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

  
  В раздел документов «Приходная накладная» добавлена функция «Проставить срок годности из карточки». Для работы с функцией надо иметь право на функциональную роль: «Прих. накл.: Простановка срока годности из карточек». Функция доступна в режиме редактирования документа со статусом «Черновик».
  Функция заполняет поле «Годен до» значением, которое вычисляется следующим образом:
  [Дата и время истечения срока годности ] = [Дата накладной и время запуска функции] + [Срок годности (из карточки товара)]
  Если срок годности товара в карточке более трёх дней (72 часов), то время считается равным 00:00.
  Если срок годности в карточке не задан, то поле «Годен до» не заполняется.
  Функцию можно использовать при оприходовании продукции собственного производства или продукции партнеров, когда она поступает в магазин по приходным накладным.
  

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

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

  Заказ поставщику. Отображение названия контрагента поставщика

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

  Акт сортировки. Общие основания.

  
  В интерфейс раздела документов «Акт сортировки» добавлен элемент для отображения и редактирования общего основания документа.
  

  Требование на отбор. Отображение суммы по фактическому количеству.

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

  Заказ от клиента. Название статуса «Согласован».

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

  Торговая точка. Обработка КИЗ.

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

  Процесс «Формирование пакета заказов на базе контракта».

  Использование цен маркетингового контракта при создании заказа.

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

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

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

  Процесс «Прием по заказу ТСД». Простановка цены в приходную накладную.

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

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

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

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

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

  Почтовый модуль, Сервер обмена данными. Фильтр СуперМагМарко.

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

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

  
  Для документа «УПД на приход» добавлены следующие функции для генерации номера документа: GenerateDocNoUI, GenerateDocNoUIbyINN , GenerateDocNoUIDate, GenerateDocNoUIDatebyINN.
  Функции работают аналогично таким же функциям документа «Накладная поставщика» («WE»).
  При приеме XML-пакета в функциях GenerateDocNoWEbyINN, GenerateDocNoWEDatebyINN, GenerateDocNoWEDatebyINN2, GenerateDocNoUIbyINN, GenerateDocNoUIDatebyINN, GenerateDocNoUIDatebyINN2 и ClientByINN для определения контрагента используется информация об ИНН и КПП. В предыдущих версиях предполагалось, что ИНН и КПП однозначно характеризуют контрагента. Однако выяснилось, что в некоторых случаях в базе данных может существовать множество контрагентов с одним и тем же ИНН, КПП, что порождает неопределенность и ошибку при нахождении контрагента в процессе выполнения функций.
  В текущей версии в перечисленных выше функциях в случае обнаружения нескольких контрагентов с заданным ИНН и КПП выбирается один с наименьшим значением GLN.
  

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

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

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

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