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


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

ЕГАИС.

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


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

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


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

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

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

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

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


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

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

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


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

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

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


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


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

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

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


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

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


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

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

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


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

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

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


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


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

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

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

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

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


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

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


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

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

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


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

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


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

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


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

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

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

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

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

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


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

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


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


    В сервер обмена данных добавлен аналитический объект IOSMIOBOXMARKCODES для получения списка алкогольных марок, содержащихся в упаковке алкоголя. Аргументом функции является код упаковки алкоголя, нанесенный на коробку с алкоголем, ответом является список марок алкогольной продукции, содержащейся в упаковке.
    Пример команды:
    GET http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber="03000009996110518000000002"
    Где localhost:8085 – ip адрес сервера обмена данных
    03000009996110518000000002 – код упаковки.
    Пример выполнения запроса с помощью curl:
    curl.exe -s -X GET http://localhost:8085/out/json/IOSMIOBOXMARKCODES/*/pBoxNumber="03000009996110518000000002"
    Ответ:
    {
      "PACKAGE": {
        "name": "a585380c-6e27-4360-80b3-e10dd2930bfc",
        "POSTOBJECT": [
          {
            "description": "Алкогольные марки упаковки",
            "action": "normal",
            "Id": "IOSMIOBOXMARKCODES",
            "IOSMIOBOXMARKCODES": {
              "SMIOBOXMARKCODES": [
                {
                  "sMarkCode": "203200440290891018001TDUDFPG72ZVRLX26KFXGWGKEWAPS6I3KETE4KMQ27KNZYK5BZ55AL2YQBYAX64E6ZGV6EWAGOQLGB3LN23GVRADBCMUWJQKOSVIF5MP4Q37ZD3LFWRTOZLENXJYT7XNYA"
                },
                {
                  "sMarkCode": "203200441445631018001QDPHWDIZYDCGO5BLRSYAQ24WUM2RO3W7WIQOPLBHPFUVNLEJOMFJ6SBW5XD2DWTACK2K37DXO7KVMHAIPDJAB7PDRRI5XRV556PJPBIHMPOVHBSPEVIARJB4Y3EN6U5WA"
                },
                {
                  "sMarkCode": "2032005721293710180017FAO7IRYXT5IL6JBLBEL3QTNGIJ6YI4AO4RSDVLZLMTBEQPG5KAYWPXRNG3RPHXVLYD6ZEZY4CPCOMV2WZ5COU3QKVKXYLHPP5CCDQNTP6TT4ZCQMNXE7CDRQIU3AXTRI"
                },
                {
                  "sMarkCode": "203200572167291018001ZKIC7T7YKZI3UPNICE4SLSKC7UGGLBQUBJF25LPCX3OJU55FUUF3VA4WA7J3KSMXKSNRMDXSQ5366JDAIKF34FHON3SZGXVKWX4ALPVAOBHO6JZUEZ2VW4VVCL46X3VGI"
                }
              ]
            }
          }
        ]
      }
    }

    Ответ, когда марок нет:
    {
      "PACKAGE": {
        "name": "0e99d351-d167-4cc6-8ece-9998f5e5e76e",
        "POSTOBJECT": [
          {
            "description": "Алкогольные марки упаковки",
            "action": "normal",
            "Id": "IOSMIOBOXMARKCODES",
            "IOSMIOBOXMARKCODES": {}
          }
        ]
      }
    }
    Формальное описание структуры JSON:
    {
      "$schema": "http://json-schema.org/schema#",
      "title": "IOSMIOBOXMARKCODES, Export",
      "description": "Алкогольные марки упаковки",
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "PACKAGE": {
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "name": {
              "type": "string"
            },
            "POSTOBJECT": {
              "type": "array",
              "items": {
                "type": "object",
                "additionalProperties": false,
                "properties": {
                  "description": {
                    "type": "string"
                  },
                  "action": {
                    "type": "string"
                  },
                  "Id": {
                    "type": "string"
                  },
                  "IOSMIOBOXMARKCODES": {
                    "type": "object",
                    "additionalProperties": false,
                    "properties": {
                      "SMIOBOXMARKCODES": {
                        "type": "array",
                        "items": {
                          "type": "object",
                          "additionalProperties": false,
                          "properties": {
                            "sMarkCode": {
                              "anyOf": [
                                {
                                  "type": "string"
                                },
                                {
                                  "type": "null"
                                }
                              ]
                            }
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
    Для использования объекта надо в интерфейсе сервера обмена данных поместить объект в перечень разрешенных для запроса и объявить его доступным:

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

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


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

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


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

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

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