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

Для работы со справочником необходимо иметь функциональное право «Редактирование классификатора ОКПД2».

Карточки складского учета. Группа классификатора ОКПД2.

В разделе «Карточки складского учета» на закладку «Классификация» добавлено назначение артикулу группы классификатора ОКПД2:

Назначить группу классификатора списку артикулов можно в функции «Изменение классификации» кнопки «Обработать»:

Для поиска арткулов по значению группы классификатора ОКПД2 добавлен элемент «ОКПД2» в закладку «Прочее» фильтра карточек:

Для отображения кода классификатора ОКПД2 в таблице отобранных карточек в диалог кнопки «Поля» добавлен флаг «Код ОКПД2»:

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

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

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

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

В текущей версии действие алгоритма распространено на ТТН с операцией «продажа». Алгоритм работает, как для операций регистра торгового зала (списание, кассовая реализация), так и операций регистра склада (списание, продажа).

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

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

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

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

Прием УПД. Режим приема УПД.

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

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

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

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

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

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

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

Для приема поставки в режиме «Без накладной поставщика» в диалог создания процесса «Подсчет кодов КИЗ ТСД» добавлен элемент «по УПД»:

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

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

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

Если поставка прибыла до получения электронного УПД от поставщика, подсчет кодов КИЗ можно выполнить, указав контрагента, номер и дату документа поставщика из сопроводительных документов. Под номером документа поставщика понимается тот номер документа, который в УПД на приход показывается в поле «Номер УПД», в XML -схеме находится в поле <SUPPLIERDOC>, а в схеме ФНС XML - в поле <НомерСчФ>.

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

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

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

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

Аналогичные изменения внесены в программу Супермаг Мобайл Андроид.

Функция проверки «Контроль наличия УПД при принятии приходной накладной»

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

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

Почтовый модуль. Протокол «УПД фильтр». Квитанция провайдера ЭДО.

В предыдущих версиях протокол «УПД фильтр» с форматами данных XML или JSON предполагал следующую последовательность обмена данными при приеме УПД на приход:

- получение УПД в формате XML или JSON ;

- отсылка файла подтверждения приема с результатом приема 1 или 3 и с полной спецификацией принятого товара (если что-то принято);

- получение исправленного УПД, если результат приема 3 и файл ответа содержит спецификацию приема;

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

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

<SENDDATTIM>2021-07-06T12:12:32/SENDDATTIM>

< ERRORTEXT > Ошибка ЭЦП </ ERRORTEXT >

</APPERAK>

Если после отсылки файла подтверждения будет получена квитанция со значением RESULT = 3, что означает ошибку при прохождении в системе ЭДО, то файл подтверждения можно будет отослать повторно из открытого на просмотр документа:

Если RESULT = 1 (при отсылке файла подтверждения с флагом приема) или 2 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно.

Приходная накладная. Индикация состояния обмена УПД. Фильтр документов по состоянию обмена.

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

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

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

Накладная на перемещение. Регистрация КИЗ при перемещении товара.

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

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

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

Создана новая функция проверки 239 «Контроль наличия КИЗ для маркированных товаров». По умолчанию функция проверки отключена.

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

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

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

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

Функция проверки «Контроль статуса УПД / накладной поставщика при разоприходовании приходной накладной».

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

Функция выполняется при понижении статуса приходной накладной с «Принят на складе» до «Черновик».

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

- в основании приходной накладной имеется УПД в статусе «Сформирован» или «Обработан» или накладная поставщика в статусе «Принят» или «Закрыт»;

- имеется УПД в статусе «Сформирован» или «Обработан», в основании которого указана приходная накладная.

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

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

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

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

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

При приеме перемещения с контролем КИЗ надо указать документ, по которому будет проводиться прием:

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

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

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

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

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

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

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

Резервирование товара документом «Заказ от клиента» в статусе «Согласован».

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

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

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

В связи с этим внесены следующие изменения:

- Удалены функция проверки 22 «Запрет принятия док., приводящего к отр. остаткам с учетом заблокированных (подготовленных) док.» и функция проверки 60 «Запрет принятия док., приводящего к отр. остаткам с учетом опер. продаж и заблокированных (подготовленных) док.»

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

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

- Изменен алгоритм автоматической генерации складского требования. При расчете потребностей мест поставки для текущих РЦ и артикула:

Формула расчета доступного количества:

[Доступное кол-во на РЦ] = [Остаток РЦ] - [Резерв РЦ] - [В приемке / в пути РЦ] - [Потери РЦ] – [Кол-во из заблокированных накладных на перемещение и расходных накладных, в которых РЦ является местом хранения «Из»]

заменена формулой:

[Доступное кол-во на РЦ] = [Остаток РЦ] - [Резерв РЦ] - [В приемке / в пути РЦ] - [Потери РЦ]

Упразднена формула коррекции текущего запаса:

[Запас] = [Запас] + [Кол-во из заблокированных накладных на перемещение из РЦ в текущее МХ].

- В разделе «Бизнес-анализ» из группы полей «Текущие остатки» удалено поле «Готово к отгрузке».

- Из таблицы раздела «Остатки» удалено поле «Готово к отгрузке».

- Из таблицы окна свойств артикула «Остатки» удалено поле «Готово к отгрузке».

- В накладной на перемещение статус «Подготовлен» получил название «Заблокирован».

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

В связи с тем, что документ «Заказ от клиента» начал влиять на таблицу остатков, после установки версии требуется запустить полный перерасчет остатков (Административный модуль – База данных – Утилиты – Перерасчет остатков).

Документы. Функция «Упорядочить №№»

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

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

Текущее положение строк на экране можно менять с помощью сортировки строк по колонкам, например, по названию товара или по артикулу.

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

Цены маркетинговых контрактов.

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

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

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

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

В текущей версии исключение артикулов управляется настройкой (Административный модуль - База данных – Конфигурация - Заказы поставщикам):

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

Весы самообслуживания. Загрузка групп PLU .

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

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

Контроль остатков ТСД. Автоматическая генерация документов.

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

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

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

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

Контроль зала ТСД.

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

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

Отгрузка заказа ТСД.

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

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

Маркировка. Опция «Учет кодов КИЗ при приемке и отгрузке товаров».

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

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

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

Периоды. Интерфейс страницы.

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

В текущей версии интерфейс журнала разделен на две закладки «Периоды» и «Журнал». На закладке «Периоды» показывается список закрытий периодов, на закладке «Журнал» - полный журнал событий закрытия периода:

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

Процедура обрезки базы данных.

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

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

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

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

- Проведена оптимизация процедуры закрытия периода для ускорения ее работы. Оптимизация распространяется на все виды закрытия периода.

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

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

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

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

Дерево страниц

Изменения1047.doc