Дерево страниц
Перейти к концу метаданных
Переход к началу метаданных

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 3 Текущий »


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

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

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


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

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


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

Просканированная марка (факт)

Собственный учет

Учет ЕГАИС

Марка 1

Нет

Нет

Марка 2

Есть

Нет

Марка 3

Нет

Есть


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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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


    Описание экземпляра товара по запросу актуальной номенклатуры выглядит следующим образом:
    "items": [
    {
    "id": "some-uniq-identifier",
    "vendorCode": "string",
    "categoryId": "some-uniq-identifier",
    "location": "Бакалея. Линия 8",
    "name": "Молоко Домик в деревне",
    "description": {
    "general": "string",
    "composition": "string",
    "nutritionalValue": "string",
    "purpose": "string",
    "storageRequirements": "string",
    "expiresIn": "string",
    "vendorCountry": "Россия",
    "packageInfo": "Тетрапак",
    "vendorName": "Буренка"
    },
    "price": 1000,
    "oldPrice": 1234.56,
    "vat": 20,
    "barcode": {
    "value": "987654321098",
    "values": [
    "987654321098"
    ],
    "type": "ean13",
    "weightEncoding": "ean13-tail-gram-4"
    },
    "measure": {
    "value": 1000,
    "quantum": 0.5,
    "unit": "GRM"
    },
    "volume": {
    "value": 100,
    "unit": "DMQ"
    },
    "isCatchWeight": false,
    "sortOrder": 0,
    "images": [
    {
    "hash": "string",
    "url": "string"
    }
    ]
    }
    ]
    Информация о товаре содержит, в том числе, атрибут "isCatchWeight". В прошлых версиях атрибут «isCatchWeight» получал значение true, если базовая единица измерения товара была весовой или если штучному товару была назначена альтернативная весовая единица измерения.
    В текущей версии атрибут получает значение true, только если базовая единица измерения является весовой. Во всех прочих случаях она получает значение false.

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


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

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