№ |
Название |
стр |
1 |
Изменения1053 сп1 |
2 |
2 |
Изменения1053 сп2 |
5 |
3 |
Изменения1053 сп3 |
7 |
4 |
Изменения1053 сп4 |
9 |
5 |
Изменения1053 сп6 |
12 |
6 |
Изменения1053 сп7 |
14 |
7 |
Изменения1053 |
16 |
8 |
Изменения1054 сп1 |
44 |
9 |
Изменения1054 сп2 |
50 |
10 |
Изменения1054 сп3 |
51 |
11 |
Изменения1054 сп4 |
55 |
12 |
Изменения1054 |
60 |
13 |
Изменения1055 сп1 |
82 |
14 |
Изменения1055 сп2 |
89 |
15 |
Изменения1055 сп3 |
95 |
16 |
Изменения1055 сп4 |
98 |
17 |
Изменения1055 |
102 |
Изменения функционала в версии 1.053 сервис пак 1
Заказ поставщику. Опция печати «с дополнительной информацией».
Почтовый модуль. XML-фильтр.
Функция экспорта «FindCSDocDate». Дата ближайшего документа «Продажи по кассе».
Функция экспорта «FindCSDocId». Идентификатор ближайшего документа «Продажи по кассе»
Функция импорта «ArticleByVariousUI». Артикул товара по информации об артикуле Супермаг, артикуле контрагента, штриховом коде, КИЗ или ОСУ.+
Кассовый модуль. Протокол УМ4 XML. Прием информации о проведенных скидках / наценках
Административный модуль. Задание «Сбор 'мусора'». Очистка очереди артикулов на кассу.
В диалог печати документа «Заказ поставщику добавлена опция «Форма печати документа» - «с дополнительной информацией»:
При выборе опции в печатной форме выводятся колонки:
В прошлых версиях для ТТН на приход с состоянием «Обмен прекращен из-за ошибки или отказа» не была запрещена привязка к приходным накладным (в интерфейсе показывалась кнопка «Подобрать накладную»). Считалось, что для персонала достаточно визуализации текущего состояния документа. В текущей версии введен явный запрет на операцию с документом с таким состоянием.
В справочнике «Коды ТН ВЭД» дополнен перечень кодов, доступных для заполнения поля «Код ЧЗ» («Ветеринарные препараты» и ниже):
Для документа УПД на приход, в спецификации которого есть поле «Ключ товара из УПД», создана функция импорта «ArticleKeyByVariousUI». Функция позволяет из перечня полей исходного документа - артикул Супермаг+, артикул контрагента, штриховой код, КИЗ или ОСУ, взять первое попавшееся непустое значение и поместить его в заданное поле (Ключ товара из УПД).
Функция используется для того, чтобы в случае, когда оказалось невозможным автоматически определить артикул по данным документа поставщика, поместить в УПД в специальное поле некоторое значение, по которому можно было бы в дальнейшем определить этот артикул.
Программы Супермаг Мобайл 1.6, 2.3, 2.4 в режимах работы «Контроль зала» обращаются к серверу приложения для получения количества товара, которое числится в месте хранения. Для этого режима работы определяется тот остаток, который должен фактически быть в наличии.
В прошлых версиях остаток считался как: остаток – потери – оперативная реализация
В текущей версии остаток считается как: остаток – потери – оперативная реализация – количество в накладных на перемещение в текущее место хранения со статусом «отправлен».
Примечание: «остаток» это количество по всем документам в статусе отпущен/принят на складе и отпущен/принят полностью (2 и 3). Приходные накладные в статусе «принят на складе» это товар принятый, но еще не обработанный, то есть имеющийся в наличии. Накладные на перемещение в статусе «отправлен» это товар, отгруженный из места отгрузки, который едет от места отгрузки или уже приехал, но еще не обработан в месте приема. Считается, что приемка перемещения действие намного более быстрое, чем само перемещение и будет правильнее отнести его к товару, который еще не прибыл.
В текущей версии в протоколе УКМ4 XML при выгрузке артикулов типа «уценка» в тэге <addProperty> - дополнительные характеристики товара, выгружаются следующие тэги:
<addProperty>
<id>markdown_parent_sku</id>
<value>базовый артикул артикула уценки</value>
</addProperty>
Условная доп. характеристика «markdown_parent_sku» позволяет кассе корректно обрабатывать КИЗ, относя его к базовому артикулу, а не к артикулу уценки, когда штриховой код базового артикула на экземпляте товара заклеивается штриховым кодом артикула уценки.
В версии 1.053 была выполнена работа: «Копирование цен из УПД в приходную накладную для собственного контрагента неплательщика НДС», следующего содержания:
«При создании приходной накладной на основании УПД и при копировании в приходную накладную цен из УПД теперь учитывается флаг собственного контрагента приходной накладной «Плательщик НДС». Если собственный контрагент не плательщик НДС, то ставка НДС для всех товаров накладной устанавливается нулевой, а цена из УПД берется полная и копируется в обе колонки цен приходной накладной, независимо от режима округления. Такое же изменение внесено в функцию «Заполнить документ ценами из УПД на приход» и в функцию проверки соответствия цен УПД и приходной накладной.»
Как выяснилось, изменение функции «Заполнить документ ценами из УПД на приход» в версию 1.053 не попало. В текущей версии этот недостаток исправлен.
Изменения функционала в версии 1.053 сервис пак 3
Меркурий.
Использование альтернативных единиц измерения при гашении ВСД.
Гашение ВСД с продукцией без идентификатора.
Почтовый модуль.
Рассылка документов в доверительные базы данных. Учет обслуживаемых мест хранения.
Функция импорта ArticleKeyByVariousUI. Порядок поиска ключа.
Функция экспорта ContractVATRate. Ставка НДС из документа «Контракт с поставщиком» - основания документа.
Приходная накладная. Функция «Заполнить документ ценами из УПД на приход». Алгоритм работы, для собственного контрагента - неплательщика НДС.
В прошлых версиях предполагалось, что единицы измерения Меркурия можно однозначно сопоставить с единицей измерения Торговой системы с некоторым коэффициентом пересчета, например, килограмм и килограмм, грамм и 0,001 килограмм, пучок и штука и т.д. И, что этого достаточно для сравнения количества товара приходной накладной и сопоставленной ей ВСД.
То есть, при сопоставлении количества продукции ВСД с количеством соответствующего артикула приходной накладной сопоставление производилось для тех пар единиц измерения, которые описаны в справочнике единиц измерения Меркурия и с тем коэффициентом пересчета, который указан для этой пары единиц измерения.
Как выяснилось, на практике штучные артикулы в ВСД могут быть представлены продукцией с весовой единицей измерения. Для каждого такого артикула вес будет свой, и описать такие соответствия в справочнике единиц измерения Меркурия невозможно.
В текущей версии при сопоставлении товара приходной накладной и продукции ВСД, если в справочнике единиц измерения ГИС Меркурий не обнаружена соответствующая пара единиц измерения, такая пара ищется в альтернативных единицах измерения артикула. И если она находится, то используется с учетом коэффициентом пересчета единицы измерения артикула в альтернативную единицу измерения.
Например, в справочнике единиц измерения ГИС Меркурия имеется пара единиц измерения: «килограмм» Торговой системы и «кг» Меркурия. Для принимаемого артикула с единицей измерения «шт» имеется альтернативная единица измерения «0,3 килограмм». Тогда, при гашении ВСД принятые штуки будут пересчитаны в килограммы с коэффициентом 0,3, и полученная величина будет сопоставлена с количеством из ВСД.
В прошлых версиях для гашения ВСД надо было предварительно удостовериться, что продукция ВСД связана с артикулом Торговой системы и при отсутствии такого соответствия, предварительно подобрать артикул для продукции и зафиксировать эту связь.
В текущей версии для тех ВСД, у которых продукция не имеет идентификатора, то есть имеет пустое значение в поле «Ид. номенклатуры» описания продукции, связь ВСД с накладной можно устанавливать без предварительного подбора артикула. Такая связь не приводит к какому-либо сопоставлению артикула и продукции, а только к сопоставлению конкретного ВСД и пункта спецификации приходной накладной.
В текущей версии при рассылке документов в доверительные базы данных документы ставятся в очередь на рассылку, если место хранения документа имеется в перечне обслуживаемых мест хранений доверительной базы данных. Если для базы данных такой список не определен, то документы будут отсылаться без ограничений.
В прошлых версиях при рассылке документов в доверительные базы данных реакции на список обслуживаемых мест хранения не было.
Функция ArticleKeyByVariousUI возвращает ключ товара Супермаг+ по артикулу Супермаг+, артикулу контрагента, штриховому коду, КИЗ или ОСУ пришедшего документа. Под ключом артикула понимается значение, например, штриховой код EAN, по которому в будущем можно будет опознать артикул, если при приеме документа артикул идентифицировать не удалось. Например, если в систему в будущем будет добавлен новый штриховой код, то по его совпадению с ключом артикула можно будет принять решение о проставлении артикула с таким штриховым кодом в ранее принятый документ.
В текущей версии в функции изменен порядок поиска ключа. В прежней версии порядок поиска по содержанию документа был такой: артикул Супермаг+, артикул контрагента, штриховой код, штриховой код из КИЗ, штриховой код из ОСУ. В текущей версии порядок следующий: штриховой код, штриховой код из КИЗ, штриховой код из ОСУ, артикул Супермаг+, артикул контрагента.
Создана новая функция для формирования XML файлов при экспорте документов. Функция позволяет заполнить тэг значением ставки НДС. Ставка НДС для артикула спецификации берется из документа «контракт с поставщиком», который находится в основании отсылаемого документа.
Аргументами функции является тип, номер отсылаемого документа и артикул спецификации.
В предыдущих версиях функция «Заполнить документ ценами из УПД» и аналогичная функция, которая используется для переноса цен при генерации приходной накладной при приеме на основании УПД, для случая, когда собственный контрагент накладной является неплательщиком НДС, работала следующим образом: В приходную накладную проставлялись цены из цены полной УПД, нулевая ставка НДС, режим округления из УПД на приход и, затем, производился расчет сумм, с учетом принятого количества.
В некоторых случаях из-за ошибок округления стоимость товара в накладной могла не совпасть со стоимостью в УПД.
В текущей версии, если собственный контрагент – неплательщик НДС, в приходную накладную принудительно проставляется режим округления «Полная сумма», а цена, проставляемая в полную цену и цену без налогов накладной, определяется как сумма позиции УПД / кол-во позиции УПД без округления.
Изменения функционала в версии 1.053 сервис пак 4
Печать в ценнике штрихового кода типа «маркировка GS1».
Почтовый модуль. Экспорт данных в формате XML.
Применение функции экспорта к полю аргументу.
Контроль заполнения тэгов с признаком обязательности заполнения.
В текущей версии при печати ценников со штриховым кодом товара разрешено печатать, в том числе, штриховой код типа «маркировка GS1». В предыдущих версиях коды такого типа игнорировались. Код типа «маркировка GS1» является частью кода GS1, размещенной после кода применения 21 (GTIN). Как правило, это EAN код товара, дополненный лидирующим нулем или 1. При извлечении кода «Маркировка GS1» из GS1, лидирующий символ отбрасывается и в базе данных сохраняется 13 символьный код. Тем не менее, в GS1 марок КИЗ могут присутствовать не только EAN13, но и любые другие коды. Печатать их штрихами в виде кода EAN13 не всегда возможно, а если возможно, то не всегда сканеры читают такие коды корректно. Если печать штрихами невозможна, такой код в ценнике не печатается. Некорректное чтение напечатанного кода сканером происходит в тех случаях, когда в качестве GTIN используется короткий код (UPC E, EAN 8) – в этом случае для соблюдения правил формирования кода марки короткий код дополняется нулями до 13 символов. Это не препятствует его печати и чтению сканером, но сканер может отбросить один или несколько нулей и тогда считанный код не совпадет с тем, который использовался для печати.
В почтовом модуле при формировании файла в формате XML при экспорте данных разрешается использовать функции, которые на основании информации из тэгов аргументов позволяют заполнять другие тэги. В прошлых версиях это всегда были новые тэги, например, для выгрузки названия артикула надо было создать простое поле, например, «CARDFULLNAME», затем применить к нему функцию, указав в качестве аргумента поле «ARTICLE»:
В текущей версии для сохранения значения функции можно выбирать, в том числе тэг, который является аргументом функции, например:
Пользоваться новой возможностью следует с осторожностью. Поле, изменившее свое значение, не может быть источником информации для других функций. Также надо помнить, что порядок исполнения функций преобразования не определен. И, кроме того, тэг, входящий в первичный ключ таблицы не должен получать значений, нарушающих первичный ключ.
Схема с использованием тэга аргумента в качестве тэга результата не может быть использована в работе почтового модуля предыдущих версий Супермаг+.
Примечание: при отсылке документов по протоколу «УПД фильтр» при применении функции CorrectKIZ к полю markCode одновременно меняется формат тэга с BASE64 на STRING.
Примечание: при отсылке документов «УПД на приход», «УПД на отгрузку» и «Накладная поставщика» по протоколу «УПД фильтр» корректировка кода КИЗ по правилам ЦРПТ осуществляется автоматически.
В предыдущих версиях при отсылке XML объектов отсутствовала проверка, заполнено ли поле (тэг) или нет, при наличии в схеме ограничения "minOccurs="1" nillable="false"". То есть, можно было отсылать объект с пустым / отсутствующим значением тэга, когда в схеме указано, что тэг обязан иметь значение.
В текущей версии такая проверка реализована и отсылка объекта, нарушающего XSD схему, не допускается. При отсылке такого документа будет получена ошибка отсылки, например:
Изменения функционала в версии 1.053 сервис пак 6
Склады и магазины. Заполнение списка складов из файла.
В разделе «Склады и магазины» перечень функций кнопки «Обработать» дополнен функцией «В список из файла ….». При вызове функции показывается диалог, в котором можно выбрать файл для загрузки списка идентификаторов мест хранений и группу классификатора списка мест хранений:
Структура данных в файле должна быть следующей:
Идентификатор места хранения;Название места хранения
Например:
4; Семеновский
86; Пражский
120;Склад возврата
Кодировка файла ANSI или UTF-8 (без спецификации)
Файл не должен содержать кодов мест хранения, отсутствующих в Торговой системе. В этом случае импорт будет отменен с сообщением, например:
При приеме данных названия мест хранения из файла игнорируются, список мест хранения всегда дополняется данными из файла. Если до работы функции в списке были другие места хранения, они в нем останутся.
Изменения функционала в версии 1.053 сервис пак 7
Карточки складского учета. Ненапечатанные ценники.
Функция «Списание маркированной продукции».
Формат обмена «Яндекс.Еда». Передача информации об остатках товара.
Отчет «Главная касса».
В текущей версии изменен подход к определению «ненапечатанный ценник». В прошлых версиях ценник считался ненапечатанным, если после последней печати ценника произошло любое изменение карточки товара или цены товара. В текущей версии ценник считается не напечатанным, если изменилось название карточки или цена карточки. Это позволит избежать избыточной печати ценников при изменениях в карточках, не влияющих на содержание ценника.
В документах «Расходная накладная», «Приходная накладная» и «Требования на отбор» изменено поведение функции «Списание маркированной продукции».
Содержание тэга <cost> (цена) формируется в соответствии с очередной рекомендацией ЦРПТ: «Для того чтобы цена воспринималась правильно, формируемую цену передавать в копейках».
То есть, теперь при формировании тэга <cost> цена передается как целое число, полученное умножением цены на 100.
Для расходной накладной в тэг <trade_participant_inn> теперь помещается ИНН собственного контрагента, а не ИНН клиента, как это было в прошлых версиях. В других документах поведение функции осталось прежним.
\\
При получении от Яндекс Еды запроса об актуальной информации об остатках товара в ответ передается информация следующего вида:
\\
\{
"items": \[
\{
"id": "some-uniq-identifier",
"stock": 7.45
\}
\]
\}
\\
Где "id" – артикул, "stock" – текущий остаток товара.
\\
В предыдущей версии в тэге "stock" передавалось значение поля «Оперативно доступно» карточки складского учета. Значение поля «Оперативно доступно» определяется как «Остаток» за вычетом «В приемке / в пути», «Потери» и «Оперативная реализация». В текущей версии передается значение «Оперативно доступно» плюс «В приемке / в пути».
\\
То есть, товар, который принят, но не прошел полный цикл оформления приходных документов, не будет исключаться из количества, доступного для заказа товара.
\\ |
Создан новый отчет «Главная касса». Отчет помещен в группу «Бухгалтерские».
Отчет показывает движение денежных средств в главной кассе места хранения с сальдо на начало и на конец каждого дня отчета и на начало и конец периода отчета.
Изменения функционала в версии 1.053
Меркурий.
Карточки складского учета. Справочник подконтрольной продукции.
Гашение ВСД ГИС «Меркурий».
ЕГАИС.
Контроль уникальности артикула для кода алкогольной продукции.
Удаление файлов TTNHistoryF2Reg.
ЭДО.
Обработка УКД, поступившего сразу после получения УПД.
Копирование цен из УПД в приходную накладную для собственного контрагента неплательщика НДС.
Расходные накладные. Списание маркированной продукции.
Расходная накладная, накладная на перемещение. Функция «Проставить основания…».
Накладная на перемещение. Поле «Страна» в спецификации документа.
Акт переоценки.
Фильтр документов по полю «Комментарий».
Функция «Скопировать цены в цены для кассы других мест хранения».
Заказы поставщикам.
Автоматическая генерация заказов.
Экспорт в документ «Накладная поставщика».
Заказ от клиентов. Причина закрытия заказа.
Правило генерации номеров документов для связанных документов.
Автоматическое задание. Блокировка неисполненных заказов поставщикам.
Формирование пакета заказов на базе контракта. Кнопка «Поля».
Алгоритмы расчета среднесуточной реализации.
Справочник «Дополнительные характеристики товара». Определение цвета для значений характеристик.
Карточки складского учета.
Обработка карточек.
Закладка «Заказ»
Склады и магазины.
Диалог «Поля» для добавления колонок в таблицу отобранных мест хранения.
Функции кнопки «Обработать».
Стандартный диалог выбора мест хранения.
Диалог выбора мест хранения в разделе «Главная касса».
Почтовый модуль.
FTP транспорт. Протокол FTPS.
УПД фильтр. Прием УПД на приход. Поле OURUTDID.
Прием УКД для УПД, по которому еще не было приема поставки.
Почтовый модуль, Сервер обмена данных. Фильтр «СуперМагМарко»
Сервер обмена данными. Формат «Яндекс. Еда». Изменение в протоколе обмена.
Кассовый модуль. Протокол УМ4 XML. Прием информации о проведенных скидках / наценках.
Перечень исправлений.
В прошлой версии были внесены изменения для прямого обмена с ГИС Меркурий. В сервер обмена данными был добавлен протокол обмена с ГИС Меркурий и изменены справочники единиц измерения ГИС Меркурий и площадок ГИС Меркурий. В текущей версии добавлена работа со справочником подконтрольной продукции и возможность проводить гашение ВСД непосредственно в ГИС Меркурий.
Перед началом прямого обмена с ГИС Меркурий необходимо получить атрибуты доступа к нему (см. описание версии 1.052) и настроить адресат обмена в администраторе сервера обмена данных:
В текущей версии создан новый справочник подконтрольной продукции, доступ к которому сделан в разделе карточек складского учета. Прежний справочник в разделе «Номенклатура ГИС «Меркурий»» сохранен для обмена с провайдером документами производства и перевозки по протоколу «Меркурий – обмен данными».
В разделе карточек складского учета в форму карточки добавлена закладка «Меркурий» для отображения списка продукции Меркурия, связанной с артикулом:
В разделе можно ввести данные о продукции Меркурия, если известен GUID продукции. Для этого надо ввести GUID в поле «Глобальный идентификатор номенклатуры» и нажать кнопку «Сохранить». При этом произойдет обращение к Меркурию и при обнаружении продукции с указанным GUID будут получены остальные атрибуты продукции:
Еще один способ заполнения номенклатуры продукции Меркурия реализован в разделе «Гашение ВСД ГИС Меркурий».
При работе с номенклатурой продукции Меркурия необходимо учитывать, что в Меркурии справочник продукции не является глобальным и в документах могут присутствовать GUID и описании продукции, которого нет в центральном справочнике, соответственно, заранее завести такую продукцию в справочник Супермаг+ невозможно. Это можно сделать только при получении ВСД в разделе «Гашение ВСД ГИС Меркурий».
Необходимо учитывать, что без занесения продукции Меркурия в справочник Супермаг+ невозможно сопоставлять документы Меркурия и документы Супермаг+. То есть продукцию надо заносить в справочник Супермаг+, даже если она отсутствует в центральном справочнике Меркурия.
Раздел «Гашение ВСД ГИС «Меркурий»» полностью переработан для прямого обмена с Меркурием.
В разделе можно запросить ВСД для хозяйствующего субъекта и площадки, нажав кнопку «Запросить данные из ГИС «Меркурий»»:
Выбор площадки делается в диалоге кнопки «Выбрать» из перечня площадок, которые имеются в разделе «Площадки ГИС «Меркурий»» и полные данные которых получены из ГИС «Меркурий».
В результате выполнения запроса будет получен спискок ВСД за указанный диапазон дат. Меркурий не позволяет получить только непогашенные ВСД. Соответственно, чтобы отобразить только непогашенные ВСД необходимо в фильтре раздела выбрать «статус ВСД» «Оформлен» и нажать кнопку «Перечитать»:
В случае ошибки обмена с Меркурием содержание ошибки можно посмотреть в журнале сервера обмена данных:
Например, ошибка вида: «Инициатор, ответственный за выполнение операции, с указанным идентификатором не найден в реестре РСХН, либо идентификатор не соответствует установленному формату» связана с неверным значением в поле «Учетная запись пользователя Меркурий»:
Необходимо иметь в виду, что Меркурий представлен несколькими системами, которые имеют разные логины и пароли. Логин и пароль Ветис API позволяют получить доступ к справочникам Меркурия, а для доступа к документам необходимы данные логина подсистем Цербер и Меркурий. Это обусловило перечень атрибутов доступа для формата «Меркурий - Ветис API» сервера обмена данных.
Для гашения ВСД необходимо выполнить следующие действия:
Линейная регрессия (учитывает тенденцию изменения реализации, то есть наклон графика реализации). Дает хороший по точности прогноз на относительно близкое будущее. \\ Особенность алгоритма линейной регрессии заключается в том, что в качестве результата расчета получается не одно число, а линейный график, устремленный в будущее. Чтобы определить число, которое можно использовать в качестве будущей ССР, необходимо указать количество дней будущего периода, для которого эта величина будет использоваться. Например, для 7 дней будущего периода ССР считается, как прогноз на 4-й день (середина будущего периода). \\ Для всех алгоритмов расчета доступна новая опция «Исключать выбросы». \\ Определение дат с аномальной реализацией, то есть с выбросами, выполняется после получения перечня дней, которые определяются прочими условиям расчета (положительный остаток, выходные дни и т.д.). Выбросы определяются по критерию Хампеля. \\ Для управления расчетом ССР внесены изменения в интерфейс настройки расчета в разделах классификатора товаров, карточек складского учета и автоматического задания «Расчет среднесуточной реализации»: \\ !worddav0f6e657526702afe163a35dd2ef972d8.png|height=425,width=484! \\ Диалог учета дней включает опцию исключения выбросов: \\ !worddav7aa0abd9bd957e0c87f1f57d5fe8157f.png|height=453,width=422! \\ Диалог выбора метода расчета предлагает выбор метода и для метода линейной регрессии - опцию выбора глубины прогноза: \\ !worddav9bd99cc156edacb2ee1d3b894465fdf8.png|height=184,width=240! \\ Приложение: \\ Линейная регрессия \\ Y = a + b * x \\ a = (summ i=1,n (Yi) * summ i=1,n (Xi^2) - summ i=1,n (Xi) * summ i=1,n (Xi*Yi))/ (n * summ i=1,n (Xi^2) - (summ i=1,n (Xi))^2) \\ b = (n * summ i=1,n (Xi*Yi) - summ i=1,n (Xi) * summ i=1,n (Yi))/ (n * summ i=1,n (Xi^2) - (summ i=1,n (Xi))^2) \\ Или \\ b = ( \[среднее X*Y\] - \[среднее X\] * \[среднее Y\] ) / ( \[среднее X^2\] - \[среднее X\]^2 ) a = \[среднее Y\] - b * \[среднее X\] \\ Критерий Хампеля. \\ Выбросами считаются все значения, которые выходят за диапазон: \\ \[median - 3 * MAD; median + 3 * MAD\] в которых MAD — это медианное абсолютное отклонение и определяется как медиана абсолютных отклонений от медианы данных: \\ MAD = median(|Xi-Xср|) \\ |
Изменения функционала в версии 1.054 сервис пак 1
Расчет среднесуточной реализации.
Учет влияния маркетинговых акций.
Исключение из расчета продаж по артикулам типа «уценка».
«Формирование пакета заказов на базе контракта». Средняя реализация для маркетинговых акций.
Раздел «Цены». Закладка «Наценки». Функция «Установить наценку».
Акт переоценки. Выбор вида цены акта.
Заказ поставщику. Информационное поле «Минимальное требование».
Административный модуль. Интерфейс мастера описания задания.
В прошлых версиях при расчете среднесуточной реализации была реализована возможность уменьшать диапазон расчета среднесуточной реализации при наличии внутри диапазона маркетинговой акции.
Например, если расчет ведется в диапазоне с 01 по 30 число месяца и в этом диапазоне была маркетинговая акция с 05 по 10 число, то начало диапазона расчета сдвигается с 01 на 11 число, чтобы исключить из расчета возможный всплеск продаж, вызванный маркетинговой акцией. Или если для того же диапазона расчета c 01 по 30 число месяца будет обнаружена акция с 25 по 5 число следующего месяца, то диапазон расчета сдвигается на 25 число. А для рассчитанной среднесуточной реализации устанавливается флаг «в ходе маркетинговой акции», чтобы при использовании этой среднесуточной реализации для прогноза продаж за пределами маркетинговой акции, скорректировать её на коэффициент К2 маркетинговой акции.
В текущей версии флаг «Уменьшать диапазон расчета при наличии маркетинговой акции перенесен из настроек расчета среднесуточной реализации групп товаров, периодических заданий, карточки товара и т.д., в административный модуль в раздел «База данных», закладка «Конфигурация», в новую группу данных «Среднесуточная реализация»:
В эту группу добавлена новая опция «Включать или исключать дни маркетинговой акции», которая позволияет при расчете среднесуточной реализации использовать альтернативный алгоритм учета маркетинговых акций. Если опция включена, то учет дней акции производится следующим образом. Если последний день расчета попадает на действие маркетинговой акции, в расчете участвуют все дни из диапазона расчета, входящие в дни действия акций и среднесуточной реализации присваивается флаг «в ходе маркетинговой акции», если не попадает, то учитываются все дни из диапазона расчета, кроме дней акций.
В алгоритм расчета среднесуточной реализации добавлена возможность исключать продажи, возвраты и прочее движение артикула, выполненное с использованием его уценочного артикула. Для исключения такого движения в административный модуль в группу данных «Среднесуточная реализация» добавлен флаг «Исключать из расчета движение по артикулам типа «Уценка»». По умолчанию флаг не установлен.
Опция действует для всех случаев расчета кроме раздела «ССР» (Среднесуточная реализация), который вызывается из карточек товара кнопкой «Посмотреть реализацию по дням» и в разделе «Формирование пакета на базе контракта» кнопкой «Перейти к разделу «Среднесуточная реализация»».
В таблицу процесса формирования пакета заказов на базе контракта добавлено поле «Ср. реал-ция для марк. акций». При создании процесса поле не заполнено. Для заполнения поля необходимо выполнить функцию «Средняя реализация для маркетинговых акций». Функция вызывается из выпадающего меню кнопки «Среднесуточная реализация»:
Функция позволяет посчитать среднюю реализацию в ходе последних маркетинговых акций с учетом следующих условий:
Алгоритм работы функции следующий: для артикула за последние 365 дней ищутся все выполненные и выполняющиеся маркетинговые акции. Для них, начиная с последних, определяется перечень дней, в которые проходила маркетинговая акция количеством не более, указанного в параметре «В диапазон расчета включать последние … дн. с акциями». Из этих дней исключаются дни, по условиям, определенным в опции «Учет дней…»:
Для оставшихся дней определются расходы и приходы в соотвествии с перечнем операций, определенных в опции «Операции…». Из суммы расходов вычитается сумма приходов и результат делится на количество дней, участвующих в расчете.
В разделе «Цены» на закладку «Наценки» добавлена кнопка «Установить наценку». При нажатии кнопки вызывается диалог функции, которая позволяет для выбранной группы классификатора товаров установить заданное значение наценки для всех выбранных видов цен:
В интерфейсе открытого для редактирования документа «Акт переоценки» элемент интерфейса для выбора вида цены - выпадающий список, заменен на диалог следующего вида:
В диалоге можно устанавливать фильтр видов цен флагом «только виды цен места хранения» (места хранения акта переоценки), можно сортировать строки по коду вида цены или по названию и можно управлять размером диалога.
В документе «Заказ поставщику» в перечень информационных полей добавлено поле «Мин. требование». При выборе этого поля для отображения в спецификации документа показывается колонка со значением «Мин. требование» из карточки складского учета, закладка «Заказ», для места хранения документа.
В предыдущих версиях интерфейс мастера описания задания имел одну платформу для всех видов заданий, что определяло одинаковый размер диалогов для всех страниц мастера всех видов заданий. В текущей версии каждое задание имеет свой размер диалога мастера, оптимизированный под набор данных для описания задания.
В мастере задания «генерация заказов» при переходе на страницу «Генерация заказов: соглашения о поставках» теперь вызывается диалог, в котором можно выбрать необходимые соглашения:
В диалоге можно отмечать или снимать флаг выбора для всех строк, управлять способом отображения списка разрешенных мест хранений. Размер диалога можно установить по выбору оператора.
По завершению выбора соглашений делается возврат на страницу мастера для продолжения работы с ним:
Страница мастера «Генерация заказов: соглашения о поставках» показывается при выборе опции «по выбранным соглашениям о поставках» на странице «Генерация заказов: параметры».
Изменения функционала в версии 1.054 сервис пак 2
Подсчет марок ТСД. Функция получения артикула по коду алкогольной марки.
Почтовый модуль. Функция импорта ClientByAnyGLNINN.
Редактор XML схем. Работа с функциями BaseOrderID, BaseOrderDate, BaseOrderQuantity.
Для программы Супермаг Мобайл реализована функция, которая позволяет программе ТСД запрашивать информацию о принадлежности алкогольной марке артикула Торговой Системы. Информация извлекается из связи строки ТТН ЕГАИС, в которой имеется информация о марке, и строки накладной Торговой системы. Обращение к функции реализовано в СМ Мобайл 2.4, начиная с версии 2.4.466.33, в режиме работы «Подсчет алкоголя» для варианта подсчета уже принятого алкоголя (инвентаризация, отгрузка), то есть подсчета без загрузки ТТН ЕГАИС (используется при приеме поставки).
Создана новая функция ClientByAnyGLNINN для обработки XML файлов при импорте документов. Функция возвращает код контрагента по его ИНН и КПП или GLN, в зависимости от того, что встретится во входном файле.
В прошлых версиях были реализованы функции экспорта для занесения в XML файл экспортируемого документа данных из заказа поставщику - основания отсылаемого документа. Однако эти функции были недоступны для работы в редакторе XML схем. В текущей версии функции добавлены в перечень функций экспорта интерфейса редактора XML схем.
Изменения функционала в версии 1.054 сервис пак 3
Меркурий. Групповое гашение ВСД.
Контракт с поставщиками. Синхронизация списков артикулов с соглашениями о поставках.
Соглашение о поставках. Функция «Проставить параметры заказа из спецификации контракта».
Автоматическая генерация заказов. Алгоритм использования атрибута «Частота заказа».
Кассовый модуль. Протокол УКМ4 XML.
Выгрузка штрихового кода с флагом «Обмен с EDI».
Выгрузка признака маркировки товара белорусской маркой.
Почтовый модуль. Функция импорта GenerateDocUIDateAnyGLNINN.
Сервер обмена данными. Формат «Яндекс Еда». Изменение в протоколе обмена.
В раздел «Гашение ВСД ГИС «Меркурий» добавлена функция «Сопоставить и погасить». Функция позволяет для отобранных ВСД выполнить поиск подходящих приходных накладных или накладных на перемещение, сопоставить ВСД с накладными и выполнить гашение ВСД.
Условием подбора накладных является совпадение места хранения накладной и площадки, для приходной накладной - совпадение контрагента поставщика и соответствующей ему площадки ВСД, а для накладной на перемещение места хранения «Из» и соответствующей ему площадки. Кроме того, в накладной должен быть артикул из ВСД и его количество не должно отклоняться от количества в ВСД больше чем на 5 %. При больших отклонениях сопоставлять накладные и гасить ВСД надо вручную.
В текущей версии при смене статуса контракта с «Черновик» на «Принят», если у контрактов имеются соглашения о поставках, то делается проверка на наличие в соглашениях артикулов, отсутствующих в контракте, и если такие артикулы есть, предлагается их удалить из спецификации соглашений о поставках:
В ходе удаления артикулов из соглашений, при необходимости, выполняется понижение статуса соглашений до черновика, потом восстанавливается прежний статус.
В прошлых версиях функция «Проставить параметры заказа из спецификации контракта» была доступна в режиме редактирования черновика документа. В текущей версии функцию можно вызвать на экране отобранных документов для списка документов:
По прежнему, можно обрабатывать только соглашения о поставках в статусе «Черновик».
В алгоритмах генерации заказов для определения минимального интервала времени между заказами поставщику используется атрибут «Частота заказа». Атрибут позволяет реализовать условие «заказывать не чаще, чем раз в заданное количество дней», когда поставщик не согласен принимать заказы и выполнять поставку в произвольный момент времени.
В предыдущих версиях последний заказ искался отдельно для каждого артикула. То есть искался последний заказ, в котором имелся заданный артикул. Поиск велся среди мест хранений соглашения о поставке, по которому делается заказ. Если такой заказ отстоял от даты нового заказа меньше количества дней частоты заказа, то такой артикул не заказывался.
В текущей версии последний заказ ищется среди заказов поставщика мест хранений соглашения о поставке, но с условием наличия в этом заказе любого из артикулов соглашения о поставке, а не только обрабатываемого артикула.
Изменение алгоритма позволяет избежать ситуации, когда из-за пропуска в заказе какого-либо артикула, например, из-за неожиданного изменения спроса, он заказывался в другие даты, чем прочие артикулы, нарушая, таким образом, условие заказа товара поставщику не чаще чем раз в указанное количество дней.
В тех случаях, когда делаются дополнительные заказы вне графика по согласованию с поставщиком и их требуется исключить их из анализа последних заказов, у таких заказов необходимо снимать флаг «Учитывать при автогенерации заказов».
В текущей версии, если у артикула есть штриховой код с флагом «Обмен с EDI» (такой штриховой код может быть только один), то при выгрузке артикула в кассу по протоколу УКМ4 XML в файл updateItems в тэг <barcode> для этого штрихового кода добавляется тэг <property>, с тэгом дополнительной характеристики «GTIN» и со значением характеристики равным «GTIN».
<item>
….
<barcode>
<id>4601297000146</id>
<quantity>1</quantity>
<property>
<property_id>GTIN</property_id>
<property_value>GTIN</property_value>
</property>
</barcode>
….
</item>
В справочник кодов ТНВЭД добавлен флаг «Маркировка РБ». По умолчанию флаг не установлен:
Если флаг отметить, то при выгрузке в кассу по протоколу УКМ4 XML артикулов, которым присвоена группа ТНВЭД с флагом «Маркировка РБ», в файле updateItems в тэге дополнительных характеристик товара выгружается дополнительная характеристика с фиксированным именем «RB_Mark» и со значением «RB_Mark».
<addProperty>
<id>RB_Mark</id>
<value>RB_Mark</value>
</addProperty>
Создана функция GenerateDocUIDateAnyGLNINN для обработки XML файлов при импорте документов. Функция генерирует номер документа Супермаг+ с использованием ИНН и КПП или GLN контрагента, в зависимости от того, что встретится во входном файле, а также КПП места хранения или GLN места хранения, в зависимости от того, что встретится во входном файле, и с контролем даты документа. Атрибуты функции:
locationKppКПП места хранения
locationGLN GLN (Global Location Number) места хранения
clientInnИНН контрагента
clientKppКПП контрагента (параметр КПП может быть не задан, если в БД есть только один контрагент с указанным ИНН и произвольным КПП)
clientGLNGLN (Global Location Number) контрагента
supplierDocНакладная поставщика
docDateДата документа
Примечание: контроль даты документа необходим в тех случаях, когда поставщик начинает нумерацию своих документов заново с некоторой даты, например, с начала года.
В формате обмена данными «Яндекс Еда» поддержана команда протокола «ЯндексЕда»:
PUT
/order/{orderId}/status
Обновление статуса заказа в системе партнера по инициативе Яндекс Еды.
При получении такой команды со значением статуса «CANCELLED» соответствующий заказ от клиента блокируется с указанием причины завершения «Отменен».
При получении команды с другими значениями статуса возвращается код ошибки 500 с описанием «неподдерживаемая смена статуса».
Дополнительно внесены изменения в процедуру обработки команды отмены заказа от клиента:
DELETE
/order/{orderId}
Отмена заказа в системе партнера
В текущей версии при получении команды помимо того, что соответствующий заказ от клиента получает статус «Черновик», в поле «Причина завершения» ставится отметка «Отменен».
Изменения функционала в версии 1.054 сервис пак 4
Маркировка. Подсчет кодов КИЗ ТСД. Экспорт данных в приходную накладную.
Меркурий.
Площадки ГИС «Меркурий». Краткое название площадки.
Документ «Перевозка» ГИС «Меркурий». Функция «Проставить даты».
Карточки складского учета.
Ввод штриховых кодов типа «маркировка GS1» для весовых и объемных товаров.
Ненапечатанные ценники.
Склады и магазины. Заполнение списка складов из файла.
Кассовый модуль. Протокол УКМ4 XML. Выгрузка штрихового кода с флагом «Обмен с EDI».
Формат обмена «Яндекс.Еда». Передача информации об остатках товара.
Печатные формы. Счет-фактура. Универсальный передаточный документ.
В версии 1.054 сп1 в разделе «Подсчет кодов КИЗ ТСД» в функции «Экспорт данных в приходную накладную» было реализовано правило, по которому при создании приходной накладной данные для артикула берутся не из процесса, а из УПД, если процесс создан на основании УПД и в нем имеется строка с соответствующим КИЗ.
Изменение позволяло корректно формировать приходную накладную, если в УПД артикул представлен двумя строками с разными КИЗ и разными ценами, но возникала проблема, если прием происходил по УПД, где артикул представлен одной строкой с несколькими КИЗ упаковок товара.
В текущей версии при формировании спецификации приходной накладной из процесса, созданного на основании УПД, строки в накладной создаются в порядке строк УПД с ценами из УПД и заполняются КИЗ и количеством по журналу процесса, соотносясь со строками УПД по совпадению КИЗ.
В разделе «Площадки ГИС «Меркурий»» в таблицу площадок добавлено поле для ввода альтернативного названия площадки:
Краткое название площадки используется при выборе площадки в диалоге создания документа Меркурия, например:
Если краткое название площадки не указано, в диалогах используется название площадки, зарегистрированное в ГИС «Меркурий».
В раздел «Документ «Перевозка» ГИС «Меркурий»» добавлена функция «Проставить даты». Функция для выбранных строк спецификации документа позволяет заполнить датами поля «Изготовлен» и «Годен до»:
При выборе опции «по сроку годности из карточки товара» проставляется дата «Изготовлен» плюс количество дней срока годности из карточки.
В прошлых версиях считалось, что при сканировании КИЗ и регистрации штрихового EAN из состава КИЗ, как кода «маркировка GS1», для штрихового кода должно быть назначено количество того экземпляра товара, на который нанесен КИЗ. При ручном вводе EAN можно было зарегистрировать штриховой код без указания количества.
В текущей версии считается, что любой КИЗ, который нанесен на весовой товар или на упаковку разливного товара, то есть товара, который предполагается продавать на вес или в розлив, а не как штучный товар, EAN код из состава КИЗ идентифицирует товар, но не может указывать на его количество.
По текущим правилам при продаже весового или разливного маркированного товара для каждой части товара касса должна регистрировать КИЗ исходного экземпляра товара. В этом случае использование EAN из КИЗ для идентификации товара не должно приводить к определению количества товара, поскольку оно может быть каждый раз разным и не совпадающим с количеством исходного экземпляра.
В текущей версии регистрация EAN типа «маркировка GS1» для весовых и разливных товаров разрешается только без указания количества.
В текущей версии изменен подход к определению «ненапечатанный ценник». В прошлых версиях ценник считался ненапечатанным, если после последней печати ценника произошло любое изменение карточки товара или цены товара. В текущей версии ценник считается не напечатанным, если изменилось название карточки или цена карточки. Это позволит избежать избыточной печати ценников при изменениях в карточках, не влияющих на содержание ценника.
В разделе «Склады и магазины» перечень функций кнопки «Обработать» дополнен функцией «В список из файла ….». При вызове функции показывается диалог, в котором можно выбрать файл для загрузки списка идентификаторов мест хранения и группу классификатора списка мест хранения:
Структура данных в файле должна быть следующей:
Идентификатор места хранения;Название места хранения
Например:
4;Семеновский
86;Пражский
120;Склад возврата
Кодировка файла ANSI или UTF-8 (без спецификации).
Файл не должен содержать кодов мест хранения, отсутствующих в Торговой системе. В этом случае импорт будет отменен с сообщением, например:
При приеме данных названия мест хранения из файла игнорируются. Список мест хранения всегда дополняется данными из файла. Если до работы функции в списке были другие места хранения, они в нем останутся.
В прошлой версии при выгрузке артикула, у которого есть штриховой код с флагом «Обмен с EDI», в файл updateItems в тэг <barcode> для этого штрихового кода добавлялся тэг <property>, с тэгом дополнительной характеристики «GTIN» и со значением характеристики равным «GTIN»:
<item>
….
<barcode>
<id>4601297000146</id>
<quantity>1</quantity>
<property>
<property_id>GTIN</property_id>
<property_value>GTIN</property_value>
</property>
</barcode>
….
</item>
В текущей версии этот признак выгружается не как характеристика штрихового кода, а как характеристика артикула следующим образом:
<item>
...
<addProperty>
<property_id>GTIN</property_id>
<property_value>4601297000146</property_value>
</addProperty>
...
\\
При получении от Яндекс Еды запроса об актуальной информации об остатках товара в ответ передается информация следующего вида:
\\
\{
"items": \[
\{
"id": "some-uniq-identifier",
"stock": 7.45
\}
\]
\}
\\
Где "id" – артикул, "stock" – текущий остаток товара.
\\
В предыдущей версии в тэге "stock" передавалось значение поля «Оперативно доступно» карточки складского учета. Значение поля «Оперативно доступно» определяется как «Остаток» за вычетом «В приемке / в пути», «Потери» и «Оперативная реализация». В текущей версии передается значение «Оперативно доступно» плюс «В приемке / в пути».
\\
То есть, товар, который принят, но не прошел полный цикл оформления приходных документов, не будет исключаться из количества, доступного для заказа товара.
\\ |
Формы изменены согласно постановлению Правительства РФ от 16.08.2024 № 1096.
Изменения функционала в версии 1.054
ЕГАИС.
Списание пива с учетом срока годности.
Прием и списание / отгрузка разливного пива в штучной упаковке.
Определение ФСРАР ИД при отсылке ТТН ЕГАИС контрагенту, не имеющему КПП.
Маркировка.
Повторный прием УПД после приема с ошибками.
Прием УКД в случае, когда ранее принятый УПД имеет статус «черновик».
Отсылка УКД при отгрузке товара в случае получения акта приемки с расхождением.
Подсчет кодов КИЗ. Функция «Экспорт кодов КИЗ в файл».
Меркурий.
Справочники ГИС «Меркурий». Справочник целей (назначения грузов).
Остатки ГИС «Меркурий».
Гашение ВСД с составлением акта несоответствия.
Автоматическая генерация заданий для Супермаг Мобайл 3.
Документ «Калькуляция». Калькулятор цен и сумм спецификации документа.
Раздел «Остатки». Поля «Единица измерения» и «Среднесуточная реализация».
Почтовый модуль. Рассылка актов переоценки, созданных на основании маркетинговых акций.
Кассовый модуль. Протокол УКМ4 XML. Прием из кассы информации о смене.
Периодическое задание «Блокировка неисполненных заказов поставщикам». Выбор поставщиков.
В текущей версии при списании немаркированной продукции по кассовым документам и при отгрузке по всем операциям, кроме «Списание брака» (порча), при подборе справок РФУ2 учитываются сроки годности продукции. Срок годности определяется по дате розлива продукции, которая указывается производителем в справке РФУ1, и по сроку годности из карточки артикула, связанного с кодом алкогольной продукции. Если в карточке товара срок годности не указан, срок годности продукции считается бесконечным. При подборе партии для списания подбираются поставки с самой ранней и еще не истекшей датой годности немаркированной продукции. Перед подбором справок РФУ2 для строк ТТН в ЕГАИС запрашиваются справки РФУ1 для получения информации о датах розлива немаркированной продукции. Справки запрашиваются только для партий немаркированной продукции, у которых есть остатки на первом регистре. Справки РФУ1 запрашиваются один раз и сохраняются в базе данных.
Запрос данных из ЕГАИС в ходе операции подбора кодов алкогольной продукции может заметно замедлить выполнение функции. Чтобы этого избежать, можно заранее выполнить функцию «Запрос содержания справок «РФУ1» из ЕГАИС» в разделе «ТТН ЕГАИС на приход» или аналогичную функцию в разделе остатков ЕГАИС (см. ниже).
Для контроля сроков годности в таблицу остатков регистра склада в разделе «Остатки ЕГАИС» добавлено поле «Дата розлива». Также в таблицу добавлено поле «ТТН», по которой пришла партия:
В раздел «Остатки ЕГАИС» добавлена функция «Запрос содержания справок «РФУ1» из ЕГАИС». Функция действует для выбранных строк таблицы остатков:
Функция позволяет заранее запросить справки РФУ1 по тем позициям, по которым они будут использоваться:
Для позиций с маркированной продукцией дата истечения срока годности в текущей версии в алгоритмах не используется и имеет административный характер.
Для ТТН ЕГАИС на отгрузку создана функция проверки 245 «Контроль срока годности пивной продукции». По умолчанию функция имеет режим работы «Предупреждение». Проверка срабатывает для немаркированной продукции из спецификации ТТН ( кроме операции «порча»), если дата окончания срока годности продукции меньше даты отгрузки продукции. Функция проверки выполняется при отсылке ТТН в ЕГАИС.
В предыдущих версиях при приеме разливного пива, то есть немаркированной алкогольной продукции, которая поставляется в кэгах, но продается в розлив, предполагалось, что в документах ЕГАИС такая продукция всегда представлена с флагом типа упаковки «нефасованная». В этом случае ее количество в ТТН указывается в декалитрах. Соответственно, такая продукция в Торговой системе сопоставлялась с артикулом с единицей измерения «литр» и при приеме поставки принималось на учет в литрах с пересчетом количества из декалитров. Несмотря на то, что ЕГАИС разрешала движение немаркированной продукции для розлива, в том числе с флагом типа упаковки «фасованная», то есть в виде штучной продукции, производители регистрировали такую продукцию, как «нефасованная», и отгружали ее в декалитрах. Сейчас, из-за необходимости маркировки пива в ЦРПТ, где кэга – это всегда единичная упаковка с одной маркой КИЗ, производителям стало удобнее регистрировать такую продукцию как фасованную и фиксировать в ТТН в штуках.
С точки зрения ЕГАИС, одна и та же продукция, как фасованная (в штучной упаковке), так и нефасованная (то есть учитываемая в декалитрах) - это разная продукция с разными кодами алкогольной продукции. Если производитель предполагает декларировать выпуск продукции в ЕГАИС и в фасованном и в нефасованном виде, то есть в штуках или декалитрах, он должен зарегистрировать такую продукцию раздельно и получить для нее разные коды алкогольной продукции. Такие правила регистрации продукции в ЕГАИС не делают товар разным, и штриховой код EAN и у той, и у другой продукции, как правило, одинаковый. С точки зрения торгового предприятия это один и тот же артикул. Кроме того, по правилам торговли регистрация поступления товара должна производиться в тех единицах измерения, в которых будет производиться ее отпуск. Если товар продается в розлив, его единица измерения в торговой организации будет «литр». При приеме алкогольной продукции, соответствующей этому артикулу, и для фасованной и для нефасованной продукции прием артикула должен выполняться в его единице измерения, то есть в литрах.
В прошлых версиях при приеме алкогольной продукции тип упаковки для кода алкогольной продукции (фасованный или нефасованный) определялся по содержанию ТТН на приход. Если алкогольная продукция была нефасованная, она могла сопоставляться только с артикулами с единицей измерения «литр». При приеме такой продукции производился автоматический пересчет декалитров в литры или из литров в декалитры при отгрузке или списании. Если продукция была «фасованная», она могла сопоставляться только с артикулами с единицей измерения «штука».
В текущей версии разрешено принимать и отгружать фасованную алкогольную продукцию с сопоставлением с артикулом с единицей измерения «литр». Чтобы иметь однозначное представление о том, как необходимо пересчитывать количество артикула в количество алкогольной продукции (прежде всего для отгрузки) в раздел карточек на закладку «ЕГАИС» в таблицу свойств кода алкогольной продукции добавлено поле «тип упаковки»:
Для ранее введенных кодов алкогольной продукции это поле не заполнено. Если поле не заполнено, то для артикулов с единицей измерения «штука» по умолчанию считается, что тип упаковки алкогольной продукции «фасованная», для артикулов с единицей измерения «литр» считается, что тип упаковки алкогольной продукции «нефасованная». Оставлять тип упаковки неопределенным можно для всех кодов алкогольной продукции, кроме тех, которые относятся к фасованной разливной продукции.
Для того чтобы обновить информацию о коде алкогольной продукции и заполнить поле «тип упаковки», необходимо выполнить запрос к ЕГАИС с помощью функции «Обработать - Изменение кодов ЕГАИС».
Примечание: при ручном добавлении кода алкогольной продукции в таблицу кодов разрешается вводить только код алкогольной продукции. Прочие атрибуты необходимо получать из ЕГАИС запросом.
При приеме ТТН на приход после сопоставления позиций ТТН с позициями накладной происходит автоматическое добавление всех новых кодов алкогольной продукции в карточку товара. В этом случае информация о типе упаковки вместе с другими атрибутами кода алкогольной продукции берется из ТТН ЕГАИС.
При приеме и отгрузке / списании артикула с единицей измерения «литр» и связанной с ним алкогольной продукции с типом упаковки «нефасованная» количество продукции пересчитывается из декалитров в литры и наоборот таким же образом, как и прежде. Так же, как и прежде, в этом случае разрешается отгружать / списывать произвольное количество продукции, то есть столько литров, сколько указано в расходных накладных / кассовых документах.
Если тип упаковки алкогольной продукции «фасованная», то прием «литрового» артикула ведется с пересчетом штук в литры в соответствии с емкостью, указанной в свойствах кода алкогольной продукции. А отгрузка или списание продукции допускается только в штуках. Количество артикула в накладной, в этом случае, должно быть кратным емкости кода алкогольной продукции.
Например, прием 16 кэг емкостью 50 л. по накладной на 800 л.
При продаже продукции в розлив ЕГАИС не требует соблюдения специальной процедуры «вскрытия тары» или «постановки на кран». Также ЕГАИС не ведет учета остатка продукции вскрытой кэги по данным кассовой реализации. С точки зрения ЕГАИС, вскрытую упаковку надо списывать целиком и это можно делать как по факту вскрытия, так и по факту завершения продажи. ЕГАИС не допускает списание доли кэги и списание кэги позднее даты истечения срока годности продукции.
В текущей версии для списания кассовой реализации разливной продукции применяется следующий алгоритм: при регистрации кассового документа определяется объем проданной продукции, для нее ищется код алкогольной продукции с остатком, с учетом срока годности. Если полученный код алкогольной продукции имеет тип упаковки «нефасованный», то количество продажи списывается с пересчетом в декалитры. Если остатка для кода алкогольной продукции не хватило, делается переход к следующему коду алкогольной продукции. Если код алкогольной продукции имеет тип упаковки «фасованная» и это первая реализация по данному коду, то количество реализации пересчитывается в штуки кэг с округлением в большую сторону, и списывается целое количество кэг продукции. Объем списанных кэг в литрах сохраняется в специальной таблице остатков по кэгам за вычетом объема проданной продукции. При следующих продажах происходит уменьшение остатка по кэге без отсылки данных в ЕГАИС, пока не будет исчерпан весь объем, после чего при очередной продаже произойдет списание следующей кэги.
То есть для фасованной продукции списание кэги происходит по факту первой продажи.
Примечание: списание кассовой реализации выполняется функцией «Списание пива ЕГАИС» в разделе кассовых документов. В процессе выполнения функции создается ТТН на отгрузку. В ходе отсылки ТТН для артикула в ТТН подбираются коды алкогольной продукции, и выполняется распределение количества продаж по кодам алкогольной продукции с необходимым количеством:
Если разливного остатка достаточно для списания пива, то количество списываемой продукции в ТТН будет 0. При отсылке ТТН строки с нулевым количеством не будут добавлены в файл почтового пакета и, при наличии других строк, документ будет корректно отослан и обработан в ЕАГИС.
Для контроля текущих остатков по вскрытым кэгам в раздел «Остатки ЕГАИС» добавлена закладка «Разливное пиво»:
Фактические остатки вскрытых кэг по разным причинам могут разойтись с учетными данными. Это может привести к тому, что при замене кэги на новую в остатках будет числиться прежняя, и в ЕГАИС не будет списана новая кэга, пока не будет исчерпан остаток прежней. Это не представляет проблемы до тех пор, пока срок годности очередной списываемой кэги из-за смещения очереди кэг не окажется меньше необходимого. Эту проблему можно решать периодической инвентаризацией и списанием учетных излишков кэг. Для оперативной коррекции розливных остатков и сброса остатка текущей кэги в раздел «Остатки ЕГАИС» добавлена новая функция «Коррекция разливного остатка». Для использования функции необходимо иметь функциональное право «Коррекция разливного остатка»:
Функция позволяет для выбранных строк таблицы остатков разливного пива установить нужное значение остатка:
При установке остатка в значение 0 строка с соответствующим кодом алкогольной продукции из таблицы исчезает. При очередной продаже продукции в ЕГАИС будет списана очередная кэга и начнется новый отсчет разливного остатка вскрытой кэги.
При отсылке ТТН на расход в ЕГАИС в ТТН необходимо корректно заполнить атрибуты контрагентов ЕГАИС - участников обмена. Чтобы получить текущие атрибуты контрагента, делается запрос в ЕГАИС. По протоколу ЕГАИС запросить можно только информацию для всего контрагента целиком по его ИНН. В ответ ЕГАИС возвращает перечень атрибутов контрагента с привязкой к ФСРАР ИД контрагента. Среди перечня атрибутов для каждого ФСРАР ИД обычно имеется КПП контрагента. Это позволяет определить ФСРАР ИД и связанные с ним атрибуты контрагента ЕГАИС по КПП контрагента Торговой Системы.
Выяснилось, что контрагенты – индивидуальные предприниматели не имеют КПП и в то же время могут иметь множество магазинов, каждый со своим ФСРАР ИД. В этом случае в предыдущих версиях ФСРАР ИД контрагента ЕГАИС определялся некорректно, и ТТН отправлялось не тому адресату.
Для однозначного определения ФСРАР ИД и связанных с ним атрибутов контрагента ЕГАИС в раздел «Контрагенты» на закладку «Склады» в таблицу складов контрагента добавлено поле «Ид. ФСРАР»:
В заголовок расходной накладной на закладку «транспортный раздел» добавлено новое поле «Ид. ФСРАР». При выборе склада контрагента в накладной в документ автоматически проставляется значение ФСРАР ИД из карточки контрагента:
В документе это поле можно отредактировать вручную.
Если в расходной накладной задан ФСРАР ИД, он будет использоваться для определения данных контрагента, полученных из ЕГАИС. После получения данных о контрагенте по ИНН его атрибуты будут искаться по совпадению ФСРАР ИД и КПП, если он есть. Если эти параметры не совпадут с данными ЕГАИС, контрагент подобран не будет и документ не отошлется.
При приеме УПД на приход с критическими ошибкам, например, когда УПД содержит строки, для которых не удалось определить артикул, УПД принимается в систему со статусом «Черновик». Такие документы должны быть рассмотрены персоналом для принятия решения об отказе в приеме или, например, внесения в систему нового артикула или штрихового кода для исправления документа и начала приема поставки по нему.
В некоторых случаях поставщик успевает прислать исправленный УПД с теми же атрибутами, что и ранее принятый, до того, как персонал приступит к рассмотрению документа с ошибками. В прошлых версиях такой документ при приеме отвергался, так как считался уже принятым, а уже принятые документы повторно принимать не разрешается.
В текущей версии, если для принимаемого документа в базе данных уже есть УПД на приход, но этот УПД имеет статус «черновик», то его разрешается перезаписать.
Дополнительно в журнал истории документа «УПД на приход» добавлено поле «Сумма» документа.
В предыдущих версиях был реализован прием УКД от поставщика, когда по ранее принятому УПД еще не была произведена приемка и не был получен результат приемки. Так может произойти, если поставщик обнаружил ошибку в своем документе и, не дожидаясь ответа на отосланный УПД, сразу послал корректировочный документ. При приеме УКД в таком случае первичный УПД блокировался, создавался скорректированный УПД и будущий прием проводился по новому документу. Но, если первичный УПД принимался с ошибкой и оставался в статусе «черновик», его обработка не производилась.
В текущей версии в обработку при приеме УКД добавлены первичные УПД, принятые с ошибками и получившими статус «черновик». Такие УПД теперь также переводятся в статус «заблокирован» и формируется новый УПД с учетом коррекции.
В предыдущих версиях при отсылке УПД на отгрузку, созданного на основании расходной накладной, при частичной приемке поставки получателем использовался следующий алгоритм действий:
Если в ответ на УПД с операцией «Отгрузка получателю» приходил акт приемки с кодом ответа «2» (прием с расхождением) и в файле акта приемки (UDCONFIRM) имелась спецификация принятого товара, то создавался новый документ «УПД на отгрузку» с операцией «Акт приемки», статусом «Сформирован» и спецификацией из акта приемки.
Примечание. Документ с операцией «Акт приемки» предназначен для информирования о решении контрагента и, несмотря на то, что это документ имеет тип «УПД на отгрузку», не предназначен для пересылки контрагенту.
В основание нового документа ставится расходная накладная, что была в основании отосланного ранее УПД на отгрузку с операцией «Отгрузка получателю». Исходный документ «УПД на отгрузку» блокируется. Расходная накладная не меняет своего статуса в ожидании решения персонала.
Дальнейшее действие выполняется в расходной накладной функцией «Обработать акт приемки». Функция позволяет принять решение о согласии или несогласии с актом приемки контрагента.
В прошлой версии нажатие кнопки «Признать расхождение» приводило к замене спецификации расходной накладной на содержание акта приемки, созданию и отсылке нового УПД на отгрузку с операцией «Отгрузка получателю». УПД с операцией «Акт приемки», созданный на основании UDCONFIRM, переводился в статус «Обработан».
Кнопка «Аннулировать отгрузку» вызывала блокировку УПД с операцией «Акт приемки». Статус расходной накладной оставался без изменения в ожидании завершения процедуры согласования.
Примечание: если в расходной накладной имеются коды КИЗ для продукции с объемно-сортовым учетом, то при коррекции накладной по акту приемки они исчезнут, поскольку для такой продукции акт приемки содержит только указание на количество кодов КИЗ, но не сами коды. Это не мешает последующему правильному формированию почтового пакета для скорректированного файла УПД на отгрузку или УКД (см. ниже) при отсылке документа провайдеру.
В текущей версии при обработке акта приемки можно отослать не только новый УПД на отгрузку с операцией «Отгрузка получателю» и с новым содержанием спецификации, но и корректировочный документ (УКД).
Для принятия решения об отсылке УПД или УКД добавлена обработка тэга «ANSWERTYPE» при приеме файла акта приемки (тэг «ANSWERTYPE» в файле UDCONFIRM может принимать значение «УПД» или «УКД») и в раздел контрагентов на закладку «ЭДО» добавлена опция «ЭДО при отгрузке с расхождением»:
По умолчанию для контрагента установлен флаг «Исправительный УПД». Значение флага учитывается функцией «Обработать акт приемки», если в файле ответа о результате приемке отсутствует тэг «ANSWERTYPE» или у него нет содержания.
В тех случаях, когда определено, что надо создавать УКД, функция «Обработать акт приемки» создает документ УПД на отгрузку с новой операцией «Коррекция при отгрузке». Документ создается в статусе «Сформирован» и отсылается контрагенту.
Спецификации УКД (то есть УПД на отгрузку с операцией «Коррекция при отгрузке») и УПД на отгрузку с операцией «Отгрузка получателю» имеют принципиальное отличие. Исправительный УПД содержит спецификацию принятой продукции с количеством принятого товара и стоимостью, признанной контрагентом. Например, если контрагент принял одну позицию из двух, в спецификации УПД будет принятая позиция. УКД содержит только строки, которые подверглись изменению. Например, если контрагент принял одну позицию из двух, то в спецификации УКД будет непринятая позиция с количеством 0, а принятая строка, не имеющая изменений, в УКД будет отсутствовать.
В обоих вариантах в документ «УПД на отгрузку» теперь проставляется номер исправления (+1 к максимальному номеру предыдущих исправлений по одной и той же расходной накладной), указывается номер предшествующего УПД и его дата. Для этого в заголовок УПД на отгрузку добавлена закладка «Исправления»:
В раздел «Подсчет кодов КИЗ ТСД» добавлена функция «Экспорт кодов КИЗ в файл». Функция доступна в открытом процессе. Функция выгружает данные в файл формата CSV. Диалог функции позволяет указать или выбрать имя файла для экспорта:
Коды КИЗ помещаются в файл с преобразованием по правилам ЦРПТ, как это делается перед помещением кодов в УПД на отгрузку. То есть КИЗ в выгруженном файле не содержат нечитаемых символов и коды применения, связанные с контрольными суммами и другими специфическими данными КИЗ. Например:
010460143993125621nNc3bUI8005122000 |
010460720309891021nNc3bUI8005122000 |
010460143993125621pz>,!A: |
В раздел «Справочники ГИС «Меркурий»» в дополнение к справочнику единиц измерения добавлена закладка со справочником целей (назначения грузов):
Элементы справочника, то есть цели, доступные для оформления груза, используются при создании транспортного ВСД при отгрузке подконтрольной продукции.
Создан новый раздел «Остатки ГИС «Меркурий»» для просмотра текущих остатков по номенклатуре в ГИС Меркурий.
Для работы с разделом необходимо иметь право на функциональную роль «Меркурий. Остатки» в модуле «Меркурий. Справочные данные»:
Содержание остатков можно перечитывать независимо от наличия продукции в справочнике подконтрольной продукции в разделе карточек товара. Для запроса остатков необходимо указать хозяйствующий субъект из перечня собственных и площадку. Можно запросить все активные записи с ненулевым остатком или только те записи, которые были созданы или изменены в заданном диапазоне дат:
Примечание: запрос остатков выполняется через сервер обмена данными. Если сервер не настроен или остановлен, данные не будут получены.
В интерфейсе раздела показывается дата и время последнего получения остатка из ГИС Меркурий:
В ГИС «Меркурий» остатки ведутся по партиям, и для одной продукции может быть несколько записей.
Остатки после запроса в ГИС Меркурий сохраняются в базе данных. Если данные были прочитаны достаточно давно, информация об остатках может быть устаревшей.
В предыдущих версиях был создан раздел «Гашение ВСД ГИС «Меркурий»» и реализовано гашение ВСД для полностью полученных партий. Под полностью полученными партиями понимаются партии, для которых количество продукции в ВСД отличается от количества принятой продукции не более чем на 5%.
В текущей версии реализован протокол приема продукции, если количество принятой продукции меньше количества в ВСД на величину большее, чем 5%.
В ГИС Меркурий предусмотрено два сценария приема с расхождением: когда часть продукции возвращается и когда возврата разницы количества принятой и отгруженной продукции не происходит (если расхождение обусловлено потерями при транспортировке или ошибками). В текущей версии реализован сценарий приема с потерями при транспортировке. В этом случае в ГИС Меркурий отсылается только акт несоответствия.
При выполнении процедуры гашения делается проверка соответствия количества принятой продукции и количества продукции в ВСД. Если разница превышает 5% от количества в ВСД в меньшую сторону, показывается следующий диалог:
В диалоге по умолчанию подставляется причина, указанная в последний раз. Причина может быть введена вручную или выбрана из справочника «Причины несоответствия».
Причина несоответствия указывается в произвольной форме. Это должно быть описание причины составления акта о несоответствии или описание самого несоответствия.
После указания причины несоответствия команда гашения и акт отсылаются в ГИС Меркурий и ВСД гасится:
Если количество в приходной накладной превышает количество в ВСД более чем на 5%, то при гашении будет показано следующее сообщение:
Такая накладная может быть использована для гашения другой ВСД (в доступном количестве), если, например, по одной накладной было принято сразу нескольких поставок одной и той же продукции с разными ВСД.
Примечание. Можно гасить несколько ВСД одной приходной накладной, но нельзя гасить один ВСД несколькими приходными накладными. В последнем случае при сопоставлении ВСД с первой из приходных накладных и гашении, в Меркурий будет отправлен акт о несоотвествии.
В прошлых версиях был создан раздел «Управление заданиями Супермаг Мобайл 3». Раздел позволяет администрировать задания для СМ Мобайл 3, в том числе, создавать задания и принимать результаты выполнения этих заданий.
В текущей версии в раздел добавлена возможность создавать правила для автоматической генерации заданий СМ Мобайл 3:
Для исполнения правил необходимо, чтобы в сервере обмена данных были настроены атрибуты организации для доступа к серверу Мобайл 3 в настройках нового протокола обмена «Супермаг Мобайл 3»:
В сервере обмена данных должна быть запущена служба клиента.
Интерфейсы раздела «Управление заданиями Супермаг Мобайл 3» служат для создания правил обращения к серверу Мобайл 3 и для контроля их исполнения. Сами задачи выполняются по заданному расписанию сервером обмена данными.
Раздел позволяет создавать задачи трех типов:
Сборка мусора предназначена для удаления с сервера Мобайл 3 заданий, у которых дата создания отстоит от текущей более указанного количества дней:
Дата создания задания добавлена в сервер Мобайл 3 синхронно с изменениями в текущей версии и для ранее созданных заданий эта информация неактуальна.
Задания с давней датой создания могут образовываться, если задание не может быть выполнено по тем или иным причинам или было выполнено, но по какой-то причине не удалено после скачивания результатов работы.
Сборка мусора запускается сразу для всего множества заданий организации. Для настройки задач других типов необходимо указывать место хранения.
Задача для скачивания результатов выполненных заданий используется для получения результатов выполнения ранее размещенных заданий. Задания выполняются операторами в том темпе и в то время, которое невозможно точно спрогнозировать. Это надо учитывать при составлении расписания скачивания. При выполнении задачи скачиваются все выполненные задания заданного места хранения. После успешной загрузки результатов выполненное задание на сервере Мобайл 3 удаляется.
Настройка процедуры создания заданий зависит от типа задания. Для всех типов задания задается описание задания, сотрудник или должность, которой он будет назначен, планируемая продолжительность и расписание задачи.
Время начала выполнения задания зависит от выполняемой работы и может задаваться следующим образом:
«Не задавать» – оператор будет вправе выполнить задание, когда сочтет нужным.
«Время генерации задания + заданное количество минут» – позволяет создавать задания типа инвентаризации или проверки ценников в торговом зале, которые оператор должен выполнять время от времени. Смещение в минутах позволяет оператору заблаговременно увидеть задание до того момента, когда надо будет приступить к его выполнению, и спланировать свои действия.
«Из документа-основания» – позволяет указать время события, используя информацию из документа-основания, например, время предполагаемого прибытия поставки по заказу. Если основанием является документ «Заказ поставщику», то дата и время начала работы устанавливается равным времени поставки. Если это накладная на перемещение - то дате накладной на перемещение.
Все задания Мобайл 3 делятся на группы, которые не содержат спецификацию задания, содержат спецификацию из артикулов или спецификацию из артикулов с количеством.
В тех случаях, когда тип задания требует наличие в задании спецификации из артикулов, эту спецификацию можно сформировать, выбрав группы классификаторов товаров или документ.
Когда тип задания требует наличие в задании спецификации из артикулов с количеством, предлагается указать тип документа-основания:
При указании типа документа в качестве основания задания задание будет создаваться всякий раз по расписанию, если в базе данных будет обнаружен подходящий документ. То есть документ для места хранения задания с соответствующим статусом, для которого еще не было создано задание. Для одного документа задание создается один раз. Информация о документе, на основании которого создано задание, помещается в свойства задания. Для заказа от поставщика в свойства задания помещается название поставщика и время ожидаемой поставки:
В документе «Калькуляция» при вводе в спецификацию количества или цены ингредиента калькулятор спецификации производит вычисление суммы ингредиента. В прошлых версиях после расчета суммы и округления ее до точности валюты производился обратный расчет цены делением суммы на количество. В результате цена более точно соответствовала получившей стоимости, но меняла свою величину.
В текущей версии калькулятор цен и сумм в спецификации калькуляции не выполняет обратный пересчет цены делением суммы на количество, например при установке цены 770,33:
В предыдущей версии цена 770,33 после обратного прересчета была бы установлена в 770,3276.
В разделе «Остатки» в перечень полей, доступных для выбора в диалоге кнопки «Поля…» для текущих остатков и статистики текущих остатков, добавлены поля «Единица измерения» и «Среднесуточная реализация»:
При отображении в таблице значение среднесуточной реализации берется из карточки складского учета.
Для остатков на дату в выбор добавлено поле «Единица измерения».
Изменен алгоритм автоматической рассылки актов переоценки, созданных на основании маркетинговых акций. Акты переоценки начала и завершения маркетинговой акции имеют особые правила рассылки, чтобы избежать потери информации об акциях в местах их выполнения. При смене статуса документа с «Черновик» на «Принят к исполнению» акт автоматически ставится в очередь на отсылку в базы данных, которые обслуживают место хранения, в котором должен исполниться акт. В прошлой версии это правило поддерживалось для всех типов баз данных.
В текущей версии акты переоценки начала и завершения маркетинговых акций не ставятся автоматически в очередь на отсылку в базы данных с типом «Равноправные» и «Доверительные». Для отсылки актов в такие базы данных надо явно задать правило отсылки.
\\ В текущей версии расширен перечень принимаемой информации о смене ККТ, которую выгружает касса по протоколу УКМ4 XML. Из файла с данными закрытой смены (вида shift_\[4\]_\[2\]_\[1679\]_\[1\].xml) теперь принимается информация из следующих тэгов заголовка смены: \\ <kkm_shift_number> - номер смены ККТ. В УКМ4 номер смены (shiftNum) формируется с привязкой к кассе и не связан с номером смены, который формируется фискальным регистратором (ККТ). Это сделано для того, чтобы не менять номер кассы при замене фискального регистратора. <kkm_serial_number> - серийный номер ККТ (производителя) <kkm_registration_number> - регистрационный номер ККТ (в налоговой инспекции). \\ Эта информация принимается только из закрытых смен, в оперативных чеках ее нет. \\ Данные об атрибутах смены принимаются в таблицу SMCashZ, в которую добавлены соответствующие поля. В эту таблицу теперь принимается еще и информация о серийном номере ККТ при закрытии смены кассы Супермаг+. Соответствующее поле убрано из таблицы SMCashZPlus. \\ Для просмотра информации о смене в разделе кассовых чеков в перечень полей, доступных для выбора в диалоге кнопки «Поля…», добавлены флаги «№ Z отчета ККТ », «Регистрационный номер ККТ» и «Серийный номер ККТ»: \\ !worddavf794f372fcb27236e9270211f1021c38.png|height=214,width=258! \\ !worddav4531fcbbb4e10e59ef5e3d129e61eb7e.png|height=226,width=636! \\ |
В мастер настройки периодического задания «Блокировка неисполненных заказов поставщикам» на страницу выбора поставщиков добавлена возможность выбора группы поставщиков с использованием классификатора поставщиков или классификатора списка поставщиков:
Изменения функционала в версии 1.055 сервис пак 1
Маркировка.
УПД на приход. Функция проверки «Предупреждение повторной отсылки документа провайдеру ЭДО»
УПД на отгрузку. Транспортный раздел.
Функция «Списание маркированной продукции».
Приходная накладная. Простановка УПД и УКД в общие основания накладной.
Расходная накладная. Функция проверки «Корректность накладной для создания УПД на отгрузку».
Меркурий. Документ «Производство» ГИС «Меркурий».
Расчет среднесуточной реализации.
Заказ поставщику. Автоматическая генерация заказа.
Использование среднесуточной реализации, посчитанной по методу «с учетом коэффициентов изменения спроса»
Алгоритм Fresh. Определение остатка на день расчета.
Контракт с поставщиком. Экспорт в документ «Прогноз изменения спроса».
Соглашения о поставках. Функция «Синхронизировать артикулы со спецификацией контракта».
Почтовый модуль. Функция импорта из XML-файлов LocationByAnyGLNKPP.
Создана новая функция проверки 246 «Предупреждение повторной отсылки документа провайдеру ЭДО». По умолчанию функция имеет режим работы «Предупреждение». Функция срабатывает при смене статуса УПД на приход с «Заблокирован» на «Черновик» и с «Закрыт» на «Принят», то есть при смене тех статусов, при получении которых в систему ЭДО отправляется ответ о приеме или отказ от приема поставки. Функция проверки сообщает, что информация по документу уже была отослана провайдеру ЭДО.
В заголовок документа УПД на отгрузку в транспортный раздел добавлены поля «Марка автомобиля» и «Номер госрегистрации автомобиля». Поля заполняются при создании ТТН на основании расходной накладной значениями соответствующих полей расходной накладной:
В XSD схеме почтового объекта это поля TRUCKTYPE и TRUCKNUMBER:
<xs:element name="SMDOCTRANSPORT" msdata:Locale="ru">
<xs:complexType>
<xs:sequence>
<xs:element name="DOCID" type="xs:string" />
<xs:element name="DOCTYPE" type="xs:string" />
<xs:element name="ADDRESSLOADING" type="xs:string" minOccurs="0" />
<xs:element name="ADDRESSUNLOADING" type="xs:string" minOccurs="0" />
<xs:element name="GLNUNLOADING" type="xs:string" minOccurs="0" />
<xs:element name="TRUCKTYPE" type="xs:string" minOccurs="0" />
<xs:element name="TRUCKNUMBER" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
В документах «Расходная накладная», «Приходная накладная» и «Требования на отбор» изменено поведение функции «Списание маркированной продукции».
Содержание тэга <cost> (цена) формируется в соответствии с очередной рекомендацией ЦРПТ: «Для того чтобы цена воспринималась правильно, формируемую цену передавать в копейках».
То есть, теперь при формировании тэга <cost> цена передается как целое число, полученное умножением цены на 100.
В прошлых версиях при последовательном приеме УПД на приход и УКД к ней в общих основаниях приходной накладной, созданной на основании УПД на приход, показывался только УПД на приход. УКД в общие основания приходной накладной не проставлялись.
В текущей версии, если при приеме УКД приходная накладная на основании УПД уже есть, то УКД добавляется в общие основания приходной накладной. Если в процессе приемки приходная накладная создается на основании УКД, то есть уже после получения и УПД, и УКД, и в основании УКД есть другие УПД или УКД, то они все добавляются в основание приходной накладной.
Таким образом, в общих основаниях приходной накладной должен присутствовать весь список документов УПД на приход (с операциями УПД и УКД), которые были получены при оформлении поставки. УКД, которые могут прийти позднее в результате оформления возврата, в этот перечень не попадают.
Все накладные, созданные до текущей версии, полный перечень УПД в общих основаниях не содержат. Процедура экспорта из УПД на приход в приходную накладную в общие основания проставляет только текущий документ и цепочку оснований УПД не восстанавливает.
В прошлых версиях функция проверки 242 «Корректность накладной для создания УПД на отгрузку» срабатывала при смене статуса расходной накладной с «Принят складом» на «Принят полностью». Начиная с версии 1.049.1, документ «УПД на приход» создается на основании расходной накладной в момент смены статуса накладной с «Черновик» на «Принят складом». Смена статуса расходной накладной с «Принят складом» на «Принят полностью» происходит автоматически по факту получения от провайдера ЭДО акта приемки с кодом подтверждения приема, и проверка срабатывала слишком поздно. В текущей версии проверка дополнительно срабатывает при смене статуса документа с «Черновик» на «Принят складом».
Создан новый раздел «Документ «Производство» ГИС «Меркурий»». Раздел предназначен для передачи в ГИС «Меркурий» запросов на создание производственных ветеринарных сертификатов и производственных транзакций на списание сырья, использованного для производства продукции.
Раздел замещает разделы «Документ «Расход на производство» ГИС «Меркурий»» и «Документ «Выход из производства» ГИС «Меркурий»». Прежние разделы используют протокол обмена почтового модуля «Меркурий – обмен данными» и передают информацию провайдеру. Данные, передаваемые провайдеру, формируются на основании документов «Расход на производство» и «Выход из производства» и используются провайдером для формирования транзакций на списание сырья (расход на производство) и оформление готовой продукции (выход из производства) с использованием транзакции «Незавершенное производство» для всего ассортимента готовой продукции. Незавершенное производство позволяет формировать производственные сертификаты без обязательного указания в момент оформления конечного объема произведенной партии готовой продукции и объема сырья, использованного для ее изготовления, но делает затруднительным прослеживание со стороны ГИС Меркурий партий сырья в партии продукции и может привести к претензиям со стороны ГИС Меркурий.
В новом разделе производственный ВСД и транзакции на списание сырья создаются на основании акта производства:
Все артикулы акта производства, которые должны участвовать в запросах в ГИС Меркурий, должны быть заранее сопоставлены с номенклатурой ГИС Меркурий:
Место хранения должно быть сопоставлено с площадкой ГИС Меркурий:
В ГИС Меркурий площадка ХС должна быть объявлена производителем соответствующей номенклатуры.
В мастере создания документа «Производство» можно, при необходимости, разбить выходную продукцию на несколько партий, указав необходимое количество выходной продукции:
Для создания производственного ВСД необходимо указать вид произведенной ветсанэкспертизы:
В результате будет создан документ «Производство», который содержит все сведения для отсылки запроса в Меркурий на создание производственных документов:
При формировании запроса в ГИС Меркурий делается автоматический подбор партий сырья для списания на производство. Партии при подборе сортируются по сроку окончания годности, начиная с самых старых партий. Партии без срока годности используются в последнюю очередь, как никогда не портящиеся.
После успешной отсылки документ получает статус «оформлен»:
Внимание! В ГИС «Меркурий» нет операции аналогичной расходу на производство, когда можно произвести изменение единицы измерения и заменить один артикул другим, например, перевести штуки в литры. Соответственно, расход на производство ингредиентов подконтрольной ветеринарной продукции надо производить без преобразования артикула, а сами артикулы должны иметь те единицы измерения, которые подходят для производства.
При расчете среднесуточной реализации (ССР) методом «с учетом коэффициентов изменения спроса» в прошлой версии в карточке товара сохранялась дата расчета ССР. В текущей версии в карточке товара будет сохраняться последняя дата расчетного периода, для которого был произведен расчет. При расчете ССР не будут учитываться документы, если их дата больше текущей.
В прошлой версии при расчете прогноза изменения ССР в дни периода заказа и поставки, когда ССР посчитана по методу «с учетом коэффициентов изменения спроса», анализ факторов, влияющих на ССР, включал в рассмотрение даты начала акций, если они были больше или равны дате расчета ССР. В текущей версии рассматриваются только даты строго больше последней даты периода расчета ССР, так как если акция начинается в последний день расчетного периода, значение ССР уже скорректировано с учетом влияния этой акции.
В алгоритмах автоматической генерации заказа принято считать, что остаток из карточки товара - это остаток на конец текущего дня, то есть дня расчета заказа. В тех случаях, когда генерация заказа выполняется в ночные часы после завершения рабочего дня или для больших периодов поставки, такое предположение дает корректный результат. В алгоритме расчета Fresh расчет ведется для небольших периодов времени и может производиться в утренние часы или в течение дня для заказа поставок на текущий или завтрашний день. В этом случае остаток из карточки товара может быть как ближе по значению к остатку на конец предыдущего дня, так и ближе к остатку на конец текущего дня.
В текущей версии в алгоритм генерации заказа по алгоритму Fresh внесено следующее изменение:
Остаток на конец текущего дня определяется, как остаток из карточки товара за вычетом влияния документов товародвижения текущего дня (кроме операции «Приход», влияние которой синхронизировано с изменением количества ожидаемых поставок по заказам) и с учетом прогноза убыли для текущего дня. То есть остаток корректируется на начало дня и текущий день включается в прогноз убыли.
Детальное описание см. «Алгоритм автоматической генерации заказа.doc».
Процедура экспорта из документа «Контракт с поставщиком» в документ «Прогноз изменения спроса» расширена экспортом перечня мест хранения из соглашений о поставках контракта с поставщиком в перечень мест изменения спроса. Экспортируются места хранения только из соглашений о поставках со статусом «Принят».
Кроме того, при экспорте даты начала и завершения контракта копируются в даты начала и конца изменения спроса. При этом если какая-либо дата из контракта меньше текущей даты или не установлена, то в документе «Прогноз изменения спроса» устанавливается текущая дата.
В прошлых версиях функция «Синхронизировать артикулы со спецификацией контракта» в разделе «Соглашения о поставках» могла быть вызвана в режиме редактирования документа. В текущей версии функция может быть применена к множеству документов одновременно:
Обрабатываются только документы со статусом «Черновик».
Создана функция LocationByAnyGLNKPP для обработки XML-файлов при импорте документов. Функция возвращает место хранения Супермаг+ по значению КПП или GLN места хранения, в зависимости от того, что встретится во входном файле. Если при анализе значения КПП обнаруживается несколько мест хранения, то функция выбирает то, у которого есть собственный контрагент с заданным значением ИНН.
Атрибуты функции:
inn ИНН собственного контрагента. Может быть не задан.
kpp КПП места хранения
locationGLNGLN (Global Location Number) места хранения
Функция создана в дополнение к функциям импорта GenerateDocUIDateAnyGLNINN и ClientByAnyGLNINN, чтобы можно было использовать одну и ту же XSD-схему для приема документов от разных контрагентов, которые могут заполнять либо один, либо другой комплект атрибутов для идентификации документа, контрагента и места хранения.
Изменения функционала в версии 1.055 сервис пак 2
ЕГАИС. Причины списания алкоголя.
Маркировка. Прием маркированных товаров на основании УПД без КИЗ.
Меркурий. Гашение ВСД ГИС «Меркурий»
Групповое гашение списка ВСД.
Установление связи номенклатуры с артикулом.
Документ «Отгрузка» ГИС «Меркурий». Информация о транспорте.
Прием перемещения ТСД. Функция обновления накладной перемещения по результатам приема.
Заказы поставщикам. Автоматическая генерация заказов. Частота заказа.
Коррекция заказов поставщикам. Только номенклатуры мест хранения.
Почтовый модуль. Фильтр «СуперМагМарко». Алгоритм формирования данных.
Товарный отчет (в закупочных ценах). Ставки НДС 5% и 7%.
К перечню причин списания алкоголя добавлена причина «Приготовление». Начиная с этой версии, перечень причин хранится в таблице SSEgaisTypeWriteOff.
Для маркируемых товаров с немаркируемым остатком допустимо, когда марки, нанесенные на товар, не зарегистрированы в ЦРПТ, то есть не являются выпущенными в оборот. Это бывает, когда производитель начал маркировать продукцию заранее, до вступления закона в силу. Такие товары могут быть произведены и начать движение, когда закон еще не вступил в силу, а продолжить движение, когда закон начал действовать. Для таких товаров в УПД на приход марки отсутствуют тогда, как на товаре они присутствуют и, одновременно, после вступления закона в силу, товар считается маркированным. В прошлых версиях прием такого товара со сканированием КИЗ в процессе приема приводил к отсылке поставщику акта несоответствия с требованием коррекции УПД.
В текущей версии при использовании процесса «Прием поставки ТСД», при приеме на основании УПД, функция создания приходной накладной придерживается следующего правила. Если в УПД на приход для артикула нет ни одного КИЗ и нет ОСУ кода, а в журнале приема КИЗ имеются, то для такого артикула КИЗ из журнала приема в приходную накладную не переносятся. В результате спецификации накладной и УПД получают одинаковый состав, и прием проходит без ошибки расхождения состава накладной и УПД.
При приеме с созданием приходной накладной на основании заказа и УПД на приход, спецификация накладной может заполняться сканированием КИЗ. В момент сканирования КИЗ никаких проверок артикула по приведенному выше правилу не делается и КИЗ помещаются в спецификацию документа. Но при смене статуса приходной накладной с «Черновик» на «Принят на складе» выполняется проверка, что в основании накладной есть УПД и в УПД есть маркируемые артикулы с немаркируемым остатком, для которых нет КИЗ, а в накладной КИЗ есть. Если такое случилось, то показывается диалог с предупреждением:
В предыдущих версиях была реализована функция раздела «Сопоставить и погасить», которая позволяет для перечня выбранных ВСД выполнить поиск подходящих накладных, сопоставить ВСД с накладными и выполнить процедуру гашения. Кроме этого уже сопоставленные ВСД можно погасить кнопкой «Погасить», но в этом случае можно было погасить только один ВСД. В текущей версии этой кнопкой можно обработать список отмеченных ВСД. При выполнении действия делается проверка допустимости гашения ВСД. В дополнительных диалогах показывается список тех ВСД, которые не могут быть погашены с указанием причины, например:
В предыдущих версиях в разделе «Гашение ВСД ГИС «Меркурий»» была реализована процедура установления связи между номенклатурой ГИС «Меркурий» и артикулом Торговой Системы. Действие выполняется нажатием кнопки «Номенклатура» для выбранного ВСД и дальнейшим выбором артикула в диалоге «Номенклатура продукции». При нажатии кнопки «Сохранить» информация сохранялась в базе данных, но для того, чтобы она появилась в строках таблицы ВСД, необходимо было нажать кнопку «Перечитать». В текущей версии перечитывание таблицы происходит автоматически.
В предыдущих версиях при создании документа «Отгрузка» ГИС «Меркурий» на основании накладной информация о транспорте, необходимая для документа, импортировалась из транспортного раздела накладной. Если в накладной такой информации не было, отослать данные в ГИС Меркурий и оформить транспортный ВСД становилось невозможно.
В текущей версии в мастер создания документа «Отгрузка» добавлена страница «Транспорт»:
Информация о транспорте загружается из транспортного раздела накладной и может быть отредактирована или заполнена, если в накладной ее не было.
Процесс приема перемещения после завершения приемки и получения журнала подсчета проставляет в накладную на перемещение фактически принятое количество. В прошлых версиях в процедуре проставления фактического количества была сделана специальная обработка случая, когда в журнале подсчета артикул из накладной отсутствовал. То есть, когда перемещаемый товар при подсчете полностью пропущен. В этом случае фактическое количество в накладной на перемещение не менялось. Предполагалось, что это позволит выполнять прием перемещения несколькими бригадами, которые принимают разные части перемещения. Как выяснилось, это вступило в противоречие с текущими особенностями формирования накладной на перемещение, когда фактическое количество устанавливается равным количеству на этапе формирования документа, в предположении, что количество будет скорректировано, при необходимости, в процессе приемки.
В текущей версии возвращено прежнее поведение, когда при отсутствии артикула в журнале приема перемещения фактическое количество в накладной на перемещение обнуляется.
При автоматической генерации заказа для каждого артикула определяется действующее соглашение о поставках, из которого извлекается параметр «частота заказа». В дальнейшем, алгоритм ищет последний заказ поставщику, в котором имеется какой-либо артикул из соглашения о поставке, дата найденного заказа сравнивается с текущей датой, а полученный интервал с частотой заказа. Частота заказа используется для запрета формирования заказа чаще указанного интервала.
В тех случаях, когда поставщик ставил условие, что разные группы товаров будут им поставляться с разной частотой, описанный выше алгоритм не позволял реализовать заказ разных товаров с разной частотой заказа.
В текущей версии при поиске последнего заказа для анализа отбираются только те заказы, у которых в основании имеется текущее соглашение о поставках.
В разделе «Коррекция заказов поставщикам» имеется цветовая индикация строк с артикулами, которые не входят в номенклатуру места хранения поставки. У этих строк малиновый фон. Такие товары попадают в таблицу из соглашений о поставки в тех случаях, когда их либо специально добавили для заказа нового товара, для которого еще не принято решение о регулярных поставках, либо по ошибке, когда товар уже исключен из номенклатуры, но не исключен из контракта / соглашения о поставке.
В текущей версии в раздел добавлена кнопка «Только номенклатуры мест хранения».
Функция позволяет удалить из списка товары, не входящие в номенклатуру места хранения. При нажатии кнопки показывается диалог для выбора способа определения списка строк, которые будут удалены.
При сохранении результатов процесса в документы «Заказ поставщику», артикулы, отсутствующие в спецификации коррекции, из заказов удаляются.
Пока процесс не завершен, восстановить удаленные строки можно, нажав кнопку «Перечитать».
\\
Структура данных для СМ Марко выглядит следующим образом:
\\
<span style="color: #1d1c1d">{</span>
<span style="color: #1d1c1d"><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f9c1478a-08ca-40b9-a08d-9c3a5fedb9e2"><ac:plain-text-body><
Изменения функционала в версии 1.055 сервис пак 3
Служба сервера приложений. Принтер для печати документов и ценников.
Расходные накладные. Проставить основания. Генерация возвратов. Генерация списаний.
Формирование пакета заказов на базе контракта
Расчёт среднесуточной реализации.
Средняя реализация без акций.
Новые поля спецификации процесса.
При печати документов и ценников через службу сервера приложений (например, из ТСД) принтер определялся данными справочника «Принтеры», а если в справочнике принтер не был указан, то использовался принтер по умолчанию данного ПК. В последнем случае для корректной работы требуется запускать службу сервера приложений от имени локального пользователя. Также ранее не использовалась настройка администратор сервера приложений "Принтер печати документов и ценников с ТСД по умолчанию".
Теперь, если принтер не задан явно в справочнике «Принтеры», будет взят принтер из настроек Администратор сервера приложений – Настройка общих параметров - Принтер по умолчанию для печати из службы документов и ценников.
В указанных функциях реализовано копирование из исходной расходной накладной причин возврата в создаваемые документы.
Теперь расчёт функцией «Среднесуточная реализация» не будет использовать системные параметры расчёта (Административный модуль – База данных – Конфигурация – Среднесуточная реализация). В диалог функции добавлена кнопка «Прочие», которая позволяет задать собственные параметры расчёта:
В меню кнопки «Среднесуточная реализация» добавлена функция «Средняя реализация без акций», которая работает аналогично существующей функции «Средняя реализация для акций», но ищет реализацию за последние N дней, в которые НЕ было действующих документов изменения спроса. Результаты работы функции помещаются в новые поля «Ср. реал-ция без акций», «Реал-ция без акций».
Добавлены новые поля «Мин. дней» (Карточки складского учета, вкладка «Заказ»), «Макс. дней» (Карточки складского учета, вкладка «Заказ»), «Реал-ция для акций» (заполняется функцией «Средняя реализация для акций»).
Изменения функционала в версии 1.055 сервис пак 4
Карточка складского учета. История печати ценников. Цена на момент печати ценника.
Печать ценников только с «новой» ценой.
Акты переоценки.
Печать ценников для нескольких актов переоценки.
Значение по умолчанию вида цены при создании акта.
Кассовый модуль. Протокол УКМ4 XML. Выгрузка признака аукционного товара.
В разделе «Карточки складского учета» добавлена закладка «Напечатанные ценники» для показа журнала напечатанных ценников. В журнал добавлено поле «Цена», в котором, начиная с текущей версии, фиксируется цена, для которой печатается ценник:
Под ценой понимается текущая цена вида цены или цена из документа или иного источника цен, то есть цена, для которой печатается ценник, независимо от того, что в действительности печатается в ценнике (например, цена за вычетом скидки, цена по дисконтной карте и т.д.).
В диалог печати ценников в разделе карточек складского учета и в разделе актов переоценки добавлена опция «только артикулы с ценой, изменённой после успешной печати ценника».
Если флаг установлен, то ценники для артикулов, у которых не изменилась цена для печати, напечатаны не будут. В этом случае показывается предупреждение следующего вида:
В предыдущих версиях в разделе актов переоценки можно было напечатать ценники для одного выбранного документа. В текущей версии можно напечатать ценники для нескольких документов.
Печать производится по каждому документу отдельно, с выдачей всех предупреждений и подтверждения успешной печати в конце печати ценников. При печати из списка документов опция «количество копий из накладной-основания» недоступна. Эта опция используется, когда необходимо напечатать ценник для каждого экземпляра товара, например, для одежды, и доступна только при печати из открытого документа.
В текущей версии реализовано сохранение и последующее восстановление вида цены в мастере создания документа:
При выгрузке данных в кассу по протоколу УКМ4 XML, при формировании файла storePrices с ценами артикулов, в файле теперь выгружается тэг < is_promo_price >, с признаком того, является ли цена артикула маркетинговой.
Например:
<?xml version="1.0" encoding="utf-8"?>
<storePrices fullness="I" storeId="4">
<version>1.1</version>
<item article="Ц005627">
<price>
<value>95</value>
<minprice>0</minprice>
< is_promo_price >1< /is_promo_price >
</price>
</item>
</storePrices>
0 - не маркетинговая цена, 1 - маркетинговая. Тэг выгружается всегда.
Изменения функционала в версии 1.055
Маркировка. Функция «Списание маркированной продукции».
Меркурий.
Гашение ВСД ГИС «Меркурий». Функция «Запросить данные из ГИС «Меркурий»».
Остатки ГИС «Меркурий».
Документ «Отгрузка» ГИС «Меркурий».
Раздел «Прогноз изменения спроса».
Маркетинговая акция. Изменение коэффициентов К1 и К2 в документе со статусом «Принята» и «Исполняется».
Расчет среднесуточной реализации.
Влияние документов изменения спроса на алгоритм расчета.
Новый вариант учета документов изменения спроса «С учетом коэффициентов изменения спроса».
Автоматическая генерация заказа. Прогноз среднесуточной реализации.
Анализ реализации.
Документы. Импорт спецификации из текстового файла.
Коррекция заказов поставщику. Поле «В номенклатуре». Цветовая индикация.
Классификатор номенклатур товаров. Функция «Упорядочить положение групп».
Печать ценников на разных принтерах.
Печать из процессов ТСД. Печать для операции «Списание брака».
Почтовый объект «Статистика по текущим остаткам для артикула».
В документах «Расходная накладная», «Приходная накладная» и «Требования на отбор» имеется функция «Списание маркированной продукции» для создания файлов со списком КИЗ в формате, позволяющем использовать его для списания КИЗ на сайте ЦРПТ.
В текущей версии в работу функции внесено следующее изменение: для расходной накладной в тэг <trade_participant_inn> теперь помещается ИНН собственного контрагента, а не ИНН клиента, как это было в прошлых версиях. В других документах поведение функции осталось прежним.
Содержание тэга <cost> (цена) формируется в соответствии с рекомендацией ЦРПТ: «Для того, чтобы цена воспринималась правильно, необходимо рубли отделять от копеек точкой.
В противном случае, система честного знака считает, что все переданное число это копейки.»
В разделе «Гашение ВСД ГИС «Меркурий»» изменено поведение функции «Запросить данные из ГИС «Меркурий»» В прошлых версиях функция возвращала все входящие ветеринарные сопроводительные документы (ВСД), относящиеся к площадке и хозяйствующему субъекту. В том числе ВСД, которые были исходящими из площадки, но входящими в другую площадку хозяйствующего субъекта.
В текущей версии в таблице отображаются только входящие ВСД площадки, то есть ВСД для поступлений товара в указанную площадку хозяйствующего субъекта.
Дополнительно, в таблице ВСД теперь выводится информация о площадке получателя, а в детальной информации ВСД показывается артикул, связанный с номенклатурой ГИС Меркурий:
В таблицу остатков ГИС «Меркурий» добавлены колонки с артикулом и его названием, соответствующие номенклатуре ГИС «Меркурий»:
По двойному клику на ячейке с артикулом или названием выполняется переход к разделу карточек.
Создан новый раздел «Документ «Отгрузка» ГИС «Меркурий»» для формирования и отсылки в ГИС «Меркурий» запроса на создание ВСД. Запрос создается на основании расходных накладных и накладных на перемещение. Функционально раздел повторяет раздел «Документ «Перевозка» ГИС «Меркурий»», но использует протокол прямого обращения к ГИС «Меркурий».
Примечание: Прежний раздел «Документ «Перевозка» ГИС «Меркурий»» ведет обмен с провайдером с использованием протокола «Меркурий – обмен данными».
Раздел «Документ «Отгрузка» ГИС «Меркурий»» выполняет запрос на создание ВСД через сервер обмена данными с использованием формата «Меркурий – Вертис API». Если сервер не настроен или остановлен, данные не будут отосланы.
Для корректного оформления ВСД в накладной должен быть заполнен транспортный раздел: марка и номер госрегистрации транспортного средства.
При выборе накладной для формирования ВСД необходимо указать только один артикул спецификации, для которого будет создаваться ВСД:
Если в накладной один артикул, выбор артикула присходит автоматически:
Если месту хранения или контрагенту соответствует несколько площадок, прощадку необходимо указать вручную в диалоге кнопки «Отправитель» или «Получатель». Если для каждого адреса имеется единственная площадка, они будут определены автоматически:
На следующем шаге необходимо указать партию товара, которая будет списана с остатков ГИС «Меркурий», если таких партий несколько:
Объем партии может быть меньше отгружаемого количества, тогда для накладной надо будет создать еще один ВСД. В этом случае предлагаемое для списания количество продукции будет уменьшено на уже распределенное количество.
На последней странице мастера формирования запроса на создание ВСД «Вет. заключение» используются данные из справочника Меркурий «Назначение груза». Справочник можно заполнить запросом к ГИС «Меркурий». После этого рекомендуется удалить из справочника все лишние назначения, оставив только те, которые используются для работы:
После успешного создания документа его можно отослать в ГИС «Меркурий»:
Создан новый раздел «Прогноз изменения спроса». Для доступа к разделу надо иметь право «Док.: прогноз изменения спроса».
Документ «Прогноз изменения спроса» предназначен для описания периода времени, в начале и в конце которого ожидается изменение спроса на товары в заданных местах хранения из-за влияния какого-либо фактора, например, праздника, сезонного фактора, акции поставщика и т.д. Изменение спроса описывается как ступенчатое изменение с помощью коэффициентов К1 - во сколько раз изменится спрос в дату начала периода документа по сравнению с предшествующими днями и К2 - во сколько раз изменится спрос после даты завершения периода по отношению к дням, предшествующим периоду действия документа.
Коэффициенты ожидаемого изменения спроса устанавливаются для каждого артикула отдельно.
Документ имеет три статуса "Заблокирован", "Черновик", "Принят". Документы со статусом "Принят", наравне с маркетинговыми акциями, оказывают влияние на расчет среднесуточной реализации и алгоритмы генерации заказа.
Для документа «Маркетинговая акция» разрешено редактировать коэффициенты изменения спроса К1 и К2 при редактировании документа со статусом «Принята» и «Исполняется». Для выполнения действия необходимо иметь право «Редактирование принятой акции» и «Редактирование исполняющейся акции», соответственно.
В административном модуле в разделе «База данных», на закладке «Конфигурация» в группе данных «Среднесуточная реализация» название опции «Влияние Маркетинговых акций на расчет» изменено на «Влияние документов изменения спроса на расчет»:
Изменение названия опции связано с тем, что в алгоритмы расчета добавлен анализ документов «Прогноз изменения спроса» со статусом «Принят» наравне с документами «Маркетинговая акция» со статусом «Исполняется» или «Завершена».
В административном модуле в разделе «База данных», на закладке «Конфигурация» в группу данных «Среднесуточная реализация» добавлена опция «Влияние документов изменения спроса на расчет: с учетом коэффициентов изменения спроса». Новая опция позволяет выполнить расчет средней реализации не исключая дни маркетинговых акций (периодов изменения спроса) или дней без маркетинговых акций, как это делается в других алгоритма учета документов изменения спроса, но с коррекцией реализации каждого дня для учета влияния факторов изменения спроса на товары. Это схоже с понятием расчета инфляции с очисткой от влияния сезонных факторов.
При выборе опции расчет среднесуточной реализации (ССР) происходит по следующим правилам:
В диапазоне расчета ССР учитываются все дни периода расчета, кроме исключенных дней. Условия исключения дней задаются в опциях расчета, например, условие исключения дней, когда остаток товара будет меньше или равен нулю.
В диапазоне расчета определяются дни начала или окончания действия документов «Прогноз изменения спроса» и «Маркетинговая акция». На каждый такой день определяется коэффициент изменения спроса (определяются как К1 для дня начала действия документа и К2/К1 для дня завершения действия документа). Для каждого дня периода считается реализация, и полученное значение реализации умножается на коэффициент, соответствующий накопительному влиянию коэффициентов изменения спроса.
Например, для случая одной акции внутри периода расчета:
Дата начала К1 К2 Дата конца расчета
Диапазон расчета рассматривается от его завершения к началу. От даты конца расчета до даты завершения действия документа (дата К2) дневная реализация не корректируется. От даты К2 до даты К1 реализация умножается на К2/К1, от даты К1-1 день и до даты начала диапазона расчета реализация умножается на (К2/К1)*(К1).
Далее среднесуточная реализация считается, используя скорректированные значения дневной реализации, тем методом, который выбран в настройках расчета.
Примечание: коэффициент изменения спроса К1 означает изменение спроса для дней действия документа по отношению к предыдущим дням, то есть дням до начала действия факторов, меняющих спрос. Коэффициент К2 означает изменение спроса для дней после окончания действия документа по отношению к дням до начала действия документа, то есть коэффициент К2 показывает, как изменится спрос по отношению к «нормальному» спросу после того, как завершится действие факторов, меняющих спрос. Если требуется определить изменение спроса для дней после окончания действия документа по отношению к днями действия документа, то берется отношение К2/К1.
Выбор опции «С учетом коэффициентов изменения спроса» влияет не только на алгоритм расчета ССР, но и на алгоритм расчета предложения заказа при автоматической генерации заказа. Для нужд алгоритмов расчета заказа при сохранении рассчитанной ССР в параметры карточки (SMStockLevels) там же теперь сохраняются дата последнего дня расчета (SaleRateTime) и вид алгоритма расчета (SaleRateMarketingType). Если ССР была рассчитана «С учетом коэффициентов изменения спроса», то при расчете заказа флаг «ССР посчитана в период изменения спроса» не используется, а используется дата последнего дня расчета ССР. Это связано с тем, что прогноз ССР определяется для каждого будущего дня от дня расчета ССР с учетом коэффициентов прогноза изменения спроса будущих документов (см. ниже).
Метод может использоваться, если коэффициенты изменения спроса в документах соответствуют реальности. Если коэффициенты задаются произвольным образом, то это приведет к искажению прогноза ССР.
При расчете ССР методами «Уменьшать диапазон расчета при наличии акций» и «Включать или исключать дни акций» происходит сокращение диапазона расчета и в тех случаях, когда такое сокращение приводит к слишком малому размеру выборки (например, один или два дня), предпочтительнее использовать вариант расчета «С учетом коэффициентов изменения спроса». Метод «С учетом коэффициентов изменения спроса» не приводит к сокращению количества дней выборки для расчета. Это позволяет корректнее учитывать текущее состояние спроса с учетом всех возможных влияний, как маркетинговых акций, так и прочих факторов (праздников, сезонности, акций поставщиков и прочее).
В алгоритме автоматической генерации заказа для расчета будущей убыли товара используется значение среднесуточной реализации (ССР). Убыль рассчитается в диапазоне от текущего дня (дня расчета заказа) до дня второй поставки. Если ССР посчитана с опцией «Акции не влияют на расчет», то для всех алгоритмов расчета заказа, для каждого дня периода заказа прогноз реализации считается равным ССР.
Если ССР посчитана с опцией «Уменьшать диапазон расчета при наличии акции» или «Включать или исключать дни акции», в прошлых версиях была реализована коррекция прогноза реализации. Для всех алгоритмов автозаказа, кроме алгоритма «Fresh», прогноз реализации зависел от того, установлен ли флаг «ССР посчитана в период изменения спроса» для рассчитанного значения ССР, и попадал ли день начала периода расчета заказа в период действия документа изменения спроса. В текущей версии при задании этих опций прогноз реализации дополнительно учитывает документ «Прогноз реализации спроса» и выглядит следующим образом:
